System Card

A System Card is an external artifact generated by Spectral characterizing an agent system’s conformance to a World Model. It is produced after evaluation against a world-model-derived EvaluationFramework, and it is generated by Spectral — not by the customer.

This is what gives the system card its authority. The authority derives from the quality and provenance of the World Model, not from regulatory recognition of the reporting format. Spectral does not pursue regulatory approval for the system card format. The path to authority is methodology transparency, expert provenance at the rule level, track record of world model evolution, and the joint development of domain standards with domain expertise.

Authority Basis

The system card’s authority is structural, not organizational. The World Model is developed from authoritative and curated sources, governed by the provenance tier system, and evolved through a human-gated loop. The system card reports against that standard. Independence is built into how the standard is constructed, not into a third-party validation of who constructed it.

System cards include mandatory methodology disclosure: the world model version assessed against, the provenance composition of the rules assessed, and the eval generation methodology. This makes the authority claim checkable — a reader can evaluate the card’s credibility from the disclosed methodology rather than having to trust the generating organization’s reputation.

Alpha-posture acknowledgment

Two of the four pillars bootstrap over time: track record of world model evolution doesn’t exist for v0.1.0 (the preview footer carries this), and expert provenance at the rule level is single-operator currently — Maya dogfooding is the current curation reality. The world model is the system’s innovation core; product success depends on its quality, so the defenses against single-operator error are built into the substrate rather than delegated to procedural review. The conformity gate provides mechanical validation independent of operator judgment. Release-notes restatement handles known-error correction in subsequent versions. Methodology disclosure on the system card itself (see Mandatory Fields below) makes every rule’s provenance auditable post-hoc. The operator team itself scales with domain coverage as Spectral grows — added capacity for curation, not redundant review on individual decisions. The authority claim is calibrated to current posture, not over-claimed against it.

Mandatory Fields

Every system card carries a common set of fields. Per ADR-065 D2, system card shapes are owned by the producing context (worlds for WorldModelCard; platform for AgentPerformanceCard); the field convention is shared by ADR-015’s authority/authority-version pinning, applied across each context’s projection-local model.

• authority — the external standard or domain authority the world model is grounded in
• authority_version — version of that authority at the time of card generation
• world_model_id — the world model this card was generated against
• world_model_version — the specific version
• generated_at — generation timestamp
• methodology_disclosure — structured description of eval generation approach and provenance composition

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. A healthcare system card references the relevant clinical standards authority; a financial services card references the relevant regulatory body. The reader meets the card in their own domain’s vocabulary.

Card Types

Two card types live with the contexts that produce them.

WorldModelCard — owned by spectral.worlds. Characterizes the world model itself. Describes domain coverage, rule composition by provenance tier, version history, and methodology. Used for world model audits and domain standard disclosure.

AgentPerformanceCard — owned by spectral.platform. Characterizes an agent system’s performance against a world model. Describes conformance by rule category, failure patterns, improvement trajectory, and holdout performance. Used for agent system audits and customer-facing performance disclosure.

The split follows the context structure. The world model’s own self-characterization lives with the world model; the agent’s performance characterization lives with the optimization pipeline that produced it. The shared field convention (authority + authority_version + the mandatory-fields set above) is applied by each context’s own card type. Downstream consumers treat the rendered output uniformly because the field shapes are uniform, not because a shared Protocol pins them.

Versioning and Restatement

A published world model version is authoritative for that version. A system card generated against v2.3 is a correct characterization of performance against the v2.3 standard. If v2.4 corrects a rule that was present in v2.3, that correction is documented in the v2.4 release notes. The v2.3 system card is not retroactively invalidated.

Recertification against a new version is a separate decision — prompted by a significant version release, a regulatory requirement, or a customer’s own audit schedule. It produces a new system card against the new version, not a revision of the prior card. Prior cards remain part of the audit trail, each correct against the standard it was generated against.

Card Linkage at Render Time

The linkage between an AgentPerformanceCard (in spectral.platform) and the WorldModelCard it was generated against (in spectral.worlds) flows through event-driven projection per ADR-065 D4 — the canonical notification flow between worlds and platform. Each context renders its own card with an embedded snapshot of the reference; rendering is the job of the card renderers, not of spectral.core, and not of a shared rendering service. There is no Reader Protocol spanning worlds and platform.

The linkage mechanism — event-driven projection, embedded snapshot

When worlds publishes a WorldModelCard for a given version, it emits a world_model_card_published event onto the substrate (typed payload in spectral.worlds.contracts.events.world_model_card_published per ADR-065 D2; arrives with the worlds publication epic — see Event System for the full inventory of planned events). Platform’s projection handler consumes the event and materializes a SystemCardSnapshot (a spectral.platform-internal type) into platform’s own state, keyed by evaluation_authority_ref (the unit of authority platform stamps onto ChangeSet at scan time per ADR-030; worlds-internal naming like (world_id, world_version) is not used as the projection key).

When an AgentPerformanceCard is built, the card-build use case in spectral.platform reads the relevant SystemCardSnapshot from platform’s local state and embeds it into the card record. Rendering reads from the snapshot, never from a live fetch into worlds.

This shape is the canonical “eventual consistency on a fact already recorded elsewhere” pattern per Contract Surfaces: worlds writes the published card; platform projects into its own replica and reads from there. The dependency from platform on worlds is the event payload contract only — not a Protocol, not a runtime DI handle, not a SQL grant.

Where the renderers live

• AgentPerformanceCard is rendered inside spectral.platform by a SystemCardAttributionRenderer that receives the card model + its embedded SystemCardSnapshot.
• WorldModelCard is rendered inside spectral.worlds by its own renderer.
• Each context owns its own card rendering; there is no SystemCard Protocol spanning worlds and platform, and no shared rendering service. A shared service would have to import both worlds and platform internals — a validator violation and a context-boundary violation regardless.

What the rendered reference contains

When the AgentPerformanceCard renders its reference to the WorldModelCard, the output carries only the following:

Field	Source	Example
world_model_id	SystemCardSnapshot.world_model_id	us-federal-individual-tax
world_model_version	SystemCardSnapshot.world_model_version	0.1.0
authority_ref	SystemCardSnapshot.authority_ref	opaque version-authority handle minted at publication
Rule-count-by-tier summary	from the projected snapshot at card-generation time	e.g., Authoritative: 47, Curated: 3, Distilled: 0, Observed: 0
Published-card URL	derived from world_model_id + world_model_version	https://cards.runspectral.com/world/us-federal-individual-tax/0.1.0

What the rendered reference does not contain:

• No rule text. No rule statements, no rule identifiers beyond the opaque authority_ref.
• No eval-corpus contents. Nothing about the samples used, generating rule IDs, or attribution metadata for specific samples.
• No world-model-internal coverage deltas. Coverage deltas specific to the workspace belong on the AgentPerformanceCard’s own content sections, not on the reference.

Why event-driven projection is the right shape

• Determinism. The 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. If the WorldModelCard is updated between scan time and render time (within a version — edits to the card’s narrative sections, not the authoritative fields), the AgentPerformanceCard still reflects what was true at scan time.
• 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 + ADR-068, 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. There is no SystemCardReader Protocol in <callee>.contracts.protocols.* for this surface — it would invert the precedent set by ADR-064.

The published-card URL is included so an external reader can dereference it when online, but dereferencing is never required for the card itself to render correctly.

How an auditor verifies the reference

The external reader (operator, customer, regulator-later) verifies the reference as follows:

1. Read world_model_id + world_model_version from the AgentPerformanceCard.
2. Fetch the published WorldModelCard at the published URL.
3. Compare the rule-count-by-tier snapshot on the AgentPerformanceCard against the WorldModelCard’s corresponding counts for that version.
4. Verify the authority_ref handle matches what the WorldModelCard advertises for that version.

If any of those comparisons fail, the reference has been tampered with or the card was generated against a version that has since been retracted — both cases that warrant investigation.

Alpha and a future signing

Today, the authority_ref is a plain opaque handle (a UUID + a deterministic hash of the version’s rule set). Verification relies on the auditor trusting Spectral’s published URL.

Later, the WorldModelCard and its authority_ref are cryptographically signed (WorldModelCard signing in future considerations). An auditor can then verify the signature independently, without trusting the URL. This is the stepped trust model — the current posture relies on Spectral’s operational posture; a future adds cryptographic verifiability.

What’s Next

• Version Attribution — how the version on the card moves between contexts as metadata, not synchronization
• Operations App — Publication — operator-triggered publication transaction that mints the WorldModelCard
• Optimization Engine — how the AgentPerformanceCard is built from scan results