01 — One-Roof Principle Hardening (Branch A)

Reviews decision-pack doc 01 (…/one-roof-governance-decision-pack-2026-06-01/01-one-roof-governance-principle.md) sentence-by-sentence. Adversarial. No enactment.

A0. What the pack says (summary)

Doc 01 states the principle: every governance-related object/action lives under one central roof = one governance_registry, one Điều 32 approval spine, one Điều 31+45 detection/issue/event substrate, one Điều 35 DOT execution model; "no local governance island"; born-without-registration = governance-orphan; truth-changing-without-central-owner = anarchic object; detection must be automatic, not memory-dependent. It is federated-but-central (policy→GOV-COUNCIL, health→GOV-SIV, DOT→GOV-DOT, render→GOV-MOUT). It lists 7 forbidden "no local island" rules (§1.3), an application matrix (§1.4), examples/non-examples (§1.5/1.6), and 9 canonical forbidden patterns F-ISLAND-1…9 (§1.7).

Overall: the principle is correct and well-grounded. The defects are scoping (over-breadth at one edge, under-definition at another) and three missing carve-outs the mission explicitly asked for.

Original: §1.1 VN: "Mọi đối tượng và hành động liên quan đến quản trị đều sống dưới một mái nhà…" ("every object and action related to governance…").
Ambiguity: "related to governance" is circular — governance governs the things related to governance. It gives no operative membership test. Doc 02 §2.1 uses a different, better test ("effect on truth or authority, not table-ness"). Two docs, two scopes.
Island risk: a careless reader treats "related to governance" narrowly (only the GOV-* agencies' own artifacts) and concludes a vendor route or a grouping policy is "not governance-related" → escapes the roof.
Hardened wording: replace the scoping phrase in §1.1 with the doc-02 test verbatim: "Mọi đối tượng có thể tác động đến sự-thật hệ thống hoặc thẩm-quyền (cấu trúc, thành-viên-registry, phân-loại, đếm, hiển-thị, thực-thi, tự-động-hóa, issue, cleanup, duyệt/kiểm-toán/hoàn-tác) …" — i.e. the governance scope = the truth/authority test, stated once, identically, in both docs.
Acceptance test: doc 01 §1.1 and doc 02 §2.1 state the same membership test, word-for-word, with one cited as the SSOT of the other (Điều 37 §4.12 no-overlap).
Open question: none.

A2 — No non-governed / ephemeral / personal class is defined (the biggest over-governance risk)

Original: §1.3 forbids "local governance islands"; §1.6 non-examples include "A Registries-Pivot–only 'pin' mechanism stored in localStorage or a UI-owned table → local ownership island (forbidden)." The mission §4/§5 explicitly require clarifying what is allowed as local/non-governed (personal UI prefs, private notes, read-only utilities, user-only drafts, low-risk artifacts) and warn: "Avoid over-governing harmless local notes or personal UI preferences."
Contradiction / over-breadth: the pack conflates a personal-scope pin (affects only one user's own view; cannot change what anyone else sees as truth) with a global pin (changes shared display truth). Under §1.6 every localStorage preference is an island. At scale this floods the scanner with non-truth artifacts and trains operators to ignore island alerts (alarm fatigue → real islands hide in the noise). This directly violates the mission's anti-over-governance instruction.
Scale risk: personal/session artifacts vastly outnumber governed objects; scanning them is wasted cost and noise.
Hardened wording (new §1.0-SCOPE, "Đối tượng KHÔNG được-quản-trị"):

A non-governed artifact is one that cannot alter shared system truth or authority: it is scoped to a single user/session/agent-private view, is read-only against shared truth, and carries no approval/execution power. Examples: personal UI layout preferences, user-scoped pins/filters (a pin that re-orders only the pinning user's own view), session state, scratch notes, free-text comments, non-truth-bearing logs. These are OUT of the One-Roof coverage population — the scanner MUST NOT raise governance-orphan issues for them. The test is shared-truth reachability: if the artifact, when changed, can change what a different user or agent sees as system truth, or can authorize a mutation, it is governed (and the policy that permits the personal class — e.g. "user pins are allowed" — is itself a governed COUNCIL policy). A user-scoped pin is non-governed; a global/role/team-scoped pin is a governed policy object (rule 4).
Acceptance test: the scanner classifies a synthetic user-scoped pin as non-governed (no issue raised) and a synthetic global pin as a governed policy object (raises owner_gap if unowned). The carve-out is itself bounded by a COUNCIL-owned policy enumerating the permitted non-governed classes (so the carve-out cannot itself become an island).
Open question: OQ-A2 — is "session/user scope" always safe, or can a user-scoped pin leak into shared truth via export/share features? (Decide the boundary for shareable-but-personal artifacts.)

A3 — Direct-PG rule 6 has no defined transitional state for an already-live exception

Original: §1.3 rule 6: the live Direct-PG read-only adapter is a "sanctioned-or-orphan exception that must be either ratified … or recorded as an approved exception." Doc 03 §3.4 grades it critical/high.
Ambiguity: the adapter is already in production (Registries-Pivot is live). The pack offers two terminal states (ratified | approved-exception) but no transitional state for the window between detection and ratification. Read literally, the detector flags an already-shipped surface as critical and the gate (rule 7) "blocks production" — but production already happened.
Misimplementation risk: the gate either (a) retroactively "blocks" something live (meaningless), or (b) is quietly ignored for legacy surfaces (the gate becomes advisory → island).
Hardened wording: add a QUARANTINED transitional state to the exception lifecycle (doc 05 detail): a detected-but-not-yet-ratified live bypass is QUARANTINED with a mandatory regularization deadline; it does not "block production" (already live) but blocks any new feature that depends on it and blocks promotion until ratified-or-removed; missing the deadline escalates to critical + president notification. (Distinguish "blocks new production" from "tears down live production.")
Acceptance test: the Direct-PG adapter, on first scan, becomes a QUARANTINED exception with a deadline, not an instant critical; a new feature attempting to depend on it before regularization is gate-blocked.
Open question: OQ-A3 — what is the standard regularization deadline for an inherited/legacy bypass (e.g. 30/60/90 days)? Council to set.

A4 — Rule 7 ("no production feature without coverage") has no emergency-fix lane

Original: §1.3 rule 7 + the gate (doc 04 §4.6) block production of any feature introducing an uncovered governed object.
Risk: during an incident, a hotfix may have to touch a governed object before its coverage is fully resolved. A hard gate with no emergency lane makes the system brittle exactly when it matters — the operator will then bypass the gate informally (creating an island) because there is no governed fast path.
Misimplementation risk: an absolute gate trains people to route around it.
Hardened wording: bind rule 7 to the existing Điều 35 §6.5 ADMIN-fallback pattern: an emergency change may proceed under a president-authorized, time-boxed emergency exception that (a) INSERTs an admin_fallback_log-style record first, (b) auto-creates a system_issues regularization task, and (c) auto-escalates to critical if a retroactive APR + coverage are not filed within the fallback window (24h, per Đ35 §6.5). The gate is then firm but not brittle: there is exactly one governed emergency lane, owned by the president, audited, and self-expiring.
Acceptance test: an emergency change with a recorded admin-fallback record passes the gate provisionally; absence of the retroactive APR within the window auto-fires audit_overdue/critical.
Open question: none (reuses live Đ35 §6.5).

A5 — The seams between the 4 federated owners are themselves ungoverned (no last-resort owner)

Original: §1.2 splits ownership policy/health/DOT/render across GOV-COUNCIL/SIV/DOT/MOUT and cites the §4.12d tie-breaker.
Loophole: the most common real-world island is an object that falls in a seam nobody clearly owns (is "PIVOT_MISSING" a health matter for SIV or a policy matter for COUNCIL? is a cleanup-DOT-that-also-renders owned by DOT or MOUT?). The pack names a tie-breaker for policy ties but never an owner-of-last-resort for unmapped objects. A coverage gap caused by ambiguity ("no owner because nobody's sure") is indistinguishable from a real OWNER_GAP and may be punted forever.
Hardened wording: add to §1.2: "GOV-COUNCIL is the owner of last resort. Any governed object whose function does not map unambiguously to a federated owner defaults to GOV-COUNCIL accountability until COUNCIL assigns it. There is therefore never a 'no owner because ambiguous' state — ambiguity resolves to COUNCIL, not to a gap." (Consistent with COUNCIL holding the §4.12d tie-break.)
Acceptance test: the scanner can resolve an owner for every candidate object type, even unmapped ones (default = COUNCIL); OWNER_GAP then means "genuinely unassigned," never "ambiguous."
Open question: none.

A6 — "một mái nhà … duy nhất" (a single roof) reads as single-owner

Original: §1.1 "một mái nhà quản trị trung tâm duy nhất" (a single central roof). §1.2 clarifies federated multi-owner, but the headline VN sentence and the federated clarification are in tension for a careless reader; combined with Đ37 §4.12 "một nội dung chỉ một luật quản lý," "single roof" can be misread as "single owner."
Hardened wording: tighten §1.1 to specify the roof is the shared substrate, not a single owner: "một mái nhà = một sổ đăng ký cơ quan, một trục phê duyệt, một hệ phát hiện/issue/event, một mô hình DOT — KHÔNG phải một chủ sở hữu duy nhất. Quyền sở hữu được liên-bang-hóa theo chức năng (§1.2) nhưng mọi chủ đều đăng ký trong cùng một sổ." (one registry/approval/detection/DOT model — NOT one owner; ownership federated by function, all owners in the one registry).
Acceptance test: the principle text cannot be read to require a single owner; the "one X" list enumerates substrates, never owners.
Open question: none.

A7 — `F-ISLAND-8` ("no owner AND no detection coverage") is a weak AND

Original: §1.7 F-ISLAND-8 = "new production object with no governance owner and no detection coverage."
Loophole: the conjunction lets an object with detection coverage but no owner pass F-ISLAND-8 (it has coverage, just no owner) — yet a detected-but-unowned object is exactly an OWNER_GAP orphan that should fail. The AND is too permissive.
Hardened wording: split into two patterns: F-ISLAND-8a = production object with no owner path (regardless of detection); F-ISLAND-8b = production object not enumerable by any L1 source (invisible to detection). Both fail independently.
Acceptance test: an owned-but-undetectable object fails 8b; a detectable-but-unowned object fails 8a.
Open question: none.

A8 — Application matrix (§1.4) maps "future modules" to "resolved by detection" — circular without L1 guarantee

Original: §1.4 row "future modules / object types → resolved by detection (doc 05) → must be auto-covered, not memory-covered."
Risk: auto-coverage depends entirely on the L1 source inventory enumerating the new module's source. If adding the L1 row is itself a manual step someone must remember, the memory-dependence has merely moved up a layer (see Branch G, G1/G2). The matrix asserts auto-coverage as if it were free.
Hardened wording: qualify the row: "auto-covered iff the new module's substrate is reachable from a ground-truth enumeration (information_schema ∪ directus_collections ∪ meta_catalog ∪ route-registry); a module on a substrate with no ground-truth enumeration is UNVERIFIABLE, not auto-covered." (Branch G G1/G2.)
Acceptance test: see doc 07 (inventory-completeness check).
Open question: carried to Branch G.

A-summary — Branch A verdict

ID	Severity	Type	Disposition
A1	medium	ambiguity	adopt single truth/authority test
A2	high	gap (over-governance)	add non-governed class — Tier-1 blocker
A3	medium	gap	add QUARANTINED transitional state
A4	medium	gap	add emergency-fallback lane
A5	medium	loophole	add owner-of-last-resort
A6	low	ambiguity	tighten "single roof" wording
A7	low	loophole	split F-ISLAND-8
A8	medium	circularity	qualify auto-coverage on L1 ground truth

The principle is directionally correct and keep-able; A2 is the one finding that, left unfixed, would make the deployed scanner unusable (noise). A2 + A4 together are the "don't make it brittle / don't make it noisy" pair the mission emphasized.