ADR-026: World model version as unit of authority

Context

A system card anchors its claims to a specific world model version. Rules may be corrected in subsequent versions. A question arises: do rule corrections retroactively invalidate prior system cards generated against the prior version?

If yes, the system needs a restatement protocol and a mechanism to propagate corrections back through the card history. If no, the system needs a clear principle explaining why prior cards remain valid and a mechanism that documents the corrections without disturbing the prior cards. The design interview resolved this.

Decision

The world model version is the unit of authority. A published version is authoritative for that version. System cards generated against a prior published version are not retroactively invalidated by corrections in subsequent versions. Corrections are documented in release notes accompanying the correcting version. Release notes are the restatement mechanism.

• A published world model version is authoritative for that version. Claims made in system cards against that version are correct statements about performance against the published standard at that version.
• Rule corrections discovered in subsequent versions are documented in release notes accompanying the correcting version.
• System cards generated against a prior published version are not retroactively invalidated. They remain correct statements about performance against the standard as published at that version.
• Recertification against a new version is a separate decision by the subject, not an automatic requirement driven by the correction.
• Release notes are the restatement mechanism. They live with the world model, not with the system card.
• No separate restatement protocol is required.

This ADR decides version-as-authority and names the restatement categories below; it defines no provenance alphabet. The authoritative-source taxonomy is owned by ADR-100.

Restatement categories

Under the in-band shift, decisions ride on executable decision modules generated by the world agent (per ADR-081 + ADR-076). Release notes record corrections in three categories. The categories are uses of the restatement mechanism established above; they do not change the version-as-authority decision or introduce a separate restatement protocol.

1. Assertion change. A rule’s natural-language meaning was wrong or imprecise; the corrected meaning appears in a new version. Release notes record the old vs. new assertion and the rationale.
2. Code regeneration. Assertion unchanged but the generated code was buggy or sub-optimal; a new generation pass produces correct code that clears the implementation-readiness gate. Release notes record (prior_code_provenance → new_code_provenance) — which world-agent version, which generation run, which eval-suite version.
3. Behavioral correction. Same rule, but a class of decision contexts was being decided wrong under the prior version. Release notes explicitly identify the corrected behavior — which class of contexts now decides differently, and what the new decision is.

Audit-integrity property preserved across all three categories: prior world-model versions remain authoritative for decisions made under them. We never retroactively rewrite a version’s decisions; the corrected version is a new version with explicit lineage.

Consequences

• Release notes are a first-class artifact of the world model, not an auxiliary document. They carry the corrections record that would otherwise need to propagate through system card history.
• System card history is stable. Prior cards are not mutated when subsequent versions correct rules; they stand as historical artifacts of performance against the standard at the time.
• Recertification is an explicit decision. A subject choosing to recertify against a new version produces a new card at that version; the prior card remains on the record.
• The cross-period comparability path through authority_version (ADR-015) is preserved. Readers comparing cards across versions reconcile the differences through the release notes of the intervening versions.
• The design does not require a restatement protocol, a retroactive invalidation mechanism, or a card mutation pathway. The absence of these mechanisms is a deliberate choice following from the version-as-authority principle.