Customer Dashboard

The customer dashboard at app.runspectral.com (per ADR-052 D2) is the customer-facing surface where a customer org sees the state of its deployed decision modules. The dashboard runs as a TanStack Start app (per ADR-050) and reads from api’s surviving routes (per ADR-077 D6, aligned to the org/domain naming per ADR-086).

Scope — a read-only inspection surface + minimal interaction primitives

The dashboard is primarily a read-only inspection surface. Customers consume binding decisions via POST /decide (or the MCP equivalent per ADR-088); the dashboard is the structured, trust-first view into what’s running, what decisions have been made, and what each decision was grounded in. It is the read-mostly mirror of the Operations app — the same visual family, the opposite density.

Information architecture

Sign-in lands on an all-domains Portfolio: the cross-domain landing shown when no domain is selected, with a card per member domain that enters that domain. Entering a domain reveals four section tabs:

1. Overview — the per-domain trust-first landing. Headline trust metrics (decisions made, active ruleset version, rules in force), an attention banner (held + blocked → review), a “How decisions resolved” four-segment outcome bar with per-state counts and percentages, and a recent-decisions feed that deep-links into each decision.
2. Decisions — a trust-first log of every decision the domain’s agents received, with a deep-dive into any one of them. Detailed below.
3. Rules — the active ruleset, read-only. The active version plus where its rules came from, then the rules themselves as a plain-language list — each rule a statement, an importance, and a source citation where one is projected. Editing happens on the operator surface; this view never mutates.
4. Trust — the deployment-scoped operational record. Detailed below.

The version-scoped Ruleset Card is reached per version from the Trust version-history timeline (each entry opens that version’s card); it is a per-version artifact, not a live tab. Detailed below.

There is no Actions tab — the action registry lives on the Ruleset Card, scoped to the version that exposes it.

Trust — the System Card

The Trust tab is the System Card: the deployment-scoped operational record per ADR-082 D3, scoped to (org_id, domain_id) and live-refreshing. It establishes the credibility of the operation:

• The deterministic-decision guarantee — no language model is in the decision path; the same inputs always return the same outcome.
• How a decision is made — the four-step pipeline from the agent’s call through deterministic rule evaluation to the authoritative decision and the recorded log entry.
• The windowed status distribution — the four-state outcome counts and percentages over a selectable window (last 7 days by default, or since inception), with a per-action breakdown (each action’s total and four-state counts, busiest first).
• Decision latency — p50/p95/p99 over the same window.
• The version-history timeline — which version was deployed when; each entry links to that version’s Ruleset Card.
• Release notes for the active version.
• A System Card export — the offline artifact, the operational record with an embedded Ruleset Card snapshot, self-contained for rendering without a live connection.

Methodology, provenance composition, and gate composition are not on Trust — they live on the Ruleset Card. ADR-082 rejected merging the two cards: Trust carries the credibility of the operation; the Ruleset Card carries the credibility of the standard.

Ruleset Card

The Ruleset Card is the version-scoped methodology disclosure per ADR-082 D2 — the per-version, immutable record of the standard governing this domain. It is version-selectable (defaults to the active version; any past version is reachable from the Trust version-history timeline) and read-only. Worlds-internal authoring deliberation is filtered at the reader, so the customer sees a curated card. Its content:

• Authority basis — what the ruleset is grounded in.
• Provenance composition — where the rules come from, summarized across the source families (authoritative, curated, distilled, researched, observed). The underlying two-dimensional provenance on every rule is reconciled per ADR-100.
• Build configuration — the build and configuration provenance pinned when the version was deployed.
• Action registry — the decision actions this version exposes, each routing to a deployed module identified by content hash per ADR-080 D1.
• Gates passed — the conformity checks (review checks) and implementation-readiness verification attested when the version was approved.
• Evolution history — how this version changed from the prior one.

The card summarizes the corpus rather than re-listing every rule, and leads to Rules for the full active list.

Decisions — the log and the deep-dive

The Decisions tab is the trust-first record of every decision the domain’s agents received. It carries three surfaces:

• The log. A searchable, filterable feed: a search field over the action, outcome filter chips (proceed / hold / blocked / no action needed), and a table with a status marker that reads by shape, label, and color — never color alone. Each row names the action, the calling agent, the outcome, the ruleset version, and when, and deep-links into the decision.
• The deep-dive. The trust payload for a single decision: an outcome banner; “what the agent was told to do” (the plain-language instruction); an outcome-specific callout (“Gather before proceeding” for a hold, “Why it was stopped” for a blocked); the inputs considered, with any flagged blocker highlighted; “which rules applied — and why” (each rule a plain statement, the reason it did or did not drive the outcome, its importance, and a source citation where one is projected — the rule that drove the outcome is labeled the Determining rule); the feedback affordances; and a collapsible technical-detail block (the decision and action identifiers, aggregation mode, and reproducibility). The standing determinism claim (“no language model in the decision path”) lives on the System Card (Trust), not per decision. The banner names the calling agent that requested the decision.
• My flagged decisions. The customer’s own flagged decisions with their feedback lifecycle — Submitted, Under review, Resolved — each row deep-linking back into the decision.

Customer-operator feedback surfaces

Per ADR-090 D5, customer-operator feedback against historical decisions is the primary ongoing-improvement driver for the world model. The dashboard exposes the customer-side surfaces for that feedback flow, layered atop the inspection surface.

Two primitives sit on the decision deep-dive:

• Request a review. From the deep-dive, a customer flags the decision for operator attention with a short structured note. The flag rides the override-pattern aggregation pipeline per Evolution Loop — Phase 2 platform substrate; the world model’s flagged-decision patterns surface to the World Agent as input to rule-change proposals. The customer receives confirmation that the review was submitted, and the flag appears in the “my flagged decisions” lifecycle view.
• Mark noteworthy. A lighter-touch annotation that tags a decision for the customer’s own future reference and surfaces it in operator telemetry as a customer-perceived signal. Distinct from a review request — noteworthy marks don’t require operator action.

Richer feedback shapes from ADR-090 D5 — structured rule-level commentary, structured outcome reports — are additional surfaces atop the same override-pattern substrate.

Feedback surfaces are scoped per (org_id, domain_id) per ADR-086 D6 + ADR-087 (customer auth → token’s org_id + domain_id determines what the customer can flag).

The dashboard is not a workflow tool. Customers can flag and annotate; they do not approve modules (operator concern per ADR-080 D3), edit rules (worlds-side authoring concern per ADR-090 D3), or override decisions (decisions are binding per ADR-077). Customer affordances grow in subsequent releases as patterns of customer-initiated work emerge.

Post-release — World Agent exposure for explanations

The “explain this decision in my world” affordance — chat surface keyed to the current customer’s (org_id, domain_id) world, riding through the World Agent per ADR-081 D2 + D5 — lands just after release as the first post-v0 dashboard expansion.

The architectural commitments are already in place:

• World Agent owns customer-facing agent surfaces (per ADR-081 D2).
• Session boundary is per-world (per ADR-081 D2) — a customer’s chat session is bounded to one (org_id, domain_id) world, naturally aligned with the dashboard’s current-domain context.
• Auth scope filtering determines which tools the World Agent exposes to the customer-scope session vs operator-scope session (per ADR-081 D3).
• Conversation persistence rides ADR-043’s substrate (per ADR-078’s note that conversation persistence carries forward as substrate).

What lands post-release:

• Chat affordance in the dashboard, keyed to the customer’s current (org_id, domain_id) context.
• World Agent tool subset for customer-scope sessions (read-only over the customer’s own world: explain rule traces, walk through decision metadata, surface methodology disclosure from the Ruleset Card in natural language).
• Audit-chain capture of customer-initiated World Agent sessions per ADR-076 D3.
• Conversation persistence per ADR-043 substrate.

The post-release timing reflects v0’s “ship the inspection surface; layer agent affordances on top” approach. Customers get the deterministic surface first (the dashboard’s structured views are the audit-grade trust foundation); the agent layer is the legibility convenience.

What the dashboard is not

• Not an authoring surface. Operators author rules and approve modules through their own UI (per ADR-080 D3 + ADR-081 D4); customers do not edit world models from the dashboard.
• Not a decision interface. Customers consume decisions via the API (per ADR-077). The dashboard surfaces what has happened; it does not initiate decisions.
• Not a customer support channel. The “request a review” primitive routes structured signals; broader support workflows (chat with humans, file tickets) are out of scope for the dashboard.
• Not a billing surface. Cost observation rides the same (org_id, domain_id) segmentation as rate limits per ADR-084 D2; whether the customer-facing billing/usage view lives in the dashboard or a separate surface is a commercial-design decision out of scope here.

References

• ADR-043 — conversation persistence substrate (post-release chat affordance rides this)
• ADR-052 — Cloudflare edge (D2 establishes the proxied app.runspectral.com hostname)
• ADR-050 — TanStack Start as the frontend framework
• ADR-076 — platform pillar (D3 audit chain captures customer-initiated agent sessions)
• ADR-077 — decision API surface (the dashboard reads alongside the API; D6 surviving routes)
• ADR-078 — Spectral Agent retirement (conversation persistence carries forward as substrate)
• ADR-080 — module integrity (D1 content hash on the Ruleset Card action registry; D3 operator approval explains why customers cannot)
• ADR-081 — World Agent ownership of customer-facing agent surfaces + session boundary
• ADR-082 — the two cards: the version-scoped Ruleset Card (methodology) and the deployment-scoped System Card surfaced on Trust (operational record)
• ADR-084 — noisy-neighbor handling (D2 per-tenant observability the dashboard surfaces)
• ADR-086 — org/domain naming the dashboard uses (D6 tenancy enforcement at domain level)
• ADR-087 — auth shape determining what customers see
• ADR-088 — MCP surface (alternative consumption path)
• ADR-090 — World Agent positioning + Phase 2 customer-operator feedback (D5) the dashboard’s feedback surfaces feed
• ADR-100 — rule-provenance model the Ruleset Card’s provenance composition summarizes
• Design references — docs/design/ (operations + customer dashboard design materials)