02 — Authorization Model: Technical vs Sovereign (Branch B + B2)

Branches B and B2. Design-only. Designs a reusable, system-wide authorization model — not just a Phase-1 build unblock. Five levels L0–L4, reusing the live approval spine for L0–L2, introducing one new technical substrate governance_build_authorization for L3, and reserving human e-sign for L4 sovereign acts only. Verdict: RECOMMENDED. Adopting L0–L4 unblocks controlled Phase-1 builds without forging signatures and without requiring the President's e-signature for routine, reversible, controlled engineering — while keeping one-roof governance and a bright sovereign line.

02.0 The problem, restated from live evidence (doc 01 §01.4)

The master commit gate M-1 was defined as "≥1 row in os_proposal_approvals". Live audit proves that table is a human e-signature surface inside a sales/deal proposal module (siblings os_proposals, os_proposal_blocks, os_proposal_contacts, os_deal_stages, table_proposals; columns signature_text/image, first/last_name, email, ip_address, esignature_agreement). Two structural errors follow:

Wrong instrument. A personal e-signature record is the right artifact for a sovereign legal act, not for "a controlled additive DDL step may COMMIT." It has no notion of step / scope / TTL / rollback / single-use.
One gate for two jobs. Collapsing "technical build authorization" and "sovereign human approval" into one row means every technical build needs a personal signature → the system either stalls (correct agents refuse to forge) or invites forgery. The approval spine (apr_action_types) meanwhile has no build-authorization action type at all — so there was nowhere legitimate to record a technical build authorization.

Design principle (the fix): Separate the authorization spectrum into levels by risk and reversibility. Most controlled technical work is L0–L3 (machine/owner/council/build-owner, recorded in the governed approval spine + a build-auth record). Only genuinely sovereign acts are L4 (human e-sign). The level is chosen by the action's risk class, not by who happens to be running.

02.1 The five-level ladder (overview)

Level	Name	Typical action	Approver of record	Agent may approve?	Human required?	President e-sign?	Truth store
L0	Machine / internal low-risk	create/update a data row from an allowlisted, reversible action	automatic (governed allowlist)	Yes (allowlist lane only)	No	No	`approval_requests` (auto) + DOT/audit log
L1	Agent-proposed, technical-owner approved	medium-risk data/schema-field change	one named technical owner (human)	No	Yes	No	`approval_requests` + `apr_approvals` (1 human)
L2	Governance / council approved	high-risk governance/policy/ontology decision	council quorum (Điều 32)	AI council may vote, never self-decide	Yes (per risk)	No	`approval_requests` + `apr_approvals` quorum + `governance_audit_log`
L3	High-risk build / deploy	a controlled build/migration/activation step that COMMITs	council quorum + named build owner, recorded in a build-auth row	No (may prepare draft only)	Yes	No (unless threshold → L4)	`governance_build_authorization` (new) backed by L2
L4	Sovereign President e-sign	law enactment, constitutional change, irreversible/destructive act, sovereignty-threshold build	the President, personally	Never	Yes (the President)	Yes	human e-sign collection (interim `os_proposal_approvals`; target: dedicated governance sovereign e-sign surface — §02.3b)

Each level is fully specified in §02.2. The level escalates upward when risk crosses a threshold (§02.6); it never silently descends.

02.2 Per-level specification (all 14 B2 attributes)

L0 — Machine / internal low-risk action

Who may request: any agent, DOT, or system process.
Who may approve: automatic, by a governed allowlist (auto_approvable flag/row), not by code.
Agent approval allowed? Yes — this is the machine lane, but only for action codes on the allowlist with risk_level='low'. Fail-safe default = deny if the action is not explicitly allowlisted.
Human approval required? No.
President e-sign? No.
Truth store: approval_requests (status auto-approved) + apr_approvals(approver_type='system') + registry_changelog/DOT run log. Reuses apr_action_types create_item/update_item (risk=low).
Directus e-sign? No.
How runtime agent verifies: proposed_action_code is in the auto-approve allowlist and its apr_action_types.risk_level='low' and the action handler is implemented (not unimplemented).
Expiry/TTL: per-request (auto-approval is immediate and scoped to that single request).
Rollback/revocation: the action handler's own compensation primitive (reversible by default); allowlist entry can be revoked (L2).
Audit/provenance: approval_requests.source_context + apr_approvals.rationale='auto' + changelog.
Anti-forgery rule: the allowlist is a governed config row owned at L2; fn_auto_approve_* must check allowlist and risk_level='low'; today's fn_auto_approve_add default-approving action='add' is a hardening defect (doc 01 §01.4; implementation-index doc 27/84) and must be changed to allowlist + fail-safe.
No-self-approval rule: N/A for a machine action (no human approver to impersonate); the allowlist itself is governed at L2, so the lane can't be widened by an agent.
Links: approval_requests.proposed_action_code → apr_action_types(low).

L1 — Agent-proposed, technical-owner approved

Who may request: an agent (the proposer).
Who may approve: exactly one named human technical owner (the approver), distinct from the proposer.
Agent approval allowed? No. An AI reviewer may comment, but the recorded approval is the human owner's.
Human approval required? Yes (the technical owner).
President e-sign? No.
Truth store: approval_requests + apr_approvals (≥1 human approve, approver≠proposer); risk_level='medium' (e.g. add_field).
Directus e-sign? No.
How runtime agent verifies: approval_requests.status='approved' and an apr_approvals row with decision='approve', a registered owner identity, and approver≠proposer.
Expiry/TTL: approval valid for a configured window (e.g. apply within N days of reviewed_at); stale ⇒ re-approve.
Rollback/revocation: handler compensation + approval_requests status revert; owner may revoke before apply.
Audit/provenance: apr_approvals.rationale, reviewed_by/at, registry_changelog.
Anti-forgery rule: approver must be a registered owner identity (not free text); approver≠proposer enforced.
No-self-approval rule: enforced — proposer≠approver.
Links: approval_requests + apr_approvals + apr_action_types(medium).

L2 — Governance / council approved

Who may request: agent or human proposer.
Who may approve: council quorum per Điều 32, by risk_level. (Current high-risk quorum from rehearsals: President + 2 AI-council, reject blocks.) The President may cast a recorded vote here (apr_approvals.approver_type='president') — this is not the L4 e-signature.
Agent approval allowed? AI-council members may be quorum voters; no single agent can satisfy quorum or self-decide.
Human approval required? Yes for high-risk governance/ontology/policy (per Điều 32 mix).
President e-sign? No.
Truth store: approval_requests + apr_approvals quorum (fn_apr_quorum_check PASS) + governance_audit_log + (for governed decisions) governance_relations.
Directus e-sign? No.
How runtime agent verifies: fn_apr_quorum_check(request) PASS.
Expiry/TTL: decision validity window configurable; coverage rulesets/grouping policies are L2 rows with their own lifecycle.
Rollback/revocation: governed revert + audit; a superseding L2 decision.
Audit/provenance: all apr_approvals votes + rationales + governance_audit_log.
Anti-forgery rule: approver_type must match registered council membership; quorum count enforced by fn_apr_quorum_check.
No-self-approval rule: proposer≠approver; quorum requires ≥N distinct approvers.
Links: approval_requests + apr_approvals + apr_action_types(high) + governance_relations.

L3 — High-risk build / deploy authorization (the new lane that replaces the M-1 misuse)

Who may request: agent or human proposes a build step; the proposal is an approval_requests row with a new build-auth action type (§02.3a).
Who may approve: an L2 council quorum plus a named build owner; the result is recorded in a governance_build_authorization row referencing the approved request.
Agent approval allowed? No. The build agent may prepare a draft authorization record (status draft), but cannot set it active; activation requires the L2 quorum + named owner (an authority that is not the build agent).
Human approval required? Yes (the L2 quorum includes humans for high-risk; the build owner is a named human).
President e-sign? No — unless the step crosses the sovereignty threshold (§02.6), in which case requires_sovereign_esign=true and an L4 e-sign reference is required before COMMIT.
Truth store: governance_build_authorization (new, §02.3a) row, status='active', scoped, single-use, TTL, backed by the L2 approval_requests+apr_approvals quorum.
Directus e-sign? No (unless escalated to L4).

How runtime/build agent verifies (the COMMIT gate):

EXISTS ( SELECT 1 FROM governance_build_authorization a         WHERE a.auth_code = :auth           AND a.step_name = :step           AND a.status = 'active'           AND a.commit_allowed = true           AND now() BETWEEN a.granted_at AND a.expires_at           AND a.consumed_at IS NULL           AND a.granted_by <> :build_agent_identity        -- no self-approval           AND quorum_passed(a.request_ref) = true           -- backing L2 quorum real           AND ( a.requires_sovereign_esign = false                 OR valid_sovereign_esign(a.sovereign_esign_ref) = true ) )  -- L4 if escalated

Expiry/TTL: short expires_at (e.g. 24–72h); single-use — consumed_at is set when the step commits; a new step needs a new authorization (matches implementation-index doc 72 §72.5: "authorization expires on completion of this step").
Rollback/revocation: revoked_at/by/reason (revoke an unused/active auth at any time) and the build's own rollback runbook (rollback_plan_ref, doc-71-style).
Audit/provenance: links to request_ref, approval_ref (quorum votes), rollback_plan_ref, evidence jsonb, granted_by, consumed_at/by.
Anti-forgery rule: a build-auth row is invalid unless request_ref points to an approval_requests row whose quorum passed — enforced by a verification view v_build_auth_valid (and at build time by the verifier query above), not by the row's own status alone. An agent cannot manufacture authority by inserting a build-auth row; the row is inert without a real backing quorum it did not cast.
No-self-approval rule: granted_by ≠ build agent identity; backing quorum proposer≠approver.
Links: governance_build_authorization.request_ref → approval_requests.code; .approval_ref → apr quorum; .sovereign_esign_ref → os_proposal_approvals (nullable; only when escalated to L4).

L4 — Sovereign President e-sign

Who may request: council/President proposes a sovereign act (e.g. enact_nrm, amend_law, constitutional change, an irreversible/destructive operation, or an L3 step flagged sovereignty-threshold).
Who may approve: the President, personally, by e-signing through the Directus e-sign flow (out of band from any agent).
Agent approval allowed? Never. An agent writing this row = forging the sovereign's signature (forbidden, by governance not transport).
Human approval required? Yes — specifically the registered sovereign identity.
President e-sign? Yes (the defining property).
Truth store: a human e-signature collection. Interim: os_proposal_approvals (current M-1 surface), but see §02.3b — the cleaner target is a purpose-built governance sovereign e-sign collection, because os_proposal_approvals is semantically a sales artifact.
Directus e-sign? Yes.
How runtime agent verifies: existence of a valid e-sign row whose scope covers the act, signed by the registered sovereign identity, linked to the governing approval_requests. The agent reads it; never writes it.
Expiry/TTL: the e-signature is a durable legal record; the authority it confers is scoped to the named act (single act). Re-use for another act = invalid.
Rollback/revocation: sovereign acts are typically irreversible by design (law enactment); "revocation" = a new sovereign act (a counter-enactment), not a delete.
Audit/provenance: the e-sign record itself (name, email, IP, consent flag, timestamp) + linkage to the governance decision.
Anti-forgery rule: the human e-signature is the anti-forgery mechanism — there is no delegable token; a GPT/agent "delegated authorization" is advisory and cannot be transcribed into a signature (implementation-index doc 114 §114.5).
No-self-approval rule: the President is sovereign; the underlying request's proposer and the signing act are recorded distinctly, and the agent that prepared the request cannot be the signer.
Links: the L4 e-sign row references the governing approval_requests; for builds it is referenced by governance_build_authorization.sovereign_esign_ref.

02.3a New substrate — `governance_build_authorization` (paper design, NOT created)

The single new table this model needs. Additive; no existing CHECK widened; no existing table altered.

governance_build_authorization
  auth_code               text PRIMARY KEY      -- e.g. 'BUILD-AUTH-SB12-001'
  request_ref             text NOT NULL         -- → approval_requests.code (the governing L2 decision)
  approval_ref            jsonb NOT NULL         -- snapshot of the passing quorum (request id + voter list)
  step_name               text NOT NULL         -- exactly ONE named step
  scope                   jsonb NOT NULL         -- {objects_allowed:[], objects_forbidden:[], channel, txn_strategy}
  risk_level              text NOT NULL          -- low|medium|high|sovereign (→ a risk vocab row)
  commit_allowed          boolean NOT NULL DEFAULT false
  requires_sovereign_esign boolean NOT NULL DEFAULT false
  sovereign_esign_ref     text NULL              -- → human e-sign row, required iff requires_sovereign_esign
  rollback_plan_ref       text NOT NULL          -- → rollback runbook doc/row
  granted_by              text NOT NULL          -- council/owner identity (NOT the build agent)
  granted_at              timestamptz NOT NULL
  expires_at              timestamptz NOT NULL    -- TTL
  consumed_at             timestamptz NULL        -- single-use: set at COMMIT of the step
  consumed_by             text NULL
  revoked_at              timestamptz NULL
  revoked_by              text NULL
  revoked_reason          text NULL
  status                  text NOT NULL           -- draft|active|consumed|expired|revoked
  evidence                jsonb
  created_by              text NOT NULL
  created_at              timestamptz NOT NULL

Verification view (read-only, used by build agents and the coverage scanner):

v_build_auth_valid := every active row WHERE
  quorum_passed(request_ref)                              -- backing decision real
  AND granted_by <> created_by-if-agent                  -- no self-grant
  AND now() BETWEEN granted_at AND expires_at
  AND consumed_at IS NULL AND revoked_at IS NULL
  AND (requires_sovereign_esign=false OR valid_sovereign_esign(sovereign_esign_ref))

Invariants: status=active is necessary but not sufficient — validity is recomputed from the backing quorum; single-use; additive-only; this table is owned at L2 (GOV-COUNCIL) and its writes are themselves governed.

02.3b The `os_proposal_approvals` question — interim vs target

os_proposal_approvals is, by schema and siblings, a sales/deal proposal e-sign module. Two coherent paths; the user's instruction is honored in both ("os_proposal_approvals must remain sovereign e-sign only" ⇒ it is never a generic technical COMMIT key and never agent-writable):

Interim (no migration): keep os_proposal_approvals as the L4 sovereign e-sign surface, agent-forbidden, only for genuinely sovereign acts. M-1 is redefined (§02.7) so that L3 builds no longer depend on it.
Target (recommended, council decision): stand up a purpose-built governance sovereign e-sign collection (a Directus human-e-sign collection scoped to governance), so the sales module returns to its sales role and sovereign governance e-sign lives in a governance-owned surface. This is a clean separation but is itself an L2/L4 governance decision — flagged in doc 13 as a patch, not done here.

02.4 How an action lands on a level (risk → level map)

The level is a function of apr_action_types.risk_level × reversibility × blast-radius — data, not code:

Action class	Example	Level
reversible low-risk data write, allowlisted	`create_item`/`update_item` on a draft	L0
medium-risk schema-field add, single owner sufficient	`add_field`	L1
high-risk governance/ontology/policy decision (no substrate COMMIT yet)	register an axis, approve a topic node, set a ruleset, C-1/C-2/C-7 rulings	L2
high-risk build/migration/activation that COMMITs substrate	SB-12/13/10/11/2/1 build, event activation, backfill seed	L3 (backed by L2)
sovereign/irreversible/legal	`enact_nrm`, `amend_law`, constitutional change, destructive ops, sovereignty-threshold build	L4

02.5 The six explicit B2 answers

Why must os_proposal_approvals remain sovereign-e-sign-only? Because it is a human e-signature record (name/email/IP/consent) — semantically a personal legal act. Using it as a generic COMMIT key (a) forces every technical build behind a personal signature (operationally untenable, forgery-inviting), (b) gives it no step/scope/TTL/rollback semantics, and (c) erases the bright line that should exist around acts that genuinely need a person's signature. Reserving it for L4 keeps that line sharp.
What new/reused substrate represents technical build authorization? Reuse the approval spine (approval_requests+apr_action_types+apr_approvals) for the decision; add one new record type — governance_build_authorization — for the scoped, single-use, expiring, revocable build grant (L3), backed by that decision. Add build-auth action types to apr_action_types (e.g. authorize_build_step risk=high, activate_event_type risk=high) — rows, not code.
How to prevent agents fabricating approval? (a) No agent can satisfy quorum or self-decide (L0 allowlist is fail-safe-deny + governed; L1 proposer≠approver; L2 quorum; L3 granted_by≠agent + backing quorum recomputed by v_build_auth_valid); (b) a build-auth row is inert without a real passing quorum it did not cast; (c) L4 requires a human e-signature an agent physically cannot produce; (d) the read channel is AST-validated READ ONLY and the constraint is governance, not transport.
How to avoid requiring President e-sign for routine controlled builds? Route them to L3, not L4. A controlled, reversible, scoped build step is authorized by a council quorum + named build owner recorded in governance_build_authorization — the President is not in the loop unless the step crosses the sovereignty threshold.
How to escalate technical → sovereign when risk crosses threshold? See §02.6 — requires_sovereign_esign flips true and the L3 grant cannot be honored until a valid L4 e-sign is referenced.
How do future workflows reuse this model? See §02.7 — topic promotion, axis publication, event/DOT registration, and build/deploy all route propose→(risk-tiered approve)→(build-auth if it COMMITs substrate)→(L4 only if sovereign). One ladder, many workflows.

02.6 Escalation: technical → sovereign threshold

A step escalates from L3 to L4-required when any sovereignty trigger holds (these are governed rows, not literals):

the action is enact_nrm / amend_law / a constitutional or law-status change;
the operation is irreversible or destructive (no rollback primitive);
it changes the sovereign authority model itself (e.g. editing the L0 allowlist's top tier, or the quorum rules);
blast radius exceeds a governed ceiling (e.g. touches Birth Registry truth, or > N production objects).

Mechanics: the approval_requests carries a computed sovereignty_required flag; if set, the resulting governance_build_authorization has requires_sovereign_esign=true, and commit_allowed is not honored until sovereign_esign_ref resolves to a valid L4 e-sign. De-escalation never happens silently.

02.7 Reuse across future workflows (one model, many uses)

Workflow	Propose (request)	Approve (level)	Build-auth (L3)?	Sovereign (L4)?
Topic promotion (candidate→active/born)	`approval_requests` (`register_topic_node`)	L2 (GOV-KG-SYS/owner + council for policy)	only if it COMMITs a born taxonomy node	no (unless it changes ontology law)
Axis publication (register a new axis)	`approval_requests` (`register_axis`/`assign_axis_owner`)	L2 (GOV-COUNCIL policy)	yes — inserting the Axis Registry row is an L3 build	no
Event/DOT registration (`event_type_registry`, `dot_tools`)	`approval_requests` (`register_event_type`/`register_dot`)	L2	yes — register-before-emit row is an L3 COMMIT	no
Build/deploy (SB-12…SB-1, T6/T7, migrations)	`approval_requests` (`authorize_build_step`)	L2 quorum + named owner	yes — the canonical L3 case	only if sovereignty-threshold
Law enactment	`approval_requests` (`enact_nrm`/`amend_law`)	L2 proposal	n/a	yes — L4

Redefining M-1

M-1 is no longer "≥1 row in os_proposal_approvals". It becomes per-step: "a valid governance_build_authorization exists for THIS step (v_build_auth_valid), and if requires_sovereign_esign then a valid L4 e-sign is referenced." Sovereign e-sign is required only for L4 steps. This is the single change that unblocks Phase-1 controlled build without forging anything (doc 12, doc 13).

02.8 Consolidated invariants (apply to every level)

Discover-first / no-hardcode: allowlist, risk tiers, quorum rules, sovereignty triggers, axis owners are governed rows, never literals.
No-self-approval: at every level the granting authority ≠ the requesting agent; quorum needs distinct approvers; the build agent never grants its own build-auth.
Anti-forgery: validity is recomputed from backing records (v_build_auth_valid, fn_apr_quorum_check), not asserted by a status flag; L4 is a human signature an agent cannot produce.
Reversible by default: L0–L3 require a rollback primitive; L4 acts that are irreversible are exactly why they are L4.
Auditable: every grant links its decision, votes, rollback plan, and (if any) e-sign.
One roof: all of this lives in / references the central approval spine + governance registry; no per-workflow island (the build-auth table is governed by GOV-COUNCIL).

02.9 Verdict

RECOMMENDED. The model is additive to a working engine: 1 new table (governance_build_authorization) + a few new apr_action_types rows + one verification view + the os_proposal_approvals reservation. It dissolves the M-1 deadlock for controlled builds, keeps the President's e-signature for the acts that truly warrant it, prevents agent forgery by construction, and generalizes to topic/axis/event/DOT/build/law workflows. Phase-1 impact in doc 12; exact patches in doc 13.