ADR-082: System Card and World Model Card

Context

ADR-015 established two card shapes (WorldModelCard produced by spectral.worlds; AgentPerformanceCard produced by spectral.platform) with two mandatory fields (authority, authority_version) anchoring each card’s claims to an external versioned standard. Multi-audience rendering and the metadata envelope were left to each context’s projection layer. The card Protocol placement follows ADR-065’s event-driven projection between contexts.

Under the in-band decision-support shift, the card model changes substantively:

• AgentPerformanceCard retires entirely. Its subject — a customer’s agent’s performance under scanning — no longer exists; there is no scan, no evaluation framework attribution, no holdout outcome to document.
• WorldModelCard continues to exist but its content shifts. The world model is now an executable artifact, not a separate standard; the card documents the world-model version (its rule corpus with dual provenance, the code-generation methodology, the implementation-readiness gate composition, the configuration snapshot) rather than the world model as a Spectral-built standard.
• A new System Card content shape emerges: deployment-scoped (per customer’s deployed decision-module instance), documenting which world-model version is live for (org, domain), deployment-specific methodology disclosure, and the operational record. No conformance score; no recommendations — the System Card is documentation, not a Spectral verdict on the customer.
• The authority + authority_version convention is preserved as the structural anchor for both card shapes.

The System Card shape this ADR pins is concrete: header (org/domain + active version + enshrined date), operational record (total decisions + p50/p95/p99 latency + four-state status distribution), methodology disclosure (code generation, test coverage, implementation-readiness gate, conformity gate), version history (active + retired). It is now realized as the customer dashboard’s Trust surface (docs/design/annotated-screens/customer-6-trust.png), where the redesign distributes the operational stats across the Overview and Decisions surfaces. This ADR pins that shape architecturally.

Decision

D1 — AgentPerformanceCard retires

AgentPerformanceCard retires entirely. Its subject (a customer’s agent’s scan / evaluation / optimization history) is no longer in scope under the shift. No replacement card documents customer-agent performance because Spectral no longer scans customer agents.

Linear scope changes in Phase 4 follow: code paths that constructed AgentPerformanceCard (or were planned to — most live in cancelled epics already retired in 3a) become candidates for removal in Phase 4 build-plan work.

D2 — WorldModelCard is version-scoped; content shifts

WorldModelCard is the authoritative documentation of a specific world-model version, produced and owned by spectral.worlds. One card per (org, domain, version) triple.

Card content under the shift:

• Identity — (org, domain, version); enshrinement date; world-agent version that authored.
• Rules — the rule corpus enshrined at this version, with each rule’s tier (T1/T2/T3), assertion provenance (Authoritative / Curated / Distilled / Researched / Observed per the carry-forward taxonomy), and code provenance (which world-agent version generated the predicate, which eval-suite version validated, which generation run identifier).
• Configuration snapshot — the configuration block values stable at this version (business hours, holidays, thresholds, windows, etc.).
• Context schema — the version’s context-attribute set with sources (supplied / system_generated / computed), types, and constraints/derivation notes.
• Action registry — the actions enshrined at this version with their rules and aggregation modes.
• Methodology disclosure — code-generation methodology, multi-axis eval methodology, conformity gate composition, implementation-readiness gate composition.
• Authority anchor — authority field references the world model itself (spectral.worlds); authority_version is the version number. Convention preserved from ADR-015.

WorldModelCard is potentially shared across customers running the same (org, domain, version) baseline if that pattern emerges; the card describes the version, not any specific deployment.

Display name. The WorldModelCard is shown to customers and operators as the “Ruleset Card” — on both portals and in the Codex. “Ruleset Card” pairs with “System Card” and avoids “Model,” which reads as an ML model and undercuts the no-language-model positioning the card itself documents. The worlds authoring agent (the worlds-context WorldAgent, ADR-081) surfaces to customers and operators as the “Assistant” (“Ruleset Assistant” in full, “Assistant” in context). The masked-identifier kind label for the ruleset/world id is RULESET ·xxxx. “World” remains internal-only vocabulary: the producer type WorldModelCard, the WorldAgent, the worlds context, the /worlds/... routes, the world_model_* schema, the world_id session var, and the producer-typed publication event are unchanged — this governs display copy and the identifier kind label only.

D3 — System Card is deployment-scoped; content is operational record + methodology

The System Card is the deployment-scoped audit artifact for a customer’s deployed decision-module instance, produced and owned by spectral.platform. One card per (org, domain) deployment (the active version pointer determines which world-model version the card references at any given time; the card’s content includes prior-version history for decisions made under retired versions).

Card content under the shift:

• Identity — (org, domain); the active world-model version and its enshrinement date.
• Operational record — over the documented window (e.g., last 7 days at v0 per the mockup): total decisions, p50/p95/p99 latency, four-state status distribution (GREEN / GREEN-SKIP / YELLOW / RED counts and percentages).
• Methodology disclosure — for the active module instance: code-generation methodology (world-agent version, AST validation, banned-constructs enforcement); test-coverage methodology (per-rule inline tests, multi-axis eval); implementation-readiness gate composition; conformity gate composition. Per the mockup, the methodology block names each gate’s substantive content (e.g., “Inline tests per rule · 100% rule coverage · multi-axis eval”).
• Version history — the prior versions retired for this (org, domain) deployment, with retirement dates and reason summaries. Prior versions remain authoritative for decisions made under them (audit-integrity property carried forward from ADR-026 restatement discipline).
• Authority anchor — authority field references the deployed decision module’s identity (the module’s content hash per ADR-080 D1); authority_version is the world-model version pinned to the module. Convention preserved from ADR-015.
• What’s not on the card — no conformance score (the card documents; it does not grade); no recommendations (the card is an operational record, not a Spectral verdict on the customer’s setup); no Spectral assertions about the quality of the customer’s overall workflow (Spectral’s claim is about the binding contract per decision, not about workflow quality).

System Card content is rendered from local projection state inside spectral.platform per ADR-065 D2 + D4 (event-driven projection from worlds; no shared Protocol). The card is regenerable at any time from the platform’s audit chain + projected world-model state.

D4 — Authority + authority_version convention preserved

Both card shapes continue to carry the two mandatory fields established by ADR-015:

• authority — a reference to the standard the card’s claims are anchored to. For WorldModelCard: the world model itself (per ADR-026 D1, the world model version is the unit of authority). For System Card: the deployed module’s content hash (per ADR-080 D1).
• authority_version — the specific version of the authority. For WorldModelCard: the world-model version number. For System Card: the world-model version pinned to the deployed module.

The convention’s epistemological principle — every card claim must trace to an external versioned standard — is unchanged by this ADR. What changes is the referent of the standard for the System Card (the deployed module rather than the prior evaluation-framework attribution chain).

ADR-025 (System card authority basis — methodology transparency over regulatory recognition at alpha) applies. ADR-026 (World model version as unit of authority) applies; the version-as-authority model governs the WorldModelCard’s authority anchor.

Alternatives considered

Keep AgentPerformanceCard as a card shape, repurposed for the deployed module. Rejected. The name conveys “agent performance” — i.e., scoring a customer’s agent. Under the shift, Spectral does not score the customer’s agent; it serves binding decisions. The System Card (deployment-scoped) is the right shape; preserving the AgentPerformanceCard name would invite confusion about whether Spectral grades customer agents (it does not).

Merge WorldModelCard and System Card into a single card shape. Rejected. The two cards have different scopes (version vs. deployment), different audiences (worlds-internal + cross-customer baseline vs. customer-specific deployment), different lifecycles (a version card is enshrined and immutable; a system card is operational and refreshes as the deployment runs), and different authority anchors (the world model itself vs. the deployed module). Conflating them would force one document to do two jobs poorly.

Include conformance score / recommendations on the System Card. Rejected. Defense is structural — the conformity gate + implementation-readiness gate + multi-axis eval are the quality controls. A conformance score on the System Card would imply Spectral is grading the customer’s setup; the System Card is documentation, not a verdict. Methodology disclosure substitutes for grading.

Defer the System Card content reframe until customer feedback drives specific fields. Rejected. The System Card content was already concrete (now the dashboard’s Trust surface, docs/design/annotated-screens/customer-6-trust.png); pinning it now keeps the Codex rewrite unblocked. Future field additions can land per-card-shape without revisiting this ADR.

Drop the authority + authority_version convention as redundant under the shift. Rejected. The convention is the structural anchor for card claims; removing it would make cards self-referential. The convention’s referent shifts under D4, but the convention itself is load-bearing.

Consequences

• AgentPerformanceCard no longer exists (D1); the rest of ADR-015 (the authority + authority_version convention, the multi-audience rendering scope, the Protocol-vs-projection clarification in the body) stands.
• The Codex System Card page (apps/docs-codex/src/content/docs/system-design/world-model-system/system-card.mdx) gets rewritten to match the new content shape — tracked separately.
• The platform-side projection model for System Card content (the local SystemCardSnapshot per ADR-065) updates to carry the operational-record + methodology fields per D3. Implementation in Phase 4.
• The worlds-side WorldModelCard publication event (the producer-typed event payload per ADR-065 D2 in worlds.contracts.events.*) extends to carry the new D2 content. Additive-only versioning per ADR-044 D11.
• Linear scope: code paths for AgentPerformanceCard construction (where they exist outside the already-retired scan-pipeline epics) become candidates for removal in Phase 4 build-plan work. Most are already cancelled.
• The System Card / Trust surface (docs/design/annotated-screens/customer-6-trust.png) is the visual reference for System Card UI implementation; field-set parity between this ADR and the surface is enforced when the System Card UI lands.
• Prior-version authoritativeness for decisions made under retired versions is preserved through the System Card’s version-history section (D3) and the audit chain’s per-decision world-model-version capture (ADR-076 D3 + ADR-080 D4).