06 — Approval Spine Exact Capability (Q6)

Verdict: APPROVAL_SPINE_READY for object-level changes (policy assignment, pivot/grouping/pin rows, DOT registration) via the existing request/action vocabulary and handlers. One documented exception: law-clause enactment (amend_law / enact_nrm) has handler_ref = unimplemented and every live enact-via-APR attempt is rejected → law patches cannot be auto-applied through the APR handler; they require council_review + manual/ADMIN-fallback enactment. The request vocabulary itself is sufficient; only descriptions are placeholder (a minor APPROVAL_VOCAB polish, not a blocker).

1. approval_requests schema (live, 211 rows)

Columns: id, code, request_type, entity_type, entity_code, title (NOT NULL), current_state(jsonb), proposed_action(jsonb), alternative_actions(jsonb), evidence, source, priority, status, reviewed_by, reviewed_at, review_note, applied_at, date_created, action, target_collection, target_entity_code, source_context(json), date_updated, issue_signature, request_type_code, proposed_action_code.

• CHECKs: status ∈ {pending, approved, applied, rejected, expired}; action ∈ {add, modify, delete, review}; priority ∈ {critical, high, normal, low}; target_collection NOT NULL.
• FKs: request_type_code → apr_request_types.request_code; proposed_action_code → apr_action_types.action_code.
• entity_type is free text (no CHECK) → any object type can be targeted.

2. apr_approvals schema (live, 42 rows)

Columns: id, apr_id (FK→approval_requests), approver, approver_type, decision, rationale (NOT NULL), created_at.

• CHECKs: approver_type ∈ {human, ai_council}; decision ∈ {approve, reject, abstain}; UNIQUE(apr_id, approver) (enforces no-double-vote).

3. How to tell human/council vs machine approval

• A sovereign approval = an apr_approvals row with approver_type = human (live: only president, 14 approvals) or approver_type = ai_council (live: gemini 11, gpt 11, + gpt-ai-council/gemini-ai-council/ai_council_1/2 = 28 total). All 42 are decision = approve.
• A machine application writes no apr_approvals row; it sets approval_requests.reviewed_by directly to orchestrator-s142b / auto-apply-function / system_auto_expire and flips status → applied/expired. Machine auto-apply is not a sovereign sign-off.

4. What a valid approval artifact is

1. An approval_requests row with the correct request_type_code + proposed_action_code + (NOT NULL) target_collection.
2. Enough apr_approvals rows to meet the Đ32 quorum for the action's risk_level (high = president + ≥2 ai_council + 0 reject; med = ≥1 president; low = ≥1 / valid auto). No-self-approval (Đ32 §4.3.1).
3. status reaches approved → applied, applied via a dot-apr-execute:* handler (not hand-SQL).

Live reality (decisive): the only 42 sovereign approvals are the S178 DOT-repair campaign — targets normative_registry (21 approvals, all rejected — the enact-via-APR attempts id 204–210), dot_ops (9, applied), dot_tools (9, applied), admin_fallback_log (3, approved). Zero sovereign approvals touch any pivot / classification / label / taxonomy / grouping / pin / display artifact. os_proposal_approvals = 0 (empty). Every RP-adjacent collection (pivot_results, pivot_definitions, taxonomy_facets/matrix, label_rules, entity_labels) entered via machine birth_orphan auto-apply or expired accuracy_drift. ⇒ NO_APPROVAL_FOUND / COMMIT_FORBIDDEN holds.

5. Can approval cover each target?

Target	Coverable via APR?	Path
policy assignment (owner attach)	Yes	rule_change / schema_add + update_item/add_field handler; Council §4.12(d) minute
law / design patch	Recordable but NOT auto-appliable	amend_law/enact_nrm = risk_level high, handler_ref = unimplemented → must go council_review + manual enact into normative_registry
PG view commit	Yes (via DOT)	views = DDL → schema_add + Đ33 §13.1 E1 DOT path (dot-schema-*-apply); not via Directus
pivot definition creation	Yes	new_dot / schema_add + create_item handler
grouping policy activation	Yes	rule_change / create_item / update_item
pin policy activation	Vocab yes, but blocked	schema_add once a pin table exists — but needs law P-PIN first
phantom definition	Recordable but NOT auto-appliable	council_review (law clause P1), handler-blocked like other law patches

6. Existing request / action types suitable (all status = active)

• apr_request_types (14): reclassify, rule_change, schema_add, schema_modify, schema_delete, new_dot, retire (directly reusable) + accuracy_drift, birth_orphan, fix_repair_dot, general, other, process_improvement, user_feedback.
• apr_action_types (6): create_item (low, dot-apr-execute:create), update_item (low, :update), add_field (medium, :add_field), patch_ops_code (high, :patch_ops), amend_law (high, unimplemented), enact_nrm (high, unimplemented).
• entity_type free text → no enum patch needed to target pivot/classification/pin objects.

7. What vocabulary patch is needed?

• Not a hard vocab gap — reclassify/rule_change/schema_add/new_dot/retire already cover every Registries-Pivot policy/pivot/DOT/pin change. entity_type is free text.
• Polish (optional): most apr_request_types.description rows are placeholder "[active] Entity (chưa có) trong apr_request_types." — clarifying descriptions + adding a default_action_code per request type would harden routing (currently only fix_repair_dot → patch_ops_code is mapped).
• Real gap (not vocabulary): the amend_law/enact_nrm handlers are unimplemented → the law-enactment automation path is non-functional. Law clauses (P1/P2/P-PIN) must be enacted via council_review + manual/ADMIN-fallback, exactly as the live constitution/law set was (vps_deploy_log id 1 "ADMIN-fallback bootstrap dot-nrm-enact").

Bottom line

The Đ32 spine is ready to govern every object-level Registries-Pivot change with existing types/handlers; the discipline simply has never been walked for grouping (0 approvals). The single capability gap is law-clause application automation, which today is a Council manual-enact process, not an APR handler.