05 — Unified Governed Classification & Grouping Framework (Branch E)

A single model covering the whole system, not only Registries-Pivot. Design principle (forced by the live evidence in doc 02): bind governance RELATIONALLY, not with per-table columns. No table in the system carries owner_gov_code/approval_request_ref today; inventing them only for Registries-Pivot would itself create a divergent local pattern.

The framework = 5 existing substrates, composed

Concern	Reuse this central substrate	Law
Classification / grouping policy	taxonomy_facets + taxonomy + taxonomy_matrix + label_rules + entity_labels	Đ24 (+Đ29 species/governance_role)
Counting / pivot coverage	pivot_definitions + pivot_results + meta_catalog	Đ26
Ownership / authority	governance_registry + governance_relations + law_jurisdiction	Đ37
Approval	approval_requests + apr_approvals (+ apr_request_types/apr_action_types)	Đ32
Execution / DOT	dot_tools + law_dot_enforcement (B-tier↔A-tier pairing)	Đ35
Issue / event	system_issues + event_outbox + event_type_registry	Đ45 / Đ31 / Đ23
Display	design_templates + template_statuses	Đ28
Audit	governance_audit_log + registry_changelog	Đ37 / Đ31

How a governed grouping/classification object is bound (the relational pattern)

For any policy object (a grouping dimension, a threshold, a pin policy, a pivot definition):

1. It lives in a collection that has a governance_role (Đ29) + a birth record (Đ0-G). → makes it a managed entity.
2. Its DOMAIN (classification / classification.label / pivot) is owned by (a) a law via law_jurisdiction.coverage_type='primary' (Đ24/Đ26 already) and (b) an agency via governance_registry.domain (TO BE ASSIGNED → GOV-COUNCIL/GOV-SIV).
3. Changes are proposed via approval_requests with the existing request types (reclassify for class changes, rule_change for label-rule/threshold changes, schema_add for a genuinely new policy table, new_dot for a grouping DOT, retire for deprecation) → decided in apr_approvals under Đ32 quorum.
4. Execution is by a paired DOT (Đ35): B-tier apply (approval-gated) + A-tier audit (read-only, auto-approve).
5. Findings raise system_issues rows + event_outbox events of registered types (Đ45 register-before-emit).
6. Audit is closed by DOT-GOV-VERIFY writing to governance_audit_log; data changes logged to registry_changelog.

⇒ The "required governance fields" the mission lists are satisfied by records in these tables, not columns on the policy table:

Mission-required field	Where it lives (relational)
owner_gov_code	governance_registry.domain ↔ object's domain (+ optional governance_relations agency→object edge)
capability_code	governance_registry.capability (mother) / law_jurisdiction.coverage_type
governed_object_type / _ref	the object's collection + meta_catalog row (born entity)
approval_required / approval_request_ref	approval_requests.code (Đ32)
lifecycle_status	approval_requests.status (pending→approved→applied) + object status
scope	approval_requests payload + (for pins) scope column
risk_level	apr_action_types.risk_level
created_by / approved_by	approval_requests.source / apr_approvals.approver
audit_ref	governance_audit_log.id / registry_changelog.id
rollback_ref	DOT backup .bak-{session} (Đ35 §6.2) / superseded_by
effective_from / _to	normative_registry.valid_from/valid_until for the law clause; object status for data
dot_authority_ref	law_dot_enforcement row / dot_tools.code
system_issue_ref / event_type_ref	system_issues.id / event_type_registry row
law_ref / design_ref	law_jurisdiction.law_code (Đ24/26) + this design package

OPTIONAL queryability sugar (only if the system adopts it everywhere)

If a single queryable binding is desired, the reuse-first way is to extend governance_relations to carry object edges (source_type='agency', target_type='collection'|'pivot'|'object', relation_type='owner'). This needs the live CHECK chk_relations_target_type (currently IN (law, agency)) widened — a small schema patch, Đ37-amend + Đ32-gated, NOT a new table. Do this system-wide, not just for Registries-Pivot, or skip it. Do NOT add owner_gov_code columns to individual policy tables — that re-creates the fragmentation the mission warns against.

Non-negotiables honored

• No separate approval mechanism → reuse approval_requests/apr_approvals.
• No separate local owner model → reuse governance_registry/capability + law_jurisdiction.
• DOT actions → Đ35 paired model.
• Issues/events → system_issues/event_outbox (register-before-emit).
• No policy table without an owner+approval path → owner = domain-agency (relational); approval = Đ32. A policy table is acceptable ONLY once its domain has an assigned agency owner AND its first INSERT/schema_add is approved.

What this framework changes for Registries-Pivot

Nothing is "owned by Registries-Pivot." Registries-Pivot is a read/verification surface rendering the central substrates. Grouping/classification/pin/phantom belong to the system (Council/SIV/DOT/Đ24/26/28/31/35/45), and Registries-Pivot consumes them. This is the whole point of the user's correction.