World Model Card and System Card

Spectral publishes two card artifacts per ADR-082, each scoped to a different unit of authority and surfaced through a different consumption path.

• The World Model Card is the version-scoped methodology disclosure per ADR-082 D2. Lives in spectral.worlds. Operator-authored. Describes what was authored: the rules, their provenance, the configuration block, the action registry, the methodology by which the version was assembled.
• The System Card is the deployment-scoped operational record per ADR-082 D3. Lives in spectral.platform. Sourced from the platform’s audit chain. Describes how the deployment has run: aggregate decision totals, latency, status distribution, methodology disclosure for the deployment’s bound world-model version.

Both cards are public artifacts the customer can read. The split tracks the unit of authority: a World Model Card belongs to one immutable world-model version; a System Card belongs to one (org_id, domain_id) deployment’s operational history.

Why these two artifacts

The cards together give an auditor enough information to evaluate both the authority and the deployment:

• From the World Model Card, the auditor can verify that the rules in the deployed action modules trace to authoritative sources, that the methodology by which they were enshrined is documented, and that the provenance composition is what the operator claims.
• From the System Card, the auditor can verify that the deployment is exercising the authority as expected — decision volume, latency posture, status distribution across the four-state taxonomy, methodology coverage.

Neither artifact requires the auditor to trust Spectral’s reputation. The methodology disclosure is structural; the deployment record is observable. Authority is built into how the cards are constructed, not into a third-party validation of who constructed them.

World Model Card

Owned by spectral.worlds. Operator-authored. Generated at world-model-version publication time and re-rendered on configuration changes that don’t warrant a version bump (per the publication transaction in Evolution Loop).

Contents

Per ADR-082 D2 the version-scoped content covers the authoring path:

• Authority basis — the external standard or domain authority the world-model version is grounded in (statute, regulatory guidance, scholarly publication). Domain-local language — a tax-prep card references the relevant tax authority; a payments-operations card references the relevant clearing-system rules.
• Provenance composition — distribution of rules across the six authoritative-source tiers (Authoritative, Curated, Distilled, Researched, Observed, Assistant-drafted) per World Model. The provenance summary makes the authority claim checkable.
• Configuration snapshot — the configuration block values stable at this version (business hours, holidays, thresholds, windows, etc.) per World Model.
• Action registry summary — the set of registered actions, their rule counts by tier (T1/T2/T3), and their aggregation modes.
• Evolution history — what changed and why between this version and the prior version, using the three-category restatement discipline (configuration restatement, rule restatement, action restatement).
• Methodology disclosure — how the version was assembled, including the gates the rules passed (implementation-readiness gate, conformity gate) and the operator review path.

Mandatory fields

Every World Model Card carries a common set of fields that the auditor can lock onto.

• org_id — the org the world model belongs to
• domain_id — the domain the world model is scoped to
• world_model_version — the specific version
• authority — the external standard (domain-local language)
• authority_version — version of that authority at the time of card generation
• published_at — generation timestamp
• provenance_summary — rule-count distribution across the six authoritative tiers
• methodology_disclosure — structured description of how the version was assembled

The authority and authority_version fields use domain-local language. They describe the external standard in terms meaningful to the domain, not in world-model-specific terminology.

Authority basis — structural, not organizational

The card’s authority is structural. The World Model is developed from authoritative and curated sources, governed by the six-tier provenance system, passed through both the implementation-readiness gate and the conformity gate, and signed off by an operator at the enshrinement gate. The card reports against that construction. Independence is built into how the standard is constructed, not into a third-party validation of who constructed it.

Per ADR-080 the deployed action modules carry the same authority chain: content-hash addressed, operator-approval verified at load, code-provenance captured at code-gen time. The card is the methodology disclosure; the modules are the executable form of what the card describes.

System Card

Owned by spectral.platform. Sourced from the platform’s audit chain. Re-rendered continuously (or on a rolling-window cadence) as decisions accrue.

Contents

Per ADR-082 D3 the deployment-scoped content covers:

• Operational record — over the documented window (e.g., last 7 days at v0): total decisions, p50/p95/p99 latency, four-state status distribution (GREEN / GREEN-SKIP / YELLOW / RED counts and percentages).
• Action-level breakdown — totals and status distribution per registered action in the deployment’s bound world-model version.
• Methodology disclosure — the world-model version the deployment is bound to, with a pointer to the World Model Card for the deeper version-scoped methodology.
• Version history — when the deployment switched world-model versions, with overlay markers showing how the operational record evolved (see Version Attribution).

Mandatory fields

• org_id — the org owning the deployment
• domain_id — the domain the deployment is scoped to
• world_model_version — the version currently bound to this deployment
• authority — the deployed decision module’s identity (content hash per ADR-080 D1); the standard the card’s claims anchor to per ADR-082 D4
• authority_version — the world-model version pinned to the deployed module per ADR-082 D4 (mirrors world_model_version)
• window — the operational window covered (e.g., last_7_days, since_inception)
• generated_at — generation timestamp
• operational_summary — totals, latencies, four-state distribution
• methodology_pointer — URL to the World Model Card for the bound version

Card linkage

The two cards are conceptually paired (every System Card cites a World Model Card for the bound version) but each card is self-contained for the audit case it supports.

• A System Card’s methodology_pointer is a URL the reader can follow online; offline, the System Card embeds a snapshot of the World Model Card’s key fields (provenance summary, methodology disclosure summary, version identifier) so a downloaded PDF or exported record renders correctly without a live fetch.
• A World Model Card stands on its own — it does not depend on any specific deployment having run. An auditor can read a published World Model Card without observing any deployment’s operational record.

The embedded snapshot in the System Card is sourced from a platform-side projection of the World Model Card’s published event per ADR-065 D4 — canonical notification flow + projection-into-consumer pattern, no shared Reader Protocol spanning worlds and platform.

What the embedded snapshot contains

Field	Source	Example
world_model_version	from the projected snapshot	0.2.0
authority_summary	from the projected snapshot	IRS Publication 17 (TY 2026)
provenance_summary	rule-count distribution from the projection	Authoritative: 47, Curated: 3, Distilled: 0, Researched: 0, Observed: 0, Assistant-drafted: 0
methodology_pointer	derived from (org_id, domain_id, world_model_version)	https://cards.runspectral.com/world/...

What the embedded snapshot does not contain

• No rule text. No rule statements, no rule identifiers beyond the version handle.
• No configuration values. Configuration is part of the World Model Card itself, not duplicated on every System Card.
• No per-decision detail. The System Card carries aggregate operational record only; per-decision detail lives in the audit chain and surfaces through the Customer Dashboard Decisions tab.

System Card export — the offline artifact

The customer can export the System Card as a self-contained offline artifact. The export control lives on the dashboard’s Trust surface; triggering it downloads the artifact directly. The artifact bundles two things:

• the System Card itself — the deployment-scoped operational record (decision totals, latency, four-state status distribution, action-level breakdown, version history); and
• an embedded World Model Card snapshot for the bound version — the minimal methodology fields described above (version handle, authority summary, the six-tier provenance distribution, deployed-version history, and the methodology_pointer), with no rule text, no configuration values, and no per-decision detail.

The embedded snapshot is what lets the downloaded artifact render its methodology summary offline, without the live fetch the methodology_pointer would otherwise require. The artifact carries its own export-schema version and a generation timestamp, and reflects what was true at build time — later updates to the live cards do not retroactively change a downloaded artifact.

There is no cryptographic signing and no bulk decision-by-decision export at v0 (per ADR-080 D6): the published-card URL — the methodology_pointer — is the v0 trust anchor, and the artifact is the operational record plus the embedded methodology snapshot, and nothing else.

Why event-driven projection is the right shape

• Determinism. The System Card renders deterministically. The projected snapshot reflects what was true at card-build time; later updates to worlds-side card data don’t retroactively change rendered cards.
• Offline rendering. An auditor downloading the PDF and viewing it offline cannot make an HTTP call to resolve the reference. The snapshot is already embedded.
• Independence. The platform-side card renderer takes no runtime dependency on worlds being online. Worlds being unavailable doesn’t block card rendering of cards already projected.
• No Reader Protocol spanning worlds and platform. Per ADR-065 D3, OHS Protocols are admitted for genuinely-synchronous call flows; eventual-consistency reads (this case) belong in notification flow + projection into the consumer’s own context.

Versioning and restatement

A published world-model version is authoritative for that version. A World Model Card generated against v2.3 is a correct characterization of authoring as of v2.3. If v2.4 corrects a rule that was present in v2.3, that correction is documented in v2.4’s release-notes restatement. The v2.3 card is not retroactively invalidated.

Similarly, a System Card characterizing a deployment that ran against v2.3 decisions is a correct characterization of that operational record. Switching the deployment to v2.4 produces a new System Card row in the version history; prior windows remain queryable.

Each card is correct against the standard it was generated against. The published version is the unit of authority per ADR-026; authority attaches to what was published, not to what the standard later became.

Reserved for v1+

Cryptographic signing of the World Model Card and the embedded snapshot is reserved per ADR-080 D6 (Sigstore / in-toto / SLSA paths). At v0 the published-card URL is the customer-trust anchor; verification relies on Spectral’s operational posture. The deferral is reversible — cryptographic signatures can layer on later as an additional surface without changing the card structure.

What’s next

• Version Attribution — how the world-model version stays metadata across the context boundary
• Operations App — Publication — operator-triggered publication that mints the World Model Card and the action modules
• Customer Dashboard — Trust — the customer-facing view of the System Card