## FED: exchange and federation operations This family contains the operational processes by which a Vercy-conformant meta-model Universe exchanges knowledge with OTHER Owners. The specification layer (Federation-Contracts, Consent-and-Disclosure, semantic mapping, synchronization, Conflict-Resolution, Federation-Lifecycle 4) defines the protocol; these process cards define the runbooks a real Owner, Steward and their Agents execute day to day. Trust-Model.md 6a-7 is the doctrine anchor for every trust judgment in this family: trust is a Trust Vector of independently evaluated dimensions (Identity, Semantic, Governance, Contract, Operational, Historical), never a single scalar. The family rests on one iron rule: **information from any meta-model is readable only with the permission of its Owner.** Every process below is an elaboration of that rule in time: how permission is negotiated (FED-1, FED-2), granted and revoked (FED-3), enforced at the moment of release (FED-4), operated at scale (FED-5, FED-6), kept meaningful (FED-7), applied symmetrically to what arrives (FED-8), defended when masters disagree (FED-9), watched (FED-10) and wound down without residue (FED-11). This family covers federation-facing consent only; internal (non-federated) grants and their enforcement are GOV-7's territory, the domestic mirror of FED-3: one consent doctrine applied inward and outward, two registers, each with its own master. Glossary (palette-wide vocabulary split): **quarantine** is MIR-8's readable-but-flagged trust marking (also the MIR-6 freshness state); **admission quarantine** is FED-8's inbound holding zone, unreadable until promoted; **integrity hold** is QSC-9's marker excluding an artifact from answering and publication until cleared. This family uses admission quarantine exclusively for inbound federated content. Doctrine carried through every card: - **Negotiation of knowledge, not access to data.** A partner never receives a window into a store. Schema MAY be public; instance data is negotiated; the released artifact is always a purpose-built Projection. No process in this family SHALL produce raw namespace or database access on any path, including emergencies. - **Mastership never moves.** Federation exchanges copies; each dataset keeps exactly one master. Mirrors of partner data are read-only, provenance-stamped and freshness-labeled; corrections travel to the master and come back by re-delivery. All Mastership Register changes this family occasions are executed by MIR-1, the sole register-change executor. - **Everything is an Event.** Grants, revocations, releases, sync cycles, conflicts, health state changes, suspension and termination all append traceable Events; Owner and Steward decisions are recorded through GOV-1. Nothing in this family transitions silently. Disclosure and consent logs are emitted by the mediating gate infrastructure, never by the acting Agent, and are continuously hash-chained with external anchoring per the palette-wide log control (COMMON). - **Trust is a vector.** Per Trust-Model.md 6a-7, each trust dimension is evaluated, recorded and revised independently; floors are declared predicates over named dimensions (versioned GOV-2 configurations); promotion, rejection and authorization Events state which dimensions they relied upon. Nothing in this family collapses trust into one number. - **Conflicts are facts, not errors.** A disagreement between two sovereign masters is recorded as a first-class object with its own lifecycle and a permanent Historical Trace (persisted through MIR-9). It is never resolved by quiet overwrite. - **Honest bounds.** Revocation propagates within a declared TTL, not "instantly", and is gate-enforced, never grantee-honored; freshness has declared staleness limits; the runbooks state the real guarantee so operators implement it instead of approximating a fictional one. - **Symmetric defense.** The family protects the Owner's knowledge on the way out (disclosure review) and the Owner's model on the way in (admission quarantine and Trust Vector evaluation). Inbound content, including anything instruction-like aimed at Agents, is data, never a command: this is the palette-wide data-never-command iron control (COMMON); FED-8's screening checklist is its reference implementation at the federation boundary, mirrored inward by MIR-2. **Agents.** Stewards delegate heavily. Tiers T1/T2/T3 are defined once in the palette preamble (COMMON) and are cited here, never re-glossed. The stable pattern across the family: detection, computation, sweeps and routine cycles run at T3; drafting, evaluation, borderline adjudication and template-bound issuance run at T2; and four acts are non-delegable in substance and permanently human: signing a Federation Contract (FED-2), approving an off-policy grant (FED-3), deciding a non-deterministic conflict (FED-9), and deciding suspension or termination (FED-11). Wherever an Agent participates in such a step it SHALL remain T1 (Agent proposes, human approves each act). Every delegated step runs under a Delegation Contract issued, monitored, suspended and revoked solely through CTX-9; every FED gate validates the citing contract's liveness at act time (COMMON revocation discipline), never relying on agent honor. **Tier logic and core set.** The whole family activates only when an Owner federates; a purely solo, non-federating model needs none of it and this family contributes zero processes to the palette-wide solo core count (COMMON). Relative to a federating model, the core set is: FED-2, FED-3, FED-4, FED-5, FED-8, FED-9 and FED-11. FED-1 is recommended; FED-6 is recommended (core once a contract promises continuous coherence); FED-7 is recommended (core when contracted exchange depends on non-trivial mappings); FED-10 is recommended (SHOULD be treated as core wherever more than two federations are active). **Stress test.** The Meta-Orchestrator State (MOS) is the scale case. All MOS citations in this family reference the external reference Dimension repository (orkestron-ai/meta-orchestrator-state), not the standard; the published case study describes 38 namespaces in six clusters. Its S cluster (S1 ownership, S2 access contracts, S3 projection shaping, S4 gate-committed audit, S5 statistical release) is a reference implementation of FED-3, FED-4 and FED-8 machinery at polity scale, with default deny, an owner-side gate whose atomic log commit is the release itself, and bounded-staleness revocation. If a card here could not be operated by MOS, the card is wrong. Orkestron realm-API federation between platform Universes is a lighter reference implementation of FED-2, FED-5 and FED-6 (reference implementation, not normative). ## Interfaces to other families - **MIR.** FED-8 promotions land as mirror datasets through MIR-2's post-promotion landing (unmodified raw capture plus provenance sidecar, semantic transform into mirror locations, coverage re-walk); MIR-2 SHALL refuse federated-class content without a FED-8 promotion record. FED-2, FED-5 and FED-11 propose mastership register entries and retirements that MIR-1, the sole register-change executor, executes with its approval gates. Mirror freshness states (MIR-6) feed FED-10 signals; the MIR-7 drift-detection engine executes FED-6's boundary drift checks per contract. Conflict Historical Traces (FED-9), federation lifecycle Events and the FED-11 terminal historical package persist through MIR-9's archival machinery. Artifacts: raw captures, provenance sidecars, mastership register proposals, freshness metadata, drift Events, archived federation packages. - **ACT.** Out: FED-8's per-source Trust Vectors and admission-quarantine state are mandatory ACT-2 qualification inputs; a source below its operating floor degrades signal confidence below the auto-decide threshold, and a signal class whose evidence rests solely on federated mirrors is never auto-decidable at T3. In: actuation-linked divergence involving federated mirrors or partner-declared facts arrives from ACT-10 as conflict candidates for FED-9; outbound disclosures triggered by actuation pass FED-4 like any other release. Artifacts: Trust Vector snapshots, admission-quarantine state, conflict candidates, released Projections. - **CON.** Corrections to mirrored partner content travel to the master and return by re-delivery, never through CON's authoring chain. CON-12 standard and schema migrations invoke FED-7 for cross-version mappings and peer compatibility windows. Consumer notifications required by FED-7 mapping changes and FED-11 mirror freezes and terminations resolve against the CON-13 consumer and subscription register. Artifacts: mapping versions and deprecation notices, migration compatibility mappings, consumer notification lists. - **QSC.** QSC-6 diffs actual grants against the consent register plus the standing consent policy and verifies every auto-issued FED-3 grant cites its policy version. FED-7 regression suites and FED-8 validation rule sets execute through QSC-4 validation machinery; the Auditor samples FED-4 releases and FED-9 traces. Unauthorized-disclosure incidents open QSC-8 (the security specialization of QSC-14); all other FED incidents (residual access past TTL, admission quarantine saturation, gate outages, dead monitors) open QSC-14. FED-3 sweeps, FED-6 cycles and FED-10 monitors are registered standing jobs operated and meta-monitored through QSC-15. Artifacts: validation reports, audit samples, incident records, standing-job registry entries. - **CTX.** Every T2/T3 step in this family runs under a Delegation Contract issued, amended, suspended and revoked solely through CTX-9; FED gates validate contract liveness at act time and honor CTX-9 revocations within the declared TTL (COMMON revocation discipline), mirroring the TTL bounds this family grants partners. FED-8's hazard screening and the palette-wide data-never-command control (COMMON) are enforced constraints written into those contracts. Artifacts: Delegation Contracts, gate liveness checks, agent audit trails, sampled-review records. - **GOV.** Owner and Steward decisions across this family (FED-2 signatures and mandates, FED-3 policy exceptions and revocation orders, FED-9 rulings and appeals, FED-10 status changes, FED-11 decisions) are recorded through GOV-1; contract amendments re-enter through GOV-1's decision machinery into FED-2. Standing consent policies with aggregate ceilings, contract templates, trust policy, engagement predicates, promotion and operating floor predicates, monitoring thresholds and retention policy are versioned GOV-2 artifacts that FED executes. GOV-3 succession and deputies keep this family's T1 gates from failing closed forever on Owner loss. Internal (non-federated) grants are GOV-7, the domestic mirror of FED-3: one consent doctrine, two registers, each with its own master. Key material exchanged at FED-5, partner key rotation in FED-6 and credential retirement at FED-11 run through GOV-8. The Auditor actor named across FED cards is engaged through GOV-6. Model genesis (GOV-4) precedes FED-5; model retirement (MIR-11) sequences FED-11 per partner. Artifacts: decision Events, policy and floor configurations, grant registers, credentials and keys, auditor engagements. ### FED-1 Federation discovery and evaluation - Purpose: Find candidate partner Universes, read their public federation metadata, and evaluate whether a trust relationship is worth pursuing, without disclosing or reading any protected knowledge on either side. Federation-Lifecycle stage: Discovery and Evaluation (Federation-Lifecycle 4). - Trigger: Owner or Steward capability need ("we need supplier data"); an inbound federation inquiry from another Universe; a scheduled scan of registries and known peers (a QSC-15 registered standing job). - Actors: Steward accountable. Agent MAY execute metadata scanning and dossier compilation at T3 and evaluation assessment at T2. The pursue decision belongs to the Owner and SHALL remain T1 (Agent proposes, the Owner approves each decision), recorded through GOV-1. Auditor (engaged via GOV-6) MAY review dossiers for restricted-domain candidates. - Inputs / Outputs: Inputs: capability need statement; candidate public federation metadata (namespaces, public schemas, projection profiles, supported contract types, protocol version); own trust policy and engagement predicate (versioned GOV-2 artifacts). Outputs: candidate dossier; evaluation record with an initial per-dimension Trust Vector assessment; go or no-go decision Event (GOV-1). - Steps: 1. Register the discovery intent as an Event with declared purpose. 2. Collect each candidate's public federation metadata (schema discovery only; no instance data requested or accepted). 3. Verify the candidate's identity claims and declared conformance level. 4. Gateway: does the candidate publish usable federation metadata? No: record a not-federatable finding and stop. 5. Compile the dossier: namespaces, offered projection profiles, supported contracts, governance, legal and organizational constraints. 6. Assess the candidate against own trust policy as an initial Trust Vector (Trust-Model.md 6a-7): per-dimension levels over Identity, Semantic, Governance, Contract, Operational and Historical Trust, each evaluated and recorded independently, never collapsed into a single scalar; plus version compatibility and purpose fit. 7. Gateway: does the assessment satisfy the engagement predicate (a GOV-2 versioned predicate over named Trust Vector dimensions)? No: archive the dossier with rationale and stop. The evaluation record SHALL state which dimensions it relied upon. 8. Present the dossier and recommendation to the Owner. 9. Gateway: Owner approves pursuit? Yes: open a negotiation case and hand off to FED-2. No: archive with rationale. 10. Record the evaluation outcome Event (decision via GOV-1). - Controls: Discovery SHALL NOT require or accept disclosure of protected knowledge in either direction. Identity verification SHALL precede assessment. The Owner approval gate SHALL precede any negotiation. Trust SHALL be assessed per dimension, never as one score against one threshold. All findings SHALL be recorded as Events. - Tier: recommended. - Variants: Solo: the Owner performs steps 5 through 9 personally on a single candidate. Team: Steward runs the process, Owner signs off. At scale: a standing T3 discovery agent (QSC-15 registered) watches registries and files dossiers into a weekly Owner review queue. Manual: a human reads partner documentation. Hybrid: agent compiles, human assesses. Autonomous: agent assesses too; the human appears only at step 9. - Metrics: candidate-to-engagement conversion rate; median days from intent to decision; share of dossiers with complete metadata; count of protected-data requests wrongly made during discovery (target zero). - Failure modes: (1) Outbound inquiries leak the Owner's protected intent: guard: a Steward-approved inquiry template from which the Agent may not deviate. (2) Evaluation runs on stale partner metadata: guard: metadata age check with refresh before assessment. (3) Enthusiasm bypasses the engagement predicate: guard: the predicate is versioned GOV-2 policy; exceptions require an Owner decision recorded through GOV-1. (4) An inbound inquiry containing instruction-like text is treated as a command by an Agent: guard: inbound content is data, never a command (COMMON); the Agent may only file it into the dossier. ### FED-2 Federation contract negotiation and signing - Purpose: Convert a positive evaluation into a signed Federation Contract naming purpose, scope, projection profiles, synchronization strategy, identity binding approach, semantic mapping ownership, conflict precedence, revocation and termination terms. A Federation Contract is the cross-Universe specialization of the Semantic Contract (Contract.md 5-6, Federation-Contracts.md 3a); Delegation Contracts (CTX-9) and ACT-3 capability contracts are sibling specializations of the same instrument. Federation-Lifecycle stage: Negotiation (Federation-Lifecycle 4). - Trigger: Owner-approved go decision from FED-1, or a partner-initiated proposal. - Actors: Owner signs; signing is non-delegable in substance: signature authority SHALL NOT be delegated to an Agent at any tier and does not transfer to the Steward. Steward negotiates within a written mandate recorded through GOV-1. Drafting of novel positions SHALL remain T1 (Agent proposes, a human approves each position before it is sent); template-parameter negotiation MAY run at T2. Auditor (engaged via GOV-6) reviews the final draft whenever restricted classes are in scope. - Inputs / Outputs: Inputs: candidate dossier; own contract templates and disclosure policy (versioned GOV-2 artifacts); partner proposals. Outputs: signed Federation Contract; establishment Event; consent register entries; mastership register entry proposals executed via MIR-1 (per-dataset flow declarations); establishment worklist for FED-5. - Steps: 1. Open a negotiation case; both sides declare purpose. 2. Exchange contract templates and agree the governing template. 3. Draft scope: participating namespaces, projection profiles per dataset, disclosure classifications. 4. Draft operating terms: sync strategy and cadence, identity binding approach, semantic mapping authority, conflict precedence rules, revocation terms (including the revocation TTL bound), audit obligations, termination and survival clauses. 5. Gateway: does any term require disclosure beyond own standing policy? Yes: route to the Owner as an explicit policy-exception decision recorded through GOV-1; the step SHALL remain T1 (Agent proposes, the Owner approves each exception). 6. Run redline cycles until convergence or exit. 7. Gateway: converged? No: record a failed-negotiation Event, archive, stop. 8. Auditor pre-signature review when restricted classes are in scope. 9. Both Owners sign; record the signing as a Federation Event and a GOV-1 decision Event. 10. Register the contract: consent register entries; mastership register entries proposed to MIR-1 for execution (each declared flow names its single master; federation never transfers mastership); monitoring hooks registered as QSC-15 standing jobs for FED-10. 11. Hand the establishment worklist to FED-5. - Controls: Every negotiated disclosure SHALL resolve to a named projection profile, never to store access; the signature gate SHALL verify this line by line. No contract SHALL move mastership of any dataset; MIR-1 validates every proposed flow declaration. Termination and revocation clauses (with a declared TTL) SHALL exist before signature is permitted. The Owner signature SHALL remain T1 in every variant and is non-delegable in substance. - Tier: core. - Variants: Solo: the Owner negotiates directly on the public template. Team: Steward negotiates under a mandate document; Owner signs. Federated networks MAY publish pre-approved contract templates (GOV-2) so negotiation reduces to parameter filling (Agent at T2). Manual, hybrid and autonomous variants differ only in who drafts; signing stays human in all of them. - Metrics: negotiation cycle time; share of terms taken unchanged from templates; policy-exception escalations per contract; amendment rate in the first 90 days after signing. - Failure modes: (1) The contract grants "access" instead of named projections: guard: the step 9 gate rejects any scope line that does not resolve to a projection profile. (2) Implied mastership transfer ("partner will maintain our reference list"): guard: MIR-1's one-master validation at step 10 rejects any flow without exactly one declared master. (3) An Agent negotiates past its mandate: guard: the Delegation Contract (CTX-9) enumerates negotiable parameters; everything else SHALL remain T1. (4) Missing exit terms discovered only at termination: guard: the termination clause is a mandatory template section validated before signing. ### FED-3 Consent lifecycle: grant, renewal and revocation - Purpose: Operate the permission machinery of the iron rule for federation-facing reads: every outside read of the model exists only under a live, explicit, purpose-bound, revocable grant issued by the Owner directly or under the Owner's standing consent policy. Internal (non-federated) grants are the territory of GOV-7, the domestic mirror of this process. Federation-Lifecycle stage: Active Federation (grants span Establishment through Termination). - Trigger: incoming disclosure request; contract establishment (FED-2) requiring standing grants; scheduled grant review (a QSC-15 registered standing job); Owner revocation order (GOV-1). - Actors: Owner is the grantor of record. Steward administers the consent register. Agent MAY auto-issue grants that match a pre-approved standing consent policy (a versioned GOV-2 artifact) at T2 and MAY execute revocation propagation and register sweeps at T3. Approval of any off-policy or restricted-class grant is non-delegable in substance and SHALL remain T1 (Agent prepares, the Owner approves each grant). - Inputs / Outputs: Inputs: disclosure request (requester, declared purpose, scope, duration); Federation Contract; standing consent policy with per-grantee aggregate scope ceilings (GOV-2); consent register. Outputs: consent record (grant, denial, renewal or revocation) as a traceable Event; updated consent register; grant enforcement material consumed by the FED-4 gate; per-grantee live disclosure surface compilations for Owner attestation (FED-10 input). - Steps: 1. Receive and log the request as an Event: requester, declared purpose, requested scope, duration. 2. Validate: requester identity, live Federation Contract, purpose explicitly stated. 3. Gateway: does the request match the standing consent policy and a pre-approved template? The yes branch has two structural preconditions: (a) the cumulative-disclosure composition check (the step 4 computation) SHALL run and pass on the auto-issue path too; (b) the grantee's aggregate live scope after issue SHALL remain under the per-grantee aggregate ceiling declared in the standing policy; crossing a ceiling structurally escalates to T1 even for a template-matching request. Both preconditions met: the Agent issues the grant at T2, the grant record citing the standing policy version it was issued under, and continues at step 6. Otherwise: continue. 4. Prepare a grant proposal for the Owner: what becomes readable, under which projection profile, for how long, and what the request composes to when combined with the requester's existing grants and the declared partner-affiliation group's grants (cumulative disclosure check). 5. Gateway: Owner approves? The step SHALL remain T1 (Agent proposes, the Owner approves each grant; decision recorded through GOV-1). No: issue a traceable denial with rationale and stop. 6. Record the consent record: grantor, grantee, purpose, scope, projection profile, duration, revocation terms, and the issuing authority (GOV-1 decision Event, or the standing policy version for auto-issue). 7. Mint the grant's enforcement material with a bounded validity window (short TTL), so revocation has a declared worst-case propagation time. Revocation is gate-enforced, never grantee-honored (COMMON revocation discipline). 8. Schedule a renewal review before expiry using the COMMON register-recertification pattern (parameterized: register = consent register; thresholds = grant durations; approver = Owner or standing policy); expiry without renewal SHALL close the grant automatically. 9. On a revocation order: append the revocation Event, stop honoring the grant at the gate within one TTL, notify the grantee, and record which obligations survive (retention, deletion, confidentiality of already-delivered projections). 10. Periodic hygiene: the Agent sweeps the register for expired, unused and orphaned grants and proposes cleanup (T2), and compiles each grantee's total live disclosure surface for periodic Owner attestation; the attestation Event is a FED-10 input. - Controls: Default deny: no consent record, no read. Consent SHALL be explicit, purpose-bound, identifiable and traceable. A grant approved for one purpose SHALL NOT authorize another. Grants are created only by Owner decision or mechanically under an Owner-approved, versioned standing consent policy; Agents SHALL never expand access outside such a policy, and every auto-issued grant SHALL cite its policy version (QSC-6 diffs actual grants against register plus standing policy and verifies the citation). Revocation SHALL preserve historical audit records and SHALL NOT retroactively invalidate reads made while the grant was live. Consent Events are appended by the register and gate machinery, never by the requesting or issuing Agent, and are hash-chained per the palette-wide log control (COMMON). The Owner MAY override any auto-issued grant. - Tier: core. - Variants: Solo: the Owner approves every grant personally; the standing policy is empty; all steps SHALL remain T1. Team: Steward operates the register; the Owner approves policy and exceptions. At scale: a consent policy agent auto-issues template grants at T2 with a cooling-off revocation window; high-sensitivity classes always require the full ceremony. MOS stress case (external reference repository): the S2 access-contract layer runs this process for an entire polity with constitutional standing templates and an owner-side gate. - Metrics: time from request to decision; share of grants auto-issued within policy; measured revocation propagation time versus the declared TTL bound; grantees above a declared fraction of their aggregate ceiling; attestation cadence adherence; reads attempted without a live grant (target zero; each one opens a QSC-8 incident). - Failure modes: (1) Purpose creep: a grantee reuses a grant for a new purpose: guard: purpose is part of the grant identity; the gate rejects mismatched purpose declarations and opens an incident (QSC-8). (2) Revocation advertised as instant: guard: the TTL bound is written into the grant itself; honest bounds, not fictional absolutes. (3) Zombie grants outliving their contract: guard: contract termination (FED-11) cascades a revocation sweep, and step 10 catches strays. (4) An Agent auto-issues an off-policy grant: guard: template match is machine-checked before issue, off-policy approval is structurally T1, every auto-issue cites its policy version, and the Steward samples every auto-issue stream. (5) Salami-slicing within policy: many individually in-policy grants compose beyond anything the Owner would knowingly approve: guard: the composition check and the aggregate ceiling are structural preconditions of the auto-issue branch, and the periodic Owner attestation of each grantee's total live disclosure surface catches accumulated residue. ### FED-4 Disclosure review and projection release - Purpose: Shape and check every outbound share before it leaves: what leaves, what is redacted, and that the released artifact is a purpose-built Projection, never raw model access. This is the gate where the iron rule is physically enforced. Federation-Lifecycle stage: Active Federation. - Trigger: a read request arriving under a live grant (FED-3); a sync batch (FED-6) preparing an outbound payload; any ad hoc export request. - Actors: Steward accountable for the release policy. Agent generates projections and runs release checks at T2, and at T3 for previously-released, established profiles (full audit trail). First release of a new projection profile, and any release containing restricted-class content, SHALL remain T1 (Agent prepares the artifact, a human approves each release). Auditor (engaged via GOV-6) samples released artifacts. - Inputs / Outputs: Inputs: live consent record; projection profile; source records with mastership and freshness metadata; redaction and classification rules; declared partner-affiliation groups. Outputs: released Projection instance; disclosure Event naming requester, declared purpose, projection profile, decision, timestamp, the governing Federation Contract and the responding Universe identity (Consent-and-Disclosure 12); blocked release with rationale when checks fail. - Steps: 1. Resolve the request to a consent record and verify it is live. The check is fail-closed: if validation or the disclosure log write (per-release or aggregate, as applicable) cannot complete, nothing leaves. 2. Assemble candidate content strictly from the profile's declared scope. 3. Verify mastership and freshness: externally-mastered (mirrored) content SHALL carry its master and harvest time; content beyond its staleness limit SHALL be flagged or excluded per profile rule. 4. Apply shaping: omit fields, transform values, aggregate, anonymize or redact per profile. The canonical records remain unchanged. 5. Run the release checklist: classification match; least knowledge (nothing beyond the declared purpose); no restricted identifiers; no third-party content whose own contract forbids redisclosure; cumulative-disclosure composition check against the grantee's other grants and against the declared partner-affiliation group's combined grants (two affiliated grantees SHALL NOT jointly receive what neither could receive alone). 6. Gateway: all checks pass? No: block the release, record the reason, route to the Steward for fix or denial; the fix-or-deny decision SHALL remain T1. 7. Gateway: first use of this profile, or restricted class present? Yes: human approval of the concrete artifact before release (SHALL remain T1). 8. Release the Projection and append the disclosure Event in the same commit as the release decision. For established T3 profiles the gate MAY instead append one aggregated disclosure Event per sync cycle or grant period, carrying request count, scope and content hash; fail-closed then binds to the aggregate commit. Per-release Events remain mandatory for T1 releases, first releases of a profile, and restricted classes. 9. Post-release: Auditor samples; a drift check confirms the released profile still matches the contract. - Controls: No path SHALL produce raw namespace or database access. Every disclosure SHALL be logged: per release as exactly one Event or, for established T3 profiles only, per cycle as one aggregated Event; in both forms the Event carries the governing Contract and responding Universe (Consent-and-Disclosure 12). The disclosure log is emitted by the gate itself, never by the acting Agent, is continuously hash-chained with external anchoring (COMMON), and is Owner-readable at all times. A release without a live consent record is an incident (QSC-8), not an error. Fail-closed binds to the log write. - Tier: core. - Variants: Solo: the Owner reviews each outbound artifact against a one-page checklist. Team: Steward owns profiles, Agent generates, a human approves novel releases. At scale: a fully automated T3 gate for established profiles with fail-closed aggregated logging and sampled human audit. MOS stress case (external reference repository): S3/S4 machinery, where the owner-side gate's atomic log commit is the release itself and every shape comes from a closed enumeration. - Metrics: releases per period and share auto-released; block rate with top block reasons; audit findings per 100 sampled releases; unlogged releases (target zero; each one opens a QSC-8 incident). - Failure modes: (1) Over-collection: profile scope quietly wider than the purpose: guard: periodic profile-versus-purpose review plus the least-knowledge check in step 5. (2) Redaction bypass through derived values (an aggregate that reverses to individuals, or affiliated grantees combining lawful projections): guard: composition and small-cell checks in the checklist, computed across declared partner-affiliation groups. (3) A stale mirror shipped as fresh truth: guard: step 3 labeling and staleness exclusion. (4) Gate outage plus pressure to ship anyway: guard: fail-closed is contractual; an emergency release requires an Owner decision recorded through GOV-1. ### FED-5 Federation establishment and initial synchronization - Purpose: Bring a newly signed federation to operating state: verify identities, establish identity bindings for shared entities, load agreed semantic mappings, and perform the first full exchange with every inbound byte passing admission quarantine and every outbound byte passing disclosure review. FED-5 presupposes an activated model born through GOV-4; establishment is never a substitute for model genesis. Federation-Lifecycle stage: Establishment (Federation-Lifecycle 4). - Trigger: signed Federation Contract handed off from FED-2. - Actors: Steward runs establishment. Agent executes binding proposals, mapping loads, the initial sync and reconciliation diffs at T2 (each batch reviewed). Owner (or Steward under an explicit mandate recorded through GOV-1) declares activation. Partner roles mirror these. - Inputs / Outputs: Inputs: Federation Contract; both parties' public schemas; identity binding approach; initial semantic mappings; projection profiles; key material custodied through GOV-8. Outputs: identity binding register entries; activated mapping set; first mirror datasets (promoted through FED-8, landed via MIR-2); mastership register entries executed via MIR-1; federation activation Event; baseline health snapshot for FED-10. - Steps: 1. Verify mutual identity and contract references; exchange technical endpoints and key material (issued, custodied and inventoried through GOV-8). 2. Establish identity bindings: the Agent proposes candidate matches between shared entities (T2); confirm bindings per the contract's binding approach; record each binding as an Event. Entities below the confidence threshold remain unbound, never force-matched. 3. Load and validate the initial semantic mappings (method per FED-7); every mapping names its authority and the versions on both sides. 4. Dry run: exchange one small representative Projection in each direction; verify shape, mapping application and logging on both sides. 5. Gateway: dry run clean? No: fix and repeat; three failed cycles escalate to both Stewards. 6. Execute the initial full exchange per contract scope: inbound payloads land in admission quarantine (FED-8); outbound payloads pass disclosure review (FED-4). 7. Reconcile: counts, checksums and spot checks between sent and received. Discrepancies are recorded, never silently patched. 8. Record freshness metadata and propose the mastership register entry for every new mirror dataset to MIR-1 (the sole register-change executor, including its Owner gate for new external systems); only after the entry exists does the mirror become readable to local Consumers. 9. Gateway: reconciliation within tolerance and admission quarantine promotions complete? No: hold activation and escalate. 10. Declare the federation Active; record the activation Event; snapshot baseline metrics for FED-10. - Controls: No instance data SHALL flow before contract signature and identity verification. The initial load is not exempt from admission quarantine or disclosure review. Every mirror SHALL have a mastership register entry (executed via MIR-1) before Consumers can read it. Activation SHALL pass the reconciliation gate. - Tier: core. - Variants: Solo: the same steps at toy scale; the dry run may last the whole first month. Team: split between a data Steward (bindings, mappings) and an ops Steward (sync, reconciliation). Hub topology: a hub Universe runs FED-5 per spoke using templated bindings. Manual: file-based exchange with human reconciliation. Hybrid: Agent syncs, human reconciles. Autonomous: T3 permitted only after the same contract shape has been established at least once under human review (probation per CTX-9). - Metrics: days from signature to activation; binding precision on sampled pairs; reconciliation discrepancy rate at initial load; share of initial payload rejected in admission quarantine. - Failure modes: (1) Forced identity matches create false sameness across Universes: guard: sub-threshold pairs stay unbound; borderline pairs go to human review. (2) The bulk load bypasses admission quarantine "because volume": guard: quarantine capacity is part of establishment planning; bypass requires an Owner exception recorded through GOV-1. (3) Mirrors readable before register entries exist: guard: the readability flag flips only after MIR-1 executes the entry in step 8. (4) Endless establishment: guard: the three-cycle escalation at step 5 plus an activation deadline in the contract. ### FED-6 Continuous synchronization operation - Purpose: Keep agreed datasets coherent between federated Universes on the contracted cadence, moving only Projections, preserving mastership on both sides, and surfacing drift instead of hiding it. Federation-Lifecycle stage: Active Federation. - Trigger: contracted schedule (a QSC-15 registered standing job); change Events on own mastered datasets (event-based sync); a partner sync request. - Actors: Agent operates routine cycles at T3 with a full audit trail. Steward reviews exceptions and drift reports at T2. Owner is involved only when a cycle raises a consent or conflict escalation. The semantic branch of step 7 SHALL run at T2 or stricter in every variant. - Inputs / Outputs: Inputs: sync plan from the Federation Contract; change Events since the last cycle; mapping set; consent records; admission quarantine capacity. Outputs: outbound Projections (via FED-4); updated mirrors (via FED-8 promotion and MIR-2 landing); a sync cycle report Event with freshness updates; drift findings; conflict candidates handed to FED-9. - Steps: 1. Start the cycle on trigger. Gateway: federation Active and contract unexpired? No: stop and alert. Precheck partner key validity (custody and rotation per GOV-8). 2. Compute the outbound delta from own mastered datasets per contract scope. 3. Pass the outbound batch through disclosure review (FED-4) and send. 4. Receive the inbound batch into admission quarantine (FED-8); await promotion. 5. Apply promoted content to mirrors; update freshness metadata. Mirrors remain read-only for local Consumers. 6. Drift detection: run the MIR-7 drift-detection engine at the federation boundary per contract: compare fingerprints of shared datasets against partner-declared fingerprints; boundary drift findings are MIR-7 drift Events tagged with the contract. 7. Gateway: drift or mapping errors found? Classify: mechanical (resolvable in the direction the contract's conflict rule declares; Agent fixes at T3) or semantic (two masters appear to disagree; open a conflict object and hand to FED-9). 8. Close the cycle: write the sync report Event (volumes, rejections, drift, latency); update health signals for FED-10. 9. Gateway: consecutive failed cycles above the threshold? Escalate to the Steward and mark the federation Degraded. - Controls: Sync SHALL move Projections, never raw stores. Flow direction per dataset SHALL match the mastership register; a cycle that would write against a declared master SHALL abort. Every cycle SHALL produce a traceable report Event. Drift SHALL be resolved only in the contractually declared direction, never by per-incident judgment; semantic drift SHALL NOT be auto-fixed. - Tier: recommended (core once a contract promises continuous coherence). - Variants: Solo: a weekly manual export-import with a checklist. Team: Agent-run nightly cycles with a Steward exception queue. Multi-federation: one sync agent per contract, with no shared credentials across federations (GOV-8 custody rule). Manual, hybrid and autonomous variants map steps 2 through 8 to T1, T2 and T3 respectively; the semantic-drift branch stays at T2 or stricter in all variants. - Metrics: cycle success rate; end-to-end latency versus contracted cadence; drift incidents per thousand records; mean time from drift detection to resolution or escalation. - Failure modes: (1) Silent conflict resolution by overwrite: guard: step 7 classification is mandatory and semantic drift cannot be auto-fixed; audit compares mirror changes against conflict records. (2) Backpressure: admission quarantine backlog grows until sync "skips" it: guard: the cycle fails closed when quarantine is saturated; skipping is not an option; saturation opens a QSC-14 incident. (3) Cadence theater: cycles run green but move nothing because a filter died: guard: a zero-delta streak alarm in FED-10, meta-monitored by QSC-15. (4) Credential breakage after partner key rotation: guard: the key validity precheck in step 1 with its own alert class, and routine rotation with per-consumer cutover handled through GOV-8. ### FED-7 Semantic mapping maintenance - Purpose: Keep the term-to-term correspondences between two models correct as both sides evolve, so exchanged Projections keep meaning what both parties think they mean. Federation-Lifecycle stage: Active Federation (also serves Evolution, when contract scope or standard versions change). - Trigger: a schema version-change Event on either side; a mapping error surfaced by sync (FED-6) or admission quarantine (FED-8); a scheduled mapping review; a new dataset added to contract scope; a CON-12 standard or schema migration requiring cross-version mappings and a peer compatibility window. - Actors: Steward holds mapping authority for own side. Agent proposes mappings and detects breakage at T2 and applies pre-approved mechanical updates (renames, version bumps with unchanged semantics) at T3. Meaning-affecting edits SHALL remain T1 (Agents propose, both parties' Stewards approve each edit). Auditor samples mapping quality. - Inputs / Outputs: Inputs: both schemas with versions; current mapping set with authorities; change Events; error reports; external reference standards where the contract uses a canonical hub. Outputs: versioned mapping updates recorded as Events; deprecation notices; regression test results; updated mapping registry entries. - Steps: 1. Detect or receive the change: schema version Event, error report, review date or CON-12 migration notice. 2. Impact analysis: which mappings reference the changed terms and which contracted Projections use them (Agent, T2). 3. Gateway: did semantics change, or only representation? Representation only: the Agent applies the mechanical update at T3, records the Event, done. Semantics changed: continue. 4. Draft the new mapping with an explicit correspondence type (exact, broader, narrower, approximate) and declared transformation rules where needed. 5. Cross-review: both Stewards confirm the drafted meaning (SHALL remain T1 where Agents assist). Disagreement here becomes a conflict candidate for FED-9. 6. Version and publish the mapping. The previous version is deprecated, never deleted: historical mappings SHALL remain reconstructable. 7. Regression test: re-run representative exchanges through the new mapping and compare against expected outputs (QSC-4 validation machinery). 8. Gateway: regression clean? No: roll back to the prior version and reopen at step 4. 9. Notify consumers of the mapping change, resolved against the CON-13 consumer and subscription register; schedule the next review. - Controls: A mapping SHALL describe correspondence and SHALL NOT redefine either side's canonical meaning. Every mapping SHALL name its publishing authority and the versions of both participating models. Meaning-affecting changes SHALL be confirmed by both parties. Deprecated mappings SHALL be preserved. - Tier: recommended (core when contracted exchange depends on non-trivial mappings). - Variants: Solo: the Owner keeps a hand-maintained mapping table with a review date. Team: one mapping Steward per domain. Hub topology: a shared mapping registry that spokes subscribe to; registry mappings still obey every rule here. Autonomy ceiling: T3 only for representation-level updates; semantic drafting is at most T2 and semantic approval SHALL remain T1. - Metrics: ratio of mapping breakage found in review versus in production (should favor review); median time from schema change to updated mapping; regression coverage of active mappings; count of approximate mappings pending upgrade. - Failure modes: (1) Silent semantic drift: terms still map but meanings diverged: guard: scheduled semantic reviews with sample-based back-translation checks. (2) Unilateral mapping edits: guard: publishing a semantic change requires both authorities' signatures. (3) History lost in cleanup: guard: deprecation instead of deletion is machine-enforced. (4) Transformation rules that "improve" facts in flight: guard: transformations are declared and tested; enrichment belongs in the model's own layers, never inside a mapping. ### FED-8 Incoming-data admission quarantine and trust evaluation - Purpose: Ensure nothing received from a partner touches the model's readable surface until it is validated, provenance-stamped and trust-evaluated inside admission quarantine (the inbound holding zone, unreadable until promoted), and keep an evidence-based Trust Vector per source current (Trust-Model.md 6a-7). Federation-Lifecycle stage: Active Federation (and guard of the Establishment initial load). - Trigger: any inbound payload (sync cycle, ad hoc delivery, initial load); scheduled Trust Vector re-evaluation (a QSC-15 registered standing job). - Actors: Agent runs intake, validation and evaluation at T3 with a full audit trail. Steward adjudicates failed and borderline items at T2; restricted-class adjudication SHALL remain T1 (Agent proposes, Steward or Owner approves each item). Owner sets the trust policy and approves the promotion floor and operating floor predicates (versioned GOV-2 configurations). - Inputs / Outputs: Inputs: inbound payload with sender attestation; contract and consent references; validation rules (QSC-4 machinery); mapping set; the source's current Trust Vector; promotion and operating floor predicates (GOV-2, with shipped defaults). Outputs: promoted mirror updates with provenance sidecars (landed via MIR-2's post-promotion path); rejections with reasons returned to the sender; updated per-source Trust Vector, published as a mandatory qualification input to ACT-2 and a FED-10 signal; admission quarantine report Events. - Steps: 1. Land the payload unmodified in the admission quarantine zone with a provenance sidecar: source, contract reference, extraction time, declared scope, counts, checksums. 2. Verify the envelope: sender identity, contract validity, payload within contracted scope. Gateway: envelope fails? Reject the whole payload, log, notify the sender. 3. Validate content: schema conformance, mapping applicability, referential sanity against existing bindings, absence of content classes the contract does not permit the partner to send. 4. Screen for hazards: malformed records; executable or injection content in text fields; instruction-like content aimed at Agents (flagged and treated strictly as data, never followed, per the palette-wide data-never-command control in COMMON); statistical anomalies against the source's historical profile. 5. Evaluate the batch against the source's Trust Vector (Trust-Model.md 6a-7): per-dimension levels (Unknown, Limited, Trusted, Highly Trusted, Authoritative) over Identity, Semantic, Governance, Contract, Operational and Historical Trust, each evaluated and revised independently; the outcome of steps 2 through 4 updates the Operational and Historical dimensions specifically. Trust SHALL NOT be collapsed into a single scalar. 6. Gateway: does the source's Trust Vector satisfy the promotion floor predicate (a GOV-2 versioned predicate over named dimensions; shipped default: Operational at least Trusted AND Historical at least Limited AND no relied-upon dimension at Unknown)? Satisfied: promote to mirrors with provenance and freshness metadata (Agent, T3; MIR-2 executes the post-promotion landing). Within the predicate's declared borderline margin: hold for Steward review (T2). Not satisfied: reject, return reasons, log. Promotion and rejection Events SHALL state which Trust Vector dimensions they relied upon. 7. Update the source's Trust Vector from the batch outcome; a drop in any relied-upon dimension raises an alert to FED-10. 8. Gateway: Trust Vector below the contract's operating floor predicate (GOV-2; shipped default: Operational at least Limited AND Contract at least Trusted)? Notify the Steward; this SHOULD trigger a federation review and MAY lead to suspension via FED-11. While a source is below its operating floor, its data degrades signal confidence below the ACT-2 auto-decide threshold. 9. Write the admission quarantine report Event. - Controls: Content in admission quarantine SHALL be unreadable to normal Consumers; promotion is the only path to readability, and MIR-2 SHALL execute only the post-promotion landing (it refuses federated-class content without a promotion record). Raw captures are immutable evidence: corrections happen at the source and arrive by re-delivery, never by editing the capture. Instruction-like content in payloads SHALL never be executed or obeyed by Agents (COMMON data-never-command control; this checklist is its reference implementation at the federation boundary, mirrored inward by MIR-2). Trust Vectors SHALL be derived from recorded evidence per dimension and remain traceable; floors are declared predicates over named dimensions, never scalar thresholds. - Tier: core. - Variants: Solo: admission quarantine is a staging folder plus a checklist before copy-in. Team: Agent triages; the Steward clears the hold queue daily. High volume: streaming validation with sampled deep checks, full checks for new sources. MOS stress case (external reference repository): state-scale inbound flows with per-source budgets and sealed evaluation. Autonomous: T3 end to end within policy; holds always go to a human. - Metrics: promotion rate and median admission quarantine dwell time; rejections by reason class; per-dimension Trust Vector trajectory per source; incidents traced back to promoted content (target zero; filed through QSC-14). - Failure modes: (1) Admission quarantine becomes a rubber stamp under volume: guard: a dwell floor for new sources, sampled deep validation, and Auditor review of promotion statistics. (2) Injection through data: an Agent follows instructions embedded in a payload: guard: step 4 screening plus the palette-wide rule that payload content is never an instruction source (COMMON). (3) Trust inflation from many trivial clean batches: guard: Operational and Historical updates weight recency, severity and batch materiality, not raw counts, and floors read named dimensions so one inflated dimension cannot mask another. (4) Rejected data resubmitted unchanged until it slips through: guard: a resubmission matcher compares checksums; repeated identical rejects escalate to the Steward. ### FED-9 Cross-master conflict resolution - Purpose: Resolve disagreements between two sovereign masters about shared or bound facts without either side overwriting the other's authority, and preserve the conflict itself as a permanent semantic fact. Federation-Lifecycle stage: Active Federation (escalation MAY feed the Suspension transition). - Trigger: semantic drift from FED-6; a mapping cross-review disagreement (FED-7); an admission quarantine finding contradicting local records (FED-8); actuation-linked divergence involving federated mirrors handed over from ACT-10; a partner-raised dispute. - Actors: Agent detects, records and classifies at T3, and investigates and drafts resolution options at T2. The Resolution Decision is human and, for non-deterministic conflicts, non-delegable in substance: Steward for operational conflicts, Owner for authority or contract conflicts; where an Agent assists, the step SHALL remain T1 (Agent proposes options, the human approves each decision), recorded through GOV-1. Deterministic rule application MAY run at T2. Auditor verifies the Historical Trace. Joint bodies act per contract on escalation. - Inputs / Outputs: Inputs: the conflicting assertions with provenance from both sides; applicable contract clauses (precedence, dispute procedure); mapping set; binding records; the conflict history of this pair. Outputs: a conflict object with full lifecycle (Detection Event, investigation record, Resolution Decision with rationale, Resolution Event, Historical Trace persisted through MIR-9); updated mappings, bindings or annotations as decided; escalation packages for unresolved conflicts (GOV-1 appeal machinery on own side, contract dispute ladder across sides). - Steps: 1. Register the conflict as a first-class object with its own identity (never a transient error) and append the Detection Event. 2. Classify: identity conflict, mapping ambiguity, projection inconsistency, version incompatibility, lifecycle mismatch, contract disagreement, trust disagreement, or synchronization drift (Conflict-Resolution 4a). 3. History check: has this pair conflicted on this point before? Reuse the prior resolution rationale instead of re-litigating (Agent, T3 lookup). This step is mandatory. 4. Investigate: establish which Universe is authoritative for each disputed element per mastership declarations and contract (Agent drafts the finding, T2). 5. Gateway: does the contract's declared precedence rule resolve the conflict deterministically? Yes: apply the rule, record the Resolution Decision and Resolution Event (Agent MAY execute at T2), continue at step 9. 6. Draft resolution options with consequences: accept the partner value into the mirror with annotation; keep own value and record an annotated deviation; split the datum so each side masters its part; amend the mapping; amend the contract. 7. Decision by the accountable human, recorded through GOV-1; the step SHALL remain T1 where an Agent assists. No participant SHALL rewrite the other side's authoritative record. 8. Gateway: do the parties agree? No: escalate per the contract's dispute procedure (joint Stewards, then Owners, then the contractually named authority); suspension of the affected scope MAY apply while escalated, with decision deadlines per level. 9. Execute the decision. Corrections are new traceable artifacts (annotation, new mapping version, new record version), never deletions of Events, historical mappings, prior versions or historical contracts. 10. Append the Resolution Event with rationale and close the conflict object into its permanent Historical Trace (archived via MIR-9). - Controls: Conflicts SHALL never be silently resolved. The authoritative Universe remains the source of truth for its own objects. Resolution SHALL NOT justify disclosure beyond what the investigation strictly needs, and investigation reads are logged by the gate. The full trace (detection, alternatives considered, decision, rationale) SHALL survive resolution permanently through MIR-9's archival machinery, so past reconciliations are explainable and are not re-opened. - Tier: core. - Variants: Solo: the same lifecycle at small scale; the Owner is the entire escalation ladder. Team: standing conflict review between Steward pairs on both sides. Multi-party federation: a named neutral arbiter in the contract. Autonomy ceiling: deterministic rule application at T2 or T3; any judgment call SHALL remain T1. - Metrics: mean time from detection to resolution; share resolved deterministically by declared rules; recurrence rate of the same conflict pair; escalations per quarter. - Failure modes: (1) A quiet overwrite during sync erases the disagreement: guard: FED-6 forbids auto-fixing semantic drift, and audit compares mirror changes against conflict records. (2) Settled conflicts get re-litigated: guard: the step 3 history check is mandatory before investigation. (3) A conflict is used to fish for extra partner data: guard: investigation disclosure is scoped by least knowledge and every read is logged. (4) Escalation limbo: guard: contractual decision deadlines per level, with default-to-suspension of the affected scope on expiry. ### FED-10 Federation health monitoring - Purpose: Continuously observe every active federation (mirror freshness, consent hygiene, sync quality, Trust Vector trajectory, conflict aging, contract compliance) so degradation is seen by machinery before it is felt by Consumers. Health states (Healthy, Degraded, At-risk) are an operational overlay on the relationship, orthogonal to the canonical Federation-Lifecycle stage; At-risk feeds the Suspension transition (FED-11). Federation-Lifecycle stage: Active Federation, with step 7 operating the Evolution transition. - Trigger: continuous or scheduled evaluation (daily is typical; registered and meta-monitored as a QSC-15 standing job); threshold-breach alerts from FED-3, FED-4, FED-6 and FED-8; a pre-review before contract renewal. - Actors: Agent computes signals and watches thresholds at T3. Steward receives alerts, confirms states and runs periodic reviews at T2. Owner receives the periodic health report and decides status changes at the contract's review cadence (decisions recorded through GOV-1). - Inputs / Outputs: Inputs: sync reports, disclosure logs, consent register, admission quarantine reports and per-source Trust Vectors (FED-8), Owner attestations of per-partner live disclosure surface (FED-3 step 10), conflict register, contract terms and service levels, the FED-5 baseline snapshot. Outputs: a health state per federation (Healthy, Degraded, At-risk); alert Events; the periodic health report; recommendations (renew, renegotiate, suspend, terminate) feeding FED-2 or FED-11. - Steps: 1. Collect per-federation signals: last successful cycle; mirror freshness versus staleness limits; admission quarantine reject rate; Trust Vector trend per relied-upon dimension; open conflicts and their age; upcoming grant expiries; disclosure block rate; due or overdue Owner attestations of the partner's total live disclosure surface; unanswered partner communications; zero-delta streaks. 2. Evaluate signals against contract service levels and internal floors (versioned GOV-2 configurations). 3. Gateway: any hard floor breached (consent violation, unlogged release, Trust Vector below the operating floor predicate)? Yes: raise an incident (QSC-8 for disclosure violations, QSC-14 otherwise), mark the federation At-risk, and propose suspension of the affected scope. 4. Gateway: soft degradation (stale mirrors, rising rejects, aging conflicts)? Yes: mark Degraded and open remediation tasks with owners and deadlines. 5. Compile the periodic health report per federation with trend deltas against the baseline. 6. Steward review: confirm or adjust states; threshold changes are made only through recorded GOV-2 configuration change Events. 7. Owner review at the contract's cadence: renew, evolve (the Evolution transition: return to FED-2 for amendment), suspend or terminate (hand to FED-11); the review includes attesting each partner's total live disclosure surface as compiled by FED-3. 8. Record every state change as an Event. - Controls: Health states and threshold changes SHALL be traceable Events; thresholds live as versioned GOV-2 configurations. An At-risk state SHALL block new grant auto-issuance for that partner until cleared and SHALL propose the Suspension transition. Monitoring SHALL read only operational metadata, never partner content beyond what contracts already delivered. State downgrades MAY be automatic; state upgrades require Steward confirmation. - Tier: recommended (SHOULD be treated as core wherever more than two federations are active). - Variants: Solo: a monthly checklist over one federation. Team: a dashboard plus a weekly Steward review. Fleet scale: a cross-federation view with anomaly detection; at MOS scale (external reference repository) the monitoring machinery is itself subject to audit. Autonomous: signal computation always T3; the Owner review at step 7 is never delegated. - Metrics: detection lead time (share of degradations seen by the monitor before a Consumer complaint); mean time spent in Degraded; false alert rate; review cadence adherence. - Failure modes: (1) Green dashboard, dead federation: metrics measure activity, not meaning: guard: include semantic probes (a round-trip sample exchange) among the signals. (2) Alert fatigue: guard: the hard-floor versus soft-degradation split in steps 3 and 4, with the alert budget reviewed quarterly. (3) Thresholds quietly loosened to stay green: guard: threshold changes are versioned GOV-2 configuration Events with rationale and the Auditor reviews them. (4) Monitoring itself over-reads partner data: guard: the metadata-only rule in Controls, checked in audit samples. (5) The monitor silently dies: guard: FED-10 runs as a QSC-15 registered standing job with independent meta-monitoring escalating into QSC-14. ### FED-11 Federation suspension and clean termination - Purpose: Pause or end a federation without losing history, leaking residual access or corrupting mirrors: revoke live grants, settle surviving obligations, disposition mirrors per contract, and preserve the complete record. A model that cannot exit a federation cleanly cannot safely enter one. Federation-Lifecycle stage: Suspension, Termination and Historical Preservation (Federation-Lifecycle 4). - Trigger: Owner decision (GOV-1); contract expiry; an At-risk escalation from FED-10; a partner request; Trust Vector collapse from FED-8; a model retirement runbook (MIR-11) sequencing termination per partner; a governance or legal order. - Actors: Owner decides suspension and termination; the decision is non-delegable in substance and recorded through GOV-1. Steward executes the runbook. Agent executes checklist steps at T2 (each completion verified) and runs revocation sweeps and inventory diffs at T3. Auditor (engaged via GOV-6) certifies closure. Partner-facing notices SHALL remain T1 (Agent drafts, a human approves each notice). - Inputs / Outputs: Inputs: the Federation Contract (termination and survival clauses); the consent register filtered by partner; mastership register mirror entries; identity binding register; open conflicts; the disclosure log. Outputs: suspension or termination Event; revocation sweep results; mirror disposition record; final reconciliation statement; the preserved historical package (participants, contracts, Events, sync history, mappings, bindings, trust decisions) archived via MIR-9. - Steps: 1. Record the decision Event through GOV-1: who, why, suspension or termination, effective date. 2. Gateway: suspension or termination? Suspension: pause or revoke active grants within one TTL, halt sync cycles (standing jobs paused via QSC-15), freeze mirrors read-only with a Suspended label, keep contracts and historical obligations alive, set a review date, done (the resume path re-enters through a FED-5 dry run). Termination: continue. 3. Notify the partner per the contract's notice terms. 4. Revocation sweep: revoke every live grant to the partner, walking the delegation graph for delegated and derived grants; verify at the gate that no partner capability remains valid past one TTL (Agent, T3; Steward verifies the report). Revocation is gate-enforced, never grantee-honored. 5. Outbound residuals: enumerate what was delivered and survives under surviving obligations; send deletion or retention notices as the contract requires; record the partner's destruction or retention attestations. 6. Inbound residuals: disposition mirrors per contract. Default: freeze as a clearly labeled historical archive ("as of final sync"). Deletion only where contractually required and lawful, executed conservatively (backup first, small test scope, then full run) with a tombstone Event. 7. Close open conflicts: resolve them, or record them closed-unresolved with their full trace. None are silently dropped. 8. Update registers: mastership entries retired via MIR-1; identity bindings marked historical (preserved, never deleted); mappings deprecated with history intact; partner credentials and keys retired through GOV-8; standing jobs for this federation torn down through QSC-15; dependent Consumers notified against the CON-13 register. 9. Final reconciliation: both parties confirm the closing state; a disagreement goes through FED-9 one last time. 10. Assemble the historical package and store it under normal retention (retention policy per GOV-2, archival via MIR-9). Historical preservation SHALL outlive the federation. 11. Auditor certifies the closure checklist; record the termination Event; FED-10 stops monitoring and retains the last state. - Controls: Termination SHALL NOT delete historical Events, identity bindings, audit records or contractual history. Residual partner access past one TTL is an incident (QSC-14). Deletion steps SHALL follow conservative destructive-operation practice: explicit criteria, backup, small-scope test, then execution. Previously disclosed knowledge remains governed by surviving contract obligations after termination. - Tier: core. - Variants: Solo: the same checklist, executed in an afternoon. Team: a Steward-led runbook with Agent checklist execution. Contested termination: a legal hold MAY freeze mirror disposition while every other step proceeds. Autonomy ceiling: the decision and all partner-facing notices SHALL remain T1; sweeps and diffs run at T3. - Metrics: time from decision to zero residual access; checklist completion rate at Auditor certification; residual access incidents after the TTL (target zero); historical package completeness score. - Failure modes: (1) The revocation sweep misses a delegated or derived grant: guard: the sweep walks the delegation graph and is verified by a gate-side probe. (2) Frozen mirrors quietly used as if fresh: guard: machine-readable "historical, as of final sync" labels that warn Consumers on every read, with addressees resolved against CON-13. (3) History destroyed in cleanup zeal: guard: deletion scope is limited to content the contract requires deleted, never Events or registers, and the Auditor certifies. (4) Termination stalls half-done (grants dead, mirrors ambiguous): guard: a single runbook with completion certification; FED-10 keeps the federation At-risk until certified.