06 — Proposal / Review / Agent Workflow Model (hardened)

Package: one-roof-axis-auth-proposal-operational-hardening-build-ready-design-2026-06-02 Mode: DESIGN ONLY · READ-ONLY · NO COMMIT · NO MUTATION Hardens: prior …-2026-06-01/05-axis-proposal-layer-*.md + 08-agent-workflow-and-review-model.md. Closes GPT review gap #4: "Proposal layer needs exact reuse decision for unit_edit_draft, approval_requests, iu_merge_set, doc_reviews; avoid vague hybrid design."

6.0 Decision: Hybrid PG-native (the Git model, not a Git server)

Implement the Git-like change-management model (base-version, diff, review gates, merge, rollback, signed-off-by) inside PostgreSQL using existing substrate. Do not stand up external Git/GitLab/Gitea/GitLawb now.

Option	Verdict	Why
Hybrid PG-native ✅	CHOSEN	~80% of the Git model already exists in PG; truth stays in PG; no new dependency; agents operate via existing approval spine; reversible.
Native-PG-only (no Git semantics)	rejected	loses diff/merge-base/branch discipline that uncertain content needs.
External Git server (GitLab/Gitea)	deferred	only ever a future front-end for human-facing collaborative document text editing (could front `unit_edit_draft`); never for axis/topic governance proposals.
GitLawb-like	deferred	same as above; no operational need now.

6.1 Exact reuse decision (the substrate, role-by-role)

GPT gap #4 demands precision. Each live table, what it IS reused for and what it is NOT:

Live table	Reused FOR	NOT used for	Key columns leveraged
`approval_requests` (211)	the proposal envelope + the decision record (L0–L2); carries `proposed_action jsonb` + `source_context`	not for storing content bodies; not auto-approve (`action='review'` only)	`code, request_type_code, proposed_action_code, action, status, proposed_action, source_context, issue_signature, target_collection`
`apr_approvals` (42)	votes / signed-off-by (quorum, INV-1)	not a free-text log	`apr_id, approver, approver_type, decision, rationale`
`unit_edit_draft`	branch / working-copy for IU content edits; base-version + content-hash diff; staleness conflict	not for axis/topic membership (that's `axis_assignment`)	`unit_id, base_version_ref, base_content_hash, draft_body, draft_content_hash, draft_status, applied_version_ref, stale_at`
`iu_merge_set` / `iu_split_set`	merge / split change-sets + idempotency + revert	not for simple single-node edits	`merged_iu_id, source_iu_ids[], change_set_id, idempotency_key, rolled_back_at/by/reason`
`doc_reviews`	two-gate human/AI review of proposals	not for the final quorum (that's `apr_approvals`)	`status, review_gate_1 jsonb, review_gate_2 jsonb, resolution jsonb, history jsonb, created_by_type`
`unit_version` (182) / `registry_changelog` (69,070)	history / audit	not the live truth	version anchors; change log
`governance_build_authorization` (NEW, doc 03)	the L3 grant to apply an approved proposal	not the decision (that's the quorum)	per doc 03
`axis_assignment` (NEW, doc 05)	the candidate/quarantine working state for uncertain-axis proposals	not content text	`zone, confidence, provenance`

Git-concept → PG-substrate map: branch=unit_edit_draft; merge-base=base_version_ref+base_content_hash; diff=base_content_hash vs draft_content_hash (content) / current_state vs proposed_action (governed rows); conflict=stale_at; review=doc_reviews+approval_requests/apr_approvals; merge=applied_version_ref/iu_merge_set; history=unit_version/registry_changelog; revert=iu_merge_set.rolled_back_*; signed-off-by=apr_approvals+L0–L4; apply-grant=governance_build_authorization. No new proposal table is needed.

6.2 The proposal lifecycle (one envelope, six states)

DRAFT  →  DIFF  →  REVIEW  →  APPLY  →  VERIFY  →  CLOSE
(author  (compute (doc_reviews (L3 grant   (post-     (consume grant;
 draft/   diff vs   2-gate +    + promote   condition  changelog;
 candidate base)    quorum)     txn, doc11) checks)    event)

The envelope is one approval_requests row whose proposed_action jsonb carries the change: a unit_edit_draft ref (content edit), axis_assignment candidate rows (membership), or proposed taxonomy/iu_relation changes — plus a change-set record. One envelope = one reviewable, approvable, revertible unit.

6.3 The six agent roles (config-driven, never self-approving)

Role	Input	Output (store)	Allowed	Forbidden
Propose	content/signal	`approval_requests` / `unit_edit_draft` / `axis_assignment(zone=candidate)` / `taxonomy(status=candidate)`	create drafts & candidates	set `zone='approved'`; set grant `active`; apply
Validate	a proposal	`doc_reviews.review_gate_1`	check schema/evidence/provenance	approve high-risk; promote
Critique	a proposal	`doc_reviews` / `system_issues`	adversarial review, raise issues	block by fiat (must record)
Sync / apply	an approved + L3-granted proposal	target table via approved DOT handler only	apply under a valid `governance_build_authorization`	apply without a valid grant; bypass the verifier
Quality	live state	`system_issues` / `kg_quality_log`	run detectors	mutate truth
Handoff	a state change	`event_outbox` (signal, after SB-11)	emit a registered governance event	push payload data through the queue (Điều 45)

Golden rule (Điều 39): AI proposes, never self-enacts. No single agent constitutes a quorum (INV-1). High-risk changes need L2 quorum (humans/council) + L3 grant (granter ≠ executor).

6.4 Uniform assertion schema (every proposal carries this)

{ match_score, confidence,
  evidence: [ {kind, ref, weight} ],
  provenance: { source, source_authority, extraction_method, resolved_by, timestamp },
  assertion_mode: asserted | inferred | proposed }

assertion_mode='asserted' ⇒ human/authoritative (TBox-adjacent). 'inferred'/'proposed' ⇒ AI (ABox). TBox (schema/types) = human; ABox (instances/facts) = AI — an AI may populate facts but not redefine the schema.
Missing provenance ⇒ the assignment is quarantine, never reviewed for promotion (doc 05 §5.2 CHECK).

6.5 Diff / review / merge / rollback (concrete)

Diff: content = base_content_hash vs draft_content_hash; governed rows = current_state vs proposed_action jsonb. Stale base (stale_at set) = conflict ⇒ rebase the draft before review.
Review: doc_reviews.review_gate_1 (validator) + review_gate_2 (critic) + resolution; then the L2 quorum on approval_requests is the binding decision.
Merge / apply: only via the promotion txn (doc 16) under a valid L3 grant; iu_merge_set/iu_split_set give change_set_id + idempotency_key.
Rollback: pre-apply = drop the draft/candidate; post-apply = change_set_id reverse + revoke the grant + runbook (doc 16); deprecate-not-delete.

6.6 KG self-learning bounds (Điều 39)

KG weight updates are bounded: CHECK ABS(new_weight - old_weight) ≤ max_delta; snapshots in kg_weight_snapshots; a trigger REJECTs modifier='ai_self_learn' editing species/relation_type (schema). AI may adjust instance weights within bounds; it may not silently rewrite the ontology.

6.7 Avoiding hardcoded workflows (config-driven)

Workflows are rows, not code paths: workflow_categories/workflow_step_relations (the steps), dot_tools/dot_iu_command_catalog (the operations), apr_action_types (the action vocabulary + risk), kg_auto_approve_rules (auto lanes), label_rules (deterministic assignment), SB-12 governance_ruleset (the active rule set). A new workflow = new rows referencing existing primitives — no new bespoke pipeline. The canonical 8-step agent loop (observe → discover → propose → validate → critique → seek-approval → apply-under-grant → verify-and-handoff) is the only loop; specific workflows differ only by which config rows they reference.

6.8 How an approved proposal syncs into PG truth

Pointer to doc 16: one idempotent, L3-authorized promotion transaction writes truth (+ Birth for born objects) + flips axis_assignment.zone + reconciles entity_labels, records changelog/audit, consumes the grant, then projections refresh by Điều 45 signal (after SB-11). Until the governance event domain is registered, refresh is synchronous + manual.

6.9 Open decisions & forbidden-compliance

O-PROP-1: when (if ever) to front unit_edit_draft with an external Git UI for human document editing (future, non-blocking).
O-PROP-2: doc_reviews gate definitions per axis kind (deterministic axes skip gate-2 critique of confidence, keep integrity gate).
Forbidden-compliance: design-only; no draft/candidate/approval/grant/event created; read-only.