03 — Accountable Owner vs Supporting Roles (Branch C)

Reviews the ownership model in decision-pack doc 01 §1.2 and doc 08 §8.1 (Đ37 drafts). This branch is under-served by the pack — it implies a multi-owner model but never states the accountable-vs-supporting rule the mission §6 requires. This doc supplies the missing taxonomy.

C0. What the pack says (summary)

Doc 01 §1.2 says ownership is "federated by function": policy→GOV-COUNCIL, health→GOV-SIV, DOT→GOV-DOT, render→GOV-MOUT. Doc 08 §8.1 §4.16 says owner assignment is one governance_relations edge. The pack relies on Điều 37 §4.12 ("một nội dung chỉ một luật quản lý" — one content, one governing law) as the no-overlap rule. It never distinguishes an accountable owner from supporting roles, and never states the "exactly one accountable owner per responsibility scope, but unlimited support roles" rule. This is the mission's central Branch-C ask, and the pack does not answer it.

Overall: a real GAP. Left unfixed, the "one owner" rule (Đ37 §4.12) can be read to forbid GOV-SIV auditing a GOV-COUNCIL-owned policy, which would break the federated model the pack itself proposes.

C1 — Missing role taxonomy (the core gap)

Original: the pack has owners but no role types. Mission §6 enumerates: accountable owner, delegate, executor, reviewer, auditor, render owner, health owner, policy owner, exception approver.
Risk: without named roles, every agency touching an object looks like a competing "owner," so either (a) §4.12 is read strictly and support is forbidden, or (b) §4.12 is ignored and multiple real owners proliferate (island risk).

Hardened wording — define the role set (new Đ37 §4.15-bis "Vai trò quản trị"):

Role	Cardinality per (object × scope)	Definition	Authority
Accountable owner	exactly 1	answerable for the object within a responsibility scope; the §4.12 "one law/one owner" applies per scope	sets policy / approves changes in scope
Delegate	0..n	acts with the owner's authority within a bounded grant; recorded centrally with TTL	owner-equivalent within grant
Executor	0..n	runs the change (a DOT, an operator); has no decision authority	apply-only, post-approval
Reviewer	0..n	gives a verdict in the approval flow (Đ32 quorum members)	vote, not decide-alone
Auditor	0..n	verifies after the fact; raises issues; never mutates the object	read + raise issue
Exception approver	per Đ32 risk	authorizes a bypass (TTL-bounded)	grant exception

Acceptance test: for any governed object and any responsibility scope, the coverage view returns exactly one accountable owner and any number of supporting roles; a second accountable owner in the same scope is a LOCAL_GOVERNANCE_ISLAND/conflict finding, but a supporting role is never a conflict.
Open question: none.

C2 — Responsibility-scope is the missing dimension that reconciles §4.12 with federation

Original: Đ37 §4.12 (enacted): "một nội dung chỉ một luật quản lý." Doc 01 §1.2 assigns four owners to (e.g.) one grouping policy.
Contradiction: read naively, four owners for one object violates §4.12. The pack builds on §4.12 but never reconciles it with multi-owner federation → the new draft Đ37 §4.15 would contradict the enacted §4.12 it depends on (an Đ37 §4.12 SSOT self-conflict — exactly the kind of conflict the mission asks me to find).
Hardened wording (resolves the contradiction): define responsibility scope as the unit of accountability, and restate §4.12 mapping: "§4.12's 'one content → one governing authority' means one accountable owner per responsibility scope, NOT one owner per object. A governed object has up to six scopes — policy, health/integrity, execution, render/display, approval, audit — and each scope has exactly one accountable owner. Distinct accountable owners across distinct scopes are not an overlap and do not violate §4.12."
Acceptance test: the grouping policy resolves to {policy: COUNCIL, health: SIV, execution: DOT, render: MOUT} — four scopes, four accountable owners, zero §4.12 violations; a draft clause that says "exactly one owner per object" (no scope qualifier) fails this test.
Open question: none — this is the keystone fix for Branch C.

C3 — Stress test 1: grouping policy

Mission ask: "Council owns policy, SIV audits health, DOT executes, MOUT renders."

Hardened mapping:

Scope	Accountable owner	Supporting roles
policy (what the grouping rule is, the ≤50 ceiling)	GOV-COUNCIL	reviewers = Đ32 quorum
health (is grouping count-integrity correct, PIVOT_MISSING)	GOV-SIV	auditor = DOT-GOV-COVERAGE-AUDIT
execution (apply a grouping change to PG)	GOV-DOT (executor)	paired checker DOT
render (display grouped pivot)	GOV-MOUT	—
approval	Đ32 spine (COUNCIL quorum)	president on high
audit	GOV-SIV	`governance_audit_log`

Test: no scope has two accountable owners; COUNCIL owns policy, not render; MOUT cannot change the policy, only display it (Đ28 NT-D1).

C4 — Stress test 2: Direct-PG exception (mission's hardest case)

Mission ask: "who owns policy, who owns technical implementation, who owns risk?"

Hardened mapping:

Scope	Accountable owner	Note
exception policy (is this bypass allowed at all?)	GOV-COUNCIL (exception approver, Đ33 §13)	grants TTL-bounded exception
technical implementation (the adapter route/object)	GOV-MOUT (surface owner)	the route is a render/API surface
risk (read-only enforced? privileges? TTL honored?)	GOV-SIV (health)	monitors role grants + overdue; raises `direct_pg_unratified_exception`
execution (run/deploy)	GOV-DOT / operator	with `vps_deploy_log` ledger

Test: the three mission questions each resolve to a distinct accountable owner; none is "unowned." This is the concrete answer the pack lacked.

C5 — Stress test 3: pivot coverage

Mission ask: "SIV owns health, DOT executes repair, Council approves policy, MOUT displays."
Hardened mapping: health/PIVOT_MISSING → GOV-SIV (accountable); pivot-repair execution (INSERT pivot_definitions via governed DOT, Đ26 §0-AU/§1E) → GOV-DOT (executor); counting-contract policy change → GOV-COUNCIL approves (Đ32); display → GOV-MOUT. Owner of the pivot as an object = its source-collection owner by inheritance (doc 04 §4.4), with SIV accountable for health — consistent, no conflict.

C6 — Separation of duty is implied but never stated

Original: doc 06 (DOTs) has propose / approve / apply / verify as distinct steps and paired checkers, but the pack never states separation-of-duty (SoD) as a rule.
Risk: without an SoD rule, a future "convenience" refactor could let the proposing DOT also apply (self-grant), or let an executor approve its own change — re-creating a local-approval island under the roof.
Hardened wording (new §4.16-note): "Propose, approve, and apply-verify MUST be held by distinct authorities. A DOT may propose and (post-approval) apply, but approval is always Điều 32 quorum, never the proposing/applying DOT; the apply-verifier (tier-A paired DOT) MUST differ from the applier (tier-B). No role may both author and approve the same change (Đ32 §4.3 no-self-approve generalized to all governed objects)."
Acceptance test: the DOT design (doc 06) shows approval held only by Đ32 quorum; a synthetic "self-approving DOT" fails CI (F-ISLAND).
Open question: none.

C7 — Delegation has no recorded form

Original: the role table (C1) includes "delegate," but the pack/substrate has no delegation record (governance_relations only does agency→law).
Trap: delegation "by memory" is an island. If GOV-COUNCIL delegates render-accountability to GOV-SIV provisionally (e.g. pending MOUT activation, doc 10 J6), there is nowhere governed to record it.
Hardened wording: a delegation is a governed object (an approval_requests row of a delegate_authority action-type, TTL-bounded, audited) — never a comment or a convention. An undocumented delegation is itself an OWNER_GAP/island.
Acceptance test: the provisional render-owner delegation (doc 10 J6) is expressible as a recorded, TTL-bounded delegation, not a note.
Open question: OQ-C7 — does delegation need a new apr_action_type, like exceptions (E2)? (Likely the same new-action-type work.)

C-summary — Branch C verdict

ID	Severity	Type	Disposition
C1	high	gap	define role taxonomy (accountable + 5 support roles)
C2	high	contradiction	responsibility-scope reconciles §4.12 with federation — keystone
C3–C5	—	stress tests	concrete mappings supplied (grouping / Direct-PG / pivot)
C6	medium	gap	state separation-of-duty explicitly
C7	medium	gap	delegation must be a recorded governed object

Branch C was the least-developed part of the decision pack. C1+C2 are mandatory before canonical design — without responsibility-scope, the new Đ37 clause contradicts the enacted §4.12.