10 — Design Impact & Recommendation (Q10)

Synthesis of Q1–Q9 against the recommended Option-4 model (POLICY→GOV-COUNCIL, HEALTH→GOV-SIV, DOT→GOV-DOT, RENDER→GOV-MOUT).

1. Is the recommended model implementable as-is?

PARTIAL. Three of four owners are live and ready; the fourth (render) and three policy objects (threshold/phantom/pin) and the direct-pg path are blocked. Specifically:

• Implementable now (no law change): GOV-SIV health role (count-integrity/orphan/drift/verification), GOV-DOT execution lifecycle (Đ35 paired DOTs), GOV-COUNCIL classification/grouping policy ownership + §4.12(d) assignor authority.
• Not implementable as-is: render ownership (GOV-MOUT draft + Đ28 orphaned), threshold/phantom/pin (no law), direct-pg API (unratified), governance-audit minutes (dormant).

2. Which owner assignments are CONFIRMED (live-ready)?

Owner	Role	Confirmed by
GOV-SIV	health: count-integrity, orphan, drift, system-verification	active; owns Đ31; 22 DOTs; orphan/drift issues live
GOV-DOT	execution: grouping scan/propose/apply/audit	active; owns Đ35; A/B tiering + ops + pairing live
GOV-COUNCIL	policy: classification/grouping + cross-system assignor	active; owns Đ37; §4.12(d) authority; Đ24/29 exist

3. Which owner assignments NEED approval (mechanism exists)?

• Attach classification domain → GOV-COUNCIL and pivot domain → GOV-SIV (+GOV-DOT exec) via governance_relations owner edges + governance_registry domain — schema_add/rule_change APR + Council §4.12(d) minute to governance_audit_log.
• Activate GOV-MOUT draft → active (Đ37 onboard/equip) and bind it to Đ28 (or assign Đ28 to it) — approval-gated.
• Gate new pivots / new dimensions / label-rule changes through Đ32 (new_dot/schema_add/rule_change) — they are currently ungated (machine birth_orphan only).
• Register the issue/event types (doc 09) + activate the dormant mother.*/governance.* event lane.

4. Which law/design patches are MANDATORY before implementation?

Patch	Blocks	Authority
P2 — Đ24/Đ29 ungrouped-ceiling clause	threshold / display_policy commit; group_too_large	GOV-COUNCIL council_review
P1 — Đ31 phantom definition (source_model-aware)	phantom detection, phantom_count, PIV-302, cleanup	GOV-COUNCIL council_review → GOV-SIV detect
P-PIN — pin/personalization clause (host law TBD)	global registry_pin	GOV-COUNCIL council_review
Đ28 ownership — assign display law to an active agency	render/route governance for RP	GOV-COUNCIL §4.12(d)
Đ41/Đ33 read-only-adapter clause OR Directus view-PK	direct-pg API ratification	GOV-DOT/GOV-NRM-SYS + Council
Govern-audit activation (P6)	ownership-minute audit loop	GOV-COUNCIL (wire DOT-GOV-VERIFY/DISCOVERY)
(recommended) P-DRIFT / P-REG	Đ37 schema↔law drift; Đ20/23/45 unregistered	GOV-NRM-SYS/Council

Note: law clauses cannot be enacted via the APR handler (amend_law/enact_nrm = unimplemented, doc 06) → they go council_review + manual enact.

5. Which parts of the Registries-Pivot design must be patched FIRST?

The canonical design package registries-pivot-os-agency/ still frames display_policy/registry_pin as standalone tables with "owner = likely GOV-COUNCIL (TODO)" and labels render owner as "GOV-MOUT (Đ28)". Patch order (design-doc work, a later prompt — not done here):

1. Record the relational ownership binding (no owner_gov_code columns; bind via domain + governance_relations + law_jurisdiction).
2. Correct render owner: GOV-MOUT is born of Đ7, is draft, and Đ28 is agency-orphaned — render ownership requires activation + Đ28 binding, not a one-line assignment.
3. Mark display_policy / registry_pin / phantom_count / PIV-302 as DEFER-until-law (P2/P-PIN/P1).
4. Record the direct-pg exception as unratified + un-ledgered (must back-fill vps_deploy_log + ratify or replace).

6. What can safely proceed NOW (read-only / already-central)?

• Label/grouping reuse via Đ24/Đ29 (query existing facets/labels/species/governance_role).
• Orphan + drift detection (live, GOV-SIV) and count-integrity detection (read-only, raises issues without approval).
• Pivot READ / coverage reporting (render existing pivots; mark gaps PIVOT_MISSING as a display string).
• Keep serving the live RP route (read).
• Author-mode drafting of law-patch text, DOT specs, APR drafts, design-doc patches (drafting ≠ enacting).
• The §4.12(d) Council ratification step for the ownership model (the GPT review's "next recommended action").

7. What MUST NOT proceed?

• Any standalone registry_grouping_policy / local display_policy / registry_pin table without a domain-agency owner + Đ32 approval — REJECT (island risk; GPT direction explicit).
• Any local approval/sign-off flow — only approval_requests/apr_approvals are valid.
• Any grouping DOT outside Đ35 (hand-SQL, Nuxt-side, --admin, curl … || true).
• Any frontend grouping arrays / hardcoded CAT-* rows / count math (Đ28 NT-D1/D3).
• Self-approval of any of the above (Đ32 §4.3.1).
• Enacting threshold/phantom/pin as law by an agent (council_review only; handler is RESERVED anyway).
• Committing pivot rows / phantom_count by hand-INSERT (Đ26 1E).
• Treating the direct-pg API as a sanctioned convention without explicit Đ41/Đ33 approval + a vps_deploy_log entry.

Headline

The central spine is real and the model is mostly ready — its weak points are render ownership (GOV-MOUT draft + Đ28 orphaned), three no-law-home policies, the unratified/un-ledgered direct-pg path, and a dormant audit loop. None require a new agency or per-table gov columns; all are walkable via the existing Đ32/Đ35/Đ37/Đ45 substrate plus a small set of council_review law clauses.