Skip to main content

Frontend Visualization

The DPO2U frontend exists to make compliance operations legible to humans. Its job is not to invent truth; its job is to reveal it.

What the frontend should show​

The frontend is strongest when it makes one workflow obvious:

  1. compliance input enters the system
  2. evidence is generated or retrieved
  3. an attestation state is produced
  4. the resulting proof or status becomes reviewable

That is more valuable than a generic dashboard full of animated widgets.

The three display modes​

The frontend should communicate its operating mode explicitly.

Live Mode​

Use Live Mode when the screen is backed by the canonical runtime surface and the data currently displayed came from a real backend path.

Examples:

  • live MCP health
  • live OpenAPI-discovered capabilities
  • real status/results returned by the active backend

Degraded Mode​

Use Degraded Mode when only part of the backend is reachable or when some fields are unavailable.

In degraded mode, the UI should:

  • show only what actually resolved
  • leave missing fields empty or unavailable
  • avoid synthetic counts that look operational
  • explain what is missing

Demo Mode​

Use Demo Mode when the screen exists to explain workflow shape rather than report live system state.

Demo mode is acceptable when it is clearly labeled. It becomes harmful when it masquerades as production telemetry.

Current documentation stance​

During the June 2026 VPS reconciliation work, DPO2U removed several hardcoded claims from the frontend and started making mode signaling explicit.

That work reflects a simple principle:

if the backend did not answer, the UI should not fabricate confidence.

Hero workflow over dashboard theater​

The most convincing DPO2U screen is not a crowded control room. It is a workflow that answers, in order:

  • what was checked?
  • what evidence was used?
  • what attestation or score was produced?
  • what can another party verify from it?

A strong product-facing frontend should therefore prioritize:

PrioritySurface
P0compliance request / intake
P0evidence and schema review
P0attestation outcome
P1verification / export surface
P2internal operational telemetry

What the frontend is not​

The frontend is not:

  • the canonical source of tool inventory
  • proof that a backend capability exists
  • a substitute for MCP/OpenAPI verification

Those roles belong to the runtime surfaces.

Product rule​

When a customer asks, "what does the solution actually do in practice?", the frontend should answer with a visible path from compliance question to verifiable result.

That is the core presentation standard for DPO2U.