## GOV: governance, access and operations This family is where the Owner's authority becomes procedural. Every other family's cards end an escalation with a human decision: MIR disputes mastership, CON approves and rules, FED signs and terminates, ACT accepts risk above the floor, QSC certifies, CTX arbitrates. GOV is the machinery behind those sentences: it makes decisions recordable and appealable (GOV-1), authors the policies and configs the gates evaluate (GOV-2), guarantees the deciding human exists and is replaceable (GOV-3), births the model that all of this governs (GOV-4), funds the work (GOV-5), procures independent eyes (GOV-6), grants and revokes internal access (GOV-7), and keeps the keys (GOV-8). Every T1 gate in the palette resolves here: the decision is a GOV-1 Event, the matrix it consulted is a GOV-2 artifact, the human who made it is on the GOV-3 role register, and the access it presupposed is a GOV-7 grant. Governance, access and operations are one family because they are three faces of one act of authority. A decision that creates permission (governance) is worthless without the grant that encodes it (access) and the custody, rotation and succession machinery that keeps both true over time (operations). Splitting them is how earlier drafts of the palette produced phantom families: load-bearing artifacts handed to owners that did not exist. Four laws: 1. **Authority is procedural.** No decision without a ledger Event citing the decider's authority; no policy without a version; no permission without a register entry; no role without a successor path. A gate that cannot cite these is not fail-closed, it is broken. 2. **GOV authors, others execute.** The Impact Matrix, approval matrix, auto-approval lane criteria and lane classifier, standing consent policies, tier maps, gate configs, retention policy, decision SLAs and severity rubrics are versioned GOV-2 artifacts, shipped with defaults, executed by the CON, FED, ACT and QSC gates. All of them belong to the security-critical dataset class (COMMON): acceptance at T1 with a second human reviewer, structurally ineligible for auto-approval lanes, hashes anchored continuously by QSC-9. 3. **Grants are contracts.** Internal access grants are Semantic Contracts (Contract.md 3a and 5-6): explicit, purpose-driven, versioned, revocable, time-bounded. GOV-7 mirrors FED-3's discipline inward and masters the register QSC-6 audits. Revocation is gate-enforced with bounded propagation, never honored on trust. 4. **No gate fails closed forever.** Deputies, escrowed Owner authority, quorum succession and continuity drills (GOV-3) bound every fail-closed state in time. Fail-closed is a safety posture; fail-forever is a design defect. The family is delegation-heavy in execution and human at the core. Agents assemble decision files, draft policies, run registers, mint and sweep grants, reconcile inventories and watch every SLA, at T2 and T3 under Delegation Contracts mastered by CTX-9. What never delegates in substance: appointing, deciding, ruling on appeal, consenting to disclosure, accepting risk, engaging an auditor and approving custody. Tiers are used as defined in the palette preamble (COMMON) and never re-glossed here. Vocabulary note: where GOV cards say quarantine, it is MIR-8's sense (readable but flagged trust marking); admission quarantine (FED-8 inbound holding) and integrity hold (QSC-9) do not occur in this family. Core processes: GOV-1, GOV-2, GOV-3 and GOV-7 for every conformant model; GOV-4 core at birth (it executes once, and a conformant model SHALL be able to show its genesis record); GOV-8 core wherever any credential exists. Recommended: GOV-5, GOV-6. Reference implementations: vault custody and scoped per-role agent services in the Orkestron ecosystem; the Meta-Orchestrator State (the external reference Dimension repository, orkestron-ai/meta-orchestrator-state) is the scale stress case, where resource governance (GOV-5) and standing-policy grant issuance (GOV-7) are constitutive, not conveniences. ## Interfaces to other families Both directions, by family key and process ID: - **CON**: In: GOV-2 policy and config changes enter the model exclusively through the CON chain (CON-1 intake, CON-3 gates, CON-4 review at T1 with a second reviewer; auto-approval lanes structurally ineligible per the security-critical dataset class); GOV-1 ledger appends use CON-1's registered channel with the mechanical event-append lane. CON-9 appeals escalate to GOV-1 as the Owner appeal instance; CON-13 supplies the consumer identities GOV-7 grants resolve against; CON-10 consumes GOV-3 role identity for Steward-side actors. Out: the approval matrix, auto-approval lane criteria and the diff-based lane classifier executed by CON-4's gateway; the retention policy CON-8 history rules and MIR-9 cite; GOV-1 rulings returned to CON-9 as precedent; GOV-4 genesis scaffolds the manifests and structures that CON-3 and CON-6 thereafter maintain. - **MIR**: In: MIR-1 mastership disputes and MIR-8 quarantine-release escalations arrive at GOV-1; MIR-6's SLA realism review consumes the GOV-5 capacity plan; MIR-11 retirement invokes GOV-7 revocation sweeps, GOV-8 credential retirement and a GOV-1 terminal decision. Out: GOV-7 issues the per-pipeline source-read grants MIR-2 and MIR-5 cite; GOV-2 retention policy parameterizes MIR-9; GOV-4 initializes the Mastership Register (empty) that MIR-1 solely executes thereafter. - **ACT**: In: ACT-12 tier and envelope findings feed GOV-1 decisions (and route to CTX-9 step 8 as named inputs); repeated emergency invocations reach GOV-1 through QSC-14. Out: GOV-2 authors and versions the Impact Matrix every ACT card cites as a required input, the ACT-2 default correlation window, the ACT-4 assessment schema, and the per-class emergency limits and cumulative impact budgets enforced mechanically at ACT-6 dispatch; GOV-8 retires effector credentials in step with ACT-3 retirement. - **FED**: In: FED-2 signatures, FED-11 terminations and the periodic Owner attestation of each partner's total live disclosure surface are recorded as GOV-1 Owner Events (the attestation feeds FED-10); FED-5 key exchange consumes GOV-8-custodied local material; FED-6 partner-rotation failures land in GOV-8 on the local side. Out: standing consent policies with per-grantee aggregate scope ceilings are GOV-2 artifacts executed by FED-3; GOV-7 is FED-3's declared domestic mirror (shared consent discipline, separate registers; a partner never holds a GOV-7 grant); GOV-3 succession evidence MAY serve partners as Trust Vector governance-dimension input. - **QSC**: In: QSC-6 audits the GOV-7 grant register (actual grants diffed against register plus standing policy; every auto-issued grant cites its policy version); QSC-9 continuously anchors hashes of GOV-2 artifacts and GOV-8 published fingerprints; the first QSC-4 run gates GOV-4 activation; QSC-14 orders GOV-8 emergency rotation and receives GOV residual-access and starving-machinery incidents; QSC-15 runs GOV standing jobs (rotation, expiry sweeps, telemetry collection) from its registry. Out: GOV-5 capacity plans and the telemetry dataset feed QSC-11 planning intake; GOV-6 provisions time-boxed Auditor access for QSC-5 and QSC-10 and certifies its teardown; GOV-3 drill findings and GOV-8 reconciliation findings enter QSC-11 debt intake. - **CTX**: In: Delegation Contracts are mastered solely by CTX-9; GOV cites them and never issues them; CTX-9 consumes GOV-2 tier maps for scoping and GOV-5 compute quotas for contract limits, and records the Owner sign-offs its step 2 requires as GOV-1 Events; CTX-7 unresolved arbitration patterns escalate to GOV-1. Out: GOV-7 grants gate CTX-1 extraction; Context Packages carry the grant IDs they were built under and expire on GOV-7 revocation or their fixed TTL, whichever is sooner; GOV-3 handovers execute through CTX-8 mechanics. Key artifacts this family exports: the governance ledger (GOV-1); the versioned policy and configuration set including the Impact Matrix (GOV-2); the role register and succession plan (GOV-3); the genesis record and activation Event (GOV-4); the capacity plan and telemetry dataset (GOV-5); engagement and attestation records (GOV-6); the internal grant register (GOV-7); the credential inventory and published signing-key fingerprints (GOV-8). ### GOV-1 Governance decision and escalation ledger - Purpose: Make Owner and Steward authority procedural: receive every escalation the palette routes to a human, decide it within a declared SLA, record the decision as a versioned Event with rationale and cited authority, and run the appeal ladder. A decision that is not in the ledger did not happen, and no gate may act on it. - Trigger: Any process escalates a decision to the Owner or a Steward (the palette's T1 gates and named escalations: MIR-1 mastership disputes, MIR-8 quarantine releases, CON-9 appeals, CTX-7 unresolved arbitration patterns, FED-2 signing decisions, FED-11 terminations, QSC-11 risk acceptances, ACT-12 findings, and all GOV-2 through GOV-8 decision points); a role holder initiates a decision; an appeal is filed; a decision SLA breaches; the periodic Owner attestation of partner disclosure surfaces falls due. - Actors: The Owner decides Owner-class matters; Stewards decide within delegated sections; deciding and ruling on appeal are non-delegable in substance. Agent MAY assemble the decision file (evidence, impact, precedent search) at T3, MAY draft an options assessment at T2, and MAY run queue routing and SLA tracking at T3. No Agent decides at any tier. - Inputs / Outputs: Inputs: the escalation with its evidence, the applicable GOV-2 policies and decision-class taxonomy, the GOV-3 role register, prior decisions as precedent. Outputs: a decision Event (decider, authority cited, rationale, effective date), queue and SLA state, appeal records, directives to the executing process, and the periodic attestation records that feed FED-10. - Steps: 1. Register the escalation, classify it by decision class (GOV-2 taxonomy), and assign the decider from the role register (Agent at T3). 2. Gateway: is the assigned decider available? If not, invoke the GOV-3 deputy or succession path; an escalation SHALL NOT wait on an absent human beyond its class SLA. 3. Assemble the decision file: evidence, affected datasets and actors, applicable policy versions, precedent (Agent at T3). 4. Draft options with consequences (Agent MAY draft at T2). 5. Decide: the human decides and states rationale (non-delegable). Where the decision changes a policy or config, route execution through GOV-2; where it changes access, through GOV-7; where it changes a register, through the register's sole executor (MIR-1 for mastership). The ledger records; the owning process executes. 6. Record the decision Event, notify the escalating process and affected actors, and open execution tracking with a completion state. 7. Gateway: appeal filed within the declared window? One step up the ladder: Steward decisions appeal to the Owner; Owner decisions are re-heard by the Owner only on new evidence. The appellate decision is final within the Universe. 8. Review the ledger on cadence: aging queues, overdue executions, and recurring decision classes that SHOULD be converted into GOV-2 standing policy (decide once, encode, stop deciding repeatedly). This review MAY join the consolidated quarterly review (COMMON). - Controls: Every decision names its authority (role, and the delegating decision where authority was delegated); the ledger is append-only versioned Events; each decision class carries an SLA with breach alarms; the deputy path is exercised per GOV-3 so no queue fails closed on an absent human; executing processes SHALL refuse a directive that cannot cite a ledger Event; ledger appends execute through the CON chain as a registered channel using the mechanical event-append lane (COMMON), while the decision content itself is never lane-eligible. - Tier: core - Variants: Solo: the ledger is the Owner-Steward's decision log; the discipline that survives is authority citation, rationale, and the SLA alarm that catches self-neglect. Team: per-section Steward queues with an Owner appeal lane. Federated: cross-Universe matters leave the ledger as FED-9 cases; the ledger records only this Universe's position, consents and attestations. At MOS scale, agent-assembled decision files and precedent search keep thousands of escalations tractable; queue routing is the load-bearing step. - Metrics: Median decision latency per class against SLA; SLA breach count; appeal rate and reversal rate; share of recurring decisions converted to standing policy per period; directives executed without a ledger citation (target zero). - Failure modes: Decisions made in chat and never recorded, so gates act on authority that cannot be audited (guard: executing processes refuse directives without a ledger Event reference). A queue silently starving because its decider left (guard: step 2 deputy gateway plus the GOV-3 continuity drill). The ledger becoming a bottleneck for what should be policy (guard: step 8 conversion review with a recurrence threshold). Appeal used to stall execution indefinitely (guard: one appeal step, time-boxed, with the original decision in force unless suspended by the appellate decider). ### GOV-2 Policy and configuration lifecycle - Purpose: Author, version and retire every policy and configuration artifact the palette's gates evaluate: the approval matrix, auto-approval lane criteria and the diff-based lane classifier, standing consent policies with per-grantee aggregate scope ceilings, risk appetite, retention policy, tier maps, gate configs, decision-class taxonomy and SLAs, severity rubrics, watch and threshold configs, and the Impact Matrix. GOV-2 authors; CON, FED, ACT and QSC execute. Shipped defaults make every gateway decidable on day one. - Trigger: A GOV-1 decision directs a policy change; a shipped default needs local adaptation; a scheduled policy review falls due; a finding proposes a change (QSC audit, ACT-12, classifier mismatch log, QSC-14 postmortem lesson); GOV-4 genesis instantiates the shipped defaults. - Actors: The Owner approves policies that create or bound authority (consent policies, approval matrix, risk appetite, retention policy); the Steward authors and maintains within Owner-approved bounds. Agent MAY draft policy text and compute impact diffs at T2 and MAY run distribution, uptake verification and review scheduling at T3. Every acceptance step SHALL remain T1 (Agent proposes, human approves each act) with a second human reviewer per the security-critical dataset class (COMMON). - Inputs / Outputs: Inputs: the GOV-1 directive or proposal, the current versioned artifact, the shipped palette defaults (Impact Matrix defaults: low/medium/high impact by reversible/compensable/irreversible with assessment floor medium, rollback-plan floor medium, separation-of-duties and independent-evidence floor high, solo default everything reversible and in-scope below the floor; gateway defaults for FED-8 floors as Trust Vector predicates, the ACT-2 correlation window, the ACT-4 assessment schema, MIR-4 semantic order, CTX-1 selection rules), findings and postmortem lessons. Outputs: a versioned artifact with effective date, a change Event with rationale, distribution to executing gates, and a policy register entry with review-by date. - Steps: 1. Register the proposal; identify the affected artifact and every gate that executes it (Agent at T3 computes the consumer list from the policy register). 2. Draft the change (Agent MAY draft at T2); machine-evaluated configs (lane classifier, floors, ceilings, tier maps, budgets) are expressed in executable form plus a human-readable rationale. 3. Run impact analysis: which processes, lanes, contracts and running gates change behavior; where tooling exists, simulate the classifier or floor change against a recent sample (Agent at T3). 4. Accept: T1 with a second human reviewer (security-critical class, COMMON); the change enters the model through the CON chain (CON-1 intake, CON-3 gates, CON-4 review); auto-approval lanes are structurally ineligible for this class, enforced in CON-4's gateway, not by classification. 5. Version and publish with a forward-only effective date; distribute to executing gates; gates SHALL pin the version they evaluate and stamp it in their Events. 6. Verify uptake: no gate still evaluates a superseded version past the cutover window (Agent at T3); a stale gate is a QSC-14 incident. 7. Review each artifact by its review-by date; the review MAY join the consolidated quarterly review of the Solo/Minimal profile (COMMON). - Controls: Every artifact is versioned and hash-anchored continuously by QSC-9, with any unexplained diff opening QSC-8; acceptance never below T1, second reviewer mandatory, lanes structurally ineligible; the lane classification consumed by CON-4's gateway SHALL NOT originate from the submitting agent or its orchestrator, and classification-versus-diff mismatches are logged as findings; shipped defaults are the floor: a model that has not localized them runs them as shipped; every executing Event cites the policy version it evaluated. - Tier: core - Variants: Solo: shipped defaults do most of the work; the Owner-Steward localizes only what pinches, a declared cooling period stands in for the second reviewer, and the next GOV-6 engagement samples every policy change made since the last one. Team: Steward-authored, Owner-approved, second reviewer from another section. Federated: standing consent policies and disclosure floors are the FED-facing subset; a change touching a live Federation Contract triggers FED-7 compatibility review before its effective date. Drafting and simulation are agent work; acceptance is never autonomous. - Metrics: Artifacts past review-by date (target zero); gate version staleness incidents; classifier mismatch findings per period; share of changes traceable to a GOV-1 decision or a postmortem lesson; simulation coverage of classifier and floor changes. - Failure modes: Config drift: a gate evaluates an edited-in-place config with no version Event (guard: QSC-9 hash anchoring plus version pinning at the gate). Policy changed to legalize yesterday's exception (guard: forward-only effective dates; retroactive legalization requires an Owner decision in GOV-1 naming the affected acts). A lane-criteria widening riding an auto-approval lane (guard: structural ineligibility in CON-4's gateway). Defaults localized so aggressively the model's conformance story diverges from the palette's (guard: localizations are diffs against the shipped default, visible as such to the Auditor). ### GOV-3 Role appointment, succession and continuity - Purpose: Ensure that the humans the palette's gates depend on always exist: appoint the Owner, Stewards, Auditor liaison and deputies; keep an Owner succession plan with escrowed authority and quorum rules; train and hand over Stewards; and drill continuity so that no T1 gate fails closed forever. - Trigger: GOV-4 genesis; a role falls vacant or its holder is unavailable; a planned transfer; the periodic continuity drill; a deputy invocation from GOV-1 step 2; a GOV-8 role-change credential sweep. - Actors: The Owner appoints (non-delegable in substance); appointees accept scope explicitly; succession quorum members act under the plan when the Owner cannot. Agent MAY maintain the role register, track acceptances and expiries, and run drill logistics at T3, and MAY draft handover packages at T2. Appointment, transfer and succession invocation decisions are human. - Inputs / Outputs: Inputs: candidate identity and qualification evidence, the role register, the succession plan, the GOV-2 tier map bounding each role's delegation authority. Outputs: appointment and transfer Events, the updated role register, deputy designations with scoped standing authority, the versioned succession plan, handover packages, drill reports. - Steps: 1. Appoint: the Owner (or a delegated Steward for sub-roles) appoints, scoping the role to sections and decision classes; record the appointment Event; update the role register (Agent at T3 for register mechanics). 2. Brief and train: the appointee completes CON-10 identity and briefing for contribution rights plus role-specific training (GOV-1 decision duties, GOV-2 artifacts in scope, the T1 gates the role serves); acknowledgment is recorded before queue assignment. 3. Designate deputies: every Steward role carries at least one deputy with scoped standing authority naming the decision classes the deputy may decide and for how long when invoked; Owner-class matters name the succession plan, never an informal deputy. 4. Maintain the Owner succession plan: successor or quorum designation, escrowed authority (credentials and signing capability recoverable under the quorum rule, custody per GOV-8), incapacity criteria, invocation procedure. The plan is a GOV-2 class artifact: versioned, T1 with second reviewer, reviewed on cadence. 5. Hand over on transfer: outgoing and incoming holders execute a handover using CTX-8 mechanics (declared state, handover note as model content, explicit acceptance); open GOV-1 queue items are reassigned; grants re-pointed via GOV-7; credentials via GOV-8. 6. Invoke succession: on Owner incapacity per the plan's criteria, the quorum invokes escrowed authority; every act under escrow is an Event citing the plan version; the first duty is appointing or confirming a new Owner, after which escrow closes and material is re-escrowed. 7. Drill continuity on cadence: exercise the deputy path and dry-run the succession procedure the way MIR-9 exercises reconstruction; verify escrow recoverability without exposing material; file findings into QSC-11. - Controls: Every T1 gate in the palette SHALL resolve to a currently appointed human via the role register; no role without a deputy or succession path (fail-closed is bounded in time, never forever); escrow custody is separated per GOV-8 so no single custodian can invoke alone; succession acts are the most heavily evidenced Events in the ledger; drill findings are QSC-11 debt with aging alarms. - Tier: core - Variants: Solo: the register is trivial but the succession plan is not: a solo Owner-Steward SHALL name an heir or executor arrangement and escrow recovery material, or the model dies with its human; the drill is an annual recovery walkthrough. Team: deputies per section, cross-trained on adjacent queues. Federated: partners MAY require succession-plan evidence before signing long-lived contracts (a Trust Vector governance-dimension input); role changes touching signing authority trigger GOV-8 fingerprint re-anchoring and partner notice. - Metrics: Roles with a current deputy and a tested succession path (target 100 percent); drill cadence adherence and findings closed; median vacancy duration; escalations stalled on an absent decider (target zero). - Failure modes: The Owner is gone and every T1 gate fails closed forever (guard: succession plan with escrowed authority and quorum invocation; drills prove it works before it is needed). Deputy authority so vague it is never used, or so broad it is a shadow Owner (guard: designations name decision classes and durations). Handover by folklore, the new Steward learning by breaking things (guard: CTX-8 style handover package plus training acknowledgment before queue assignment). Escrow material staler than the systems it unlocks (guard: drill step verifies recoverability every cycle). ### GOV-4 Model and Dimension genesis - Purpose: Bring a new model or Dimension from nothing to Active conformantly: scaffold the repository from a conformant template, appoint roles, initialize registers and manifests, instantiate the policy set from shipped defaults, pass the first validation run, register in the Universe, and emit the activation Event. A model not born through genesis has no authority baseline for any later audit to stand on. - Trigger: An Owner decides to create a model or Dimension (recorded in GOV-1); an organization adopts the standard for a new domain; Dimension bootstrap at MOS scale; CTX-3 decomposition promotes a part to a sovereign model. - Actors: The founding Owner authorizes (non-delegable); the appointed Steward executes the scaffold. Agent MAY execute the mechanical scaffold, register initialization and validation runs at T2 (human reviews each stage output). Nothing in genesis runs at T3: the tier ladder (CTX-9) has no track record to draw on at birth. - Inputs / Outputs: Inputs: the founding decision, the conformant template (structure, BOOTSTRAP, manifest and register skeletons, shipped GOV-2 defaults, versioned with provenance), role candidates, the initial scope declaration. Outputs: a scaffolded repository, appointment Events (GOV-3), initialized manifest.yaml and sources.yaml (mastered by MIR-1 thereafter), an initialized Event log, empty grant register (GOV-7), credential inventory (GOV-8), role register (GOV-3) and consumer register (CON-13), the instantiated policy set, the first QSC-4 validation report, the Universe registration, and the activation Event. - Steps: 1. Record the founding decision in GOV-1: purpose, scope, conformance target, governing standard version. 2. Appoint the Owner and at least one Steward via GOV-3; establish the succession plan skeleton before activation, not after. 3. Scaffold the repository from the conformant template: BOOTSTRAP.md, manifest.yaml, empty Mastership Register, Event log, well-known locations (Agent at T2). 4. Instantiate the GOV-2 policy set from shipped defaults (Impact Matrix, approval matrix, lane criteria and classifier, tier maps, gate configs, retention policy, decision SLAs, severity rubrics); localize only what the founding decision requires; record versions. 5. Initialize registers and operations: grant register, credential inventory, role register, consumer register; declare initial cadences and SLAs; register standing jobs with QSC-15 (no unregistered crons from day one). 6. Seed initial content, if any, through the lawful paths only (CON-7 bulk import or MIR-2 harvest under declared register entries, with MIR-1's Owner gate for new external systems); genesis itself moves no content. 7. Gateway: is the first QSC-4 validation run green at the declared conformance target? If no, remediate and re-run. Activation SHALL NOT proceed on a red, waived or skipped first validation. 8. Register the model in the Universe or Dimension registry; for federating models this is the identity FED-1 discovery later resolves. 9. Emit the activation Event (model identity, standard version, conformance target, validation report reference, register states). The model is Active; genesis closes and its scaffold authority expires. - Controls: Activation is gated on the first QSC-4 run without exception; roles and the succession skeleton exist before activation; no content lands during genesis outside the CON and MIR lawful paths; the template is versioned and its provenance recorded; genesis credentials and scaffold grants carry an activation-bound TTL per GOV-7 and expire at step 9. - Tier: core at birth (executes once per model, dormant thereafter; a conformant model SHALL be able to show its genesis record) - Variants: Solo: half a day with the template; the steps that matter are 2 (succession skeleton), 4 (defaults as shipped) and 7 (the validation gate). Team: staged execution with per-stage sign-offs. Federated and MOS: Dimension bootstrap at scale runs genesis per Dimension from a shared template lineage; the registry entry makes the newborn addressable; CTX-3 promotion cases inherit content lawfully through the decomposition record, never by copy. - Metrics: Time from founding decision to activation; first-validation pass rate (a poor template shows here first); post-activation defects traced to genesis shortcuts; share of models with a complete genesis record (target 100 percent). - Failure modes: A model activated on a red or skipped first validation, so every later audit lacks a clean baseline (guard: step 7 is unwaivable). Genesis scaffold authority lingering after activation as an ambient super-grant (guard: activation-bound TTL; the first QSC-6 audit verifies zero genesis grants live). Registers created empty and never filled while content arrives anyway (guard: step 6 lawful-path rule plus MIR-1 refusal on undeclared external involvement). Template rot: new models born from a stale template inherit yesterday's defaults (guard: the template is a versioned artifact with its own review-by date under GOV-2). ### GOV-5 Stewardship resourcing and capacity planning - Purpose: Give the palette an economy: plan steward hours, agent compute quotas and storage budgets against what the declared cadences actually cost, keep utilization telemetry as a model-mastered dataset, and feed cost reality back into SLA, cadence and contract decisions so under-resourcing surfaces as a decision, not as quiet rot. - Trigger: The periodic planning cadence (MAY join the consolidated quarterly review, COMMON); a new obligation changes the load (a federation, a dataset class, a standing job); a telemetry threshold trips (utilization, backlog, storage projection); the QSC-11 planning cycle requests capacity input. - Actors: The Owner accepts the plan and its trade-offs (funding and priority are non-delegable in substance); the Steward drafts. Agent SHALL collect telemetry and compute projections at T3 and MAY draft the plan at T2. Acceptance SHALL remain T1 (Agent proposes, human approves each act). - Inputs / Outputs: Inputs: period telemetry (steward time per family, agent compute per Delegation Contract, storage per dataset class, queue depths, SLA attainment), the retention policy (GOV-2), the standing-job registry (QSC-15), open debt (QSC-11). Outputs: a versioned capacity plan (hours, quotas, budgets per period), resourcing decision Events, the telemetry dataset (model-mastered), and named feeds to QSC-11 planning, the MIR-6 SLA realism review and CTX-9 contract limits. - Steps: 1. Collect the period's telemetry (Agent at T3); telemetry is emitted by the mediating infrastructure per the palette's logging rule, never self-reported by the Agents being budgeted. 2. Project forward: storage against the retention policy, compute against contract growth, steward hours against cadence obligations and queue trends (Agent at T3). 3. Gateway: does any declared obligation exceed projected capacity? Every underfunded cadence is listed explicitly; silent stretching is the failure this process exists to prevent. 4. Draft the plan with trade-offs per shortfall: fund it, reduce the cadence (a GOV-2 change), narrow the scope, or accept the risk (a QSC-11 entry with Owner sign-off) (Agent MAY draft at T2). 5. Accept: the Owner accepts the plan at T1; record resourcing decision Events; changed cadences and SLAs route through GOV-2; changed contract quotas route to CTX-9. 6. Publish the telemetry dataset and the plan; QSC-11 consumes both in its planning intake. 7. Watch thresholds between cycles (Agent at T3); a breach opens an off-cycle review, and a sustained breach is a QSC-14 incident: the machinery is starving. - Controls: Telemetry is model-mastered and mechanically collected, never estimated after the fact; every declared cadence in the palette appears in the plan with a cost line (unfunded obligations are named, not implied); risk acceptance is an Owner Event, never a silent default; the plan is versioned with its assumptions stated. - Tier: recommended (SHOULD be core above a declared size or consumer threshold, and wherever agent compute is metered or exchanged) - Variants: Solo: the plan is one page: the hours the human really has, the storage the retention policy really implies, and the honest reduction decisions that follow; the value is making the mismatch visible before it becomes vanity SLAs. Team: per-family budget lines and a real planning session. MOS: constitutive: tiered compute exchange between Dimensions makes GOV-5 the market interface, and per-contract quotas become enforcement inputs for CTX-9 limits and ACT-6 budget checks. - Metrics: SLA attainment versus funded capacity (the correlation is the point); unfunded obligation count (target zero, by funding or by explicit reduction); storage projection accuracy; off-cycle review count per period. - Failure modes: Vanity SLAs: declared cadences nobody can staff, discovered at audit (guard: step 3 explicit underfunding list; the MIR-6 realism review consumes the plan). Telemetry self-reported by the agents being budgeted (guard: infrastructure-emitted telemetry only). Storage growing to the retention default until the disk is the incident (guard: projection against retention policy with thresholds; QSC-13 consumes the same projection for backup sizing). The plan produced and ignored (guard: resourcing decisions are Events with execution tracking in GOV-1). ### GOV-6 Auditor engagement lifecycle - Purpose: Make independent audit procurable and safe: select and qualify the Auditor, attest independence structurally, scope the engagement, provision time-boxed access via GOV-7, accept the deliverables, verify access teardown, and rotate auditors so audit never becomes capture. - Trigger: A QSC-5 audit or QSC-10 certification falls due; a GOV-1 decision orders an audit; a GOV-2 rule requires periodic engagement (including the solo peer-audit arrangement); a QSC-14 postmortem recommends independent review. - Actors: The Owner engages the Auditor and accepts the report (non-delegable in substance); the Steward scopes and coordinates. Agent MAY run candidate screening, conflict-of-interest checks, logistics, milestone tracking and teardown verification at T3, and MAY draft the engagement scope at T2. The Auditor is by definition not an actor in this model's other processes for the duration of the engagement. - Inputs / Outputs: Inputs: the audit obligation (QSC-5 and QSC-10 requirements), the candidate pool with qualification and independence evidence, the engagement history (rotation state), the scope proposal. Outputs: an engagement record (scope, deliverables, period), a signed independence attestation, GOV-7 grants (time-boxed, purpose-bound), the accepted report as an Owner Event in GOV-1, a teardown verification record, and the updated rotation state. - Steps: 1. Establish the need and scope from the triggering obligation; draft deliverables and the engagement period (Agent MAY draft at T2). 2. Select: screen candidates for qualification and structural independence: no current or recent Contributor, Steward, operator or vendor-of-record relationship to this model, and never audit of own work (Agent screens at T3; the selection decision is human and recorded in GOV-1). 3. Attest: the Auditor signs the independence attestation; the attestation is a versioned engagement artifact. 4. Provision access via GOV-7: read grants scoped to the engagement's datasets, purpose-bound to the engagement record, TTL equal to the engagement period plus the declared closure window; credentials via GOV-8; never ambient or shared access. 5. Run the engagement: the Auditor works under QSC-5 and QSC-10 process rules; this process tracks milestones and access use through mediating-infrastructure logs. 6. Accept deliverables: the Owner accepts or contests the report in GOV-1; findings enter QSC-11 debt intake. 7. Tear down: revoke grants and credentials at closure; verify zero residual access with a gate-side probe (Agent at T3); residual access past TTL is a QSC-14 incident. 8. Update rotation state: consecutive-engagement limits per GOV-2 policy; the same Auditor SHALL NOT exceed the declared consecutive count without a rotation or a documented Owner exception. - Steps note: only steps 1, 4, 5, 7 and 8 admit agent execution; selection, attestation acceptance and report acceptance are human acts. - Controls: Independence is attested before access and structurally checked, not just declared; access is GOV-7 time-boxed and purpose-bound, with teardown verified, never assumed; report acceptance is an Owner Event; rotation limits with recorded exceptions; the Auditor's own access trail is audit evidence for the next engagement. - Tier: recommended (SHOULD be core for any model that publishes conformance claims or certifies via QSC-10) - Variants: Solo: the peer-audit arrangement: a reciprocal engagement with another model's Owner-Steward under the same attestation, access and teardown discipline; rotation means alternating peers. Team: organizational procurement rules stack on top; the palette's requirements are the floor. Federated: partners MAY recognize each other's engagement records as Trust Vector evidence. MOS: per-realm cross-auditing agent appointments follow this same lifecycle, with agent auditors named under their accountable operators. - Metrics: Engagements with verified teardown (target 100 percent); residual-access findings per engagement (target zero); rotation compliance; time from obligation due to engagement start. - Failure modes: The perpetual auditor: one auditor forever, independence decaying into familiarity (guard: rotation limit with recorded Owner exceptions). Audit access outliving the engagement as forgotten grants (guard: TTL plus the step 7 probe; QSC-6 diffs catch stragglers). Independence attested but structurally false: the auditor operates the infrastructure they audit (guard: the step 2 screen covers operator and vendor-of-record relationships). No procurement path when the audit falls due, so the obligation quietly lapses (guard: the obligation itself triggers this process with an SLA in GOV-1). ### GOV-7 Internal access grant lifecycle - Purpose: Issue, renew and revoke every internal access grant (Consumer read scopes, Agent read scopes, pipeline source access, projection endpoint access, engagement access) and master the internal grant register that QSC-6 audits. GOV-7 is the domestic mirror of FED-3: the same discipline of request, decision, purpose binding, TTL, renewal and revocation with bounded propagation, applied inward. Grants are Semantic Contracts per Contract.md 3a and 5-6: explicit, purpose-driven, versioned, revocable, with parties, scope, effective period, obligations and lifecycle state. - Trigger: An access request (human, Agent under contract, pipeline, Consumer via CON-13 registration, Auditor via GOV-6); a standing consent policy match; a renewal falls due; a revocation cause arises (role change per GOV-3, contract suspension per CTX-9, incident, retirement per ACT-3, FED-11 or MIR-11); the recertification cadence. - Actors: The Owner decides grants outside standing policy (non-delegable in substance); Stewards decide within Owner-delegated sections. Agent MAY auto-issue at T2 strictly under an Owner-approved, versioned standing consent policy, citing the policy version in the grant; Agent SHALL execute registration, propagation, expiry sweeps and revocation mechanics at T3. Agents never expand access outside such a policy. - Inputs / Outputs: Inputs: the request (requester, datasets, purpose, duration), the grant register, standing consent policies with per-grantee aggregate ceilings (GOV-2), the requester's Delegation Contract state (CTX-9) where the requester is an Agent, and the mastership and sensitivity of the requested datasets. Outputs: a grant recorded as a versioned Semantic Contract in the register, issuance, renewal and revocation Events, capability material minted with short validity, propagation confirmations, and recertification records. - Steps: 1. Register the request; validate requester identity and, for Agents, live Delegation Contract scope (Agent at T3). 2. Gateway: does the request match a standing consent policy, including its per-grantee aggregate ceiling after composition with the requester's existing grants? If yes, auto-issue at T2 citing the policy version. Crossing a ceiling structurally escalates to T1 regardless of template match. 3. Otherwise decide at T1: Steward within delegated sections, Owner for restricted classes; purpose SHALL participate in the decision: the same dataset MAY be grantable under one purpose and denied under another. 4. Bind and issue: record the grant with purpose, scope, effective period and obligations; mint capability material with short validity so worst-case revocation propagation is bounded; register entry before material, never after. 5. Propagate: gates and channels consume the register; every read, write and dispatch validates grant (and, for Agents, contract) liveness at act time, at the gate, never by requester honor. 6. Renew: renewal is a fresh decision or a fresh policy match, never an automatic extension; unrenewed grants expire by TTL. 7. Revoke: on cause, revoke in the register, invalidate capability material, tear down channels within the declared TTL, and verify with a gate-side probe that no residual access remains; residual authority past TTL is an incident (QSC-14, or QSC-8 where security-relevant). 8. Recertify on cadence via the generic register-recertification pattern (COMMON): enumerate entries, check age and usage against mediating-infrastructure access logs, re-approve or retire, record the Event; MAY join the consolidated quarterly review. - Controls: The register is the single source QSC-6 diffs against (actual grants versus register plus standing policy, with every auto-issued grant citing its policy version); no capability material without a register entry; TTL on all material, no perpetual grants; revocation is gate-enforced with bounded propagation and probe verification; Context Packages carry the grant IDs they were built under and expire on grant revocation or their fixed TTL, whichever is sooner; access logs are emitted by the mediating infrastructure, never self-reported. - Tier: core - Variants: Solo: the register still exists: the Owner-Steward's own agents and pipelines each hold real scoped grants, or QSC-6 has nothing true to audit; issuance ceremony is light, TTL and revocation discipline are not. Team: per-section delegation with standing policies for routine read scopes. Federated: outward-facing grants are FED-3's; the two registers share the consent discipline but never merge, and a federation partner never holds a GOV-7 grant. MOS: thousands of citizen-agent read scopes run on standing policies with aggregate ceilings; human attention goes only to ceiling crossings and restricted classes. - Metrics: Share of live access with a current register entry (target 100 percent, QSC-6 verified); worst-case revocation propagation time against TTL; residual-access incidents (target zero); auto-issue share and policy-citation completeness; recertification currency. - Failure modes: Ambient access: channels provisioned once, grants forgotten, register fiction (guard: capability TTL forces re-mint from the register; QSC-6 diff catches divergence). Agent self-expansion in the name of a task (guard: agents never expand access outside standing policy; the gate validates against the register, not the agent's claim). Revocation honored by the revoked party (guard: gate-side enforcement plus probe; honor-based compliance is non-conforming). Aggregation within policy: many small in-policy grants composing past what the Owner would knowingly approve (guard: the step 2 composition check against per-grantee ceilings, mirroring the FED-3 discipline inward). ### GOV-8 Credential and key lifecycle - Purpose: Manage every secret the model references but never stores: inventory credentials and keys keyed to effector, pipeline, partner and engagement register entries, separate custody, rotate routinely as standing jobs, run signing-key succession with re-anchoring of published fingerprints, retire credentials together with what they served, and provide the emergency-rotation interface to the incident process. - Trigger: A new effector (ACT-3), pipeline (MIR-2 register entry), partner exchange (FED-5) or engagement (GOV-6) needs credentials; a rotation falls due; a holder or role changes (GOV-3); a retirement runs (ACT-3, FED-11, MIR-11); an incident directive orders emergency rotation (QSC-14, QSC-8); the inventory reconciliation cadence. - Actors: The Owner approves custody arrangements and signing-key succession (non-delegable in substance); the Steward operates the lifecycle. Agent MAY execute rotation mechanics, cutover verification and fingerprint publication at T2 (human reviews each rotation batch); inventory reconciliation and expiry watching run at T3. No Agent SHALL hold, read or transcribe secret values: agents operate references and custody-service operations; the material stays inside custody boundaries, per the ACT-3 rule that credentials live outside the model and are referenced, never stored. - Inputs / Outputs: Inputs: the credential inventory (model-mastered references, never values), effector, pipeline, partner and engagement register entries, the custody policy (GOV-2), the rotation schedule, incident directives. Outputs: inventory entries keyed to their register anchors, rotation Events with cutover confirmations, published signing-key fingerprints with re-anchoring Events, retirement Events, custody attestations. - Steps: 1. Inventory: every referenced secret has an entry naming its register anchor (which effector, pipeline, partner or engagement), custodian, storage location class, rotation cadence and expiry (Agent reconciles at T3); an unanchored credential is a finding. 2. Assign custody per policy: separation such that no single actor holds both a credential and the approval authority over its use; succession escrow material (GOV-3) is held under quorum custody. 3. Issue: mint or receive credentials into custody; record the inventory entry and its linkage: a credential without a live GOV-7 grant or register entry behind it serves nobody lawfully. 4. Rotate routinely: standing jobs registered in QSC-15 rotate on cadence with per-consumer cutover: new material issued, consumers cut over, old material verified dead, Event recorded (Agent at T2 per batch). 5. Run signing-key succession: generate the successor under custody; re-anchor published fingerprints (the QSC-9 verification chain locally, partners via the federation channel); declare a short dual-validity window; retire the predecessor with a succession Event. An expired signing key with no successor breaks the QSC-9 and QSC-10 chain: succession is scheduled before expiry, never after. 6. Retire: when an effector (ACT-3), federation (FED-11), pipeline or the model itself (MIR-11) retires, revoke and destroy or archive-under-custody its credentials in the same runbook; verify dead with a probe. 7. Rotate on emergency: on an incident directive (QSC-14, or QSC-8 for security incidents), rotate the affected class out of cadence; containment first, ceremony after; the incident record carries the rotation Events. 8. Reconcile on cadence: diff the inventory against register entries and against custody reality; orphan credentials (no anchor) and shadow credentials (in use, not inventoried) are findings; MAY join the consolidated quarterly review (COMMON). - Controls: Values never in the model, references only; every credential anchored to a register entry and a purpose; custody separation enforced (nobody approves the use of a credential they hold); rotation is a standing job with cutover verification, not a calendar hope; fingerprint re-anchoring precedes predecessor retirement; usage logs come from the mediating infrastructure, never from the credential holder; emergency rotation SHALL NOT wait on routine cadence. - Tier: core where any credential exists (any model with an effector, a credentialed pipeline, a federation or an engaged auditor; a purely hand-authored, non-federating model with no credentialed machinery MAY leave it dormant) - Variants: Solo: a vault or password manager, an inventory file of references, calendar-driven rotation and one tested recovery path; the discipline that survives is anchoring, expiry and the succession escrow. Team: a custody service with per-role access, custodian roles distinct from approver roles. Federated: partner key rotation is a coordinated cutover with notice per the Federation Contract; the FED-6 partner-rotation failure mode is handled here on the local side. Reference implementation: vault-held credentials operated by scoped agent services that execute rotation without reading values (an Orkestron-style pattern); MOS scale adds per-Dimension custody domains. - Metrics: Inventory coverage (referenced secrets with anchored entries, target 100 percent); rotation currency (share within cadence); orphan and shadow findings per reconciliation (trend to zero); signing-key succession lead time before expiry; emergency rotation time from directive to verified cutover. - Failure modes: A signing key silently expires and every signature verification fails at once (guard: succession scheduled before expiry with a dual-validity window; QSC-9 monitors chain continuity). Rotation rotates the secret but not the consumers, causing an outage read as an attack (guard: per-consumer cutover verification inside the standing job). A departed holder retains credentials (guard: the GOV-3 role-change trigger, custody attestation and probe). Shadow credentials minted ad hoc during an incident and never inventoried (guard: step 7 records rotations in the incident record; step 8 diffs custody reality).