GPT Direction — Registries-Pivot Grouping Must Use System Governance

Date: 2026-05-31 Reviewer: GPT Council

User correction

The grouping problem must not be treated as a local Registries-Pivot governance problem. It must be integrated into the system-wide governance model.

Risk identified:

• Each surface creates its own mini-governance.
• Grouping policies, labels, pins, phantom definitions, and classification workflows drift away from Điều 37 / governance_registry / approval spine.
• The system becomes fragmented and arbitrary.

Principle

Registries-Pivot grouping/classification must be governed by the same system-wide governance substrate:

• governance_registry as owner/capability matrix;
• approval_requests / apr_approvals for approval spine;
• workflow_change_requests for proposal flow where applicable;
• system_issues / event_outbox for issue/notification substrate;
• DOT governance under Điều 35;
• no-double-ownership / no-orphan governance from Điều 37;
• no local governance table unless it is registered and owned by the central governance model.

Required correction

Do not design registry_grouping_policy, display_policy, registry_pin, phantom policy, or grouping DOTs as standalone local registries.

They must be defined as governed objects with:

• owner_gov_code;
• capability requirement;
• approval gate;
• lifecycle status;
• audit fields;
• proposal/change path;
• rollback/retire path;
• relation to governance_registry;
• relation to DOT governance if executed by DOT.

Governance decision needed

Before implementing grouping automation, the system must decide which existing governance owner is responsible:

• GOV-MOW? if grouping is considered workflow/design surface governance;
• GOV-MOIT? if grouping is considered input/form/table metadata governance;
• GOV-COUNCIL? if grouping is cross-system taxonomy/registry governance;
• another existing governance row if already available.

No new owner should be minted unless reuse-first proves absence and Điều 32 approval exists.

Design consequence

Next work must be a governance alignment macro, not a UI patch:

1. read Điều 37 and related governance laws;
2. map all grouping-related artifacts to central governance substrate;
3. identify which objects are local-only today and must be pulled into governance_registry/approval spine;
4. propose a single governance model for grouping/classification/pin/phantom/pivots;
5. patch canonical design docs;
6. only then implement PG structures/DOTs/UI.

Non-negotiable

• No separate Registries-only governance island.
• No local approval system.
• No local ownership semantics.
• No grouping DOT that bypasses DOT governance.
• No policy table without owner_gov_code and approval path.
• No global pin/group/phantom action without central approval gate.