# QSC: quality, consistency and security operations ## Doctrine A Vercy model is only the primary digital reflection of reality while four claims stay demonstrably true: its content is good (complete, accurate, evidence-backed), its content is coherent (no contradictions inside a model or between the models of one Universe), its content is protected (read only under Owner grants, written only by attributable actors within scope, tamper-evident end to end), and its machinery is operable (the apparatus that keeps the first three claims true is itself running, backed up and watched). The QSC family operates the machinery that keeps those four claims measurable and enforced. Three principles govern every QSC process: 1. **Gate and gradient are never confused.** Validation (V0-V5) is the pass/fail gate; the Semantic Coherence Score, per the standard's quality doctrine, is the gradient on top of it. A model SHALL NOT claim a validation level it has not achieved, and a high Semantic Coherence Score SHALL NOT substitute for conformance. 2. **Assessment never mutates the assessed.** Every QSC run reads pinned versions, produces immutable, reproducible reports (any party can recompute the same verdict from the same evidence), and routes fixes through the normal change process (CON). Findings that are not fixed immediately go to the quality debt register (QSC-11); nothing is silently dropped. 3. **Delegation with accountability.** Stewards delegate most QSC execution to Agents under Delegation Contracts whose single System of Record is CTX-9, at tiers T1/T2/T3 as defined once in the palette preamble (cited here, never re-glossed). Accountability stays with the Steward, agents never expand their own access or audit their own actions, and every agent act is attributable in an Event trail emitted by the mediating infrastructure (gate, channel, runtime), never by the acting Agent. The family audits the agents as rigorously as it audits the content. ## The four loops - **Quality loop:** QSC-1 (Semantic Coherence Score) and QSC-4 (validation) measure; QSC-11 (debt register) plans remediation; QSC-10 (conformance) declares honestly what was achieved; QSC-12 (outcome drift) checks that a valid model still serves its purpose. - **Consistency loop:** QSC-2 inside one model, QSC-3 across the models of one Universe; both feed QSC-11. - **Security loop:** QSC-6 (access review against the GOV-7 grant register), QSC-9 (integrity verification), QSC-7 (agent behavior audit), QSC-8 (leak and exposure response, the security specialization of QSC-14). - **Operations loop:** QSC-13 (backup and disaster recovery), QSC-14 (operational incident management and postmortem), QSC-15 (standing job and monitoring operations). QSC-5 (periodic audit) independently reviews all four loops, including whether the loops themselves ran honestly. ## Core set After the palette-wide retiering, the QSC core set is: QSC-2, QSC-4, QSC-6, QSC-8, QSC-9, QSC-11, QSC-13 and QSC-14, plus QSC-7 wherever Agents execute processes and QSC-15 wherever any standing job, scheduler or monitor is declared (a purely manual model MAY omit those two and SHALL document that it does), plus QSC-10 for any model that publishes or federates externally. QSC-1, QSC-3 and QSC-5 are recommended; QSC-12 is optional. The Solo/Minimal conformance profile in COMMON consolidates the standing cadences this family mandates (one quarterly consolidated review covers the QSC-6 and QSC-11 recertification and planning steps due in the window; one weekly combined sweep covers the mechanical steps of QSC-2 and QSC-9). ## Vocabulary 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: excluded from answering and publication until cleared. Internal grants are Semantic Contracts (Contract.md 3a) mastered by GOV-7; a Federation Contract is the cross-Universe form of a Semantic Contract, and QSC uses that term in every cross-Universe context. ## Stress test MOS (the Meta-Orchestrator State, cited here as a reference to the external reference Dimension repository orkestron-ai/meta-orchestrator-state, not to the standard) exercises the family at its extreme: 38 interlocking namespaces in six clusters (QSC-3 becomes mandatory in practice), thousands of AI citizen agents acting under delegation (QSC-7 at T3 scale with statistical sampling), value-balancing hypotheses whose success is observable in live flows (QSC-12), and sovereignty rules where every cross-model read requires an Owner grant (QSC-6 over the GOV-7 register). If a process card below could not run for MOS, it was rewritten until it could; a solo Owner-Steward with one model runs the same cards in their minimal variants under the COMMON Solo/Minimal profile. ## Interfaces to other families - **MIR (mirror and actualization):** In: raw-capture hashes with capture-time attestations from MIR-2 (attestor separated from collector per COMMON), the Mastership Register (MIR-1) consumed by QSC-1, QSC-2, QSC-13 and QSC-15, MIR-7 drift Events and run records (QSC-9 step 5 verifies MIR-7 ran and samples honesty, never re-runs detection), MIR-6 SLA breach findings and MIR-1 declared-entry debt into QSC-11 intake, MIR-8 quarantine state consumed by scoring and reporting. Out: integrity findings to MIR-7, structural findings to MIR-1, report and history persistence per MIR-9 retention. MIR-11 model retirement receives its final QSC-4 and QSC-10 snapshots and a QSC-13 terminal backup, and tears down this family's standing jobs via QSC-15. - **ACT (actuation):** In: ACT-12 loop-health reports and orphan-link findings into QSC-11; random independent re-verification sampling of below-floor actuations reported through QSC-7 together with ACT-12; actuation trails emitted by the ACT-6 dispatch gates (infrastructure-emitted per COMMON) audited by QSC-7 and hash-chain-verified by QSC-9. Out: QSC-7 tier evidence routed into CTX-9 step 8 governs the contracts ACT agents act under; QSC-14 provides the incident discipline for ACT-8 emergency anomalies; QSC-13 degraded-mode rules suspend dispatch above the Impact Matrix floor (a GOV-2 artifact) during outages. - **CON (contribution and change):** QSC-2 and QSC-4 (V0-V2) act as blocking gates on CON-4 change acceptance (green check identifiers recorded in change Events); every QSC finding returns as a fix through the CON chain, since QSC never mutates content. CON-11 is the sole capture path for intended external edits (QSC-9 raises findings, never routes or regenerates). CON-12 standard migrations dual-run QSC-4 and mandate a QSC-10 statement update. CON-13's consumer and subscription register resolves QSC-8 and QSC-14 notifications. Structure and manifest ownership, including the coverage walker, is CON territory (CON-3/CON-6); walker findings land directly in QSC-11 intake. - **FED (federation):** Establishing or amending a federation requires a current Validation Report through V4 (QSC-4) and a Conformance Statement or certificate (QSC-10, core for federating models). FED-8 admission quarantine (inbound holding, unreadable until promoted) precedes any landing QSC-9 later verifies. QSC-8 exchanges breach notices under Federation Contract clauses (FED-2 terms, FED-11 termination). FED-3 auto-issued grants are reviewed by QSC-6 against register plus standing consent policy with policy-version citations. FED-10 health evaluation registers as a QSC-15 standing job. - **CTX (context and delegation):** CTX-9 is the single System of Record for the Delegation Contract lifecycle: QSC-7 reconciles against it, suspends through its fast path, and routes tier promotion and demotion recommendations into CTX-9 step 8 as named inputs. CTX-1 origin and taint classes are the basis of QSC-7 step 4 injection-bait refusal tests. Context Package expiry on grant revocation is verified within QSC-6 and QSC-7 reviews. - **GOV (governance, access and operations):** Decisions, appeals and risk acceptances are recorded through GOV-1. The approval matrix, gate configs, auto-approval lane criteria, severity rubrics, watch configurations, backup and retention policies and tier maps are GOV-2 versioned artifacts that QSC executes and QSC-9 anchors (security-critical dataset class per COMMON). Roles, deputies and succession come from GOV-3. GOV-4 genesis gates a new model's activation on its first QSC-4 run. GOV-5 capacity plans and utilization telemetry feed QSC-11 planning. GOV-6 engages the Auditor for QSC-5 and the certifier for QSC-10, with time-boxed access provisioned via GOV-7 and verified torn down. GOV-7 masters the grant register QSC-6 diffs against; internal grants are Semantic Contracts (Contract.md 3a). GOV-8 masters credentials and keys: routine rotation runs as QSC-15 standing jobs, signing-key succession re-anchors QSC-9's published fingerprints, and QSC-8 containment uses GOV-8's emergency rotation interface. - **QSC internal:** Standing jobs and watchdogs live in QSC-15; incidents in QSC-14 with QSC-8 as its security specialization; backups and disaster recovery in QSC-13; every finding, from every family, lands in QSC-11. ### QSC-1 Record, layer and model quality assessment - Purpose: Measure completeness, accuracy and evidence backing of model content at three granularities (per record, per layer, per model) and produce the model's Semantic Coherence Score: a reproducible, banded quality gradient per the standard's quality doctrine, never a conformance verdict. - Trigger: Scheduled cadence declared by the model (for example weekly); after a significant change batch; on Steward request; always before certification (QSC-10). - Actors: Steward (accountable, sets scoring profile). Agent: score computation and roll-up at T3; accuracy sampling against evidence at T2 (human reviews disputed samples); changes to weights, thresholds or required-field templates SHALL remain T1 (Agent proposes, human approves each act). Auditor MAY recompute any published score. - Inputs / Outputs: Inputs: model repository at a pinned version (records, manifests, Mastership Register per MIR-1, provenance sidecars), versioned scoring profile (dimension weights, required-field template per record type), previous quality report. Outputs: quality report (per-record scores, per-layer roll-ups, the model's Semantic Coherence Score 0-100 with band and per-dimension breakdown), quality debt candidates for QSC-11. - Steps: 1. Pin the model version and fingerprint; load the versioned scoring profile. 2. Enumerate records via the model's coverage walker (CON-3/CON-6 structure machinery). Gateway: walk green? If red, abort scoring, file a structural finding directly into QSC-11 intake, report the red walk to the Steward. 3. Score completeness per record: required fields present per the record type template; Display Name and description present for public concepts. 4. Score evidence backing per record: provenance present and resolvable; cited evidence links resolve; significant facts declare owner and origin. 5. Score accuracy on a stratified sample per layer: model-mastered facts compared against their cited evidence; mirrored facts compared against the external master within its declared staleness limit (Agent proposes verdicts at T2; Steward reviews disputed samples). 6. Score freshness per record against the declared review cadence of its dataset. 7. Roll up scores as transparent weighted sums per layer and per model, normalized to 0-100 with published bands. 8. Gateway: any record, layer or dimension below its floor threshold? File typed debt items to QSC-11. 9. Publish the quality report as an immutable artifact, including method, profile version, sample lists and full breakdown; record a scoring Event. - Controls: Scoring profile is versioned and changed only at T1 with rationale (Agent proposes, human approves each act); report SHALL be reproducible by any party from the same pinned version; scoring SHALL NOT modify content; accuracy disputes escalate to the Steward; the report states explicitly that the Semantic Coherence Score is a gradient, not a conformance verdict (gate versus gradient per the family doctrine); QSC-10 checks any published claim that cites the score. - Tier: recommended (core above a declared size or consumer threshold; the threshold is a versioned GOV-2 configuration) - Variants: Solo: single walker plus self-run sampling with a written checklist, at whatever cadence the model declares; the COMMON Solo/Minimal profile applies. Team: one Steward per bundle, consolidated model report. Federated: each model scores itself and publishes; the Universe aggregates published reports, never raw content. Manual execution possible via checklist; hybrid (T3 compute, T2 sampling) is the normal mode; fully autonomous only for computation, never for profile changes. - Metrics: Semantic Coherence Score and trend; share of significant facts with resolvable evidence; accuracy sample pass rate; scoring coverage (records scored divided by records enumerated). - Failure modes: Score gaming by weight tuning (guard: profile versioned, T1-only changes, profile published with every report). Scoring a stale working copy (guard: pin version and fingerprint in step 1). Sample too small to mean anything (guard: minimum sample size per layer enforced by the profile). Score treated as conformance (guard: mandatory gate-versus-gradient statement in the report; QSC-10 checks claims). ### QSC-2 Intra-model consistency assessment - Purpose: Verify that a single model is internally consistent: every reference resolves, declared invariants hold, and no two facts contradict each other without an annotated deviation. - Trigger: Every change batch (as a gate before acceptance in CON-4); scheduled full sweep at the model's cadence; on demand after imports or restructuring; after a QSC-14 postmortem lands new invariants. - Actors: Steward (accountable, adjudicates contradictions at T1). Agent: mechanical checks at T3; contradiction candidate detection at T2. Contributors execute fixes through the normal change process (CON). - Inputs / Outputs: Inputs: model head at a pinned version, versioned invariant catalog (standard invariants plus model-declared ones, extended by versioned lesson changes from QSC-14), Mastership Register (MIR-1), previous consistency report. Outputs: consistency report; contradiction register entries; debt items for QSC-11. - Steps: 1. Pin the version; load the invariant catalog. 2. Run reference resolution: relationship endpoints, event subjects, projection subjects and contract references all resolve to declared identities (V2-02 discipline); count dangling references. 3. Check structural invariants: unique identifiers, canonical naming, bundle and layer membership per the manifest. 4. Check mastership invariants: no edits inside mirrors, raw captures or generated artifacts; every dataset covered by the Mastership Register; no dataset writable on both sides of a partition. 5. Check lifecycle invariants: every state transition has its Event; no silent transitions; Object, Version and Projection lifecycles tracked independently (three-times separation). 6. Run the semantic contradiction scan: the same property asserted with conflicting values for the same subject in the same context, without an annotated deviation (Agent flags candidates at T2). Gateway: contradiction confirmed? Steward adjudicates at T1: order a fix, or record an annotated deviation with rationale. Silent deletion of one side is forbidden. 7. Publish the consistency report; file unresolved findings as debt items. - Controls: Check set mapped to stable check identifiers so two runs on the same version reach the same verdict; deviations SHALL be annotated, never silently accepted; the report is an immutable artifact; mirror hashes compared against the independently emitted harvest attestation sidecars (MIR-2, attestor separated from collector per COMMON) to detect in-model tampering with mirrored bytes; invariant changes arriving from QSC-14 postmortems land as versioned catalog changes, never ad hoc edits. - Tier: core - Variants: Solo: automated checks plus self-adjudication with a written deviation log; under the COMMON Solo/Minimal profile the mechanical steps MAY run inside the weekly combined sweep with one combined Event. Team: adjudication routed to the Steward of the affected bundle. Federated: runs per model; cross-model concerns hand off to QSC-3. Manual: checklist-driven walk (viable only for small models); hybrid is standard; autonomous T3 for all mechanical steps. - Metrics: Dangling reference count (target 0); invariant violations per thousand records; mean time from contradiction flagged to adjudicated; share of contradictions closed as annotated deviation versus fixed. - Failure modes: Agent "fixes" a contradiction by deleting one side (guard: adjudication is T1-only; agents may only flag). Invariant catalog rots while the model evolves (guard: catalog versioned, reviewed at every QSC-5 audit, and fed by QSC-14 lessons). Edits inside mirrors pass unnoticed (guard: harvest-time attestation hashes verified every sweep, see QSC-9). Gate skipped under deadline pressure (guard: change acceptance in CON-4 requires a green consistency check identifier recorded in the change Event). ### QSC-3 Cross-model consistency assessment - Purpose: Verify that the models of one Universe agree where they overlap: shared identities resolve or are mapped, no dataset has two masters, cross-model references and consumed projections stay within contract, and no two models assert contradictory facts about a shared subject. - Trigger: Scheduled Universe-level cadence; a new model joining the Universe (born via GOV-4); any mastership change; a conflict reported by any Steward. - Actors: Universe-level Steward or a council of the involved Stewards (accountable). Owner of each model grants read scope through GOV-7 (nothing is compared without a grant). Agent: graph building and mechanical checks at T3; conflict candidate analysis at T2. Adjudication of confirmed conflicts is joint T1 between the Stewards of the involved models, recorded via GOV-1. - Inputs / Outputs: Inputs: read grants per model (GOV-7), each model's manifest, Mastership Register, fingerprints, declared semantic mappings and contracts; the Universe identity register. Outputs: cross-model consistency report; mastership conflict register; mapping gap list; debt items routed to the owning models. - Steps: 1. Confirm a current GOV-7 read grant from every Owner in scope. Gateway: any model not readable? Exclude it, record the scope reduction visibly in the report. 2. Pin the version and fingerprint of every included model; build the cross-model reference graph. 3. Check identity agreement: the same real-world entity carries one canonical identity or an explicit declared mapping between models. 4. Check mastership uniqueness across the Universe: no dataset claimed as master by two models; partitions explicit on both sides. 5. Check projection and contract consistency: every cross-model consumption goes through a declared Projection under a Contract, within the agreed version range. 6. Flag semantic conflicts: contradictory assertions about shared subjects (Agent at T2). Gateway: lawful partition or genuine violation? The Stewards of both models adjudicate jointly at T1; unilateral edits to a sibling model are forbidden. 7. Publish the report to all involved Stewards and the Universe Steward; file debt items into each affected model's register. - Controls: Owner permission per model via GOV-7, least-scope read only; the comparison SHALL NOT write to any model; joint adjudication for cross-model conflicts recorded via GOV-1; all comparison reads appear in access logs emitted by the mediating infrastructure (COMMON) and are auditable by QSC-7. - Tier: recommended (SHALL be treated as core once a Universe operates more than one model) - Variants: Solo (one Owner, several models): the Owner-Steward self-grants via GOV-7 and runs the same mechanics. Team: a standing Universe consistency round with rotating chair. Federated between sovereign Universes: out of scope here; only published projections are compared under MUFP synchronization rules. Hybrid is standard; autonomous T3 for graph checks with T2 conflict triage. - Metrics: Cross-reference resolution rate; open mastership conflicts (target 0); mapping coverage of declared overlaps; median age of open conflicts. - Failure modes: Comparing stale mirrors and reporting phantom conflicts (guard: staleness check before comparison, fingerprints recorded in the report). One Steward "fixing" another's model (guard: joint T1 adjudication, fixes only via the owning model's change process). Comparison agent reading beyond its grants (guard: scope declared in its CTX-9 Delegation Contract, verified by QSC-7). Excluded models silently forgotten (guard: scope reductions are mandatory report content and age as debt). ### QSC-4 Validation run (V0-V5) - Purpose: Execute layered validation per the Validation specification, producing a Validation Report that gates conformance claims, publication and federation. - Trigger: On creation before first activation (the GOV-4 genesis gate); on every change batch (at least V0-V2); before establishing or amending a federation (through V4); scheduled full run; on request before certification; dual-run during a CON-12 standard migration (old and new target levels); final snapshot during MIR-11 model retirement. - Actors: Steward (accountable; decides on Error remediation at T1; waivers do not exist, Errors are fixed or the level is not claimed). Agent: executes the validator and assembles the report at T3. Auditor MAY re-run independently on the same pinned version. - Inputs / Outputs: Inputs: model head at a pinned version and fingerprint, a validator implementing the Abstract Test Procedures for each claimed level, previous Validation Report, target level. Outputs: Validation Report (model identity, fingerprint, highest level achieved, per-check status by check identifier, findings with severity and location, validator identity, timestamp); Conformance Statement update trigger when the achieved level changes; debt items. - Steps: 1. Pin the model version and compute the fingerprint. 2. Run V0 (syntax). Gateway (repeated after every level): unresolved Errors at this level? Stop, publish the partial report, file debt items, notify the Steward. 3. Run V1 (structural: composition hierarchy, manifest, primitives). 4. Run V2 (semantic: unique identities, resolving references, well-typed relationships, canonical naming, fingerprint match). 5. Run V3 (constitutional: identity persistence, owner and provenance on significant facts, projection discipline, contracts and purpose on external projections, explicit context). 6. Gateway: does the model federate or intend to? Run V4 (public schema discoverability, contracts on exchanged projections, published version and fingerprint, mappings for imported standards). 7. Gateway: does a live runtime exist? Optionally run V5 (instances conform to the model; no semantic drift; outcome drift signals delegated to QSC-12). V5 findings are Info and never block. 8. Assemble and publish the Validation Report as an immutable, referenceable artifact. 9. Gateway: achieved level lower than previously claimed? Treat as a significant change: record a regression Event with rationale, notify the Steward and Owner, trigger a Conformance Statement update (QSC-10). - Controls: A level passes only with zero unresolved Errors; the report is traceable and referenced by conformance claims; the validator itself is versioned and named in the report; regression SHALL be documented, never silently absorbed; Warnings older than a declared number of cycles escalate directly into QSC-11 debt intake. - Tier: core - Variants: Solo: validator in the repository toolchain, run before every publish. Team: wired into the change pipeline as a blocking gate for V0-V2 and a scheduled full run. Federated: partners exchange Validation Reports during negotiation; each side MAY re-run on the published interchange package. Manual validation is nonviable beyond toy models; hybrid or autonomous T3 execution with T1 remediation decisions is standard. - Metrics: Highest level passed and its stability over time; Error count trend per level; median time from Error found to resolved; run frequency versus declared cadence. - Failure modes: Claiming an unachieved level (guard: every claim must cite a report identifier; QSC-10 verifies). Validating a copy instead of the head (guard: pin-and-fingerprint in step 1, fingerprint printed in the report). Warnings ignored forever (guard: aging escalation into QSC-11). V5 findings misused to block releases (guard: V5 severity is Info by definition; the gateway notes it). ### QSC-5 Periodic quality and security audit - Purpose: Independent periodic review, by an Auditor, of the model and of the QSC apparatus itself: did the assessments run, were they honest, and are they effective. - Trigger: Schedule (for example quarterly); Owner request; mandatory after any major incident (QSC-8, QSC-14) or critical agent violation (QSC-7). - Actors: Auditor (independent; SHALL NOT audit work they performed or supervised; engaged, attested and rotated via GOV-6, with time-boxed access provisioned via GOV-7 and torn down at closure). Agent: evidence collection and cross-referencing at T2 under the Auditor's direction. Steward responds to findings. Owner receives the final report directly; acceptance is recorded as a GOV-1 Event. - Inputs / Outputs: Inputs: all QSC reports since the last audit, the quality debt register, access logs (emitted by mediating infrastructure per COMMON), Delegation Contracts from the CTX-9 System of Record and agent action logs, incident records (QSC-8, QSC-14), the QSC-15 job registry, QSC-13 backup and drill evidence, declared cadences. Outputs: audit report with findings and ratings; management response; remediation commitments filed into QSC-11 with deadlines. - Steps: 1. Agree the audit scope and period with the Owner; pin the evidence window. 2. Collect evidence (Agent at T2): reports, logs, registers, read-only. 3. Verify execution: every QSC process ran at its declared cadence, including QSC-13 backup jobs and DR drills and QSC-15 heartbeat operations; gaps listed; alarms reconciled against QSC-14 incident records (every alarm accounted for). 4. Re-perform samples: recompute a sample of Semantic Coherence Scores (QSC-1), re-run validation on a pinned past version (QSC-4), re-decide a sample of access review verdicts (QSC-6), re-trace a sample of agent actions against CTX-9 contracts (QSC-7), re-verify a restore sample against QSC-13 manifests. Gateway: re-performance diverges from published results? Escalate as an integrity finding, widen the sample, inform the Owner immediately. 5. Review debt register honesty: findings from reports actually filed, aging tracked, closures evidence-backed, risk acceptances not expired. 6. Review the delegation posture: contracts current in CTX-9, tiers matched to demonstrated reliability, no self-auditing agents. 7. Draft findings; give the Steward a bounded response window; record responses verbatim. 8. Issue the final report to the Owner; file remediation items with owners and deadlines into QSC-11. - Controls: Auditor independence enforced structurally by GOV-6; all audit access is read-only, time-boxed via GOV-7 and logged; the report goes to the Owner, not only to the audited Steward; re-performance (step 4) is mandatory, an audit without it is not an audit. - Tier: recommended - Variants: Solo: an external peer audit procured via GOV-6, or a time-boxed cold self-review against the published checklists after a deliberate gap (weakest acceptable form, declared as such in the report). Team: internal audit role separate from stewarding. Federated: Universes MAY exchange auditors or recognize each other's audit reports. Hybrid execution; autonomous evidence collection only, judgment stays human. - Metrics: Findings count and severity mix; repeat-finding rate (same cause twice); remediation on-time completion rate; cadence adherence rate discovered in step 3. - Failure modes: Self-audit theater (guard: GOV-6 independence attestation; solo variant must name its compensating mechanism). Audit that only reads reports without re-performing (guard: step 4 is mandatory). Findings with no owner or deadline (guard: register intake requires both). Audit access quietly widened into a standing grant (guard: audit grants are time-boxed GOV-7 grants; GOV-6 verifies teardown at closure). ### QSC-6 Access review and permission drift detection - Purpose: Ensure that actual read and write access on every surface matches what Owners have granted, detect drift continuously, and shrink access back to the granted state. Information from any model is readable only with its Owner's permission; this process makes that sentence operational against the GOV-7 grant register. - Trigger: Continuous drift monitor (event or threshold based, a QSC-15-registered standing job); periodic full review (for example quarterly); on any grant change; on any personnel or agent change; on contract expiry. - Actors: Owner (sole grant authority, exercised through GOV-7 decisions or Owner-approved standing consent policies; approves expiries and any expansion at T1). Steward runs the review. Agent: diffing actual permissions against the grant register at T3; executing revocations of unauthorized excess at T2 (Steward sample-reviews); anything touching privilege escalation or grant expansion SHALL remain T1 (Agent proposes, human approves each act). Consumers are notified of changes affecting them via the CON-13 register. - Inputs / Outputs: Inputs: the grant register mastered by GOV-7 (who may read or write which dataset, projection or contract, granted by which Owner, until when), the Owner-approved versioned standing consent policies (GOV-7 internally, FED-3 for federation), actual permission state of every declared surface (repository, publication channels, projection endpoints, federation contracts, credentials and tokens per the GOV-8 inventory), access logs emitted by mediating infrastructure. Outputs: access review report; drift findings; revocation and repair actions recorded as Events; expiry proposals; grant register attestation (the register itself changes only through GOV-7). - Steps: 1. Enumerate the declared surface list; export the actual permission state of every surface. 2. Diff actual state against the GOV-7 grant register plus the active standing consent policies (Agent at T3); check that every auto-issued grant cites the policy version it was issued under. 3. Gateway: unauthorized excess found (including an auto-issued grant that cites no policy version)? Classify: benign drift (misconfiguration, leftover) or possible breach. Possible breach triggers QSC-8 immediately. 4. Revoke benign excess (Agent at T2, Steward samples) through GOV-7's revocation path with its bounded propagation TTL; record each revocation as an Event with before and after state. 5. Repair missing-but-granted access (provisioning drift in the other direction). 6. Recertify grants by invoking the COMMON register-recertification pattern by reference (register: the GOV-7 grant register; thresholds: the declared dormancy window; approver: the Owner via GOV-7); dormant grants receive expiry proposals; the Owner decides. 7. Verify that every externally exposed Projection is governed by a Contract (a Federation Contract cross-Universe, a Semantic Contract internally per GOV-7) and declares a purpose; contract-less exposure is an Error finding. 8. Publish the review report; refresh the drift monitor baseline; attest the grant register with the Owner at every full review. - Controls: Grants are created only by Owner decision or mechanically under an Owner-approved, versioned standing consent policy (GOV-7 internally, FED-3 for federation); agents may never expand access outside such a policy; every permission change is an Event; the surface list is itself a registered dataset audited by QSC-5; breach-classified findings bypass normal queues into QSC-8; the drift monitor is a QSC-15-registered standing job whose dead heartbeat is a QSC-14 incident. - Tier: core - Variants: Solo: quarterly self-review with a scripted differ; the Owner-Steward attests their own register (declared as such); under the COMMON Solo/Minimal profile the recertification step MAY run inside the consolidated quarterly review with one combined report and per-register Events. Team: Steward runs, Owner attests, security-focused Contributor operates the monitor. Federated: each side reviews its own surfaces; contract-governed cross-Universe access is reviewed against the Federation Contract terms on both sides. Hybrid standard; continuous detection autonomous at T3, corrections at T2, grant decisions always human. - Metrics: Drift findings per period and their classification split; mean time from detection to revocation; dormant grant share; surface coverage of the review (surfaces reviewed divided by surfaces declared); auto-issued grants with missing policy citations (target 0). - Failure modes: Shadow copies on surfaces nobody enumerated (guard: surface list is mandatory register content; QSC-5 audits its completeness). Over-eager revocation breaking legitimate Consumers (guard: T2 sampling plus staged revocation with notice via CON-13, except in breach containment). The grant register itself stale or wrong (guard: Owner attestation each full review; GOV-7 is its sole master). Drift monitor silently dead (guard: QSC-15 heartbeat; a monitor that has not reported within its cadence escalates as a QSC-14 incident). ### QSC-7 Agent behavior audit - Purpose: Verify that delegated Agents stayed within their Delegation Contracts: scope, permitted actions, tier discipline (per the palette preamble ladder) and complete audit trails; verify refusal behavior including injection-bait refusal; recommend tier promotions and demotions on evidence into CTX-9. - Trigger: Scheduled cadence; anomaly threshold in action logs; after any incident; on any request to promote an agent to a higher autonomy tier; arrival of below-floor actuation re-verification sampling results (ACT-9/ACT-12). - Actors: Steward (accountable; can suspend a contract alone through CTX-9's fast path). Auditor for the independent periodic form (engaged via GOV-6). A reviewing Agent MAY assist at T2 but SHALL NOT audit its own actions or those of agents it orchestrates. Owner is informed of confirmed violations. - Inputs / Outputs: Inputs: Delegation Contracts from the CTX-9 System of Record (scope, permitted datasets and actions, oversight tier, limits), complete agent action logs emitted by the mediating infrastructure (gate, channel, runtime) per COMMON, model change history, QSC-6 access logs, random independent re-verification sampling results for below-floor actuations (reported through QSC-7 together with ACT-12), CTX-1 origin and taint class definitions. Outputs: agent audit report; violation register entries; tier adjustment recommendations routed into CTX-9 step 8 as named inputs; suspension requests to CTX-9; debt and incident items. - Steps: 1. Inventory active Delegation Contracts from the CTX-9 System of Record and map agents to them. Gateway: any agent acting without a current contract? Suspend it immediately through CTX-9's fast path, escalate to the Steward and Owner. 2. Reconcile action logs against scope: writes only to permitted masters (per the Mastership Register), reads only within granted scope, volumes within declared limits. 3. Verify tier discipline per the preamble ladder: T1 acts each have a recorded human approval; T2 acts have the sample reviews actually performed; T3 acts have a complete, gap-free trail and the periodic review done. Verify gate-side revocation enforcement: every act validated its citing contract's liveness at the gate at act time; residual authority past the declared revocation TTL is an incident (QSC-8). 4. Verify refusal behavior, explicitly including injection-bait refusal: the agent refused where the standard requires refusal (ambiguous mastership, edits to mirrors or artifacts, red coverage walk, restricted disclosure) and refused to treat content of non-authored origin and taint classes (per CTX-1 tagging) as instructions; test with sampled injection bait. 5. Detect anomalies (Agent at T2): volume spikes, off-cadence activity, novel surfaces, out-of-scope read attempts; reconcile independent below-floor re-verification samples against the agent's own verification claims (divergence is a violation candidate). 6. Gateway: violation confirmed? Classify severity. Critical: suspend the contract via CTX-9, review and if needed revert the affected writes through the change process, notify the Owner, open QSC-8 if exposure is possible, otherwise open a QSC-14 incident. 7. Recommend tier changes on evidence and route them into CTX-9 step 8 as named inputs; promotion requires the CTX-9 ladder's declared number of consecutive clean audits, demotion follows any confirmed violation pattern; the change itself executes only in CTX-9. 8. Publish the report; file violations and systemic causes into the registers (QSC-11 for debt, CTX-9 for the agent record). - Controls: No self-audit; every agent write SHALL be attributable (no identity, no write, enforced at the write path); action and read trails are emitted by the mediating infrastructure, never by the acting Agent, and Agents hold no write path to their own trails (COMMON); trails are hash-chained and integrity-checked by QSC-9; suspension is a one-actor fast path for the Steward via CTX-9; promotion gate is evidence-based, never convenience-based, and lives in CTX-9; all mechanical reconciliation MAY run at T3; confirmation of violations and all tier recommendations SHALL remain T1 (Agent proposes, human approves each act). - Tier: core (wherever Agents execute processes; a purely manual model MAY omit it and SHALL document that it does) - Variants: Solo: the Owner-Steward reviews their agents' logs on cadence with scripted reconciliation; small scale makes full-trail review feasible. Team: separation between the Steward who delegates and the reviewer who audits. Federated and MOS-scale: statistical sampling over thousands of agents with full-trail review triggered by anomaly score; per-realm audit agents cross-audit each other, never themselves. Hybrid standard; detection autonomous, judgment human. - Metrics: Confirmed violations per thousand agent actions; trail completeness rate (target 100 percent); median time from critical detection to suspension; share of active agents with current CTX-9 contracts (target 100 percent); injection-bait refusal pass rate (target 100 percent). - Failure modes: Unlogged actions (guard: the write path rejects unattributed writes; trails are infrastructure-emitted; gaps in trails are themselves critical findings). The auditing agent audits itself or a collaborator (guard: separation rule enforced in contract topology). Tier creep, agents drifting to T3 without the promotion gate (guard: tier recorded in the CTX-9 contract, changes only through CTX-9's ladder). Alert fatigue burying real violations (guard: severity classing with thresholds reviewed at QSC-5). ### QSC-8 Leak and exposure response - Purpose: Contain, assess and remediate unauthorized disclosure or exposure of model information, restore the lawful access state, and notify affected parties honestly. QSC-8 is the security specialization of QSC-14: it applies QSC-14's incident discipline (severity rubric, evidence pinning, Owner-gated closure, blameless postmortem, lesson routing) to the security incident class. - Trigger: A drift finding classified as possible breach (QSC-6); an unexplained integrity mismatch on a security-critical dataset (QSC-9, mandatory open); a QSC-14 triage that classifies an incident as security class; a report by any actor (Steward, Contributor, Consumer, federation partner); an external notification. - Actors: Steward as incident lead (deputy per GOV-3 when unavailable). Owner decides notifications, grant changes and all irreversible steps at T1 (non-delegable consent, recorded via GOV-1). Agent assists containment and forensics at T2 (evidence collection, log correlation, staged revocations); any irreversible action (key rotation, contract termination, projection retirement) is T1. Auditor conducts the post-incident review. - Inputs / Outputs: Inputs: the triggering signal, access logs (infrastructure-emitted per COMMON), the GOV-7 grant register, contracts (including Federation Contracts with their breach clauses), the CON-13 consumer register, classification of the affected datasets, the QSC-14 severity rubric. Outputs: incident record (an Event timeline from open to close), containment actions, notification notices, post-incident report (QSC-14 postmortem form), remediation debt items. - Steps: 1. Open the incident record; pin evidence first: snapshot relevant logs, compute and store hashes, freeze deletion (nothing is deleted). 2. Contain with the least destructive effective step: revoke exposed credentials and tokens via GOV-8, revoke or shrink grants via GOV-7, suspend affected Projections (Projection Lifecycle suspension; do not retire Objects, per the three-times separation). 3. Gateway: containment requires an irreversible act (key rotation through GOV-8's emergency rotation interface, contract termination)? Owner decision at T1 before execution, recorded via GOV-1. 4. Assess scope: which datasets, which fields, which Consumers or partners (resolved against CON-13), over what time window; state confidence explicitly. 5. Gateway: are Consumers or federation partners affected? Notify per contract terms and Owner-approved wording. The decision is recorded even when the answer is "no notification required", with rationale. 6. Eradicate the root cause: fix the grant or standing policy via GOV-7, patch the pipeline, amend the contract, correct the surface list. 7. Recover: re-issue grants via GOV-7, resume suspended Projections, verify with a targeted QSC-6 run. 8. Post-incident review with the Auditor, run as the QSC-14 blameless postmortem (mandatory for this class): timeline, causes, what the monitors missed; lessons route per QSC-14 step 6 as versioned changes into invariants (QSC-2), monitor and watchdog rules (QSC-6, QSC-9, QSC-15) and debt items. 9. Close only with Owner sign-off and no open eradication item. - Controls: Evidence preservation precedes any cleanup; least-destructive-first containment; all notifications Owner-approved; no silent closure (the closure Event references the post-incident report); Federation Contract breach clauses honored bidirectionally; key rotations execute only through GOV-8; grant changes only through GOV-7. - Tier: core - Variants: Solo: the Owner-Steward runs the same sequence with a pre-written one-page runbook; the post-incident review MAY be a cold self-review declared as such. Team: incident lead plus a scribe keeping the Event timeline live. Federated: joint incident handling when the exposure crosses a contract boundary; each side runs its own record, notices are exchanged as contract artifacts. Hybrid standard; agents never act irreversibly. - Metrics: Time from signal to containment; time from scope assessment to notification decision; scope revision count after first assessment (accuracy proxy); repeat-cause rate across incidents (tracked with QSC-14). - Failure modes: Evidence destroyed during cleanup (guard: pin-first rule in step 1). Over-response that retires Objects or versions instead of suspending Projections (guard: lifecycle discipline named in step 2). Quiet non-notification (guard: step 5 is a mandatory recorded decision). Root cause never actually fixed (guard: closure blocked while an eradication item is open). ### QSC-9 Integrity verification - Purpose: Verify that model content, histories, logs and published copies have not been tampered with or corrupted: fingerprints, hashes, signatures, append-only Event histories, hash-chained security logs, and continuous anchoring of the security-critical dataset class. - Trigger: Schedule (light daily run, deep weekly run, both QSC-15-registered standing jobs); before accepting a backup or a restore (with QSC-13); on demand after suspicious activity; as a step of every publication. - Actors: Steward (accountable, handles alarms at T1 or T2 by severity). Agent executes all checks at T3. Auditor verifies the method (what is hashed, where reference hashes live) at least annually. - Inputs / Outputs: Inputs: model head, declared Semantic Fingerprints per version, raw-capture hashes with their capture-time attestations (emitted by pipeline infrastructure or the attestation service, never by the harvest Agent, per COMMON), the Event log, hash-chain heads and external anchor receipts for security-relevant logs, published projection hashes, MIR-7 run records, the security-critical dataset inventory (COMMON class list), backup manifests (QSC-13), signatures and key references (GOV-8). Outputs: integrity report; alarm Events; integrity hold markers on suspect artifacts; expected-hash updates recorded as Events when regeneration is legitimate; findings to MIR-7. - Steps: 1. Recompute the model fingerprint and compare with the declared one (V2-05 discipline). 2. Verify raw captures unchanged since harvest: hash each against its capture-time attestation sidecar; the attestor is separate from the collector (COMMON), so a capture whose only attestation is self-issued by the harvest Agent is itself a finding. 3. Verify the append-only property of the Event history and the continuity of hash-chained security-relevant logs (action, read, dispatch, disclosure, consent): no rewritten or removed entries, each entry commits to its predecessor, sequence continuity intact, timestamps monotone per stream, external anchors present at the declared short cadence. 4. Verify signatures where used: signed Validation Reports, certificates, published statements; resolve keys against the GOV-8 inventory (an expired or superseded signing key is a finding routed to GOV-8). 5. Verify MIR-7 ran on cadence over the declared write-back surfaces and sample its results for honesty: drift Events present where published hashes diverge, dispositions recorded. Gateway: mismatch between sampled reality and MIR-7's records? Raise a finding to MIR-7; QSC-9 never executes regeneration or proposal routing itself. 6. Anchor the hashes of the security-critical dataset class continuously (per COMMON: BOOTSTRAP and bootstrap materials, process and gate definitions, approval matrix, auto-approval lane criteria, Delegation Contracts, sources.yaml mastership and conflict-rule fields, severity rubrics, watch and threshold configs). Gateway: any diff not explained by a recorded, dual-reviewed T1 change Event? Open QSC-8 immediately. 7. Test-restore a backup sample against its QSC-13 manifest (QSC-13 owns backup creation and the full DR drill; this step is the continuous sampling). 8. Gateway: any other mismatch not explained by recorded Events? Place an integrity hold on the artifact (excluded from answering and publication until cleared, enforced at the read path), raise an alarm Event, open a QSC-14 incident and assess whether QSC-8 must open. 9. Publish the integrity report. - Controls: Reference hashes stored separately from the content they protect, or signed; an alarm SHALL NOT be closed by the same Agent that raised it; integrity hold is enforced at the read path; legitimate regenerations update expected hashes only through recorded Events; periodic model fingerprints are anchored in published reports and security-relevant logs are continuously hash-chained with external anchoring at a declared short cadence, so history rewriting is externally detectable within a bounded, declared window. - Tier: core - Variants: Solo: repository tooling (version control hashes plus a fingerprint script) covers most steps; backup restore test monthly; under the COMMON Solo/Minimal profile the mechanical steps MAY run inside the weekly combined sweep with one combined Event. Team: separate custody of the reference hash store. Federated: partners verify exchanged packages against published fingerprints; either side can prove tampering to the other. Autonomous T3 execution is the norm; alarm handling is human. - Metrics: Verification coverage (artifacts checked divided by artifacts declared); unexplained mismatch count (target 0); anchoring latency versus the declared cadence; backup restore test pass rate; security-critical anchor coverage (class members anchored divided by class members declared, target 100 percent). - Failure modes: Hashes stored beside content and tampered together (guard: separate or signed reference store). History rewritten between anchors (guard: continuous hash-chaining plus short-cadence external anchoring; QSC-5 verifies the declared cadence is honest). Drift handling duplicated or usurped (guard: MIR-7 is the sole detection engine and CON-11 the sole capture path; step 5 verifies, never re-runs). Alarm fatigue from legitimate regenerations (guard: regenerations pre-register their expected-hash updates as Events, so only true surprises alarm). ### QSC-10 Certification and conformance checking - Purpose: Assess and honestly declare the model's conformance to the Vercy standard (constitutional compliance, architectural level A1-A5, validation level achieved), maintain the Conformance Statement, and support independent certification. - Trigger: Initial publication; periodic re-check; every major model version; a certification request; any regression detected by QSC-4; any change that affects a claim in the current statement; mandatory update after a CON-12 standard migration; final conformance snapshot during MIR-11 model retirement. - Actors: Steward prepares the statement. Agent compiles the evidence dossier at T2. Auditor or certifying party verifies independently (engaged via GOV-6; re-runs validation, inspects the repository). Owner signs the statement (non-delegable in substance; the signature is recorded as a GOV-1 Event). - Inputs / Outputs: Inputs: Validation Reports, quality reports and the Semantic Coherence Score (QSC-1), repository evidence (manifests, registers, mappings, package metadata), the previous Conformance Statement. Outputs: updated Conformance Statement (model name and version, standard versions, conformance level, validation level achieved, imported standards, federation profiles, fingerprint); certification dossier; a certificate or a gap list; regression documentation where applicable. - Steps: 1. Gather the current evidence set and pin the model version it describes. 2. Map every claimed level requirement to concrete evidence (report identifiers, repository paths). Gateway: every claim evidence-backed? Remove or downgrade unbacked claims; a claim without a citable report does not survive this step. 3. Draft or update the Conformance Statement. 4. Label the status explicitly: self-declared versus independently certified; the two SHALL be distinguishable at a glance. 5. Gateway: independent certification sought? Hand the dossier to the Auditor or certifier (GOV-6 engagement), who re-runs validation on the pinned version and inspects the repository rather than trusting self-reported runs. 6. Record the verdict (certificate or gap list); any regression from the previous statement is documented with a rationale Event, never silently absorbed. 7. Owner signs; publish the statement, with the Semantic Coherence Score band presented alongside as the quality gradient, never in place of the pass/fail level. - Controls: No claim without a report identifier; mandatory self-declared versus certified labeling; regressions documented and versioned (loss of conformance is itself a recorded, versioned fact); the statement is versioned with the model and its update is wired into the release path. - Tier: core (for any model that publishes or federates externally; recommended otherwise) - Variants: Solo: self-declaration with full evidence mapping, honestly labeled; independent certification deferred until federation makes it worthwhile. Team: Steward prepares, an internal reviewer plays certifier for dry runs. Federated: partners exchange statements during negotiation and MAY require certificates for sensitive Federation Contracts. Hybrid; evidence compilation delegable, signing never. - Metrics: Statement freshness versus model version (lag target zero releases); claims-with-evidence rate (target 100 percent); certification findings per cycle; time from detected regression to published statement update. - Failure modes: Aspirational claims (guard: the evidence-mapping gateway). Statement goes stale while the model moves (guard: release path blocks on statement currency for externally published models). Semantic Coherence Score confused with conformance in the published statement (guard: fixed statement structure separating gate and gradient). Certifier rubber-stamping self-reported results (guard: independent re-run is a condition of any certificate). ### QSC-11 Quality debt register and remediation planning - Purpose: Hold every known quality, consistency, security, operational and conformance deficiency, from every family, in one governed register, and convert findings into deliberate remediation instead of losing them. - Trigger: Any QSC process files a finding; a finding filed by another family (MIR-1 declared-entry debt, MIR-6 SLA breach findings, ACT-12 orphan-link findings); a coverage-walker red or floor finding; QSC-4 Warning aging; the periodic planning cadence (for example monthly); a threshold breach (debt volume or age above the declared budget). - Actors: Steward owns the register and the prioritization. Agent: register hygiene (intake, dedup, linking, aging) at T3; drafting remediation plans at T2. Owner decides risk acceptances at T1, recorded via GOV-1. Contributors execute fixes through the normal change process. Auditor reviews register honesty at QSC-5. - Inputs / Outputs: Inputs: findings from QSC-1 through QSC-10, QSC-12, QSC-13 drill findings and QSC-14 postmortem actions; debt filed by other families (MIR-1 declared-entry debt, MIR-6 SLA breach findings, ACT-12 orphan-link findings); coverage-walker findings and QSC-4 Warning-aging escalations wired directly into intake; capacity plans and utilization telemetry from GOV-5; the Owner's declared risk appetite (a GOV-2 policy). Outputs: the debt register (typed items: quality, consistency, security, operational, conformance; each with severity, age, source report identifier, responsible Steward, due date), remediation plans, risk acceptance records with expiry, closure evidence. - Steps: 1. Intake findings continuously from all named sources; normalize and dedupe on stable keys (check identifier plus location) (Agent at T3). 2. Classify each item by type and severity against the versioned severity rubric (a GOV-2 artifact in the security-critical dataset class). 3. Gateway: security-critical item? Fast-track outside the normal planning rhythm, linking to QSC-6, QSC-8 or QSC-14 as applicable. 4. At each planning cadence: rank open items by risk and effort against the GOV-5 capacity plan; the Agent proposes a remediation batch at T2. 5. Steward approves or amends the plan. 6. Gateway: item proposed for risk acceptance instead of remediation? Owner decision at T1, recorded as a GOV-1 Event with rationale and an expiry date; indefinite acceptance is forbidden, expired acceptances re-surface automatically. 7. Execute fixes via the normal change process of the owning model. 8. Verify closure: re-run the originating check on the fixed version and attach the passing evidence; no evidence, no closure. 9. Report the debt posture to the Owner each cycle: totals, aging distribution, burn-down, expired acceptances. - Controls: The register is itself a model-mastered, versioned dataset; closure requires re-check evidence; risk acceptances expire; aging thresholds escalate automatically (an item past its threshold is raised to the Owner without asking); the severity rubric is versioned and security-critical class (changes SHALL remain T1 with a second human reviewer, hashes anchored by QSC-9); QSC-5 audits register honesty. - Tier: core - Variants: Solo: a single register file in the repository; under the COMMON Solo/Minimal profile the planning pass MAY run inside the consolidated quarterly review. Team: register sections per bundle Steward, one consolidated posture report. Federated: each model keeps its own register; cross-model findings from QSC-3 are filed into every affected model with cross-links. Hybrid standard; hygiene fully autonomous, prioritization and acceptance human. - Metrics: Open debt by severity; mean and maximum item age; burn-down rate per cycle; expired risk acceptances open (target 0); cross-family intake share (items from non-QSC sources actually landed). - Failure modes: Register as graveyard where findings age forever (guard: automatic aging escalation plus the QSC-5 honesty check). Closure without verification (guard: step 8 evidence requirement enforced at register level). Severity inflation or deflation to game planning (guard: versioned security-critical rubric, Auditor samples classifications). Duplicate floods from automated checks (guard: stable dedupe keys at intake). ### QSC-12 Outcome drift watch - Purpose: Continuously compare declared purposes and hypotheses held in the model against observed outcomes, raising Outcome Drift signals when the model is valid (all checks green) but the purpose it encodes is not being met. - Trigger: Continuous or scheduled background run wherever a live runtime exists (a QSC-15-registered standing job); registration of a new hypothesis or intent; a watched metric crossing its tolerance. - Actors: Agent runs the watch at T3 (strictly read-only). Steward triages signals at T2. Owner decides hypothesis revisions at T1, recorded via GOV-1. Auditor MAY review the watch's coverage and thresholds. - Inputs / Outputs: Inputs: declared intents and hypotheses with their success metrics and tolerances, hot descriptive facts read through Virtual Projections, current validation status (a drift signal presumes V0-V4 green, otherwise the finding belongs to QSC-4). Outputs: Outcome Drift Events (Info severity); drift dossiers (intent, evidence, trend); revision proposals routed to the change process; documentation debt items. - Steps: 1. Inventory watchable intents: every declared purpose paired with a measurable outcome and tolerance. Gateway: intent has no measurable outcome? File a documentation debt item and exclude it, visibly, from coverage. 2. Read outcomes through Virtual Projections, read-only, at the declared cadence. 3. Compare observed outcomes against declared expectations. Gateway: divergence beyond tolerance for the declared number of consecutive observations? Raise an Outcome Drift Event, surfaced to the Steward and Owner; it never blocks structural conformance. 4. Assemble the drift dossier: the intent, the evidence trail, the trend, the affected records. 5. Steward triage at T2: is the measurement wrong, has the world changed, or is the hypothesis wrong? 6. Route by triage outcome: measurement fix becomes a debt item; a changed world becomes a model update through the change process; a wrong hypothesis becomes a revision proposal for the Owner at T1. 7. Record the disposition on the originating Event; update thresholds only through the versioned watch configuration. - Controls: The watch is read-only by contract (verified by QSC-7); drift severity is Info and SHALL NOT block conformance or releases; every signal becomes a recorded Event surfaced to the Owner; the watch configuration (tolerances, observation windows) is in the security-critical dataset class (COMMON): changes SHALL remain T1 with a second human reviewer, hashes anchored by QSC-9; a dead watch escalates via QSC-15 as a QSC-14 incident. - Tier: optional (recommended for any model with a live runtime; for MOS-class models whose whole purpose is balancing observed value flows, effectively indispensable) - Variants: Solo: a periodic script comparing a handful of declared metrics, findings reviewed monthly. Team: a standing watch service with Steward triage rotation. Federated: each Universe watches its own outcomes; contract-relevant drift (a partner-facing promise unmet) MAY be disclosed under the Federation Contract's terms. Autonomous detection, human interpretation, always. - Metrics: Intent coverage (watchable intents divided by declared intents); drift signals raised and resolved per period; median triage time; false positive rate after triage. - Failure modes: Metric worship, fixing the number instead of the meaning (guard: triage explicitly separates measurement error from hypothesis error). Silent drift on unwatched intents (guard: step 1 files visible coverage debt). Drift signals weaponized to block releases (guard: Info severity is definitional). The watch acquiring write habits over time (guard: read-only Delegation Contract in CTX-9, audited by QSC-7). ### QSC-13 Backup and disaster recovery - Purpose: Guarantee that the model and its operating machinery survive loss: execute the backup policy as standing jobs, keep offsite immutable copies under separate custody, meet declared RTO and RPO per criticality class, and prove recovery by periodic full-DR drills that rebuild the operation, not just the content. - Trigger: Standing backup cadence (QSC-15-registered jobs); before risky operations (a CON-12 migration, major restructuring); terminal backup during MIR-11 retirement; DR drill cadence; a real loss event (under QSC-14 incident command). - Actors: Steward (accountable). Owner approves the backup policy with its RTO/RPO targets (a GOV-2 versioned policy) and any production restore at T1. Agent executes backup jobs at T3 and drill mechanics at T2. A custodian separate from the Steward holds offsite copy custody. Auditor reviews drill evidence via QSC-5. - Inputs / Outputs: Inputs: the backup policy (scope, cadence, RTO/RPO per criticality class, retention per the GOV-2 retention policy), the declared backup scope (model repository, Event history, all registers: Mastership Register per MIR-1, GOV-7 grant register, QSC-11 debt register, CON-13 consumer register, QSC-15 job registry, the reference-hash store, integrity-hold and quarantine evidence, standing configurations), encryption keys referenced via GOV-8 (never stored inside the backup they protect). Outputs: backup sets with manifests and per-artifact hashes; backup Events; DR drill reports; degraded-mode declarations; restore records. - Steps: 1. Execute scoped backup jobs at cadence (registered in QSC-15); write manifests with per-artifact hashes; record a backup Event per set. 2. Replicate to offsite immutable storage under separate custody; verify immutability and custody separation (the writer cannot delete or rewrite what it wrote). 3. Verify each set: manifest complete against the declared scope; hashes match; QSC-9 step 7 samples restores continuously. 4. Gateway: any criticality class outside its RPO (missed or failed backups)? Open a QSC-14 incident; do not silently reschedule. 5. Run the periodic full-DR drill: rebuild the operation from cold storage in an isolated environment: repository, Event history, registers, standing jobs from the QSC-15 registry, gate configurations, the Delegation Contract register replica (CTX-9); then re-run QSC-4 (V0-V2 minimum) and a QSC-9 sweep on the rebuilt copy; measure achieved RTO and RPO against declared targets. MIR-9's reconstruction drill rebuilds one past state; this drill rebuilds the operation. 6. Gateway: drill missed a declared target, or a machinery gap found (something needed to operate that no backup contained)? File findings to QSC-11 with due dates; a machinery gap is additionally a severity-classed QSC-14 finding. 7. On a real loss event: operate under QSC-14 incident command; declare degraded mode per the pre-declared rules (MIR harvest pipelines pause or run capture-only; ACT dispatch above the Impact Matrix floor is suspended and T3 actuation halts until integrity is re-verified); restore per runbook; restore into production is T1 with Owner approval; verify with a full QSC-9 sweep before lifting degraded mode. 8. Record every restore, drill and degraded-mode window as Events; route lessons through QSC-14 into the runbook and policy. - Controls: The backup scope is declared, versioned and diffed against the register inventory each cycle (an in-scope dataset missing from the scope is a finding); offsite copies are immutable and custody-separated; keys are never stored with the ciphertext they open (GOV-8 custody rules); a backup that has never restored is treated as nonexistent (continuous QSC-9 sampling plus the drill); RTO and RPO are declared per criticality class and tested, never merely asserted; degraded-mode rules are pre-declared, not improvised. - Tier: core - Variants: Solo: repository replication to an independent offsite target plus a quarterly scripted restore drill; the drill review MAY run inside the COMMON consolidated quarterly review. Team: custodian role separate from the Steward; drills rotate the operator so recovery knowledge is not a single head. Federated: partner-held escrow copies MAY serve as offsite storage under Federation Contract terms; a partner storage outage is a QSC-14 trigger. Hybrid standard; backup execution autonomous at T3, production restores always T1. - Metrics: Backup success rate per criticality class; achieved versus declared RPO and RTO (drill-measured); restore sample pass rate (with QSC-9); time since last successful full-DR drill; scope coverage (datasets backed up divided by datasets registered). - Failure modes: Backups exist but the operation cannot be rebuilt (guard: the drill rebuilds machinery, registers and standing jobs, not just content). Backups destroyed together with the primary (guard: offsite immutability and custody separation verified in step 2). Keys lost with the infrastructure (guard: GOV-8 custody separation and escrow). Silent RPO erosion from quietly failing jobs (guard: step 4 incident on any class outside RPO; QSC-15 meta-monitoring of the jobs). Restore untested until the day it is needed (guard: continuous QSC-9 sampling plus the periodic drill). ### QSC-14 Operational incident management and postmortem - Purpose: One incident discipline for every incident class: detect, open, contain, eradicate and close operational failures with severity classing and Owner-gated closure, and convert lessons into versioned guards. This process generalizes the mechanics QSC-8 pioneered; QSC-8 is its security specialization and runs the security class under this discipline. - Trigger: A meta-monitoring escalation from QSC-15 (dead scheduler per MIR-3, dead freshness monitor per MIR-6, dead QSC-6 drift monitor, dead QSC-12 watch); an integrity alarm from QSC-9 not classified as security; admission quarantine saturation or backpressure (FED-8, FED-6); a CON-11 capture path that stopped running; a QSC-13 backup failure, missed RPO or drill machinery gap; a report by any actor; any process card whose alarm path names an incident. - Actors: Steward as incident lead (a deputy per GOV-3 when unavailable). Agent assists evidence collection and containment at T2. Owner decides irreversible steps and closure at T1 (non-delegable consent, recorded via GOV-1). Auditor MAY attend postmortems above the severity floor. - Inputs / Outputs: Inputs: the triggering signal, the versioned severity rubric (a GOV-2 artifact in the security-critical dataset class), relevant logs (emitted by mediating infrastructure per COMMON), the QSC-15 job registry, runbooks. Outputs: incident record (Event timeline from open to close), severity classification, containment and eradication actions, blameless postmortem report above the floor, lesson items routed as versioned changes, QSC-11 debt items. - Steps: 1. Open the incident record; pin evidence first: snapshot logs, compute and store hashes; nothing is deleted. 2. Classify severity against the rubric. Gateway: security class (unauthorized disclosure, exposure, tampering, credential compromise)? Hand over to QSC-8, the security specialization; QSC-14's discipline continues inside it. 3. Contain with the least destructive effective step; any irreversible act requires an Owner decision at T1 first, recorded via GOV-1. 4. Eradicate the root cause; interim workarounds are recorded as workarounds, never closed as fixes. 5. Gateway: severity at or above the declared postmortem floor? A blameless postmortem is mandatory: timeline, contributing causes, what the monitors missed, what worked. Below the floor a short closure note suffices. 6. Route lessons as versioned changes: invariants into the QSC-2 catalog, monitor and watchdog rules into QSC-15 (and the MIR-6, QSC-6, FED-10 rule sets), runbook and process card amendments through the normal change process, remaining work into QSC-11 with owners and due dates. 7. Close only when the eradication item is done (or the Owner records a dated risk acceptance via QSC-11 step 6) and, above the floor, the postmortem is published; the closure Event references the postmortem. 8. Track repeat causes across incidents; a repeated cause raises severity one class on recurrence. - Controls: Evidence preservation precedes cleanup; the severity rubric is versioned and in the security-critical dataset class (changes SHALL remain T1 with a second human reviewer, hashes anchored by QSC-9); postmortems are blameless (findings name causes and guards, never persons at fault); no silent closure; lessons SHALL land as versioned artifacts, not folklore; QSC-5 reconciles alarm logs against incident records (every alarm ends in an incident, a finding, or an explicit recorded no-action rationale). - Tier: core - Variants: Solo: the same sequence with a one-page runbook and a self-run postmortem declared as such; the postmortem floor MAY sit higher but SHALL exist. Team: incident lead plus scribe; postmortem review in the standing cadence. Federated: incidents crossing a contract boundary exchange notices per Federation Contract terms; each side keeps its own record. Hybrid standard; agents never act irreversibly. - Metrics: Time from signal to open; time from open to containment; postmortem completion rate above the floor (target 100 percent); repeat-cause rate; lessons landed as versioned changes divided by lessons identified. - Failure modes: Alarms dead-ending at "escalate to the Steward" with no record (guard: every alarm path names QSC-14; QSC-5 reconciles alarms against incidents). Postmortem theater with no landed changes (guard: step 6 requires versioned artifacts; the landing-rate metric exposes it). Severity gamed to dodge postmortems (guard: versioned security-critical rubric; Auditor samples classifications). Blame culture suppressing reports (guard: the blameless rule is a control, not a preference). ### QSC-15 Standing job and monitoring operations - Purpose: Own the standing machinery every guard in the palette leans on: a registry of all scheduled jobs, monitors, watchdogs and alert channels generated from the Mastership Register and process declarations, their deployment and health, and the meta-monitoring that watches the watchers, escalating into QSC-14. No unregistered crons. - Trigger: Continuous operation; any process declaring or retiring a standing job; a heartbeat miss; the alert channel test cadence; an environment or infrastructure change. - Actors: Steward (accountable). Agent operates the registry, deployment and meta-monitoring at T3; registry changes SHALL remain T1 for jobs touching security-critical datasets (Agent proposes, human approves each act) and MAY run at T2 otherwise. Owner approves jobs that touch security-critical datasets at T1. - Inputs / Outputs: Inputs: the Mastership Register (MIR-1) and each family's process declarations of cadences, monitors and heartbeats (MIR-3 refresh schedules, MIR-4 subscriptions, MIR-6 monitors, the QSC-6 drift monitor, QSC-9 sweeps, the QSC-12 watch, QSC-13 backup jobs, FED-10 evaluation, GOV-8 rotation jobs), the alert channel inventory, infrastructure state. Outputs: the job and watchdog registry (a model-mastered, versioned dataset); deployment and change Events; health reports; heartbeat records; QSC-14 incident escalations; environment change Events. - Steps: 1. Generate and reconcile the registry from the Mastership Register and process declarations, in both directions. Gateway: a running job absent from the registry (an unregistered cron), or a declared job not running? File a finding; an unregistered job touching model surfaces is a QSC-14 incident. 2. Deploy and configure schedulers, monitors and alert channels per the registry; record every deployment and configuration change as an Event. 3. Operate meta-monitoring: every registered job and monitor has a heartbeat watched by a watcher independent of the scheduler it watches; watchers are themselves cross-watched, never self-watched. 4. Gateway: heartbeat missed beyond its declared tolerance? Escalate automatically as a QSC-14 incident; a dead monitor is an incident, not a log line. 5. Test alert channels on cadence: the page path is exercised end to end, including the receiving human; a failed channel test is a finding. 6. Track environment and infrastructure changes affecting standing jobs; record them as Events and re-verify affected heartbeats after each change. 7. Report standing-machinery health each cycle: registry coverage, heartbeat compliance, channel test results; file aged gaps into QSC-11. - Controls: The registry is a model-mastered, versioned dataset; no unregistered crons (two-direction reconciliation between registry and runtime); watchers independent and cross-watched; alert channels tested, never assumed; jobs touching security-critical datasets require Owner T1 approval and their configurations are anchored by QSC-9; every registry change is an Event. - Tier: core (wherever any standing job, scheduler or monitor is declared; a fully manual model MAY omit it and SHALL document that it does) - Variants: Solo: a single registry file plus one cross-check script and a calendar-tested alert path; under the COMMON Solo/Minimal profile the reconciliation MAY ride the weekly combined sweep. Team: operations duty rotation; channel tests rotate the receiving human. Federated: partner-facing monitors (FED-10) register here; cross-boundary alert exchange runs per Federation Contract terms. Hybrid standard; meta-monitoring autonomous, registry changes human-approved. - Metrics: Registry coverage (running jobs registered divided by running jobs found, target 100 percent); heartbeat compliance rate; mean time from heartbeat miss to QSC-14 escalation; alert channel test pass rate. - Failure modes: The watcher of the watchers dies silently (guard: cross-watching topology, never self-watched; QSC-5 verifies it). Registry rots while crons accumulate (guard: two-direction reconciliation in step 1). The alert channel works until the night it matters (guard: end-to-end channel tests including the human). An infrastructure change silently kills jobs (guard: step 6 re-verification after every recorded change).