# CON: contribution and entry control This family governs how information enters a Vercy-conformant meta-model and how that entry is controlled. Its doctrine follows from three canon invariants: every file has a declared meaning (ARCH-017), every dataset has exactly one master (ARCH-018), and every change is an explicit, traceable event (Lifecycle, Change Process). From these, the family derives its four laws: 1. **No side doors for authored content.** Nothing authored becomes part of the model except through the declared entry path (CON-1). A commit that bypassed intake is a defect the coverage walker must surface. Harvested content is different by design: 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. 2. **No anonymous facts.** Every entry carries provenance: who asserted it, when, from what source, under which authority, and why (CON-2). An entry without provenance is not admissible. For harvested content the provenance of record is the MIR-2 sidecar; CON-2 references it and never re-authors it. 3. **Write only where truth lives.** Edits land only in each dataset's System of Record. Attempts to edit mirrors, raw captures or generated artifacts are refused and routed to the master (CON-5). A dataset absent from the register with no external system involved is model-mastered and authored in place, per the Data-Mastership 6 default. 4. **Humans stay accountable, agents execute.** Stewards delegate heavily: most steps in this family run at T2 or T3 under Delegation Contracts (tiers per the palette preamble), but approval of breaking or contested entries, acceptance of security-critical datasets, and the granting of entry rights remain human acts, and CON-9 rulings are non-delegable in substance. Accountability never transfers to the Agent. The Delegation Contract lifecycle itself is CTX-9's; CON holds only the entry-rights register that references it. Two cross-family instruments shape this family's execution. The security-critical dataset class (defined in COMMON) is structurally ineligible for auto-approval lanes: CON-4's gateway enforces the ineligibility mechanically, acceptance is always T1 with a second human reviewer, and the diff-based lane classifier that decides lane eligibility is a GOV-2 artifact that never trusts the submitting agent's own classification. The editorial fast lane (defined in COMMON) runs the opposite direction: for editorial or corrective changes under the declared size threshold, one T3 agent pipeline emits a single composite Event that is conformant evidence for CON-1, CON-2, CON-3, CON-4 and CON-6. Vocabulary (per the COMMON glossary): quarantine is MIR-8's readable-but-flagged trust marking (also the MIR-6 freshness state); admission quarantine is FED-8's inbound holding, unreadable until promoted; integrity hold is QSC-9's exclusion marker. CON's intake hold is none of these: a pre-admission parking state for submissions that have not yet passed the identity or provenance gates. The family scales from a solo Owner-Steward with one notebook-sized model (where intake, review and approval collapse into a single person plus a T3 gatekeeper agent, and the Solo/Minimal conformance profile in COMMON consolidates the periodic reviews) up to the MOS stress case, a state-scale Universe where thousands of AI citizen-agents contribute continuously, bulk imports load whole world-model corpora, and disputes over entries are routine (MOS is a reference to the external reference Dimension repository, orkestron-ai/meta-orchestrator-state, not to the standard). The palette supports that scale because validation gates (CON-3), auto-approval lanes (CON-4) and mastership enforcement (CON-5) are fully mechanical, while human attention is reserved for executing the GOV-2 approval matrix, disputes and rights grants. Orkestron production models (the Orkestron.AI product model, the DevTeam.Games platform model) serve as reference implementations of the mastership and drift-capture patterns. Core processes (no conformant model operates without them): CON-1, CON-2, CON-3, CON-4, CON-5, CON-6, CON-8, CON-10, CON-11. Recommended: CON-7, CON-9, CON-12, CON-13. ## Interfaces to other families - **GOV:** GOV-1 records the Owner rulings and appeals that CON-9 escalates and the migration adoption decisions that trigger CON-12. GOV-2 authors and versions the approval matrix, the auto-approval lane criteria, the diff-based lane classifier, the gate configurations and the revocation-propagation TTL; CON-3, CON-4 and CON-10 execute these artifacts and never author them. GOV-3 appoints the Stewards and deputies the CON-4 matrix names. GOV-5 receives consumer and dependency load reports from CON-13. GOV-6 engages the Auditor who samples CON-4 approvals, CON-7 imports and CON-12 migrations. GOV-7 issues the internal access grants CON-13 mirrors into consumption entries. GOV-8 supplies the credentials for the channel access CON-10 provisions. - **MIR:** MIR-1 is the sole executor of Mastership Register changes: CON-7 step 1 invokes it (including its Owner gate for new external systems) before any byte moves, CON-9 step 4 escalates mastership disputes to it, and CON-5/CON-6 register updates execute through it. MIR-2 is intake and approval for harvested content under an active `sources.yaml` entry and the single owner of the harvest provenance sidecar that CON-2 references; CON-7 raw landings follow MIR-2's discipline. MIR-7, the sole drift-detection engine, emits the drift Events that trigger CON-11, and CON-6 step 7 triggers its republish-and-check path. MIR-8 quarantine notifications resolve addressees against CON-13. MIR-9 persists superseded states for CON-6 and CON-8 and the pre-migration snapshots for CON-12. MIR-10 supplies the base reason-code taxonomy stamped on CON-6, CON-7 and CON-8 transition Events. - **ACT:** ACT decision, command and intent Event appends are registered CON-1 channels executing through the CON chain, with the declared mechanical auto-approval lane in CON-4 for mechanical event appends. ACT-10 supersession notices resolve their addressees against CON-13; ACT-10 routes register changes to MIR-1 and catalog or effector changes to ACT-1/ACT-3, while its supersession Events carry MIR-10 reason codes like CON's own. - **CTX:** CTX-5 write-back sets are a registered CON-1 channel; CTX-7 is the concurrency-integration step that feeds CON-4, not a parallel approval authority. CTX-9 is the single System of Record for the Delegation Contract lifecycle: CON-10 obtains contracts by reference, entry rights die with their contract, and CTX-9 suspension and revocation Events propagate to the CON-10 entry-rights register and channel teardown within the GOV-2 TTL, verified by a gate-side probe. CTX-1 packages consume CON-2 provenance metadata and CON-13 consumer profiles. - **FED:** Proposals from partner Universes enter CON-1 under their Federation Contract, and their payloads reach CON only after FED-8 admission quarantine and promotion. CON-8 retraction notices propagate under Federation Contract disclosure terms, and FED-11 reads CON-13 for partner-side consumers of frozen mirrors. Disputes crossing sovereignty boundaries leave CON-9 for FED-9. CON-12 peer notification uses FED-7 cross-version mappings through the declared compatibility window. - **QSC:** CON emits the raw material audits run on: validation reports (CON-3), approval Events with rationale (CON-4), provenance completeness stats (CON-2), auto-approval escape and mismatch findings, and the append-only change history (CON-6), consumed by QSC-5 and QSC-9. QSC-9 verifies that MIR-7 and the CON gates ran on cadence and continuously anchors the hashes of the security-critical dataset class CON-4 protects. QSC-11 receives lane escape findings and CON-13 dependency reports as debt intake. QSC-14 receives TTL-breach and residual-authority incidents from CON-10 and operational incidents escalated from dead CON standing jobs. QSC-15 runs and meta-monitors CON's standing jobs: the CON-3 link-index full recomputation sweep, the recertification schedules of CON-10 and CON-13, and gate automation health. - **Structure and manifest authoring is CON territory:** manifest kind rules, exclusion lists and layout declarations are model-mastered content authored through the CON chain, executed as law by CON-3's gates and maintained through CON-6's structural changes; the coverage walker is CON-6's merge invariant, and fresh walk reports travel with every structural change. ### CON-1 Contribution intake - Purpose: Receive and register every proposed authored entry into the model, whether from a human or an agent, whether a structured record or raw material, and route it into the correct entry path. Intake is the single front door for authored contributions: authored content that did not pass it SHALL NOT become part of the model. Harvested content does not pass here: 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. - Trigger: A Contributor submits content through any accepted channel (change proposal, pull request, message, form, agent proposal); CON-11 forwards a sponsored proposal packaging an intended external edit; an ACT decision, command or intent Event append arrives on its registered channel; a CTX-5 write-back set arrives on its registered channel; a proposal arrives from a partner Universe under its Federation Contract (after FED-8 admission quarantine and promotion). - Actors: Contributor submits. Steward owns the intake queue and its routing policy. Agent MAY classify and route submissions at T2 and MAY register and acknowledge them at T3; an Agent SHALL NOT silently discard a submission at any tier. - Inputs / Outputs: Inputs: the submission, the repository manifest and kind rules (ARCH-017), the Mastership Register (`sources.yaml`), the entry-rights register from CON-10. Outputs: a registered contribution with a stable intake identifier, an intake Event, a routing decision (structured path, raw path, external-master routing, or rejection), and, whenever a routing decision is later changed, a mandatory re-routing Event referencing the intake identifier. - Steps: 1. Receive the submission and assign an intake identifier (Event: contribution received). 2. Identify the Contributor and check entry rights against the CON-10 register; the gate validates the citing Delegation Contract's liveness at act time (COMMON revocation rule), never trusting the agent to stop itself. For sponsored proposals from CON-11, the rights check resolves against the packaging Agent's Delegation Contract; the external editor appears only in provenance. Gateway: rights valid for this dataset and kind? If no, reject with reason or route the requester to CON-10 onboarding; unknown identities go to the intake hold, never to merge. 3. Gateway: structured or raw? Structured records proceed on the record path; authored raw material (documents, transcripts, submitted captures) is landed under `raw///` untouched, with a provenance sidecar via CON-2. 4. Resolve the target dataset in `sources.yaml`. Gateway: is the model the master? If the dataset is external-mastered, hand off to CON-5 for routing to the master system. 5. Invoke CON-2 to capture full provenance for the submission. 6. Queue the contribution for CON-3 validation gates and acknowledge receipt to the Contributor. Any later change of the routing decision SHALL be recorded as a re-routing Event referencing the intake identifier. - Controls: Identity and entry-rights check before any content is accepted, with contract liveness validated at the gate at act time; mandatory dataset lookup before routing; raw material SHALL never be edited during intake; submissions from unregistered actors SHALL be held in the intake hold, not merged; the harvest exclusivity sentence of the Purpose is normative; mechanical ACT and CTX Event appends ride the declared mechanical auto-approval lane in CON-4, subject to the GOV-2 lane classifier; the COMMON editorial fast lane's composite Event is conformant evidence for this card. - Tier: core - Variants: Solo: the Owner-Steward is the only human Contributor and intake degenerates to a gatekeeper Agent (T3) registering the Steward's own edits; most editorial changes ride the COMMON editorial fast lane. Team: a shared queue with per-dataset routing. Federated: proposals arriving from partner Universes enter through the same door but are additionally checked against the governing Federation Contract, and their payloads reach CON-1 only after FED-8 admission quarantine and promotion. Manual execution is a checklist; hybrid uses an Agent for classification with human routing decisions; autonomous runs the whole intake at T3 with sampled review. - Metrics: Median intake-to-routing-decision time; percentage of submissions auto-routed correctly, computed from re-routing Events; rejection rate at intake; count of merges detected that bypassed intake (target zero). - Failure modes: Direct commits bypassing intake (guard: coverage walker plus repository branch protection; every orphan file triggers an intake audit). Harvest batches erroneously re-processed through CON-1, stalling scheduled refreshes on a review queue (guard: the harvest exclusivity sentence; the register entry is the standing authorization). Raw material misclassified as a structured record and hand-polished (guard: origin classification at step 3 is mechanical, by channel and location). Unknown contributor content merged on urgency (guard: intake hold, no merge without a rights check). ### CON-2 Provenance capture - Purpose: Bind every entry to its full provenance: who asserted it, when, from what source, under what authority, and why. Provenance is what lets downstream trust machinery (validation V3-02, the Provenance Graph, federation trust) function at all. - Trigger: Every contribution accepted by CON-1; every generation run producing artifacts; every correction or retraction in CON-8. Harvest runs are excluded: MIR-2 is the single owner of the harvest provenance sidecar, and CON-2 references that sidecar as the provenance of record for harvested-origin content. - Actors: Contributor supplies the rationale. Steward defines the provenance schema for the model. Agent SHALL execute the mechanical capture at T3: an agent that cannot complete provenance SHALL park the entry, not merge it. - Inputs / Outputs: Inputs: the contribution, actor identity, channel metadata, for agents the Delegation Contract identifier, for harvested-origin content the MIR-2 sidecar reference. Outputs: a completed provenance record (for authored raw datasets a `_provenance.yaml` sidecar: source, scope, capture time, tool, record count; for harvested content a reference to the MIR-2 sidecar), `assertedBy` and `derivedFrom` edges for the Provenance Graph, and a provenance-complete flag on the entry. - Steps: 1. Determine the asserting actor: human identity, or agent identity plus the Delegation Contract under which it acts. For sponsored proposals, the asserting actor is the packaging Agent under its contract; the external editor is recorded as the source of the assertion via `derivedFrom`, never as the rights-holding submitter. 2. Record the timestamp and the entry channel. 3. Classify the origin: authored, harvested, or generated (ARCH-017 section 9). Gateway: origin determinable? If not, hold the entry and escalate to the Steward. 4. For content of harvested origin, the provenance of record is the MIR-2 sidecar with its capture-time attestation (emitted by pipeline infrastructure the harvest Agent cannot write to, per COMMON); CON-2 links to it and SHALL NOT re-author it. For generated content, record generator and inputs. For authored raw submissions, write the sidecar at intake. 5. Capture the rationale (why this entry exists) from the Contributor. 6. Emit `assertedBy` and, where inputs are known, `derivedFrom` edges as part of the intake Event. 7. Gateway: provenance complete per the model's schema? If no, return to the Contributor; if yes, mark provenance-complete and release to CON-3. - Controls: No entry SHALL be admitted without complete provenance (enforces V3-02); agent contributions SHALL name their Delegation Contract; provenance records are append-only and SHALL never be edited after merge, only superseded; a harvested-origin entry lacking a MIR-2 sidecar reference SHALL be refused. - Tier: core - Variants: Solo: rationale MAY be a one-line commit message, but actor, time and origin remain mandatory; editorial changes riding the COMMON fast lane satisfy this card through the composite Event. Team: rationale references a discussion or Change Request. Federated: provenance additionally names the origin Universe and the Federation Contract. Fully autonomous at T3 in all variants; only missing-rationale escalations reach a human. - Metrics: Percentage of entries with complete provenance at first submission; count of provenance-incomplete holds per period; percentage of harvested-origin entries carrying a valid MIR-2 sidecar reference (target 100). - Failure modes: Agent contributions logged under a generic service identity, destroying accountability (guard: Delegation Contract ID is a required provenance field, validated at the gate). Rationale rot ("fix", "update") making history unauditable (guard: minimum rationale rules in the GOV-2 gate config, sampled by the Auditor). Harvest sidecars fabricated or re-authored after the fact (guard: sidecars are authored solely by MIR-2 in the same run, with capture-time attestation the harvest Agent cannot write to; CON-2 refuses harvested-origin entries without them). ### CON-3 Validation gates - Purpose: Apply mechanical admission checks to every contribution before it can reach review: syntax, structure and kind classification, schema conformance, naming and style, and link integrity. Gates make quality a property of the pipeline, not of reviewer vigilance. - Trigger: A contribution released by CON-2; a pre-merge check on any change set; scheduled re-validation of the whole model. - Actors: Agent SHALL run the gates at T3. GOV-2 authors and versions the gate configuration; CON-3 executes it. Contributor fixes reported failures. Auditor MAY review gate coverage. - Inputs / Outputs: Inputs: the contribution, schemas, the manifest's kind rules and exclusion list, naming conventions, the model's style rules, the model-wide link index. Outputs: an explainable validation report (check identifiers, pass or fail, reason), a pass or fail verdict, and for structural changes a fresh coverage-walk report. - Steps: 1. Run syntax validation (V0): every artifact parses. 2. Run structural validation (V1): the file is classified by exactly one kind rule or layer enumeration; no orphan, no ambiguous classification (ARCH-017 section 7); declared locations exist. 3. Run schema validation against the declared kind's schema and required fields. 4. Run naming and style checks: canonical names, identifier patterns, the model's editorial rules. 5. Run link integrity (V2) against the incrementally maintained model-wide link index: every internal reference resolves, including inbound references to the changed content; references to external masters resolve to a register entry. A scheduled full recomputation sweep (a standing job registered with QSC-15) is the integrity backstop that corrects index drift. 6. For contributions touching the normative rule base, run the policy consistency check: a change making the rule set unsatisfiable SHALL NOT pass. 7. Gateway: all gates pass? If no, return the explainable report to the Contributor (Event: validation failed). If yes, route to CON-4 (Event: validation passed). - Controls: Every check has a stable identifier and an explainable result; the gate configuration is a GOV-2 policy artifact that CON-3 executes; gate definitions belong to the security-critical dataset class (COMMON), so changes to them are accepted only at T1 with a second human reviewer through CON-4, and QSC-9 anchors their hashes continuously; no merge path exists that skips the gates; manifest kind rules and exclusion lists are model-mastered content authored through the CON chain (CON territory), executed here as law. - Tier: core - Variants: Solo: a local pre-commit hook plus the coverage walker; the link index MAY be the walker's own output. Team: gates run in shared automation on every proposed change. Federated: incoming federated content additionally passes V4 interoperability checks. Manual execution (a human running a checklist) conforms but SHOULD be temporary; hybrid and autonomous both run gates at T3. - Metrics: First-pass gate success rate; mean time from failure report to resubmission; count of defects found downstream that a gate should have caught (escaped defects, target zero); index-versus-sweep divergence findings per full recomputation (target zero). - Failure modes: Gates weakened to pass a deadline (guard: gate config changes are security-critical class, T1 plus second reviewer, visible in history). Orphan files accumulating via the exclusion list (guard: exclusion asserts no semantic content; Auditor samples exclusions). Link index drifting from reality so per-contribution checks pass while the model rots (guard: the scheduled full recomputation sweep is the backstop; divergences are findings, and a sweep that stops running is a QSC-15 escalation). ### CON-4 Review and approval - Purpose: Decide which entries need human approval and which are auto-approved, execute the review chain, and record every approval as a traceable Event. This is where Steward accountability is exercised. - Trigger: A contribution passes CON-3 validation gates; CTX-7 hands over a concurrency-merged change set (CTX-7 is the concurrency-integration step that feeds CON-4, not a parallel approval authority); a mechanical Event append arrives from the registered ACT or CTX channels for the declared mechanical lane. - Actors: Steward approves within their sections; additional reviewers as the approval matrix requires. Agent MAY pre-review at T2 (summarize the change, compute the diff, flag risks, propose a classification) and MAY auto-approve at T3 only within an explicitly declared auto-approval lane whose eligibility the GOV-2 classifier confirms. Approval of breaking changes SHALL be human; acceptance of security-critical datasets SHALL be T1 with a second human reviewer. - Inputs / Outputs: Inputs: the validated contribution, its provenance record, the approval matrix (a GOV-2 artifact CON-4 executes), the diff-based lane classifier verdict (a GOV-2 gate config), the change classification. Outputs: an approval or rejection Event with actor and rationale, a merged entry handed to CON-6, or a returned contribution. - Steps: 1. Classify the change on both axes of the Change Process: impact (editorial, corrective, evolutionary, breaking) and semantic change type (model-structure, meaning, contract, projection-behaviour, and so on). An Agent MAY propose the classification at T2, but the classification consumed by the lane gateway SHALL NOT originate from the submitting agent or its orchestrator. 2. Run the diff-based lane classifier (GOV-2 gate config): it forces human review whenever the diff touches normative keywords, schemas, identities, register entries, contracts or any security-critical dataset, regardless of the proposed classification; classification-versus-diff mismatches are logged as findings, not just escapes. Gateway: auto-approval lane? A change qualifies only if the classifier permits it and the lane's declared criteria hold (typically: editorial or corrective impact, low-risk dataset, all gates passed, contributor in good standing); the security-critical dataset class and sponsored (external-origin) proposals are structurally ineligible. If eligible, merge at T3 with a full audit trail (Event: auto-approved) and skip to step 7. 3. Gateway: does the change touch the security-critical dataset class (COMMON)? If yes, acceptance SHALL be at T1 with a second human reviewer, independent of any classification. 4. Assign reviewers per the approval matrix. Gateway: is the Contributor also the sole required approver? If the matrix forbids self-approval for this class, add an independent reviewer. 5. Reviewers assess meaning, placement and consequences; the Agent supplies impact analysis (what references this entry, what depends on it) from the Provenance Graph. 6. Gateway: approve, request changes, or reject? Requests return to the Contributor; rejections close with rationale. 7. Record the decision Event (actor, timestamp, classification, rationale) and hand approved entries to CON-6. - Controls: The approval matrix, lane criteria and lane classifier are GOV-2 authored, versioned artifacts that CON-4 executes; breaking and meaning-changing entries SHALL NOT be auto-approved; security-critical datasets and sponsored proposals are structurally ineligible for auto-approval, enforced in the step 2 gateway rather than by classification; self-approval limits per the matrix; every decision carries a rationale; auto-approval lanes are reviewed periodically against their escape rate; the COMMON editorial fast lane is a declared lane whose classifier is this same GOV-2 mechanism and whose composite Event is conformant evidence for this card. - Tier: core - Variants: Solo: the Owner-Steward approves everything; the practical control is the T2 Agent pre-review acting as a second pair of eyes, plus the editorial fast lane for editorial changes; the second-reviewer rule for security-critical datasets binds even solo (an external peer or the Auditor). Team: matrix-driven multi-reviewer chains. Federated: entries affecting exposed Projections or Federation Contracts additionally require the counterparty-facing Steward. Autonomous execution means broad T3 lanes with human review of samples and of every flagged case, the normal MOS-scale posture. - Metrics: Median review turnaround; auto-approval share and its escape rate (auto-approved entries later corrected or retracted); classification-versus-diff mismatch findings per period; reviewer load per Steward; percentage of decisions with substantive rationale. - Failure modes: Auto-approval lane widened until review is fiction (guard: lane criteria changes are GOV-2 changes in the security-critical class; escape rate threshold auto-suspends a lane). Self-licensing via agent-proposed classification (guard: lane eligibility derives from the independent diff-based classifier, never from the submitting agent). Rubber-stamping under load (guard: Auditor samples approvals; turnaround and depth are reported). Orphaned queue when a Steward is absent (guard: deputy appointed via GOV-3 named in the matrix; aging alerts escalate through GOV-1). ### CON-5 Mastership enforcement - Purpose: Guarantee that every write lands only in its dataset's System of Record. Edits aimed at mirrors, raw captures or generated artifacts are refused and routed to the true master, per ARCH-018. - Trigger: Any write attempt on the model; CON-1 detecting an external-mastered target; a correction in CON-8 targeting mirrored content. - Actors: Agent SHALL enforce at T3: consult the register, refuse non-conforming writes, package and route corrections. Steward handles escalations, register gaps and mastership disputes. Contributor with access to the external system carries routed corrections there. - Inputs / Outputs: Inputs: the write request, `sources.yaml`, the target file's origin classification. Outputs: an executed write to the master, or a refusal with explanation plus a routed correction package, plus routing Events; possibly a model-mastered annotation about the mirror. - Steps: 1. Resolve the target dataset in `sources.yaml`. Gateway: register entry exists? If no entry and no external system is involved, the dataset is model-mastered and authored in place per the Data-Mastership 6 default: proceed through CON-3 and CON-4 and file a register-completion task with MIR-1. Refuse the write and open a register-gap task only when external involvement is present or origin or mastership is ambiguous (the Agent-Operations 6 refusal duty: an agent that cannot tell what it may edit must not edit). 2. Gateway: master is the model? If yes, proceed with the in-place edit through the normal chain (CON-3, CON-4). 3. If external-mastered: refuse the in-place edit. Package the correction (target system, scope, proposed change, evidence, provenance). 4. Deliver the correction to the external system directly if the Agent has a lawful write path there, otherwise to a Contributor or Steward who has access. 5. Optionally record a clearly separated, model-mastered annotation about the mirror ("source says X, we assess Y") if the model needs to state its position before the source is fixed. 6. Schedule or trigger re-harvest so the mirror reflects the corrected master; record the routing Event end to end. - Controls: Mirrors, `raw/` and `artifacts/` are read-only inside the model without exception; the refusal conditions of Agent-Operations 6 are binding on every Agent; annotations SHALL be visually and structurally separate from mirrored facts; mastership changes are versioned register events executed solely by MIR-1, never silent edits; the register-default rule of step 1 is the Data-Mastership 6 default, not a palette tightening. - Tier: core - Variants: Solo: the Owner-Steward usually has access to both sides, so routing is a reminder plus a re-harvest. Team: routing targets the external system's owning team. Federated: corrections to content mastered by a partner Universe are routed through the federation channel; federation never transfers mastership. Enforcement is autonomous (T3) in all variants; only register gaps and mastership disputes reach humans. - Metrics: Count of refused non-conforming writes (a healthy signal, not an error count); median time from routed correction to re-harvested mirror; register coverage (externally involved datasets touched by writes that have register entries, target 100 percent); drift incidents caused by copy edits (target zero). - Failure modes: A convenient edit to a stale mirror "just this once" (guard: T3 refusal is unconditional; the fast path is the annotation of step 5). An externally involved write silently defaulting to model-mastered because the register entry is missing (guard: step 1 refuses on any external involvement without an entry; V2 register validation; the lawful in-place default applies only when no external system is involved). Routed corrections dying in someone's inbox (guard: routing Events have an open state; aging routed corrections alert the Steward). ### CON-6 Versioning and change history - Purpose: Turn every approved entry into a versioned, reconstructable change: record the transition Event, advance the right version line, keep the registers and the walk true. History is append-only; the model's past SHALL always be recoverable. - Trigger: CON-4 approves a contribution; a mastership transition executed by MIR-1; a register or manifest update. - Actors: Agent SHALL execute mechanically at T3 (apply, commit, emit Events, update logs, re-run the walker); only walker failures and register conflicts escalate. Steward sets the versioning policy (what increments a record version versus a model version) and reviews history health. - Inputs / Outputs: Inputs: the approved contribution with its full decision trail, versioning policy, current version identifiers, the MIR-10 base reason taxonomy. Outputs: the change applied to the master location, a transition Event (actor, timestamp, previous state, new state, rationale, exactly one primary reason code), updated version identifiers, an updated change log, a fresh coverage-walk report where structure changed, and register updates where applicable. - Steps: 1. Apply the change to the dataset's master location. 2. Record the transition Event with actor, timestamp, previous and new state, and rationale, keeping the three independent times distinct: an object retiring, a definition versioning and a projection being revoked are three different Events. Stamp exactly one primary reason code from the MIR-10 base taxonomy on the transition Event (correction, structural-change, migration-backfill, and so on). 3. Advance version identifiers per policy (record-level always; bundle or model version per the policy's aggregation rules). Identity SHALL never change: only semantic replacement creates a new Identity. 4. Update the change log entry linking the Event, the Change Request or intake ID, and the classification from CON-4. 5. Gateway: did the change add, move or delete files? If yes, re-run the coverage walker and commit the fresh report in the same change; an orphan blocks the merge. 6. Gateway: did the change create a dataset, alter a pipeline or move mastership? If yes, the register change SHALL be executed through MIR-1 (the sole executor of Mastership Register changes) and travel in the same change set (registers over memory). 7. Publish the merged state; if the dataset feeds write-back projections, trigger the republish and drift check via MIR-7. - Controls: No silent transitions (Lifecycle 6); append-only history, no history rewriting; the walk SHALL be green at every merge point; register updates travel in the same change as the change they describe and execute through MIR-1; manifests are model-mastered content maintained here as structural changes (CON territory); superseded states persist per MIR-9; the COMMON editorial fast lane's composite Event is conformant evidence for this card. - Tier: core - Variants: Solo: version control plus a disciplined commit convention satisfies most steps; the Agent enforces the Event, reason-code and register discipline the human would forget. Team: shared automation on the merge path. Federated: version Events are what federation synchronization consumes, so their completeness is externally visible. Manual conformance is possible but fragile; hybrid and autonomous are the norm. - Metrics: Percentage of merges with complete transition Events carrying a primary reason code; walk status at merge (percentage green, target 100); register staleness incidents (changes that should have updated `sources.yaml` but did not); history reconstruction spot-check pass rate. - Failure modes: Squash or rebase habits destroying the Event trail (guard: append-only policy on published history; Auditor checks reconstructability). Version identifiers advanced without Events, or Events without version advance (guard: the T3 agent does both atomically). Walker skipped on "trivial" moves (guard: merge automation refuses without a fresh green report when paths changed). ### CON-7 Bulk import - Purpose: Ingest large bodies of content (initial model load, migration from a legacy system, onboarding a big external dataset) under control, without flooding the per-entry gates or laundering unprovenanced data into the model. - Trigger: A Steward authorizes an import; a new external system is onboarded; a migration plan (for example from a retired system of record) reaches execution. - Actors: Steward authorizes and owns the acceptance decision. MIR-1 executes the register entry, including its Owner gate for new external systems. Agent executes at T2 for routine re-imports (human reviews samples and exceptions) and SHALL run at T1 for the first import of a new source (Agent proposes, human approves each stage). Auditor (engaged via GOV-6) SHOULD sample the result post-import. - Inputs / Outputs: Inputs: the source dataset, the import authorization, mapping and transform rules, `sources.yaml`. Outputs: a raw capture with a MIR-2-owned provenance sidecar, transformed records in the model, a batch import Event referencing a manifest of imported items and carrying a primary reason code, a sampling report, and a rollback point. - Steps: 1. Declare first: invoke MIR-1 to create or update the dataset's register entry (master, scope, cadence, or a one-time migration entry), including MIR-1's Owner-approval gateway for new external systems and mastership decisions, before any byte moves; bulk import is a registered MIR-1 trigger. 2. Dry-run the transform on a sample. Gateway: sample acceptable to the Steward? If no, fix mapping rules and repeat. 3. Land the unmodified capture under `raw///` per MIR-2's landing discipline, with the MIR-2-owned provenance sidecar and capture-time attestation; facts SHALL NOT be improved during capture. 4. Transform into candidate records in a staging area; enrichment beyond the source is a separate, model-mastered layer, never mixed into the transform. 5. Run CON-3 validation gates over the whole batch; triage failures (fix rules, hold out failing records, or accept documented exceptions). 6. Review by statistical sampling per the Steward's acceptance criteria (batch size, risk). Gateway: batch accepted? If no, return to step 4 or abort with the raw capture retained as evidence. 7. Merge as a single bulk change: one import Event referencing the item manifest, stamped with exactly one primary reason code from the MIR-10 taxonomy (migration-backfill for migrations), one rollback point, register updates executed through MIR-1, walker re-run. 8. Post-import: the Auditor samples; the Steward confirms the register entry's ongoing cadence or closes the one-time entry. - Controls: Register-first rule (no import without a declared entry, executed by MIR-1 with its Owner gate); raw capture is mandatory and immutable; batch-level provenance plus per-record derivation links; single revertible merge; sampling thresholds proportional to batch risk. - Tier: recommended - Variants: Solo: the same stages compressed into one sitting; the discipline that survives is register-first (through MIR-1), raw-first, one revertible merge. Team: staging review shared between the data owner and the model Steward. Federated: importing from a partner Universe uses the federation channel and its contracts (FED-8 admission quarantine and promotion) instead of a raw harvest, but the staging and sampling stages are identical. First-run T1, steady-state hybrid at T2. - Metrics: Batch first-pass gate rate; sampled defect rate post-import; time from authorization to merged batch; rollback invocations (target zero, but the point is that it is possible). - Failure modes: Transform quietly "fixing" source facts, forking truth from the source (guard: raw capture diffing; enrichment lives in a separate layer). Import merged as thousands of individual changes, making rollback impossible (guard: single bulk Event and merge). Legacy garbage imported wholesale to be cleaned later (guard: sampling gate before merge; held-out lane for failing records). A brand-new external source onboarded on Steward authority alone, bypassing the Owner gate (guard: step 1 invokes MIR-1, whose Owner-approval gateway binds). ### CON-8 Correction and retraction - Purpose: Fix a wrong entry or withdraw one entirely, while preserving history, identity and provenance. The model corrects itself in the open: a retracted entry is marked, never erased. - Trigger: An error report from a Consumer, Auditor or Contributor; a failed re-validation; an upstream source correction arriving by re-harvest; a CON-9 ruling. - Actors: Steward decides retractions and contested corrections; retraction approval SHALL remain T1 (Agent proposes, human approves each act). Agent MAY execute corrections at T2 and MAY handle mechanical corrections (broken links, typos, formatting) at T3 through the auto-approval lane. Consumers are notified, not consulted. - Inputs / Outputs: Inputs: the error report or ruling, the affected entry with its provenance and version history, impact analysis from the Provenance Graph, the CON-13 consumer register. Outputs: a corrected new version or a retraction marking, a correction or retraction Event with rationale and a primary reason code, notifications to affected Consumers and downstream models resolved against CON-13. - Steps: 1. Register the report (Event: defect reported) and link it to the affected entry. 2. Gateway: is the affected content model-mastered? If it is a mirror, the correction routes through CON-5 to the master system; the model MAY add an interim annotation. 3. Run impact analysis: what derives from, references or was disclosed from this entry (Provenance Graph traversal; an Agent executes this at T3). 4. Gateway: correction or retraction? Correction: author the fix as a new version through CON-3 and CON-4 (mechanical fixes MAY use the auto-approval lane). Retraction: mark the entry retracted or superseded with the reason, using the canonical state vocabulary (Lifecycle 4-5); identity, provenance and history remain intact and reachable. 5. Record the correction or retraction Event with rationale, the link to the triggering report, and exactly one primary reason code from the MIR-10 base taxonomy (correction). 6. Notify affected Consumers and downstream derivations identified in step 3, resolving addressees against the CON-13 register; where the entry fed write-back projections or federated Projections, trigger republish or federation notice under the governing Federation Contract. 7. Close the report with the resolution. - Controls: Physical deletion of history is prohibited, per Lifecycle 13 (historical integrity takes precedence over physical deletion; the palette's operational additions elaborate on that cited invariant); the correction itself carries provenance; retraction of entries that were externally disclosed SHALL trigger the notification step; retractions require Steward approval, never T3; notification completeness is measured against CON-13, not folklore. - Tier: core - Variants: Solo: a lightweight loop (report is a note, correction is a versioned edit), but the retraction marking and Event remain mandatory. Team: report intake through the same channel as contributions. Federated: retraction notices propagate under the Federation Contract's disclosure terms; a partner's re-harvest closes the loop. Hybrid is the norm: T3 for mechanical, T2 for substantive, human for retractions. - Metrics: Time from report to resolution; percentage of retractions with completed downstream notification against the CON-13 addressee list; recurrence rate (same defect reported again); share of corrections that pass gates first time. - Failure modes: Silent overwrite of the wrong value, losing the fact that the model ever said otherwise (guard: corrections are new versions with Events; append-only history). Retraction by deletion, breaking inbound references and federation partners (guard: retired state per Lifecycle; V2 link checks catch dangling references). Downstream consumers never learn of the correction (guard: notification is a step with an open state, tracked to completion against the CON-13 register). ### CON-9 Entry dispute resolution - Purpose: Resolve disagreement about an entry: whether it is true, admissible, correctly placed, or correctly mastered. Disputes are surfaced and adjudicated, not buried in edit wars. - Trigger: Any role disputes an entry; two contributions conflict irreconcilably; a CON-5 routing conflict where the partition or the master itself is contested; a repeated-drift mastership smell escalated from CON-11. - Actors: Steward adjudicates within their section; the Owner is the appeal instance, with appeals recorded in the GOV-1 ledger. Auditor MAY be engaged for independence (via GOV-6). Agent MAY compile the evidence file at T3 and MAY draft an assessment at T2; the ruling SHALL be human and is non-delegable in substance. - Inputs / Outputs: Inputs: the dispute statement, the contested entry with provenance and version history, raw captures and master-system state where relevant, prior rulings. Outputs: a ruling Event with rationale, the applied outcome (upheld, amended, retracted, or recorded deviation), and where mastership is contested, a mastership-change proposal to MIR-1. - Steps: 1. Register the dispute (Event: dispute opened) naming the entry, the disputant and the claim. 2. Mark the entry Disputed. The mark is visible to Consumers; the entry is flagged, not hidden or reverted pre-ruling. 3. Agent compiles the evidence file: provenance chain, raw captures, master-system state, version history, impact analysis (T3). 4. Gateway: is the dispute about mastership or partition (who owns the truth) rather than content? If yes, escalate as a mastership-change proposal to MIR-1, the sole executor of Mastership Register changes, including its Steward and Owner gateway; CON-6 records the resulting transition Event as usual. 5. Agent drafts an assessment with options (T2); the Steward rules: uphold the entry, amend it, retract it, or record an annotated deviation ("source says X, we assess Y") when the model and the source lawfully disagree. 6. Apply the ruling through the normal chain (CON-4 for amendments, CON-8 for retractions) and clear or update the Disputed mark. 7. Record the ruling Event with rationale. Gateway: does the disputant appeal? Appeals go to the Owner once, recorded as a GOV-1 decision Event; the Owner's decision is final within the Universe. - Controls: Disputed entries stay visible with their flag; time limits on each stage so disputes cannot pend indefinitely; the ruling actor SHALL NOT be the author of the contested entry where the team size allows; all rulings are precedent-searchable; mastership outcomes execute only through MIR-1. - Tier: recommended - Variants: Solo: disputes arrive from Consumers or from source-versus-model conflicts; the Owner-Steward rules, and the deviation-annotation outcome does most of the work. Team: Steward rules, Owner hears appeals through GOV-1. Federated: disputes over federated content are handled under FED-9; this process handles only the local entry and its flags. At MOS scale, agent-drafted assessments (T2) and precedent search keep thousands of citizen-agent disputes tractable. - Metrics: Median time to ruling; share of disputes resolved by deviation annotation versus amendment versus retraction; appeal rate; reopened-dispute rate. - Failure modes: Edit war instead of a dispute (guard: the Disputed mark freezes content changes to the entry except through the ruling). Disputes used to stall inconvenient facts (guard: time limits; the entry remains visible and usable while Disputed). Ruling without evidence review (guard: the evidence file is a required input to the ruling Event). A mastership change executed inside the CON chain, skipping MIR-1's one-master validation (guard: step 4 routes to MIR-1 exclusively). ### CON-10 Contributor and Agent onboarding - Purpose: Grant entry rights deliberately: establish identity, scope the rights to datasets and kinds, bind obligations, and deliver the onboarding briefing. Entry control begins with who may enter at all. The Delegation Contract lifecycle (issue, amend, suspend, revoke, tier ladder, probation) is CTX-9's, the single System of Record; CON-10 obtains and references contracts, never issues them. - Trigger: A person or agent requests contribution rights; a Steward invites a Contributor; a new Agent is deployed against the model; a CTX-9 suspension or revocation Event arrives for propagation; the periodic rights review falls due. - Actors: The Owner grants rights or delegates granting to Stewards; the Steward defines scope and obligations for their sections. Agent MAY execute the onboarding mechanics (checks, briefing delivery, register updates) at T2. Granting itself SHALL remain T1 (Agent proposes, human approves each act). - Inputs / Outputs: Inputs: the identity of the candidate (human account, or agent identity plus its accountable human operator), the requested scope, `sources.yaml`, the model's BOOTSTRAP and conventions, for Agents the CTX-9 Delegation Contract reference. Outputs: an entry-rights register entry (for Agents referencing the CTX-9 contract identifier), a grant Event, channel access scoped to the grant, and revocation-propagation Events with their gate-probe results. - Steps: 1. Establish identity and, for an Agent, the accountable human operator behind it. 2. Gateway: human or agent? Human: deliver the briefing (BOOTSTRAP, conventions, provenance duty, mastership rules) and obtain acknowledgment. Agent: verify it can satisfy the AI-native requirements (read the entry point, classify files, distinguish what it may edit), then obtain its Delegation Contract via CTX-9; tiers, probation and the tier ladder are CTX-9's alone, and CON-10 SHALL NOT issue, amend or carry a probation regime of its own. 3. Define scope with the Steward: which datasets, which kinds, which processes. Scope SHALL cover only datasets the model masters; rights to external-mastered data are not this model's to grant. 4. Record the grant Event and update the entry-rights register; for Agents, the entry right references the CTX-9 contract identifier and is valid only while that contract is live. Provision channel access matching exactly the granted scope, with credentials handled per GOV-8. 5. Propagate revocations: CTX-9 suspension and revocation Events SHALL reach the entry-rights register and runtime channel teardown within the declared TTL (a GOV-2 configuration); a gate-side probe verifies no orphan rights remain past the TTL; residual authority past the TTL is an incident filed with QSC-14. 6. Run the periodic rights review via the COMMON register-recertification pattern, parameterized by the entry-rights register, its age and usage thresholds, and the granting Steward as approver; expired or unused grants are retired with Events. 7. On breach of obligations: revoke entry rights immediately (Event: rights revoked), notify CTX-9 (contract suspension or revocation is CTX-9's act), and re-review the actor's recent entries. - Controls: Least privilege by default; grants, changes and revocations are versioned Events; an Agent's entry rights die with its CTX-9 Delegation Contract, and every gate validates contract liveness at act time (COMMON revocation rule), never relying on the agent to stop itself; revocation propagation is TTL-bounded with a gate-side probe; accountability remains with the delegating Steward throughout. - Tier: core - Variants: Solo: the Owner-Steward self-grant is trivial, but Agent onboarding is not: even a solo model SHALL route its gatekeeper and harvest Agents through CTX-9 for real Delegation Contracts, or tier discipline has no anchor; under the Solo/Minimal profile the consolidated quarterly review lawfully satisfies step 6. Team: Steward-scoped grants with Owner oversight. Federated: partner Universes are not onboarded here; their access is a Federation Contract, and any local proposal rights they receive still pass this process. Onboarding mechanics hybrid at T2; granting always human. - Metrics: Time from request to decision; percentage of active writers with a current register entry and, for Agents, a live CTX-9 contract reference (target 100); revocation propagation time versus the declared TTL (breaches target zero); revocations per period and mean time to revoke on breach. - Failure modes: Shared or ambient credentials letting unregistered actors write (guard: channel access provisioned only from the register with GOV-8 credentials; intake rejects unknown identities). Agent scope creep beyond its contract (guard: CON-5 and CON-3 check the acting contract against the touched datasets on every write; liveness validated at the gate). Orphan rights surviving a CTX-9 revocation (guard: TTL-bounded propagation plus the gate-side probe; residual authority past TTL opens a QSC-14 incident). Rights never reviewed, accumulating forever (guard: grants expire; the recertification pattern runs on schedule with an aging alarm). ### CON-11 External edit capture - Purpose: Recover intended edits that people make in write-back projections (Pattern M copies published to wikis, sites or trackers) as proper sponsored change proposals, instead of silently merging or silently losing them. Per ARCH-018, edits in a projected copy have no authority, but they often carry real information. CON-11 is the sole capture and classification path for intended external edits; detection belongs exclusively to MIR-7, the palette's single drift-detection engine. - Trigger: A MIR-7 drift Event on a write-back projection (CON-11 is the registered consumer of these Events for the write-back class); an external user asks to change a published page. - Actors: Agent SHALL classify and package at T3, flagging uncertain cases. The Steward decides the resulting proposal through CON-4 at T1 or T2 per sensitivity; sponsored proposals are structurally ineligible for auto-approval lanes. The external editor is credited in provenance as the source of the assertion, never as a rights-holding Contributor. - Inputs / Outputs: Inputs: the MIR-7 drift Event with its diff and the external system's edit metadata (who, when), the write-back projection, the master records it was generated from, `sources.yaml`. Outputs: a classification (accidental damage or intended improvement), a sponsored change proposal entering CON-1 with full provenance, and a reconciled projection (republished or corrected). - Steps: 1. Receive the MIR-7 drift Event with the extracted diff and external edit metadata; CON-11 runs no detection of its own. 2. Classify the drift: accidental damage (formatting mangled, partial deletion) versus intended improvement (someone fixed a fact or wording in the copy). An Agent classifies at T3 and flags uncertain cases for the Steward. 3. Gateway: accidental damage? Return the disposition to MIR-7: the external copy is overwritten on the next publication and the external system's owner is notified; done. 4. For intended edits: package a sponsored proposal into CON-1 intake. The packaging Agent's Delegation Contract is the rights-holding submitter; the external editor is recorded in provenance as the source of the assertion (derivedFrom the external copy, with editor identity and edit time), never as a rights-holding Contributor. The mirrored bytes in the model are never touched directly. 5. The proposal runs the normal chain (CON-2 through CON-4). Sponsored proposals are structurally ineligible for auto-approval lanes and SHALL receive a Steward decision at T1 or T2 per sensitivity. 6. Gateway: accepted? If yes, merge to the master and republish the projection so copy and master converge on the model's terms. If rejected, republish the projection over the external edit with a notice explaining where changes belong. 7. Record the full cycle as Events (classification, proposal created, resolution, republished), each linked to the originating MIR-7 drift Event. 8. Gateway: repeated intended drift on the same copy? That is a mastership smell: escalate as a dispute to CON-9, which routes any mastership-change proposal to MIR-1. - Controls: Silent merging of external edits is prohibited (Data-Mastership 5.1); the projection carries its "do not edit here" marking with a pointer to the proposal channel; CON-11 SHALL NOT run its own detection loop (MIR-7 is the sole engine, and QSC-9 verifies MIR-7 ran on cadence); the health of the drift-check standing job is monitored by QSC-15, escalating into QSC-14; sponsored proposals never ride an auto-approval lane. - Tier: core - Variants: Solo: MIR-7's automated check plus this classification path means divergence is noticed by machinery, not by embarrassment; most drift resolves as overwrite. Team: the step 8 escalation keeps mastership questions out of edit wars. Federated: does not apply to federated Projections (those are governed by federation synchronization and FED-6); it applies only to write-back copies inside the governance domain. Fully autonomous classification and packaging at T3; acceptance decisions per CON-4, always human for sponsored proposals. - Metrics: Share of MIR-7 write-back drift Events classified within the declared window; share classified as intended edits; median time from drift Event to reconciliation; repeat-drift rate per copy (a mastership smell). - Failure modes: Intended external edits silently overwritten, burning contributor goodwill and losing corrections (guard: the classification step and sponsored-proposal path exist precisely for this; overwrite is only for accidental damage). External edits silently merged into the model, forking authority (guard: the mirror-write prohibition of CON-5 makes the proposal path the only path; sponsored proposals cannot auto-approve). Anonymous outsiders acquiring contributor rights through the capture path (guard: the sponsored-proposal pattern; the external editor exists only in provenance). Drift Events produced by MIR-7 but never consumed (guard: CON-11 is the registered consumer for the write-back class; unconsumed drift Events age into a QSC-15 escalation). ### CON-12 Standard and schema migration - Purpose: Migrate the model from one governing standard version or model-wide schema generation to the next as a single controlled, revertible change, instead of freezing on a dead standard or migrating ad hoc, which is the anonymous-edit pattern this palette exists to prevent. - Trigger: A new version of the governing standard is adopted by a GOV-1 decision; a QSC-10 conformance target change requires migration; a model-wide schema generation change crosses datasets. - Actors: Steward plans and owns the migration. The Owner approves the migration plan (a breaking Change Request; where the plan touches gate or process definitions it is security-critical class, T1 with a second human reviewer). Agent executes the transformation at T2. Auditor (via GOV-6) SHOULD sample post-migration. - Inputs / Outputs: Inputs: the migration plan as a Change Request, the old and new standard versions and schemas, mapping rules, `sources.yaml`, the current QSC-10 Conformance Statement. Outputs: the transformed model state, the raw pre-migration state retained per MIR-9, dual QSC-4 validation reports (old and new level), peer notifications with a declared compatibility window (via FED-7), a single revertible cutover Event stamped migration-backfill, and an updated QSC-10 Conformance Statement. - Steps: 1. Author the migration plan as a Change Request: impact analysis of the normative changes, affected datasets and schemas, mapping and transformation rules, rollback criteria, and the peer compatibility window. Approve through CON-4 at T1 (breaking class). 2. Preserve the raw pre-migration state per MIR-9 before any transformation; it is immutable evidence and the rollback substrate. 3. Execute the transformation in a branch; the live model is untouched until cutover. 4. Dual-run QSC-4: validate the branch against both the old and the new standard level; triage failures against the mapping rules. 5. Notify federated peers of the migration and the declared compatibility window; maintain FED-7 cross-version mappings for peers remaining on the old version through the window. 6. Gateway: dual validation green and the compatibility window declared? If no, fix the mapping rules and repeat, or abort with the branch retained as evidence. 7. Cut over as a single revertible change: one cutover Event stamped with the reason code migration-backfill, register and manifest updates in the same change set (register changes executed through MIR-1), walker re-run green. 8. Update the QSC-10 Conformance Statement to the new standard version; the Auditor samples post-migration; roll back per the plan's criteria if verification fails. - Controls: No ad hoc partial migration outside an approved plan; the raw pre-migration state is mandatory and immutable; dual validation is mandatory before cutover; the cutover is one revertible Event; the compatibility window SHALL be honored before old-version support ends; the conformance re-declaration is a mandatory step, not an afterthought. - Tier: recommended - Variants: Solo: the plan MAY be one page, but the branch, the dual QSC-4 run and the single revertible cutover survive compression. Team: mapping authorship and validation triage are separated. Federated: the peer notification and FED-7 mappings are mandatory, and the window length is contract-informed. Transformation runs at T2; the cutover decision is human. - Metrics: Dual-validation first-pass rate; time from plan approval to cutover; peers still on the old version at window close (target zero); rollback invocations; post-migration defects traced to mapping rules. - Failure modes: Migration executed as many small uncoordinated edits (guard: the plan plus the single cutover Event; QSC-4 dual-run refuses partial states). Federated peers broken mid-window (guard: FED-7 mappings maintained through the declared window). Pre-migration state lost, making rollback impossible (guard: MIR-9 retention before any transformation, verified in step 2). Conformance claim left stale after cutover (guard: the QSC-10 update is a numbered step with an Event). ### CON-13 Consumer and subscription register - Purpose: Maintain the model-mastered register of Consumers: identity, consumed datasets and projections, declared dependencies, notification channel and SLA. This is the register that MIR-8, CON-8, ACT-10 and FED-11 notifications resolve against; "known dependent Consumers" is defined by this register, not by folklore. - Trigger: A Consumer receives an access grant (GOV-7 internally, FED-3 for federation); a Consumer declares or changes its dependencies; a notification run requests addressees; the periodic recertification falls due. - Actors: Steward owns the register. Agent maintains entries at T3 for mechanical synchronization with the grant registers and at T2 for notification SLA changes. Consumers declare their own dependencies. - Inputs / Outputs: Inputs: grant Events from GOV-7 and FED-3, Consumer dependency declarations, `sources.yaml`, the projection catalog. Outputs: the consumer register as a model-mastered dataset, register change Events, addressee lists for notification runs, and dependency reports. - Steps: 1. Register the Consumer on first grant: identity, notification channel, SLA, and the GOV-7 or FED-3 grant identifiers the consumption rests on. 2. Record the consumed datasets and projections and any declared dependencies; where the Consumer declares nothing, dependencies default to the grant scope, never to guesswork. 3. Synchronize mechanically with the grant registers: a revoked or expired grant marks the consumption ended; the entry is retained for history, never deleted (Lifecycle 13 discipline). 4. Serve addressee resolution: the notification steps of MIR-8, CON-8, ACT-10 and FED-11 SHALL resolve their recipients against this register, and notification completeness is measured against it; MIR-6 dashboard targeting reads it for dependent-Consumer lists. 5. Recertify entries via the COMMON register-recertification pattern (register, age and usage thresholds, the Steward as approver); dead entries are ended with Events. 6. Report dependency concentrations and consumer counts to QSC-11 planning and to GOV-5 capacity inputs. - Controls: The register is model-mastered and changes through the normal CON chain; no notification step SHALL claim completeness except against this register; entries are ended, never deleted; synchronization with the grant registers is mechanical, and an active grant without a register entry is a finding. - Tier: recommended - Variants: Solo: the register MAY be a single file, but it is still the notification source of truth; models that publish or federate SHOULD treat this process as if core, since CON-8 and FED-11 notification completeness is unmeasurable without it. Team: Consumers self-serve dependency declarations. Federated: FED-11 termination reads this register for the partner-side consumers of frozen mirrors. Synchronization autonomous at T3; SLA changes at T2. - Metrics: Notification completeness (notified over registered addressees, target 100 percent); share of active grants with register entries (target 100 percent); stale-entry rate found at recertification; unregistered-consumer discoveries per period (target zero). - Failure modes: Notifications sent to "known" consumers from memory (guard: addressee resolution SHALL read the register; completeness is computed against it). Register drifting from grant reality (guard: mechanical synchronization plus the recertification diff against GOV-7 and FED-3). Dependencies inferred silently and wrongly (guard: declared or defaulted to grant scope, with the default recorded as such).