10 — Law Clause Hardening (Branch J)

Reviews decision-pack doc 08 (…/08-law-design-clause-drafts.md) draft clauses for Đ37/31/35/24-29/26/28/45. DRAFT ONLY — no enactment, no version bump, no normative_registry touch. Adversarial. Final tightened wording is consolidated in doc 13.

J0. What the pack drafts (summary)

Doc 08 drafts: Đ37 §4.15 (One-Roof & anarchic), §4.16 (owner-assignment protocol), §4.17 (approved-exception protocol), §4.18 (future-feature coverage), §5.4-EXT (object edges, deferred); Đ31 §4.3-Loại6 (governance-coverage check), §4.6-ext (issue classes), §4.8-ext (coverage GATE), §4.9-ext (watchdog-of-coverage); Đ35 §6.2-bis (coverage DOT lifecycle), §3-note, §6.5-note; Đ24/29 §0-OWNER, §5.2-ext, §5.4-note; Đ26 §0-OWNER, §MTx (PIVOT_MISSING), §repair; Đ28 §0-OWNER, NT-D1-ext, §VIII-ext; Đ45 §3.2/§4/§6.6 notes. §8.8 anchors One-Roof in Đ37+Đ31, references from others (Đ37 §4.12 SSOT no-overlap).

Overall: the anchoring discipline (concept in Đ37/Đ31, referenced elsewhere) is correct and avoids SSOT duplication. The defects are: undefined terms inside clauses, the §4.12 self-conflict (Branch C), over-centralization of label/taxonomy on COUNCIL, and a render-owner clause that makes the gate globally red.

J1 — Đ37 §4.15(a): "một đường sở hữu trung tâm hợp lệ" — "valid" is undefined inside the clause

Original: §4.15(a): every governed object must have "a valid central ownership path … plus approval/audit/rollback links per risk."
Ambiguity: "hợp lệ" (valid) is defined only in the report (doc 02 §2.4 / doc 04 §4.3 — the valid-owner-path list + the does-NOT-count list). A law clause must be self-contained or carry the exact cross-ref; "valid" without the definition is interpretable (someone reads a frontend constant as a "valid" owner).
Hardened wording: §4.15(a) must inline or cite the valid-owner-path enumeration AND the does-NOT-count list (comment-owner / frontend-owner / local-approval / unratified-design / machine-pseudo-approval / stale-registry-only). Add the cross-ref token (định nghĩa "hợp lệ": §4.15-def). Carry the B5 fix: an approved exception is NOT a valid owner path (it is a separate coverage state).
Acceptance test: the clause text, read alone, lets a reviewer reject a frontend-constant owner as invalid; "valid" is not interpretable.

J2 — Đ37 §4.15(b): anarchic definition inherits the D2 circularity

Original: §4.15(b): anarchic = high-risk governance-orphan that "can change truth/execution/classification/display/automation/issue/cleanup without owner/approval/audit/rollback."
Circularity: same as D2 — every governed object "can change truth/authority" by definition, so the clause makes every orphan anarchic.
Hardened wording: re-base on missing authority-critical link (D2): anarchic = governance-orphan lacking a valid owner path OR (for a mutating/high-risk object) its approval-path/rollback/dot-authority. Descriptive-only gaps (design_ref, law_ref on read-only) are orphan-not-anarchic. Computable from gap_type × profile.
Acceptance test: the clause classifies a read-only report missing design_ref as orphan-not-anarchic and a mutating-DOT-without-owner as anarchic.

J3 — Đ37 §4.16 (owner-assignment) + §5.4-EXT (object edges): the clause must state the interim rule, not defer silently

Original: §4.16: owner assignment is scan→propose→approve→apply→audit, applied "as a governance_relations edge." §5.4-EXT: agency→object edges are "the one structural change … deferred to a Tier-3 phase — NOT part of this pack." "Until then, ownership is resolved via law_jurisdiction.domain + inheritance."
Contradiction with reality (I2): §4.16 says apply writes a governance_relations edge, but the live CHECK blocks object edges, and §5.4-EXT (which would enable them) is deferred. So §4.16 as written cannot be satisfied for object-grain ownership. The two clauses are internally inconsistent about whether object ownership is expressible.
Hardened wording: §4.16 must state the two-mode interim contract (I2): "Owner assignment is applied as an agency→law edge (covering objects via law_jurisdiction+inheritance) for law-domain-anchored objects. For law-orphan objects (route/adapter/standalone-policy with no law domain), owner assignment is not expressible until §5.4-EXT or governance_object_ownership is enacted; such objects remain OWNER_GAP by construction, and the law explicitly records this as a known limitation with a named upgrade path (§5.4-EXT), not a silent gap." Reclassify §5.4-EXT from "deferred" to "prerequisite for object-grain ownership" (B7/I2).
Acceptance test: the clause, read alone, tells an implementer exactly which objects can be owned now (law-domain) and which cannot (law-orphan) and why; it does not claim object edges work.

J4 — Đ31 §4.3-Loại6 references "governed object" — a term owned by Đ37 (cross-law dependency)

Original: §4.3-Loại6 (new 6th check): "with each governed object, verify a valid central ownership path…". §8.8 claims One-Roof is "anchored in Đ37, referenced from others."
Risk: the Đ31 clause uses the term governed object defined in Đ37 §4.15. Đ37 §4.14 (cross-law two-level reference rule) requires the clause text itself to carry the cross-ref, not just the report's §8.8 prose.
Hardened wording: the Đ31 clause must carry the explicit token (governed object — định nghĩa: Điều 37 §4.15; KHÔNG định nghĩa lại tại đây — Đ37 §4.12 SSOT). Same discipline for the Đ35/24/26/28/45 notes that reference governed-object/owner/coverage terms.
Acceptance test: each cross-law clause carries an explicit Đ37 §4.15 cross-ref; no clause re-defines governed object (which would be a §4.12 SSOT violation).

J5 — Đ31 §4.8-ext (coverage GATE) inherits the F3 contradiction

Original: §4.8-ext: add Governance Coverage as a GATE for truth/authority objects — governance_orphans(truth-class)=0 required before production; TARGET (soft) for non-truth.
Contradiction (F3): "orphans(truth-class)=0" — but draft-owner objects are warning-severity orphans that the pack treats as non-blocking. Is a warning an orphan that breaks the gate? The clause must be severity-aware like the report's F3 fix, or it's the same contradiction in law.
Hardened wording: §4.8-ext GATE = zero high/critical (anarchic) orphans for touched objects (with unexpired exceptions allowed); warning orphans are TARGET-tracked with a remediation deadline, not GATE-blocking; info ignored. State the severity-awareness in the clause, matching Đ31 §4.5's existing INFO=no-issue principle.
Acceptance test: the GATE clause, applied to today's baseline, blocks on the agency-orphaned-laws/Direct-PG (high/critical) but not on the 4 draft mother agencies (warning).

J6 — Đ28 §0-OWNER makes the entire UI a high-severity orphan until GOV-MOUT activates

Original: §0-OWNER (Đ28): render/display/API ownership belongs to GOV-MOUT; "until then, display/API is display_owner_gap (high) and the RP page is rendered under an UNRATIFIED_EXCEPTION." GOV-MOUT is draft (live: 4 draft mothers) and activation is high-risk Đ32, "out of scope here."
Trap: if every render/display/API object is a high orphan until a high-risk, unscheduled activation, then every feature touching the UI fails the (severity-aware) gate — the gate is globally red on the UI, so it gets ignored (the brittleness failure, A4). And the activation is the critical-path blocker (doc 10 §10.3) with no interim.
Hardened wording — provide an interim render-owner via recorded delegation (C7): "Pending GOV-MOUT activation, render/display/API accountability is held provisionally by GOV-COUNCIL (owner-of-last-resort, A5) via a recorded, TTL-bounded delegation (C7), so render objects are covered-by-delegation (warning, tracked) rather than high orphans. The display_owner_gap becomes high only if no owner (real or delegated) exists. GOV-MOUT activation removes the delegation." This keeps the gate usable while activation is pending.
Acceptance test: with the delegation recorded, a UI feature passes the severity-aware gate (warning, tracked); without any owner or delegation, it fails. The activation blocker doesn't make the gate permanently red.
Open question: OQ-J6 — accept provisional COUNCIL render-delegation, or fast-track GOV-MOUT activation? (Delegation is lower-risk and immediate; activation is the clean end-state.)

J7 — Đ24/29 §0-OWNER over-centralizes label/taxonomy on GOV-COUNCIL (mis-assignment risk)

Original: §0-OWNER (Đ24/29): "Classification, grouping, threshold, label-dimension, and pin policy are cross-system policy objects owned by GOV-COUNCIL."
Mis-assignment risk: label/taxonomy substrate (the taxonomy_facets/entity_labels/label_rules/species machinery) is arguably GOV-KG-SYS territory (which owns NRM-LAW-39 kg) or a taxonomy owner, not COUNCIL. Dumping everything on COUNCIL conflates cross-system policy (the ≤50 grouping ceiling, pin policy — genuinely COUNCIL) with domain substrate (taxonomy/labels — KG/taxonomy domain). This violates the federated principle the pack itself sets (separate owners by function).
Hardened wording — split by responsibility scope (Branch C): "Cross-system policy (grouping ceiling, pin policy, threshold policy that spans surfaces) → GOV-COUNCIL (accountable). Taxonomy/label substrate (facets, label_rules, species mapping) → its domain owner (GOV-KG-SYS or the taxonomy owner), with COUNCIL as approver for cross-system impact. Grouping (Đ26 L2) is derived from classification (Đ24) which is derived from species (Đ36) — the derivation owners are distinct from the cross-system-policy owner." Don't centralize substrate on the policy owner.
Acceptance test: a label-facet change resolves to KG/taxonomy owner (accountable) + COUNCIL approver; a grouping-ceiling change resolves to COUNCIL (accountable). Two distinct accountable owners, no conflict (C2).
Open question: OQ-J7 — confirm the taxonomy/label substrate owner (GOV-KG-SYS vs a dedicated taxonomy agency). Live: GOV-KG-SYS owns NRM-LAW-39; Đ24 is currently agency-orphaned, so this is an open assignment.

J8 — Đ26 §0-OWNER: pivot owner = source-collection owner (inheritance) — but PIVOT as a law-orphan object hits I2

Original: §0-OWNER (Đ26): "a pivot definition is a governed object (class pivot); its owner is the owner of its source collection (inheritance)." Propose GOV-SIV → NRM-LAW-26 (health) + COUNCIL approver.
Consistency check: this is correct iff the source collection has an expressible owner (law-domain-anchored, B7-i). A pivot over a law-orphan source inherits no owner (I2). The clause should note pivots inherit only where the parent is itself covered (F6 staleness + B4 anti-hiding).
Hardened wording: add: "a pivot inherits its source collection's owner only if the source is itself covered; a pivot over an uncovered/law-orphan source is pivot_coverage_unowned (high), not silently covered (B4)." The GOV-SIV → NRM-LAW-26 health edge is an agency→law edge (expressible today — good).
Acceptance test: a pivot over a covered collection inherits its owner; a pivot over an orphan collection is flagged, not covered.

J9 — Đ45 notes: register-before-emit is correct; correct the event names (H1) in the clause

Original: §3.2-note: "the ~10 governance event_type rows … reuse the system domain for open/resolve and activate the dormant mother.governance.* shapes."
Defect (H1, live): the dormant shapes are bare governance.*/proposal.* (domain=mother), not mother.governance.*. The clause must use correct names and decide the domain (likely a new GOV-SIV-owned governance/integrity domain, not the mother domain).
Hardened wording: correct names; state the domain decision (OQ-H1); keep signal-not-data (safe_payload) + detect-vs-remediate (event vs 9-state job) + throttle-to-summary.
Acceptance test: the Đ45 clause references only live-accurate event_type/domain names.

J10 — Slot-availability and Đ45/Đ36 status drift must be resolved before drafting final text

Original: doc 08 §8 says clause numbers are "keyed to verified current structure"; doc 13 §13.4 flags Đ45 internal inconsistency (header=enacted vs trailing ban_hanh=false) and Đ36 (index v4.0 vs file v5.0 draft) as GOVERNANCE_SCHEMA_DRIFT.
Risk: drafting §4.15–4.18 assumes those slots are free; building on Đ45/Đ36 assumes a settled status. If a slot is taken or the base law's status is ambiguous, the final clause text collides or builds on sand.
Hardened wording: before the P3 drafting macro, verify slot availability (read each law's current §-list) and resolve the Đ45/Đ36 status drift (which version is authoritative) — these are prerequisites to final clause text, recorded as GOVERNANCE_SCHEMA_DRIFT findings to fix, not assumptions.
Acceptance test: P3 confirms §4.15–4.18 are unused slots and Đ45/Đ36 authoritative versions before producing final text.
Open question: OQ-J10 — resolve Đ45 (ban_hanh=false leftover) and Đ36 (v4.0 vs v5.0) authoritative status. (A content-only correction, not a version bump.)

J-summary — Branch J verdict

ID	Severity	Type	Disposition
J1	medium	undefined term	inline "valid"+does-not-count in §4.15
J2	high	circular def	re-base anarchic (D2) in clause
J3	high	contradiction	§4.16 two-mode interim; reclassify §5.4-EXT to prerequisite
J4	medium	cross-law	explicit Đ37 §4.15 cross-ref token
J5	high	contradiction (F3)	severity-aware GATE in §4.8-ext
J6	high	brittleness	interim COUNCIL render-delegation pending MOUT
J7	high	mis-assignment	split label/taxonomy substrate (KG) from cross-system policy (COUNCIL)
J8	medium	consistency	pivot inherits only if source covered
J9	medium	live defect	correct event names (H1) in Đ45 clause
J10	medium	drift/prereq	verify slots + resolve Đ45/Đ36 status before final text

J3/J5/J6 are the law-level twins of I2/F3/A4 — the three places where the drafted law would be unsatisfiable or self-blocking as written. All remain draft-only; nothing here is enacted.