04 — Governance-Orphan vs Birth-Orphan (Branch D)

Reviews decision-pack doc 03 (…/03-governance-orphan-anarchic-object.md). Adversarial. The mission's core ask: keep the four orphan concepts distinct AND specify their overlap so two scanners don't double-fire.

D0. What the pack says (summary)

Doc 03 defines four things: governance-orphan (a governed object missing ≥1 required central link), anarchic object (a high-risk governance-orphan that can change truth/authority), local-governance-island (a cluster with its own owner/approval/lifecycle), and governance coverage gap (the population measure). §3.5 positions governance-orphan as the "fourth detector," distinct from birth/registry orphan, Điều 37 orphan, and KG orphan, and says it "must not duplicate" them and is "scoped to truth/authority objects."

Overall: the four definitions are individually clear and the distinctness intent is right. Two defects: (D1) the overlap/dedup precedence the mission explicitly demands is missing, and (D2) the anarchic definition is circular against the governed-object definition.

D1 — Missing joint-classification matrix and dedup precedence (the mission's explicit Branch-D ask)

Original: §3.5 says governance-orphan "must not duplicate" birth-orphan but gives no rule for when an object is both, which detector owns the issue, or how the coalesce_key namespaces interact. Mission §7 asks precisely: "when can an object be both birth-orphan and governance-orphan; when only governance-orphan; when only birth-orphan; severity mapping; issue routing. Avoid duplicate scanners producing duplicate noise."
Trap: an object with no birth record (birth-orphan) necessarily has no owner path (governance OWNER_GAP) — so both detectors fire on one root cause, producing two issues. At scale this doubles the noise and confuses remediation (fix birth? fix owner? they're the same fix).

Hardened wording — the joint matrix + precedence rule:

State	Birth/registry orphan (Đ2/Đ37 NV1)	Governance-orphan (this)	Who raises the issue
Object not even registered/born	YES	(suppressed — see rule)	birth-orphan detector only
Object born+registered, but no governance links	NO	YES	governance detector
Object born, owner exists, missing only approval/audit/rollback	NO	YES (partial)	governance detector
Object retired (Đ36)	NO	NO (out of scope)	neither

Precedence rule (the dedup): "Birth/registry orphan is a prerequisite failure. If an object is not yet born or not in any registry (Điều 2 §3 'không trong registry = vô hình'), the governance-coverage scanner MUST NOT independently raise OWNER_GAP — the object is invisible and the birth-orphan detector already owns it. The governance detector activates only for objects that exist and are registered but lack governance links. The two detectors are sequential, not parallel: governance coverage is a layer above birth/registry coverage."

Shared coalesce namespace: both detectors write system_issues with a coalesce_key derived from (object_ref, gap_family); the governance detector's OWNER_GAP key for an unborn object is intentionally never minted (it would collide-or-duplicate the birth-orphan key). One root cause → one issue.

Acceptance test: seed an unregistered object → exactly one issue (birth-orphan), not two; then register it without an owner → the birth-orphan issue resolves and one governance OWNER_GAP issue opens. No window with two open issues for one object.
Open question: OQ-D1 — does the Điều 37 agency-orphan detector (DOT-GOV-LAW-HEALTH, "law enacted + 0 DOT active") overlap the new governance-coverage detector for the agency-orphaned laws (24/26/28/45)? Both would flag law-28's missing owner edge. Decide which owns the law-owner-edge gap (recommend: keep it with the existing Đ37 detector; governance-coverage covers objects, the Đ37 detector covers agencies/laws — state the boundary explicitly).

D2 — Anarchic-object definition is circular against the governed-object definition

Original: §3.1: "Anarchic object = a high-risk governance-orphan: a governance-orphan that can alter system truth, execution, classification, display, automation, issue-routing, or cleanup … Anarchy = orphan-hood × capacity to change truth/authority."
Circularity: doc 02 §2.1 defines a governed object as precisely something that "can affect truth or authority." So every governed object, by definition, has "capacity to change truth/authority." Therefore every governance-orphan (which is a governed object missing links) is anarchic by §3.1's own test → the orphan/anarchic distinction collapses. The pack tries to rescue it with one example ("a read-only report missing design_ref = orphan not anarchic") but that example contradicts the stated test (a read-only report still "affects display truth," so it qualifies as anarchic under §3.1).
Hardened wording — re-base anarchic on the missing-link class, not on "capacity":

"Anarchic object = a governance-orphan missing an authority-critical link — i.e. lacking a valid owner path, OR (for a mutating/high-risk object) lacking its approval-path / rollback / dot-authority. A governance-orphan missing only descriptive links (design_ref, law_ref on a read-only object, audit-ref on a non-mutating object) is an orphan but not anarchic. Anarchy is graded by which profile-mandatory link is missing (doc 02 coverage profiles), not by the object's generic 'capacity'."
This makes anarchy computable from the gap_type × profile (doc 03 §3.3 already wants "severity = function of object-class × gap-type" — D2 just makes the anarchic label follow the same computation instead of a separate circular test).
Acceptance test: a read-only report missing design_ref → orphan, severity info/warning, not anarchic; a mutating DOT missing paired_dot or owner → anarchic, critical. The classifier never marks a descriptive-only gap as anarchic.
Open question: none.

D3 — "local-governance-island" detection is defined but has no enumerable cluster source

Original: §3.1 island = "a cluster of objects that defines its own owner/approval/lifecycle outside the roof." §3.2 gap type LOCAL_GOVERNANCE_ISLAND is "(structural)."
Misimplementation risk: how does a scanner detect a cluster? Orphans are per-object and computable; an "island" is a structural pattern (a local approval flag + local owner constant + local policy table, together). The pack never says how the detector recognizes the cluster. Left vague, LOCAL_GOVERNANCE_ISLAND is detectable only by a human reading code — i.e. memory again.
Hardened wording: define island detection as derived, not primary: an island is reported when ≥2 co-located governance-shaped artifacts are found by the existing scanners — specifically (a) a no-owner_gov_code policy table (F-ISLAND-3) and (b) a local approval flag/constant (F-ISLAND-2) and/or (c) a local owner constant (F-ISLAND-1) in the same source/module. The island finding is a roll-up of co-located F-ISLAND-1/2/3 hits, computed by the CI scanner (doc 11/P8), not a separate magic detector. Until the no-hardcode/CI scanner (P8) exists, LOCAL_GOVERNANCE_ISLAND is detectable only via code review and must be marked UNVERIFIABLE-pre-CI, not silently "clean."
Acceptance test: a planted module with a local approval boolean + a local owner constant + a no-owner policy table is reported as one LOCAL_GOVERNANCE_ISLAND (roll-up), not three unrelated orphans; before CI exists, the island class is reported as unverifiable.
Open question: OQ-D3 — is island detection feasible without source scanning (i.e. from PG alone)? Some islands (a no-owner policy table) are PG-visible; others (a frontend approval boolean) need code scanning. State which island sub-types are PG-detectable vs CI-only.

D4 — Severity table (§3.3) hard-codes example→severity but says severity is "computed, never hand-set"

Original: §3.3 grades info/warning/high/critical and says "Severity is a function of object class × gap type, computed by the scanner — never hand-set." Good. But the table's rows pin specific examples to severities (e.g. "GOV-MOUT draft → warning").
Minor risk: the worked severities risk being copied as a lookup table (hand-set) rather than re-derived from (class × gap). Cosmetic but worth a note.
Hardened wording: present §3.3 as the function definition (the (class × gap)→severity rule) first, with the examples explicitly labeled "illustrative outputs of the function," and require the scanner to compute, not look up. Add the D2 rule: missing authority-critical link ⇒ at least high; missing owner on a mutating object ⇒ critical (anarchic).
Acceptance test: changing an object's class or gap type changes its computed severity without editing a severity table.
Open question: none.

D5 — "scoped to truth/authority objects, does not re-scan 181,378 template_gap rows" — good, but the scope boundary is informal

Original: §3.5 says governance-orphan detection "does not re-scan the 181,378 template_gap rows that Điều 28 already owns."
Risk: "scoped to truth/authority objects" is the right instinct (anti-noise) but stated as prose, not as a computable filter. Without a precise inclusion predicate, a future maintainer either broadens it (noise) or narrows it (blind spots).
Hardened wording: the governance-coverage population = objects whose L1 source profile is not PROFILE-EPHEMERAL and whose object_type is in the policy/authority/surface/law/DOT/pivot/exception set (doc 02 B2). template_gap rows are PROFILE-EPHEMERAL-or-Đ28-owned and explicitly excluded by source, not by row-count. State the exclusion as an L1-source flag (in_governance_coverage_population bool on the inventory row), so it is data-driven and auditable.
Acceptance test: the excluded-source list is enumerable and owned (COUNCIL); the count of excluded objects is reported.
Open question: none.

D-summary — Branch D verdict

ID	Severity	Type	Disposition
D1	high	gap (mission-explicit)	add joint matrix + birth-precedence dedup rule
D2	high	circular definition	re-base anarchic on missing-link class, not "capacity"
D3	medium	under-specified	island = roll-up of co-located F-ISLAND hits; CI-dependent
D4	low	framing	present severity as a function, examples as outputs
D5	medium	informal scope	data-driven inclusion flag on L1 source

D1 and D2 are mandatory: D1 is the anti-duplicate-noise rule the mission demanded; D2 fixes a definition that, as written, makes "anarchic" meaningless.