46 — C-7 Decision Packet: Input-Trust · Ruleset Owner · Backfill Ruleset Ownership · 60-Day Cut-Over · Observer-Trigger Ruling

Path: knowledge/dev/reports/architecture/one-roof-governance-technical-addendum-and-implementation-index-2026-06-01/ Doc: 46. Role: Decision packet for council item C-7 — the five rulings GCOS build-prep is waiting on. This is a packet, not a decision. It states questions, recommended defaults, rejected alternatives, and exact ratifiable wording. It binds nothing. Status: DECISION-PACKET ONLY. No binding. No approval. No self-approval. No mutation. Even a YES from council does not authorize build/commit — os_proposal_approvals = 0 ⇒ COMMIT_FORBIDDEN, and implementation remains NO-GO unless separately authorized through the real approval spine. Date: 2026-06-01. Authority for the questions: doc 35 §2 (new blockers), doc 38 (SB-12), doc 32 §4 / doc 41 §41.7 (handoff options), doc 31 §10 (backfill), concept C-6/A3 (60-day default). Decider: GOV-COUNCIL + human sovereign (President). Proposer (non-deciding): GOV-SIV.

46.0 What C-7 is and why it exists

C-7 was opened by the GCOS work (doc 35 §2) as the single council/human decision surface that the GCOS substrate cannot proceed past on its own, because each item is a policy/authority/ownership choice, not a technical design choice. The GPT review named it verbatim: "C-7 decision remains needed for input-trust/ruleset owner/backfill deadline/observer-trigger ruling."

The five items:

C-7 item	One-line question	Source
C-7.1 Input-trust policy	What is the minimum source-trust required to inject governance work, per scope?	doc 33 (`untrusted_source` state)
C-7.2 Ruleset owner	Who owns `ruleset_version`, and how is a bump activated?	doc 38 §38.5
C-7.3 Backfill ruleset ownership	Under whose ruleset does the one-time backfill seed run, and what is the status of verdicts seeded under a draft/interim ruleset?	doc 31 + doc 38
C-7.4 60-day legacy/backfill cut-over deadline	How long are un-onboarded legacy objects tolerated before they escalate from "legacy/deferred" to a finding?	concept C-6/A3 (60-day default)
C-7.5 Observer-trigger ruling	Does adding a fail-open `AFTER INSERT` observer trigger to Birth count as "modifying Birth," or is it an allowed external observer?	doc 32 §4 Option B / doc 41 §41.7

Cross-cutting no-self-approval rule (applies to all five): GOV-SIV may propose; it may not decide any C-7 item. The decision is GOV-COUNCIL + sovereign via the Điều 32 APR spine where a vote is required. fn_apr_quorum_check bars proposer==approver. No agent (human or AI) approves its own proposal. A C-7 ruling is recorded as a governed decision (e.g. in governance_ruleset / registry_changelog / an APR), never as an inline code default.

46.1 C-7.1 — Input-trust policy

Decision question. What minimum source-trust must a producer have before its input is allowed to inject governance work for a given target scope — and what happens to input from a below-threshold source?

Recommended default (proposed, not binding).

Trust is a per-(source_system, target_scope) property, sourced from a registry/config — never hardcoded. (no-hardcode, muc-tieu-mo §5.) Interim source list ← event_outbox.source_system / birth_registry provenance; scopes ← the 6 governance_responsibility_scope rows (SB-2).
Deny-by-default for high-risk / write scopes: a source must be explicitly trusted for a high-risk or write-path scope; absent an explicit trust grant, its input is held as input_untrusted_source (doc 33 state #7), routed to GOV-COUNCIL for a trust decision, and never silently injected and never mislabeled governance_orphan.
Allow-with-monitoring for low-risk / descriptive scopes: input from any born/registered source is accepted for candidate scan, with drift monitored (source_drift → governance_schema_drift).
Trust is revocable and audited: a trust grant/revoke is a governed change (governance.handoff.authority_changed family), recorded in registry_changelog.

Alternatives rejected.

Trust everything that was born — rejected: a born object can still carry untrusted/low-quality input for a high-risk scope; "born" ≠ "trusted to drive governance." This is precisely the "systemic-wrongness" risk doc 33 guards against.
Hardcode a trusted-source allowlist in scanner code — rejected: violates no-hardcode; a new source must be onboardable as a row, not a code change.
Treat untrusted input as a governance_orphan — rejected: conflates "we don't trust the input" with "the object is genuinely ungoverned." Must be an input-quality finding (the NOT-orphan invariant, doc 33).

What approval UNLOCKS. The dot_governance_input_gate may, at build, classify input_untrusted_source against a ratified trust policy and route below-threshold input to GOV-COUNCIL; the candidate scan may treat trust as a gate input.

What approval does NOT unlock. It does not authorize building/registering the input-gate DOT (gated on SB-10/SB-11), does not authorize any emit (register-before-emit), does not grant trust to any specific source (each grant is its own governed decision), and does not authorize COMMIT.

Exact council/human wording (ratifiable motion).

"Source-trust for governance input is a per-(source, scope) governed property held in a registry. For high-risk and write-path scopes, input from a source not explicitly trusted for that scope is HELD as an input-quality finding (input_untrusted_source) and routed to GOV-COUNCIL; it is never injected as governance work and never recorded as a governance-orphan. For low-risk descriptive scopes, born/registered input is accepted with drift monitoring. Trust grants and revocations are governed, audited changes. GOV-SIV proposes; GOV-COUNCIL decides each trust grant. No source is trusted by code default."

Risks. (a) Over-strict default starves low-risk coverage with untrusted_source noise → mitigate by scoping deny-by-default to high-risk/write only. (b) Under-strict → bad input drives governance work (systemic wrongness) → mitigate by deny-by-default on high-risk and the NOT-orphan invariant. (c) Trust registry becomes a hidden island → mitigate by routing all grants through the council + registry_changelog.

No self-approval. GOV-SIV proposes the policy and each trust grant; GOV-COUNCIL + sovereign decide; proposer ≠ approver. Implementation remains NO-GO unless separately authorized.

46.2 C-7.2 — Ruleset owner

Decision question. Who owns ruleset_version (the canonical hash over the enabled detector rows ⊕ profile ⊕ axis ⊕ scope registries, doc 38 §38.5), and how is a new ruleset version activated (vs merely computed/recorded as draft)?

Recommended default (proposed, not binding).

Policy ownership of the ruleset = GOV-COUNCIL. A ruleset version is the aggregate "active rule-set" governing every verdict; its owner must be the policy authority.
GOV-SIV proposes a bump (it computes the hash and records the candidate row); activation is via APR quorum (Điều 32) — fn_apr_quorum_check (president + 2 AI council for high-risk; proposer ≠ approver).
Storage = Option B (new tiny governance_ruleset registry row) — the recommended default from doc 38 §38.3 — because the ruleset needs governable semantics (owner, activation approval, status), which a bare evolution_snapshots scope row (Option A) cannot carry cleanly. Council may instead choose Option A (reuse evolution_snapshots scope='governance.ruleset') accepting weaker semantics.
Auto-activation MAY be permitted for pure-additive measurement rows via an explicit allowlist (council decision) — never a blanket auto-activate.
Until C-7.2 is ruled, ruleset rows may be computed and recorded as draft but not activated; a verdict referencing a draft/unowned ruleset is treated as unknown for high-risk (fail-closed, doc 38 §38.7); an unowned ruleset raises ruleset_unowned.

Alternatives rejected.

GOV-SIV owns and self-activates the ruleset — rejected: SIV is the proposer/detector; self-activation = self-approval (barred). Violates the Điều 31/32 separation.
No ruleset version at all (verdicts are timeless) — rejected: reintroduces non-reproducible / checked-forever verdicts (the exact thing SB-12 exists to prevent).
Bump the ruleset by writing law (normative_registry) — rejected: a ruleset bump is a config-version event, not a legislative act; it must not write normative_registry/law_catalog/governance_docs or change any law's status (doc 38 §38.5 "versioning is operational, not legislative").

What approval UNLOCKS. At build, SB-12 may persist governance_ruleset rows with a real owner and an activation path; activated rulesets make verdicts reproducible and high-risk-eligible; targeted invalidation on ruleset bump becomes authoritative.

What approval does NOT unlock. It does not authorize creating the governance_ruleset table (gated on G-DDL rehearsal), does not authorize activating any specific ruleset (each activation is its own APR), does not authorize emit, and does not authorize COMMIT (os_proposal_approvals=0).

Exact council/human wording (ratifiable motion).

"ruleset_version is owned by GOV-COUNCIL. GOV-SIV proposes a ruleset bump; activation requires Điều 32 APR quorum (proposer ≠ approver). The ruleset is recorded in a governance_ruleset registry row (Option B) — or in evolution_snapshots scope='governance.ruleset' (Option A) if council prefers. A ruleset bump is a configuration-version event and MUST NOT write normative_registry/law_catalog/governance_docs or change any law status. Pure-additive measurement-row bumps may auto-activate only via an explicit council allowlist. Verdicts under a draft or unowned ruleset are unknown for high-risk (fail-closed)."

Risks. (a) Activation bottleneck (every bump needs quorum) → mitigate with the additive-only allowlist. (b) Ambiguity between Option A/B left unresolved → council must pick one; default B. (c) A ruleset bump mistaken for a law change → mitigate by the explicit no-law-write clause + acceptance test (doc 38 §38.10 #4: normative_registry byte-identical across a bump).

No self-approval. GOV-SIV proposes; GOV-COUNCIL + sovereign activate; proposer ≠ approver. Implementation remains NO-GO unless separately authorized.

46.3 C-7.3 — Backfill ruleset ownership

Decision question. Under whose ruleset does the one-time backfill seed (doc 31, ~1.04M objects) run, and what is the status of the verdicts it writes if the governing ruleset is still draft/interim at seed time?

Recommended default (proposed, not binding).

The backfill seed runs under an explicitly-identified ruleset_version owned by GOV-COUNCIL (same owner as C-7.2). Every seeded candidate-state row carries (candidate_key, source_snapshot_ref, ruleset_version) so the seed is reproducible and re-keyable on a later bump.
The seed MAY proceed under a draft ruleset (so onboarding is not blocked on activation), but any high-risk verdict seeded under a draft/unowned ruleset is recorded as unknown (fail-closed at G-PROD) until the ruleset is activated; low-risk verdicts are usable and simply re-keyed if the ruleset later changes.
On ruleset activation/bump, targeted re-key (auto-close re-keyed by (coalesce_key, ruleset_version), addendum #8) re-evaluates only the affected groups (Δother = 0).
Ownership of the backfill operation = GOV-SIV (runs the read/seed sweep); ownership of the ruleset it runs under = GOV-COUNCIL. These are distinct and must not be collapsed.

Alternatives rejected.

Seed under an implicit/anonymous ruleset — rejected: produces non-reproducible verdicts; cannot be invalidated correctly on a later policy change.
Block all backfill until the ruleset is fully activated — rejected as the hard default: would stall onboarding of 1.04M objects on a governance vote; instead seed-under-draft with high-risk verdicts held unknown (fail-closed) is safer and still correct.
Let the backfill worker activate its own ruleset to unblock itself — rejected: self-approval; the worker is GOV-SIV-owned and cannot activate council-owned policy.

What approval UNLOCKS. At build, the backfill sweep may seed candidate state under a named ruleset with a clear high-risk-held-unknown rule; re-key on activation is authoritative.

What approval does NOT unlock. It does not authorize running the backfill (gated on SB-10/12/13 build), does not authorize treating draft-ruleset high-risk verdicts as clean, and does not authorize COMMIT.

Exact council/human wording (ratifiable motion).

"The one-time governance backfill seed runs under a named ruleset_version owned by GOV-COUNCIL. The seed may proceed while that ruleset is draft, but every high-risk verdict seeded under a draft or unowned ruleset is recorded as unknown and fails closed at the production gate until the ruleset is activated. On activation or any later bump, only the affected groups are re-keyed and re-evaluated. GOV-SIV owns the seed operation; GOV-COUNCIL owns the ruleset; the seed worker may not activate its own ruleset."

Risks. (a) Large unknown backlog after seed → mitigate by prioritizing ruleset activation for high-risk scopes first. (b) Seed under a ruleset that later changes a lot → re-key cost; mitigate by targeted (not blanket) invalidation. (c) Operation-owner vs ruleset-owner conflated → explicit split above.

No self-approval. GOV-SIV proposes + runs the seed; GOV-COUNCIL owns/activates the ruleset; proposer ≠ approver. Implementation remains NO-GO unless separately authorized.

46.4 C-7.4 — 60-day legacy / backfill cut-over deadline

Decision question. Legacy objects that predate governance onboarding (the bulk of the ~1.04M born spine) are tolerated as "legacy/deferred" during onboarding. For how long, and what happens at the deadline — do un-onboarded legacy objects escalate from "legacy/deferred" to an actionable finding?

Recommended default (proposed, not binding).

Carry forward the concept C-6/A3 default of 60 days, measured from backfill-seed completion (the phase='reconciling' → 'incremental' transition, doc 31 §11), configurable by council.
Before the deadline: un-onboarded legacy objects sit in deferred_birth / needs_input / legacy-exempt verdicts and raise no governance_orphan (they are visibly tracked, not silently ignored — every deferral is a recorded candidate-state row).
At/after the deadline: an object still un-onboarded with no governed exception escalates: its verdict moves toward relevant/orphan evaluation and, if genuinely ungoverned, raises governance_orphan (T7 #1) or backfill_incomplete (doc 31 #3) at escalated severity — the "legacy" grace no longer suppresses the finding.
The deadline is itself a governed parameter (held in config, owned by GOV-COUNCIL), not a code constant; its value and the escalation behavior are auditable.
Per-object extension is possible only via a granted governed exception (M-DEF-6, TTL'd), never by silently resetting the clock.

Alternatives rejected.

No deadline (legacy tolerated forever) — rejected: re-creates a permanent ungoverned population and a "checked/exempt-forever" class; defeats the coverage invariant.
Hard cut at day 60 that blocks production for all un-onboarded legacy — rejected as default: too blunt for low-risk descriptive legacy; escalate-to-finding (and fail-closed only for high-risk per G-PROD) is the calibrated behavior.
Hardcode "60" in the scanner — rejected: no-hardcode; it is a council-owned config parameter.

What approval UNLOCKS. At build, the candidate scan / exception-review DOTs may apply a ratified deadline + escalation rule to legacy verdicts.

What approval does NOT unlock. It does not authorize running those DOTs (gated), does not authorize auto-applying any remediation at the deadline (apply is NO-GO; the deadline produces a finding, not an auto-fix), and does not authorize COMMIT.

Exact council/human wording (ratifiable motion).

"Legacy objects predating governance onboarding are tolerated as deferred for a council-owned grace period (default 60 days from backfill-seed completion). During the grace period they are tracked, not orphaned. At the deadline, an un-onboarded object with no governed exception escalates to a governance_orphan/backfill_incomplete finding at escalated severity; high-risk such objects additionally fail closed at the production gate. The grace period is a governed config parameter, not a code constant; per-object extensions require a TTL'd governed exception. The deadline produces findings, never an automatic remediation."

Risks. (a) Deadline-day finding storm across 1.04M → mitigate by group_key coalescing (addendum #7) + the group_invalidation_storm ceiling. (b) Deadline set too short → mass unknown/orphan; too long → ungoverned drift; council calibrates. (c) Silent clock resets hide legacy → forbidden; only TTL'd exceptions extend.

No self-approval. GOV-SIV proposes the parameter; GOV-COUNCIL sets it; proposer ≠ approver. Implementation remains NO-GO unless separately authorized.

46.5 C-7.5 — Observer-trigger ruling (does an observer trigger "modify Birth"?)

Decision question. The default handoff path (Option A, doc 32 §4 / doc 41 §41.7) is a cursor-tail that touches Birth zero ways. Option B is an additive, fail-open AFTER INSERT observer trigger on the Birth tables that only writes a capture row to event_pending. Does adding such a trigger count as "modifying Birth" (forbidden), or is it an allowed external observer (a latency optimization)?

Recommended default (proposed, not binding).

Default implementation path = Option A (cursor-tail / CDC), which needs no ruling at all — it touches Birth zero ways and is lossless because births are append-only and ordered. GCOS does not need Option B to function.
Recommended ruling on the question: NO — an observer-only, fail-open AFTER INSERT trigger that (i) can never alter, block, or delay a birth, (ii) only writes a capture row to event_pending, and (iii) fails open (a trigger error cannot fail the birth transaction) does NOT count as "modifying Birth." It observes, it does not modify. This matches doc 32 §4 and doc 41 §41.7's recommended-but-deferred answer.
Even with a YES ruling, Option B remains build-NO-GO and is an optional latency optimization only; it must be fail-open, observer-only, write only to event_pending, and never be the inline Option C (which couples Birth to governance and is REJECTED).
The ruling is the council's, not the agent's. The agent does not self-rule the Birth boundary.

Alternatives rejected.

Option C — inline Birth-gate call into governance — REJECTED outright (doc 32 §4 / doc 41): couples Birth to governance; a governance fault becomes a birth fault. Forbidden regardless of any C-7.5 ruling.
Rule that any trigger on Birth = modifying Birth, forbidding Option B entirely — acceptable conservative outcome; costs only the latency optimization (Option A still works). Council may choose this.
Let GOV-SIV add the trigger under its own authority — rejected: the Birth boundary is a sovereign/architectural boundary; only council + sovereign may rule it, and only then is it build-eligible.

What approval UNLOCKS. If council rules YES and later authorizes build, Option B (fail-open observer trigger → event_pending) becomes an eligible latency optimization on top of Option A. (Option A needs no C-7.5 approval to be built when its gates pass.)

What approval does NOT unlock. It does not authorize creating the trigger now (build NO-GO), does not authorize inline Option C ever, does not change the default (Option A remains default), and does not authorize COMMIT.

Exact council/human wording (ratifiable motion).

"An observer-only, fail-open AFTER INSERT trigger on the Birth tables that writes solely a capture row to event_pending and can never alter, block, or fail a birth is deemed an EXTERNAL OBSERVER, not a modification of Birth. It is permitted as an optional latency optimization on top of the default cursor-tail handoff (Option A), subject to separate build authorization. Inline coupling of Birth to governance (Option C) is forbidden. The default handoff path remains the cursor-tail, which modifies Birth in no way. This ruling does not authorize building the trigger; build remains separately gated."

Risks. (a) A "fail-open" trigger that is mis-implemented to fail-closed could block births → mitigate by mandatory fail-open + a rehearsal that proves a trigger error does not roll back the birth. (b) Scope creep from observer → inline → forbid Option C explicitly. (c) Treating the ruling as build authorization → explicit "does not authorize building the trigger" clause.

No self-approval. GOV-SIV/architecture proposes; GOV-COUNCIL + sovereign rule the Birth boundary; proposer ≠ approver. Implementation remains NO-GO unless separately authorized.

46.6 Cross-item summary + dependency to build

C-7 item	Recommended default	Gates (what it unlocks at build)
C-7.1 input-trust	Per-(source,scope) registry; deny-by-default high-risk; held→COUNCIL; never orphan	`dot_governance_input_gate` trust classification
C-7.2 ruleset owner	Owner = GOV-COUNCIL; SIV proposes; APR-quorum activate; Option B storage; no law-write	SB-12 ruleset activation; reproducible high-risk verdicts
C-7.3 backfill ruleset	Named council-owned ruleset; seed-under-draft OK but high-risk held `unknown`; re-key on bump	Branch A seed verdict status rule
C-7.4 60-day cut-over	60 days from seed completion (config, council-owned); escalate-to-finding at deadline; high-risk fail-closed	Legacy escalation rule in candidate/exception DOTs
C-7.5 observer trigger	Observer-only fail-open trigger ≠ modifying Birth; Option A remains default; Option C forbidden	Option B eligibility (optional optimization)

Master constraints over ALL five (none waivable by this packet):

No self-approval — proposer ≠ approver on every item; fn_apr_quorum_check enforces it where a vote is taken.
A C-7 ruling is a decision, not a build authorization. Each item lists what it does not unlock.
os_proposal_approvals = 0 ⇒ COMMIT_FORBIDDEN — even fully-ruled, no GCOS COMMIT until the real approval spine records sovereign-backed approvals.
Register-before-emit (Điều 45) — no governance event registration/emit is authorized by any C-7 ruling.
Birth not modified by default (Option A); the C-7.5 ruling, even if YES, only makes a fail-open observer eligible for separate build authorization.

This packet binds nothing. It is the input to a council/human decision. Implementation of every item remains NO-GO unless separately authorized through the gates in doc 42 §42.5 and doc 49.