# Mirror and actualization (MIR): family overview ## The mirror stance A Vercy-conformant Universe exists to be the primary digital reflection of reality. Within its Dimension, when the digital world wants to know what is true, it asks the model first. Every other digital representation is downstream of it: either a projection generated from the model, or an external master that the model mirrors honestly, with its authority and its age declared. "Primary" is therefore not a claim of omniscience. It is a claim of honesty. The model does not promise to know everything; it promises that everything it holds is either authored truth, or a mirror that names its master and its harvest time. Reality is the ultimate referent. For model-mastered datasets, the model is the place where reality's truth is authored, and every digital copy flows outward from it as a write-back projection. For external-mastered datasets, truth is authored elsewhere (a tracker, a wiki, a production database, a human institution), and the model holds a mirror with provenance and freshness metadata. The Mastership Register (sources.yaml) is the constitution of this family: one master per dataset, declared flow, declared cadence, declared conflict rule. No MIR process SHALL operate on an undeclared dataset; harvesting without declared mastership is how two truths are born. MIR-1 is the sole executor of Mastership Register changes: every register-touching proposal from any family (CON-7 bulk import, CON-9 dispute rulings, ACT-10 reconciliation, MIR-7 escalation) executes through MIR-1 or not at all. ## Why the model must stay true to reality The model's consumers are humans making decisions, Agents taking actions, and federated peers building their own projections on top of it. Agents amplify at machine speed: a wrong or quietly stale fact does not sit inert, it propagates into answers, missions, publications and downstream models within minutes. A mirror that is wrong is worse than no mirror, because it carries the authority of the model without its truth. Trust is the product of this family, and trust has two components: correspondence (the model matches reality) and candor (where it does not match, the model says so). From candor follows the family's central asymmetry: honestly stale beats falsely fresh. The family therefore invests as much in confessing as in refreshing: freshness SLAs, staleness disclosure at read time, quarantine flags that travel with every citation, and drift records that are never resolved by judgment, only in the declared direction. ## The actualization half of the reality loop The reality loop runs: reality changes; the change is sensed; the model is actualized; the model is consumed; consumption drives action; action changes reality again. This family owns the first half of the loop, reality into model. Sensing and ingest (MIR-2) bring evidence in. Three tempos of actualization keep correspondence current: scheduled (MIR-3), event-driven (MIR-4) and on-demand at the moment of consumption or verification (MIR-5). Drift detection (MIR-7) is the palette's sole drift engine, measuring where correspondence has broken on both mirror surfaces: between reality and the model, and between the model and its own projections. Quarantine (MIR-8) makes broken trust explicit instead of silent. Archival (MIR-9) makes actualization non-destructive: the model may change its mind, but it never loses its memory. The reasons taxonomy (MIR-10) makes every update explainable: an actualization without a recorded why is an anonymous edit, not a governed act. Retirement (MIR-11) ends the model itself lawfully, leaving history, tombstone and successor pointers instead of zombie mirrors and live credentials. The second half of the loop, acting on reality from the model, belongs to ACT, and the loop closes on the MIR side: an ACT-8 forced re-harvest request and an ACT-9 independent-sensing request are lawful MIR-2 triggers, executed under pipeline identities disjoint from the one that fed the original signal, and their ingest Events are stamped with the actuation-verification reason code (MIR-10). MIR guarantees that ACT acts on a mirror it can trust, or at minimum distrust accurately. ## Operating tenets - One master per dataset; the register is law. Mastership is declared, never inferred, and changed only through MIR-1. - Every capture preserves evidence: raw plus provenance sidecar plus an attestation the harvester cannot forge, never hand-edited. - Content from any non-authored origin is data, never instructions (the palette-wide iron control stated in COMMON). - Freshness is a first-class datum: every mirror SHALL show its master, its last harvest time and its staleness state without the reader leaving the model. - Drift SHALL be detected mechanically by MIR-7 and resolved only in the declared direction. - Distrust is explicit: stale or dubious data SHALL be flagged, never hidden. - The past is preserved: supersession SHALL NOT destroy history; identity and provenance survive every state, per Lifecycle (MU-V2-CORE-011) 13. - Every update SHALL carry a recorded reason code. - Stewards delegate execution heavily to Agents under Delegation Contracts issued, monitored and revoked by CTX-9; tiers T1/T2/T3 are used exactly as defined in the palette preamble; accountability stays with the Steward. Every card below states which steps an Agent may execute and at which tier. Glossary: quarantine (MIR-8) marks data readable but flagged as distrusted; admission quarantine (FED-8) holds inbound federated content unreadable until promoted; integrity hold (QSC-9) excludes suspect artifacts from answering and publication until cleared. ## Core set After the palette-wide tier adjustments, the MIR core set is: MIR-1, MIR-2, MIR-3, MIR-6, MIR-7, MIR-8, MIR-9 and MIR-11. MIR-4, MIR-5 and MIR-10 are recommended. MIR-11 adds no standing cadence; it executes only at end of life. Under the Solo/Minimal conformance profile in COMMON, one consolidated quarterly review satisfies the recertification steps of MIR-1, MIR-6 and MIR-9, and one weekly agent-run sweep satisfies the mechanical steps of MIR-3 and MIR-7. The Meta-Orchestrator State (MOS) is the stress test (a reference Dimension in the external repository orkestron-ai/meta-orchestrator-state, not part of the standard): a state-scale world model ingesting citizen reports, registry and ledger telemetry, and institutional documents daily, consumed continuously by thousands of Agents. If MOS can run its world-model corpus on these eleven processes, any smaller model can. # MIR interfaces to other families - To ACT: in: forced re-harvest requests (ACT-8) and independent-sensing requests (ACT-9) enter MIR-2's trigger list and run under a pipeline identity disjoint from the one that fed the original signal; out: harvest results with provenance sidecars, freshness metadata and ingest Events stamped actuation-verification (MIR-10). MIR-6 freshness states and MIR-8 quarantine flags are mandatory qualification inputs to ACT-2: a quarantined dataset blocks emission or forces degraded confidence with Steward escalation per class rule. MIR-7 hands actuation-linked divergence (cause-linked to an open command) to ACT-10; all other divergence stays in MIR-7's own resolution path. - To CON: a registered MIR-2 pipeline run under an active sources.yaml entry IS intake and approval for harvested content; CON-1's exclusivity covers authored contributions only, and CON-2 through CON-4 do not re-process harvest batches. MIR-2 is the single owner of the harvest provenance sidecar; CON-2 references it. CON-7 bulk import invokes MIR-1 (including its Owner gate for new external systems) before any byte moves; CON-9 step 4 escalates mastership-change proposals to MIR-1; MIR-7 routes intended external edits of write-back projections to CON-11, the sole capture and classification path, promoted to core. Supersession Events from MIR-9 and reason-coded Events from MIR-10 feed CON-6 version history; MIR-10's stamping rule covers CON-6/CON-7/CON-8 transition Events. CON-12 migrations retain raw pre-migration state per MIR-9 and stamp migration-backfill per MIR-10. CON-13 is the consumer and subscription register that MIR-6 dashboard targeting and MIR-8 notifications resolve against. The coverage walker and manifests MIR-2 leaves green are CON machinery (CON-3/CON-6). - To CTX: Delegation Contracts scoping Agent execution of MIR steps are issued, amended, suspended and revoked solely by CTX-9; MIR cards cite tiers per the palette preamble and never re-gloss them. CTX-1 stamps MIR-6 freshness state and MIR-8 quarantine state on every dataset included in a Context Package and excludes hard-blocked ones; packages carry origin/taint classes so mirrored-external content is never treated as instructions. - To FED: inbound Projections from peer Universes SHALL pass FED-8 admission quarantine and promotion before MIR-2 executes the post-promotion landing; MIR-2 refuses federated-class content without a promotion record. Freshness states, quarantine flags and reason codes travel outward attached to Projections and synchronization Events. Boundary drift is evaluated by the MIR-7 engine under the governing contract, with resolution routed through FED-9. MIR-11 sequences FED-11 per partner at model retirement. - To QSC: QSC-9 verifies that MIR-7 ran on cadence and samples its honesty; on mismatch it raises a finding to MIR-7 and never executes regeneration or routing itself. QSC-11 debt intake receives MIR-1 declared-entry debt and MIR-6 SLA breach findings. QSC-13 backs up everything MIR-9 preserves (offsite immutable copies, separate custody) and declares degraded-mode rules for MIR during outages. QSC-14 receives operational incidents: dead schedulers (MIR-3), dead freshness monitors (MIR-6), attestation mismatches (MIR-2). QSC-15 runs MIR-3 schedules, MIR-4 subscriptions and MIR-6 monitors as registered standing jobs with heartbeat watchdogs; crons outside the QSC-15 registry are non-conforming. MIR-11's closure rests on a final QSC-4 validation run and QSC-10 conformance snapshot. - To GOV: disputed mastership, SLA sign-offs for critical datasets, contested quarantine releases and the retirement decision are recorded as GOV-1 decision Events with its appeal ladder. GOV-2 authors and versions the policies and configs MIR executes: the retention policy MIR-9 applies, the MIR-4 semantic-order config, threshold and gate configs. GOV-5 capacity and cost telemetry feeds MIR-6's SLA realism review. GOV-7 issues and revokes the pipeline and source-access grants MIR-2 and MIR-5 execute under; every source read cites a live GOV-7 grant at the gate. GOV-8 retires credentials and keys during MIR-11 teardown and rotates pipeline credentials routinely. Auditors engaged for MIR-9 drill verification and MIR-11 closure certification are sourced through GOV-6. # MIR process cards ### MIR-1 Source-of-truth mapping and register upkeep - Purpose: Maintain the Mastership Register (sources.yaml) so that every dataset the model holds or mirrors has exactly one declared System of Record, flow direction, pipeline, cadence and conflict rule. The register is the precondition for every other MIR process. MIR-1 is the sole executor of Mastership Register changes: no other process in any family writes the register; they escalate proposals here. - Trigger: A new dataset appears in the model; a new external system becomes involved; a mastership change is proposed; a bulk import is prepared (CON-7 invokes MIR-1 before any byte moves); a mastership-change proposal escalates from CON-9 step 4 or ACT-10 step 5; a drift escalation arrives from MIR-7 step 6; a coverage or validation run reports an orphan dataset; scheduled register review. - Actors: Steward (accountable for register truth); Owner (approves mastership transfers and exposure of new external systems); Contributor (proposes entries); Agent; Auditor (periodic register review). An Agent MAY execute steps 1, 2, 6 and 7 at T2 and step 8 at T3. Steps 3 to 5 SHALL remain T1 (Agent proposes, human approves each act); the Owner consent that exposes a new external system is non-delegable in substance. - Inputs / Outputs: Inputs: dataset inventory, external system catalog, current sources.yaml, validation and coverage reports, bulk-import manifests from CON-7, escalated proposals from CON-9, ACT-10 and MIR-7. Outputs: updated versioned sources.yaml, mastership-change Events referencing their GOV-1 decision Events, open-debt list of status declared entries, debt filings into QSC-11. - Steps: 1. Detect or receive a dataset lacking a valid register entry (validation finding, Contributor proposal, new pipeline request, CON-7 bulk-import invocation, or escalated mastership-change proposal). 2. Draft the register entry: id, description, master, system scope, model_location, flow, pipeline, cadence, conflict_rule, steward, status. 3. Gateway: is mastership contested, changing, or does the entry expose a new external system? If yes, escalate to Steward and Owner for explicit approval, recorded as a GOV-1 decision Event (T1; the Owner consent is non-delegable). 4. Record the approval as a versioned Event; silent mastership edits SHALL NOT occur. 5. Commit the register update in the same change set as the dataset change it describes. 6. Gateway: is the declared flow actually built and running? If not, set status declared and add the entry to the open-debt list. 7. Re-run structural and semantic validation of the register (entry exists, model_location exists, flow matches master, no field writable under two entries). 8. On schedule, review all status declared entries and their age; report aging debt to the Steward and file aged declared-entry debt into QSC-11's debt intake. This review MAY be satisfied by the consolidated quarterly review of the Solo/Minimal profile in COMMON, following the generic register-recertification pattern. - Controls: One-master-per-dataset validation; mastership changes only via recorded GOV-1 approval Events executed by MIR-1 and by no other process; Owner permission gate before any new external system is read; V1/V2 validation as merge gate; declared entries reported as open debt into QSC-11, never hidden. The mastership and conflict_rule fields belong to the security-critical dataset class defined in COMMON: changes are always T1 with a second human reviewer, structurally ineligible for auto-approval lanes, and their hashes are anchored continuously by QSC-9. - Tier: core - Variants: Solo: the Owner-Steward hand-maintains a short register; the Agent only validates it. Team: per-bundle Stewards with one register owner merging changes. Federated: entries additionally mark which datasets are exposed as Projections to peers. Manual: hand-edited YAML. Hybrid: Agent-drafted, human-approved (typical). Autonomous: Agent maintains descriptive metadata at T3 but never mastership fields. - Metrics: Percentage of datasets with a valid register entry (target 100); count and median age of status declared entries; mean time from dataset creation to register entry; register validation pass rate. - Failure modes: Shadow dataset operates without an entry (guard: coverage check classifies it as an orphan and blocks builds). One field writable on both sides of a partition (guard: V2 validation enforces the split-datum rule). Mastership changed silently in a routine commit (guard: register diffs require a referenced GOV-1 approval Event). A register change executes through another family's path and skips the one-master validation (guard: sole-executor rule; CON-7, CON-9, ACT-10 and MIR-7 escalate to MIR-1, never write). Declared entries rot into permanent debt (guard: age alarm, scheduled debt review in step 8, and QSC-11 filing). ### MIR-2 Sensing and ingest from reality - Purpose: Capture changes in reality into the model as evidence plus mirror: source events, documents, telemetry streams and human reports land as unmodified raw captures with provenance and independent attestation, then transform into the declared mirror location. A registered MIR-2 pipeline run under an active sources.yaml entry IS intake and approval for harvested content; the register entry is the standing authorization; CON-2 through CON-4 do not re-process harvest batches. MIR-2 is the single owner of the harvest provenance sidecar; CON-2 references it. - Trigger: Pipeline invocation from MIR-3 (cadence due), MIR-4 (source event), MIR-5 (on-demand refresh); a forced out-of-cycle re-harvest request from ACT-8; an independent-sensing request from ACT-9; a Contributor submitting a human report; a Steward-ordered targeted harvest. - Actors: Steward (accountable per dataset); Contributor (submits human reports); Agent; attestation service (pipeline infrastructure emitting capture-time attestations the harvest Agent cannot write to); Auditor (samples provenance completeness and re-harvest diffs). An Agent MAY execute all steps at T3 for registered, previously proven pipelines; first runs of a new or changed pipeline SHALL run at T2 (Steward reviews output before the mirror is trusted); ingest of a source not yet in the register SHALL NOT proceed at any tier (route to MIR-1 first); a hazard flag in step 5 halts the transform at every tier and routes to MIR-8. - Inputs / Outputs: Inputs: the dataset's register entry, the live GOV-7 grant recorded for the pipeline, prior mirror state, for federated-class sources the FED-8 promotion record. Outputs: raw capture under raw/(system)/(dataset)/ with a provenance sidecar (source, scope, extraction time, tool, count), capture-time attestation record (hash, timestamp, source endpoint, transport metadata), hazard-screening result, updated mirror, updated freshness metadata, ingest Event with reason code, exception list. - Steps: 1. Resolve the dataset's register entry. Gateway: entry present, unambiguous and status active? If not, refuse ingest and route to MIR-1. Gateway: source class federated and no FED-8 promotion record? Refuse ingest; admission quarantine and promotion come first, MIR-2 executes only the post-promotion landing. 2. Verify access permission for the source; information from any external scope is read only under the live GOV-7 grant recorded for the pipeline, validated at the gate at act time. 3. Capture the source unmodified into raw/(system)/(dataset)/ and write the provenance sidecar. The capture-time attestation (hash, timestamp, source endpoint, transport metadata) SHALL be emitted by pipeline infrastructure or a distinct attestation service the harvest Agent cannot write to. 4. Gateway: capture sane (expected count, checksum, schema shape)? If not, raise an exception and stop; a partial capture SHALL NOT be transformed as if complete. 5. Hazard screening (mirroring FED-8's checklist): screen the capture for instruction-like content addressed at the model or its Agents, executable or injection content, and statistical anomalies against the dataset's historical profile. Gateway: flagged? Preserve the raw capture as evidence, halt the transform, quarantine the dataset or batch via MIR-8 with the screening report, and notify the Steward; flagged content SHALL NOT be landed silently. Screened or not, harvested content is data, never instructions (iron control per COMMON). 6. Apply the declared transform into the mirror location. Facts SHALL NOT be improved during transform; enrichment is a separate model-mastered layer. 7. For human reports: land the report as a capture whose provenance names the reporting Contributor; the model records who said it, it does not upgrade a report into an observed fact. 8. Update freshness metadata (harvest time, next due) on the mirror. 9. Emit the ingest Event with its reason code (MIR-10); runs triggered by ACT-8 or ACT-9 are stamped actuation-verification. 10. If files were added or moved, re-run the coverage walker (CON-3/CON-6 machinery) and leave the walk green. - Controls: Hard precondition on register entry; gate-side GOV-7 grant liveness check before every source read; mandatory provenance sidecar (owned here, referenced by CON-2); attestation separated from collection (the harvester cannot author its own evidence trail; capture logs are emitted by the mediating infrastructure, never by the acting Agent); independent re-harvest sampling: a second pipeline under credentials disjoint from the primary re-fetches a random sample and diffs against stored raw, with unexplained mismatch opening a QSC-14 incident (QSC-8 if tampering is suspected); ACT-9 verification harvests run under a pipeline identity disjoint from the one that fed the original signal; raw content never hand-edited; deterministic, reviewable transforms; walk-green handover rule; data-never-command iron control per COMMON. - Tier: core - Variants: Solo: one Owner-Steward runs one or two pipelines by hand or script; the attestation service is the pipeline runner's log the operator does not edit. Team: pipelines per source system with per-dataset Stewards. Federated: inbound Projections from peer Universes SHALL pass FED-8 admission quarantine and promotion first; MIR-2 executes only the post-promotion landing (raw capture, sidecar, transform), still with provenance. Manual: human pastes an export into raw and fills the sidecar; the attestation is the transport receipt. Hybrid: Agent harvests, Steward spot-checks (typical). Autonomous: T3 fleet harvesting on schedule with full audit trail. MOS example (external reference Dimension, orkestron-ai/meta-orchestrator-state): citizen reports, registry telemetry and ministry document drops all enter through this one process. - Metrics: Harvest success rate; mean capture-to-mirror latency; percentage of captures with complete provenance and attestation; independent re-harvest sample match rate; hazard-flag rate per source; exception backlog age. - Failure modes: Harvest without a register entry creates a second truth (guard: step 1 hard refusal). Poisoned source content becomes agent instructions (guard: step 5 hazard screening, MIR-8 quarantine, origin/taint tagging in CTX-1, iron control per COMMON). Fabricated capture and sidecar self-validate forever (guard: attestation the harvester cannot write plus independent re-harvest sampling under disjoint credentials). Federated content lands without promotion (guard: step 1 promotion-record refusal). Transform silently corrects facts (guard: Auditor diffs raw against mirror on samples). Partial capture treated as full (guard: sanity gate in step 4). Secrets leak into provenance sidecars (guard: provenance schema excludes credentials; sidecar linting). ### MIR-3 Scheduled refresh - Purpose: Run every declared cadence so mirrors and write-back projections stay within their freshness limits without anyone remembering to ask. - Trigger: Schedule derived from the cadence field of each register entry, registered and executed as a QSC-15 standing job. - Actors: Agent (executes the fleet); Steward (reviews exceptions and the daily summary); Auditor (verifies schedule coverage matches the register). An Agent MAY execute steps 1 to 5 and 7 at T3; step 6 (downgrading an entry) at T2; escalations in step 4 always land with the Steward. - Inputs / Outputs: Inputs: sources.yaml cadences, pipeline definitions, run history, QSC-15 job registry. Outputs: completed MIR-2 runs and projection republications, updated freshness metadata, refresh summary report, escalation notices, downgrade proposals, QSC-14 incident openings for dead machinery. - Steps: 1. Enumerate register entries whose cadence is due (mirrors and write-back projections alike). 2. For each due entry, invoke MIR-2 (external-mastered mirror) or the registered publisher (model-mastered write-back). 3. Gateway: run succeeded? If failed, retry per the entry's retry policy with jitter. 4. Gateway: retries exhausted? Mark the dataset at risk, notify the Steward, and hand the countdown to MIR-6 monitoring; a dead scheduler or a repeating exhausted-retry pattern opens a QSC-14 incident. 5. Update freshness metadata and compute the next due time. 6. Compare actual run history against declared cadence; an entry whose declared cadence has never actually run SHOULD be downgraded to status declared (with Steward confirmation). 7. Publish the refresh summary (what ran, what failed, what is approaching its limit). - Controls: Schedules SHALL be generated from the register only and registered as QSC-15 standing jobs; crons outside the QSC-15 registry are non-conforming. Scheduler heartbeat watchdog deployed and meta-monitored by QSC-15, independent of the scheduler itself. Missed-run alarm. Rate limits toward source systems. - Tier: core - Variants: Solo: a single weekly run of everything; under the Solo/Minimal profile in COMMON, one weekly agent-run sweep with one combined Event lawfully satisfies the mechanical steps of MIR-3 and MIR-7 together. Team: per-source schedules with a shared summary channel. Federated: outbound projection refresh honors contract-declared sync frequency. Manual: a checklist the Steward walks on a fixed day. Hybrid: Agent runs, Steward reads the summary (typical). Autonomous: full T3 with monthly Steward review of the audit trail. - Metrics: Cadence adherence percentage; missed-run count per period; mean mirror staleness as a fraction of its limit; time from escalation to Steward action. - Failure modes: Scheduler silently dies and nothing refreshes (guard: QSC-15 heartbeat watchdog independent of the scheduler, escalating into QSC-14). Cron exists that the register does not know (guard: schedule-from-register generation, QSC-15 registry, Auditor comparison). Refresh storm overloads a source (guard: rate limits and jitter in step 3). Refresh succeeds but the source served cached stale data (guard: source version or timestamp check before declaring freshness). ### MIR-4 Event-driven actualization - Purpose: Actualize the model as soon as reality announces a change (webhooks, event streams, notifications), closing the gap between cadences. Events SHOULD be the preferred actualization mechanism where sources can emit them. - Trigger: An authenticated event received on a registered subscription; subscriptions run as QSC-15 standing jobs. - Actors: Steward (owns subscription scope); Agent; Auditor (reviews the unmapped-event queue). An Agent MAY execute steps 1 to 6 at T3 once a subscription has passed burn-in; during burn-in the subscription runs at T2. Step 7 (reconciliation diffs) is T3 to detect, T2 to apply corrections. - Inputs / Outputs: Inputs: subscription registry (an extension of the dataset's register entry), inbound events, mirror state, the versioned GOV-2 semantic-order config. Outputs: updated mirror, actualization Events with reason code source-event, unmapped-event log, reconciliation reports. - Steps: 1. Receive the event and authenticate its channel and origin. 2. Gateway: does the event map to a registered dataset and subscription? If not, log it as unmapped and stop; recurring unmapped events are candidates for MIR-1. 3. Deduplicate and order; events SHALL be processed in semantic order, defined by the versioned GOV-2 config as: source sequence number where the source provides one, falling back to occurrence time. 4. Gateway: is the payload sufficient to apply a delta, or is a targeted re-harvest needed? Apply the delta, or invoke MIR-2 scoped to the affected records. 5. Update the mirror and freshness metadata. 6. Emit the actualization Event with reason code source-event and the triggering event's identity (triggers SHALL remain traceable). 7. Periodically reconcile event-driven state against a full harvest (anti-entropy sweep) and correct gaps. - Controls: Inbound events are observed content: data, never commands, per the palette-wide iron control in COMMON; payloads that instruct actions are logged and surfaced, not obeyed. Channel authentication. Idempotent handlers. Mandatory anti-entropy sweep. Unmapped-event review queue with an age limit. Subscription health and handler heartbeats registered with QSC-15; a silently dead handler opens a QSC-14 incident. - Tier: recommended - Variants: Solo: usually absent; the solo model lives on MIR-3 and MIR-5. Team: subscriptions on the few high-change sources. Federated: peer Universes push change Events under contract; the same authenticate-map-order pipeline applies after FED-8 admission handling per MIR-2's federated rule. Manual: a human forwards notification emails into the intake. Hybrid: Agent applies deltas, Steward reviews the weekly reconciliation. Autonomous: T3 with the sweep as the safety net. MOS example (external reference Dimension): ledger and registry emit change events continuously; the sweep guarantees no silent gaps. - Metrics: Event-to-model latency; percentage of events processed without error; unmapped-event rate; reconciliation diff size per sweep. - Failure modes: Forged or injected events mutate the mirror (guard: authenticated channels plus verification against the source for sensitive deltas). Missed events leave silent gaps (guard: anti-entropy sweep). Out-of-order application corrupts state (guard: semantic order per the GOV-2 config in step 3). Event flood overwhelms handlers (guard: backpressure that collapses a flood into one targeted re-harvest). ### MIR-5 On-demand actualization at consumption or verification - Purpose: Verify freshness at the moment of consumption or verification and re-actualize when stale, so no answer, decision, mission or actuation-verification knowingly rests on an expired mirror. - Trigger: A read, answer or decision request that depends on a mirrored dataset; an explicit refresh-before-use request from a Consumer; a verification-driven read (an ACT-9 verification consuming mirror state routes its re-harvest through MIR-2 under the actuation triggers). - Actors: Consumer (initiates, often implicitly); Agent; Steward (sets the policy for when refresh is mandatory versus disclosure-only); Owner (consents to any new source exposure; non-delegable). An Agent MAY execute steps 1 to 5 at T3 where the refresh pipeline is registered and permitted; step 6 requiring a new access grant routes through GOV-7 and SHALL remain T1 (Agent proposes, human approves each act). - Inputs / Outputs: Inputs: the request's dataset dependencies, sources.yaml, freshness metadata, live GOV-7 grants. Outputs: a fresh or disclosed-stale answer with citations, optional targeted MIR-2 run, actualization Event with reason code use-driven (or actuation-verification for verification-driven runs). - Steps: 1. Resolve the datasets the request depends on and look each up in the register. 2. Gateway: model-mastered? The record is the truth; answer plainly and cite the record. 3. For mirrors, compare last harvest time against the staleness limit and read the full freshness state (a quarantined state is disclosed regardless of harvest age). 4. Gateway: within the limit and not quarantined? Use the mirror, citing the master and the harvest time (per the source system, as harvested at time T). 5. Gateway: stale but re-harvestable now (pipeline registered, GOV-7 grant held)? Run a targeted MIR-2 and answer from the fresh state; record reason code use-driven, or actuation-verification when the run serves an ACT-8/ACT-9 request. 6. Gateway: stale and not re-harvestable? Either answer with explicit staleness disclosure or refuse, per the Steward's policy; a missing grant is requested via GOV-7; a status declared mirror SHALL NOT be presented as fact, and a status retired mirror SHALL be answered only historically. - Controls: Freshness check mandatory in the answering recipe; citation discipline (master named, harvest time stated); minimum-interval throttle on hot datasets; on-demand refresh always goes through the full MIR-2 path (raw capture, sidecar, attestation included), never a shortcut fetch; grant liveness validated at the gate at act time. - Tier: recommended - Variants: Solo: the Owner-Steward's own reading habit, supported by the freshness flags. Team: enforced in shared answering tooling. Federated: peers receive freshness stamps with each Projection and apply their own before-use policy. Manual: human checks the dashboard first. Hybrid: Agent checks and discloses, human decides whether to wait for refresh. Autonomous: T3 check-and-refresh inline in agent answering. Actuation: ACT-9 independent verification widens this pattern to the moment of verification; the verifying read runs under a pipeline identity disjoint from the one that fed the original signal (see MIR-2 controls). - Metrics: Percentage of answers carrying freshness citations; stale-read rate (uses beyond the limit without disclosure, target zero); on-demand refresh latency; sampled refusal correctness. - Failure modes: Agent answers from a stale mirror without disclosure (guard: freshness check wired into the answer path and audited by sampling). Refresh loop hammers a hot dataset (guard: throttle). On-demand fetch bypasses raw capture and provenance (guard: single ingest path rule). A declared mirror is quoted as current fact (guard: status gate in step 6). A quarantined but time-fresh mirror is served unflagged (guard: full freshness state read in step 3). ### MIR-6 Freshness SLA definition and monitoring - Purpose: Define per dataset how fresh is fresh enough (cadence, staleness limit, criticality) and continuously compare actual freshness against it, so staleness is an alarm and never a surprise. - Trigger: A new register entry needing an SLA; scheduled SLA review; repeated breach of an existing SLA; a Consumer complaint about stale data. - Actors: Steward (defines SLAs); Owner (signs off SLAs for critical datasets, recorded as GOV-1 decisions); Agent; Auditor (reviews SLA realism against breach history). An Agent MAY execute step 1 at T2 and steps 3 to 6 at T3 (continuous monitoring and alerting); step 2 (setting or changing an SLA) SHALL remain T1 (Agent proposes, human approves each act). - Inputs / Outputs: Inputs: dataset criticality, source change rate, consumption patterns, breach history, GOV-5 capacity and cost telemetry, the CON-13 consumer register. Outputs: SLA parameters recorded in the register (cadence, staleness_limit), freshness state per dataset (fresh, aging, stale, quarantined), warnings and escalations, freshness dashboard, SLA review report, breach findings filed into QSC-11. freshness_state is a palette-defined extension field additional to the Mastership Register schema (Data-Mastership 6), distinct from the canonical status enum; quarantine never touches status; trust-state (quarantined) and flow-state (suspended) are independent axes that may co-exist. - Steps: 1. Propose SLA parameters for a dataset from its criticality, how fast its source actually changes, and how it is consumed. 2. Steward approves (Owner co-signs for critical datasets, recorded as a GOV-1 decision Event); record the SLA in the register as a versioned change. 3. Continuously compute each mirrored dataset's freshness state from its last harvest time and its limit; the monitor runs as a QSC-15 standing job with an independent heartbeat. 4. Gateway: limit approaching (configurable lead fraction)? Emit an early warning to the responsible Agent and Steward so refresh can happen before breach. 5. Gateway: limit exceeded? Trigger MIR-8 quarantine for the dataset, escalate, and file the breach finding into QSC-11. 6. Publish the freshness dashboard so any Consumer can see master, last harvest and state without leaving the model; dependent Consumers are resolved against CON-13; freshness and quarantine states feed ACT-2 signal qualification and CTX-1 package stamping as mandatory inputs. 7. On schedule, review SLAs against breach history, consumption reality and GOV-5 cost and capacity telemetry; adjust via step 2. This review invokes the generic register-recertification pattern in COMMON and MAY be satisfied by the consolidated quarterly review of the Solo/Minimal profile. - Controls: SLA changes are register changes (versioned Events, no silent edits); alarms cannot be muted without a recorded decision; a conservative default limit applies to any mirror lacking an explicit SLA; dashboard visibility to Consumers is mandatory; a silently dead monitor opens a QSC-14 incident via QSC-15 meta-monitoring. - Tier: core - Variants: Solo: three lines of YAML and a weekly glance at one dashboard. Team: per-bundle SLAs with a shared alerting channel. Federated: SLA states travel outward as part of projection metadata; contracts MAY declare the coherence window peers accept. Manual: calendar-driven review. Hybrid: Agent monitors, Steward tunes (typical). Autonomous: T3 monitoring with T1 threshold changes. - Metrics: Percentage of mirrored datasets with an explicit SLA; SLA breach rate; mean time in breach; warning lead time before breach. - Failure modes: Vanity SLA that is never met (guard: auto-flag entries breaching more than N times per period for forced review with GOV-5 cost input). No SLA so nothing ever alarms (guard: conservative default limit). The monitor itself dies silently (guard: QSC-15 independent heartbeat escalating into QSC-14). Limits copy-pasted across dissimilar datasets (guard: Auditor realism review in step 7). ### MIR-7 Drift detection between reality and model, and model and projections - Purpose: Detect divergence on both mirror surfaces: between external masters and their in-model mirrors (reality versus model), and between model-mastered records and their write-back projections (model versus its projections). MIR-7 is the palette's sole drift-detection engine, per Data-Mastership (ARCH-018) 7, and the sole emitter of drift Events; every other family consumes those Events, none re-detects. Record every drift and resolve it only in the declared direction. - Trigger: Every flow run (minimum, per Data-Mastership (ARCH-018) 7); scheduled drift sweep; suspicion raised by MIR-4 reconciliation; a Consumer or Auditor report. - Actors: Agent; Steward (owns contested resolutions); Auditor (samples resolutions and comparison quality). An Agent MAY execute steps 1 to 4 at T3 (detection and recording), step 5 at T2 for mature pipelines (mechanical resolution, Steward reviews samples) and at T1 for new ones (Agent proposes, human approves each act); step 6 SHALL remain T1 (Agent proposes, human approves each act). - Inputs / Outputs: Inputs: master state, copy state, conflict_rule per dataset, comparison basis definitions. Outputs: drift Events (what, where, magnitude, direction), resolutions (re-harvest or republication), routings to CON-11 (intended external edits) and ACT-10 (actuation-linked divergence), escalations to MIR-1, clean-check records, recurring-drift analysis. - Steps: 1. For each dataset in scope, compute the comparison basis: a content hash over the comparable part at minimum, plus record counts and key fields where defined. 2. Compare master state against copy state (mirror or projection). 3. Gateway: drift found? If none, record the clean check and stop. 4. Record the drift Event with what diverged, in which direction, and by how much; drift records are immutable. Gateway: is the divergence cause-linked to an open actuation command? Hand it to ACT-10 with the drift Event; ACT-10 consumes only actuation-linked divergence handed over here or by ACT-9. 5. Gateway: does the entry's conflict_rule give a mechanical resolution? For external-mastered: re-harvest, the external system wins. For model-mastered: republish, the model wins; edits found in the external copy SHALL NOT be merged silently and SHALL be routed to CON-11, the sole capture and classification path for intended external edits, triggered by this Event. 6. Gateway: not mechanically resolvable (master disputed, partition itself wrong)? Escalate to the Steward; if mastership must change, escalate as a mastership-change proposal to MIR-1 (the sole register executor). 7. Re-run the comparison to verify resolution; close the drift record with a reason code. - Controls: Resolution SHALL occur only in the direction the conflict_rule declares; per-incident judgment resolution is non-conforming. Hand-tuned projections are forks, not projections, and SHALL be regenerated. Drift records immutable and aged (open drift beyond its limit escalates). Prefer automated daily checks so divergence is noticed by machinery, not by embarrassment. QSC-9 verifies that MIR-7 ran on cadence and samples the honesty of its records; on mismatch it raises a finding to MIR-7 and never executes regeneration or routing itself. FED-6 evaluates boundary drift using this engine under the governing contract. - Tier: core - Variants: Solo: a hash check bundled into each publish and harvest script; under the Solo/Minimal profile in COMMON, one weekly agent-run sweep with one combined Event satisfies the mechanical steps of MIR-3 and MIR-7 together. Team: nightly sweep job alerting Stewards. Federated: the model-versus-projection surface extends across the boundary; drift in federated Projections is recorded by this engine and evaluated under the governing contract, pursuing semantic coherence rather than byte equality, with resolution routed via FED-9. Manual: eyeball diff on a checklist. Hybrid: Agent detects, human resolves contested cases (typical). Autonomous: T3 detect and mechanically resolve, full audit trail. - Metrics: Drift check coverage (percentage of flows with a comparison); mean time to detect; mean time to resolve; recurring-drift rate per dataset. - Failure modes: Drift resolved by overwriting the master (guard: tooling enforces the declared direction; the resolving Agent has write access only to the copy side). Comparison too coarse to notice field-level drift (guard: Auditor sampling with field-level diffs). External edits to a write-back projection silently merged (guard: mandatory CON-11 routing, never merge). A second detection loop grows in another family and double-processes the same edit (guard: sole-engine rule; QSC-9 verifies, CON-11 classifies, ACT-10 consumes, none detect). Drift alarms accumulate ignored (guard: age SLA on open drift records with escalation). ### MIR-8 Staleness quarantine - Purpose: Mark data no longer trusted (expired mirrors, failed pipelines, unresolved drift, hazard-flagged captures, dubious sources) so every Consumer and Agent sees the distrust explicitly. Quarantine is the palette's readable-but-flagged trust marking (see the family glossary): it marks trust, it never deletes data, and it is distinct from FED-8 admission quarantine and QSC-9 integrity hold. - Trigger: SLA expiry from MIR-6; a hazard-screening flag from MIR-2 step 5; harvest failures beyond the retry policy; drift open beyond its limit; source system retirement; discretionary Steward decision. - Actors: Agent; Steward (discretionary quarantine and every release); Consumers (see the flags); Auditor (verifies flags actually reach read surfaces). An Agent MAY execute steps 1 to 3 and 5 at T3 for threshold-triggered quarantine, step 4 at T2; steps 6 and 7 (remediation sign-off and release) SHALL remain T1 (Agent proposes, human approves each act). - Inputs / Outputs: Inputs: quarantine trigger with reason code, register entry, freshness metadata, the CON-13 consumer register. Outputs: quarantined freshness state, flags propagated to all consumption surfaces, notifications, remediation record, release Event. - Steps: 1. Receive the quarantine trigger and its reason code. 2. Set the dataset's freshness state to quarantined in the register and freshness metadata; the data remains readable but flagged; the canonical status field is never touched (trust-state and flow-state are independent axes). 3. Propagate the flag to every consumption surface: answering recipes, dashboards, generated artifacts, outbound Projections and packages, ACT-2 signal qualification and CTX-1 context packages (where the quarantine state is a mandatory input: it blocks emission or forces degraded confidence with Steward escalation per class rule, and hard-blocked datasets are excluded from packages). A Consumer SHALL see the warning wherever the data appears. 4. Gateway: does policy demand a hard block (security, legal, contract breach)? If yes, suspend the affected Projection rather than only flagging: via GOV-7 for internal grants and channels, via FED-3 for federation grants; the object and its data remain intact (projection lifecycle, not object lifecycle). 5. Notify the Steward and the dependent Consumers resolved against CON-13. 6. Remediate: fix the pipeline, re-harvest, resolve the drift, or re-scope the dataset. 7. Gateway: exit criteria met (a verified fresh harvest exists and related drift records are closed)? The Steward releases the quarantine; the release is recorded as an Event with rationale; contested releases escalate as GOV-1 decisions. - Controls: Quarantine SHALL NOT be removable without a verified fresh state; flags travel with citations and provenance; quarantined data SHALL NOT be presented as current anywhere; quarantine is reversible marking, never deletion; hazard-flagged content additionally requires the Steward to review the MIR-2 screening report before release. - Tier: core - Variants: Solo: a single quarantined list the Owner-Steward keeps honest. Team: automatic threshold quarantine with a weekly release review. Federated: quarantine state accompanies Projections so peers inherit the distrust signal; contracts MAY require notification on quarantine of consumed datasets. Manual: Steward flips the flag by hand. Hybrid: Agent flags, Steward releases (typical). Autonomous: T3 flagging with T1 release always retained. - Metrics: Time from trigger to quarantine; mean quarantine duration; percentage of sampled quarantined reads that displayed the flag (target 100), with the sample explicitly including ACT-2 signal qualifications and CTX-1 context packages; repeat-quarantine rate per dataset. - Failure modes: Flag set in the register but invisible at read time (guard: read-path check plus Auditor sampling of consumption surfaces including signal evaluations and packages). A quarantined but time-fresh dataset qualifies signals or enters packages unflagged (guard: step 3 mandatory-input wiring to ACT-2 and CTX-1). Quarantine misused as deletion (guard: data and history preserved by rule; only the trust state changes). Silent release under delivery pressure (guard: release requires a recorded Event and a verified harvest). Everything ends up quarantined and flags lose meaning (guard: SLA realism review in MIR-6 step 7). ### MIR-9 Archival of superseded states - Purpose: Preserve superseded model states, mirrors and captures as reconstructable history, so actualization is non-destructive: the model changes its statements without losing its memory, and historical references never break. MIR-9 is the palette's lifecycle and history persistence process: other families (CON-8 record correction, CON-12 migration, FED-11 terminal packages, MIR-11 terminal archival) persist history through it. - Trigger: Any actualization replacing prior state; a lifecycle transition to Archived or Retired (canonical state vocabulary per Lifecycle, MU-V2-CORE-011, 4 to 5); a source system being retired; a CON-12 migration retaining raw pre-migration state; MIR-11 terminal archival; periodic retention compaction. - Actors: Agent; Steward (applies retention and compaction policy); Owner (approves any physical deletion permitted by policy; non-delegable consent, recorded as a GOV-1 decision); Auditor (verifies reconstructability). An Agent MAY execute steps 1 to 3 and 6 at T3 (mechanical archival and freeze) and step 4 at T2 (applying the approved policy); the retention policy itself is authored and versioned in GOV-2, not here. - Inputs / Outputs: Inputs: superseding updates, lifecycle Events, the GOV-2 retention policy. Outputs: retained prior states (version history or explicit archive), supersession Events linking old and new state, frozen retired mirrors, reconstruction drill reports. - Steps: 1. On every superseding update, ensure the prior state is retained: version-controlled history by default, or an explicit archive location for bulk states. 2. Record the supersession Event linking the old and new state, with its reason code (MIR-10). 3. Gateway: is a source system retiring? Freeze the final export as a retired mirror (register status retired); it becomes a read-only frozen archive, answered only historically (as of the final export). 4. Apply the retention policy authored and versioned in GOV-2: what may compact, what is kept forever. Identity, provenance, ownership history, relationships, Events and semantic references SHALL survive archival in all cases; historical integrity takes precedence over physical deletion, per Lifecycle (MU-V2-CORE-011) 13. The reconstruction drill, retention compaction and Owner-approved deletion are palette elaborations on top of that cited invariant. 5. Gateway: does policy permit physical deletion of a compacted class? Only with recorded Owner approval (a GOV-1 decision; the consent is non-delegable); otherwise retain. 6. Run a periodic reconstruction drill: rebuild a chosen past state from the archive and verify it; the drill SHALL also confirm restorability from the QSC-13 offsite copies. The drill MAY be satisfied within the consolidated quarterly review of the Solo/Minimal profile in COMMON, following the generic recertification pattern. 7. Verify that archival never mutated canonical Identity and that historical references still resolve. - Controls: Versioned storage mandatory for semantic content; frozen archives read-only; reconstruction drill as a recurring gate; conservative default retention (keep everything) until a GOV-2 policy exists; deletion only by Owner-approved policy; the archive lies within QSC-13 backup scope (offsite immutable copies, separate custody), and a drill that cannot restore from QSC-13 copies is a failed drill. - Tier: core - Variants: Solo: the version control system is the archive; the drill is a checkout of an old revision. Team: explicit archive locations for bulk mirrors plus VCS for records. Federated: peers may retain projections of states the origin later archived; archival at the origin SHALL NOT invalidate the peer's historical references. Manual: zip-and-label. Hybrid: Agent archives, Steward compacts (typical). Autonomous: T3 archival with quarterly drill review. - Metrics: Percentage of supersessions with retained prior state (target 100); reconstruction drill success rate (including QSC-13 restore checks); integrity check pass rate on retired mirrors; storage consumption against the GOV-2 retention policy (with GOV-5 projections). - Failure modes: Overwrite-in-place quietly destroys history (guard: versioned storage as a structural requirement, checked by validation). Archive rot: unreadable formats or broken links years later (guard: periodic reconstruction drill). A retired mirror gets edited to fix the past (guard: read-only enforcement; corrections live as annotated model-mastered statements about the archive). Retention compaction deletes evidence later needed (guard: conservative defaults, Owner approval via GOV-1, and the always-survives set in step 4). In-model history survives but the whole repository is lost (guard: QSC-13 backup scope and the drill's offsite restore check). ### MIR-10 Reasons-for-update taxonomy - Purpose: Maintain a controlled taxonomy of why updates happen and stamp every actualization Event with a reason code, so the model's change history is explainable, auditable and analyzable rather than a stream of anonymous edits. The stamping rule extends beyond MIR: transition Events of CON-6, CON-7 and CON-8 and supersession Events of ACT-10 and ACT-11 carry codes from this same taxonomy, mapped to existing base codes. - Trigger: Model adoption (initial taxonomy); an update whose reason fits no existing code; scheduled taxonomy review; an analysis request. - Actors: Steward (owns the taxonomy); Agent; Auditor (analyzes reason distributions). An Agent MAY execute step 2 at T3 (stamping routine updates) and steps 3 and 4 at T2 (queueing unclassified reasons, drafting analysis); taxonomy changes in step 5 SHALL remain T1 (Agent proposes, human approves each act). - Inputs / Outputs: Inputs: the base taxonomy, actualization Events from MIR-2 through MIR-9, transition Events from CON-6/CON-7/CON-8, supersession Events from ACT-10/ACT-11, actuation-verification stamps from ACT-8 step 6 and ACT-9 step 5, task-reopen Events from CTX-5. Outputs: reason-coded Events, an unclassified queue, taxonomy versions, periodic reason-distribution analysis. - Steps: 1. Adopt the base taxonomy as a model-mastered dataset. Base codes: scheduled-refresh; source-event; use-driven; actuation-verification (an ingest serving an ACT-8 forced re-harvest or ACT-9 independent verification; stamped by ACT-8 step 6 and ACT-9 step 5); human-report; correction (an error in the model was found and fixed); drift-resolution; structural-change (mastership, SLA or scope changed); quarantine or release; supersession-archival; migration-backfill (executed via CON-12); insufficient-context (stamped on task-reopen Events, the computable source for CTX-5's rework metric). 2. Every actualization Event emitted by MIR-2 through MIR-9, every transition Event of CON-6, CON-7 and CON-8, and every supersession Event of ACT-10 and ACT-11 SHALL carry exactly one primary reason code; secondary codes MAY be added. A composite Event emitted by the editorial fast lane (per COMMON) carries its reason code once and is conformant stamping evidence. 3. Gateway: does no code fit? Stamp unclassified with free text and queue the case for taxonomy review; the unclassified queue has an age limit. 4. On schedule, analyze the reason distribution per dataset: a high correction rate signals a source or transform quality problem; zero use-driven updates signal dead data; a spike in drift-resolution signals a leaking projection; a spike in actuation-verification signals an unstable actuation loop. 5. Evolve the taxonomy as a versioned Steward-approved change, following the generic register-recertification pattern in COMMON for the scheduled review. Codes SHALL be deprecated, never deleted or redefined; historical Events keep their original meaning. - Controls: Reason code mandatory on every covered Event (validation rejects unstamped updates); unclassified queue age limit; deprecate-not-redefine rule; analysis findings published to the Steward. - Tier: recommended - Variants: Solo: the base twelve codes, untouched, plus an annual glance at the distribution. Team: per-bundle distribution reports feeding retrospectives. Federated: reason codes travel with synchronization Events so peers can distinguish a correction from a routine refresh when deciding how to react. Manual: reason typed into the commit message following a convention. Hybrid: Agent stamps, Steward reviews the unclassified queue (typical). Autonomous: T3 stamping with distribution anomaly alerts. - Metrics: Percentage of covered Events carrying a reason code (target 100); unclassified rate; taxonomy review cadence adherence; correction-rate trend per dataset. - Failure modes: Everything stamped with one default code, destroying the signal (guard: Auditor distribution check with an entropy floor). Taxonomy explosion into dozens of near-duplicates (guard: T1 Steward gate and deduplication at review). Codes quietly reinterpreted over time (guard: deprecate-not-redefine rule). Reasons recorded but never read (guard: scheduled analysis in step 4 with published findings). Corrections made through the CON chain stay invisible to the distribution analysis (guard: the extended stamping rule in step 2). ### MIR-11 Model retirement and succession - Purpose: End a model or Dimension lawfully: an orchestrated decommission that leaves no zombie mirrors in peer Universes, no live credentials or grants, no standing jobs alarming against a dead model, and preserves the model's full history with a durable tombstone and successor pointers. Retirement is a lifecycle act, never deletion. - Trigger: An Owner decision to retire the model, recorded as a GOV-1 decision Event; succession or merger into a successor model; a sustained non-viability finding from GOV-5 resourcing accepted by the Owner. - Actors: Owner (orders retirement; the consent is non-delegable in substance); Steward (runs the decommission runbook); Agent; Auditor (engaged via GOV-6; certifies closure); federation partners and Consumers (notified). An Agent MAY execute the mechanical teardown in steps 2 to 5 and the archival mechanics of step 7 at T2; steps 1, 6, 8 and 9 involve the Owner decision, the closing conformance statement and the certification and SHALL remain T1 (Agent proposes, human approves each act), with the Owner decision and the Auditor certification non-delegable. - Inputs / Outputs: Inputs: the GOV-1 retirement decision, the federation register (FED), grant registers (GOV-7, FED-3), the Delegation Contract roster (CTX-9), the QSC-15 standing-job registry, the CON-13 consumer register, the GOV-2 retention policy, the GOV-8 credential inventory. Outputs: sequenced termination Events, final QSC-4 validation report and QSC-10 conformance snapshot, terminal MIR-9 archive with declared custody, published tombstone with successor pointers, Auditor closure certification, the terminal Event. - Steps: 1. Record the Owner's retirement decision as a GOV-1 decision Event and freeze new intake: no new register entries (MIR-1), no new grants (GOV-7, FED-3), no new Delegation Contracts (CTX-9), no new federations. 2. Notify all registered Consumers, resolved against CON-13, with the retirement schedule and successor pointers; track notification to completion. 3. Sequence FED-11 per federation partner: terminate or hand over each federation under its contract, collecting partner acknowledgments so no peer retains an unmarked live mirror. 4. Revoke all Delegation Contracts via CTX-9 and sweep GOV-7 and FED-3 grants to zero live grants within the declared revocation TTL; run the gate-side probe verifying no orphan rights remain. 5. Tear down standing jobs, schedulers and monitors via QSC-15 until the job registry for this model is empty; retire credentials and keys via GOV-8. 6. Run the final QSC-4 validation and issue the final QSC-10 conformance snapshot as the model's closing statement. 7. Execute terminal archival via MIR-9: full model, Event history, registers and evidence, under the GOV-2 retention policy, with declared custody and QSC-13 offsite copies. 8. Publish the tombstone: a minimal durable record naming the model, its lifespan, its terminal Event, the custody of its archive and its successor pointers, with redirects for inbound references where feasible. 9. The Auditor certifies closure: zero live credentials, zero live grants, zero running jobs, notification completeness against CON-13, archive reconstructable; the certification is recorded as the terminal Event. - Controls: Retirement SHALL NOT proceed without the recorded Owner decision (non-delegable). Sequencing is mandatory: freeze, then notification, then federations, then grants and contracts, then jobs and credentials, then snapshot, then archival, then tombstone, then certification. No physical deletion during retirement beyond what the GOV-2 retention policy permits with Owner approval. The certifying Auditor SHALL NOT have executed the runbook. Tombstone and archive custody survive the model. - Tier: core - Variants: Solo: the runbook shrinks to grants, jobs, archive and tombstone; an external peer Auditor (engaged via GOV-6) certifies closure. Team: Steward-led runbook with per-family teardown checklists. Federated: FED-11 sequencing dominates the timeline; peers retain historical projections per MIR-9's federated rule, marked as originating from a retired model. Manual: a printed checklist walked once, every checkmark an Event. Hybrid: Agent executes teardown at T2, humans hold the decision and certification (typical). Autonomous: not applicable; the decision and certification are never autonomous. MOS example (external reference Dimension, orkestron-ai/meta-orchestrator-state): retiring a Dimension without stranding its citizen-agent contracts or its peers' historical references. - Metrics: Residual live credentials, grants and jobs at certification (target zero); consumer notification completeness against CON-13 (target 100); time from decision to certification; successor-pointer resolution rate after retirement. - Failure modes: Zombie mirrors persist in peer Universes (guard: FED-11 per-partner sequencing with acknowledgment collection). Live credentials survive teardown (guard: GOV-8 retirement sweep plus the Auditor's zero-residual check). Standing jobs alarm forever against a dead model (guard: QSC-15 registry emptied and verified in step 5). History lost in the rush to shut down (guard: terminal MIR-9 archival with QSC-13 copies gated before the terminal Event). Retirement stalls half-done, leaving a model neither alive nor closed (guard: sequenced runbook with per-step Events and Auditor certification as the only lawful end state).