KB-4CD1

08 — Agent Workflow & Review Model (propose/validate/critique/sync; no self-approve; config-driven, design-only, 2026-06-02)

7 min read Revision 1
one-roof-governanceagent-workflowreviewno-self-approvalconfig-drivendieu45handoffconfidence-evidencegolden-ruledesign-only2026-06-01

08 — Agent Workflow & Review Model (Branch H)

Branch H. How Agents participate so that infrastructure supports workflows without hardcoding every workflow. Verdict: RECOMMENDED — agents are proposers/validators/critics/sync-executors driven by config rows (DOT catalog + action types + rulesets + auto-approve rules), never authors of governed truth or self-approvers of risk. Anchored by Điều 39 Golden Rule: "AI proposes, never self-enacts."


08.0 The one rule everything derives from

Điều 39 NGUYÊN TẮC VÀNG: "AI ĐƯỢC ĐỀ XUẤT, KHÔNG ĐƯỢC TỰ BAN HÀNH TRI THỨC CHUẨN" — AI may propose, may not self-enact canonical knowledge. TBox (schema/ontology/scaffold) = human; ABox (data/link/weight) = AI, within PG-enforced guardrails. Combined with the L0–L4 ladder (doc 02), this fully bounds agent authority.

08.1 The six agent roles (and where each writes)

Role What the agent does Writes to May it touch truth?
Propose suggest a topic/node/assignment/edit/build approval_requests, unit_edit_draft, axis_assignment(zone=candidate), taxonomy(status=candidate) No — working zones only
Validate check a proposal against rules/invariants reads + doc_reviews.review_gate_1 (AI gate) No
Critique adversarial/quality review of a proposal doc_reviews notes, system_issues No
Sync / apply execute an approved proposal the target table, via the approved DOT handler only, under an L3 build-auth if it COMMITs born substrate Yes — only after approval + build-auth
Quality check scan for drift/anarchy system_issues, kg_quality_log No
Handoff signal next stage event_outbox (signal, not data — Điều 45) No

08.2 Agents cannot self-approve high-risk (the guardrails)

  • L0: auto-approve only for allowlisted risk_level='low' actions; fail-safe deny otherwise (doc 02). The allowlist is a governed row; an agent cannot widen it.
  • L1/L2: proposer ≠ approver; quorum by fn_apr_quorum_check; AI-council may vote but cannot constitute quorum alone for high-risk.
  • L3: the build agent may draft a governance_build_authorization but cannot set it active; validity is recomputed from the backing quorum (v_build_auth_valid).
  • L4: sovereign e-sign — an agent physically cannot produce it (forgery, forbidden).
  • KG self-learning (Điều 39 C9): bounded (CHECK ABS(new-old) ≤ max_delta), snapshot-before-batch (kg_weight_snapshots), and a PG trigger REJECTs modifier='ai_self_learn' editing species/relation_type (TBox).

08.3 Confidence / evidence / provenance schema (uniform)

Every agent-produced assertion carries, in the relevant table's columns/jsonb:

{ match_score:   numeric,        // technical similarity/extraction score
  confidence:    numeric,        // calibrated (score 0.8 ⇒ ~80% correct — NĐ-36-01 §MT9)
  evidence:      [ {kind, ref, snippet} ],
  provenance:    { source, source_authority, extraction_method, resolved_by, timestamp },
  assertion_mode: 'asserted'|'inferred'|'proposed' }

Rules: match_score is separated from approval_state (NĐ-36-01 §MT4 — high technical score ≠ approved); missing provenance ⇒ quarantine (Điều 39 A8); confidence < threshold ⇒ candidate, never approved (NĐ-36-01 NT-09 "không chắc = sai"). source_authority follows the trust hierarchy (kg_source_authority: quy định > báo cáo > chat).

08.4 Agent handoff records (Điều 45 — signal not data)

Stage-to-stage handoff uses event_outbox (the live event substrate), under Điều 45:

  • the queue carries a signal (a reference/event), not payload data;
  • event ≠ job; the executor boundary holds (an agent/DOT executes; the event does not);
  • MOT is not an executor;
  • register-before-emit (the governance event domain must be registered in event_type_registry before any emit — currently 0 governance event types registered, doc 01);
  • silent-gap / heartbeat detection (queue_heartbeat). The GCOS handoff ledger (implementation-index docs 31–35) is the cursor-tail mechanism Birth→governance; topic/axis stages reuse the same pattern.

08.5 API / checker agents

  • Checker (paired-DOT) agents: Điều 38 §6.1 "máy trước, người sau" + "derived-first": for every writer DOT that derives metadata, a checker DOT verifies it (paired DOT). Tier/binding/species counts are computed from PG, not hardcoded; the agent only proposes initial values, the DOT/system confirms.
  • API agents (e.g. Langroid Tier-4): invoked only when tiers 1–3 are uncertain (NĐ-36-01 §MT3 pipeline: PG exact/fuzzy ‖ Qdrant embedding, then agent rerank/disambiguate). The agent handles "phần khó" (the hard part), not the whole pipeline.

08.6 Config-driven workflows (no hardcode)

The workflow is assembled from rows, not coded per case:

  • dot_iu_command_catalog / dot_tools — the executable steps (DOTs);
  • apr_action_types — the action vocabulary + risk tier + handler_ref;
  • workflow_categories / workflow_step_relations — workflow grouping/order;
  • kg_auto_approve_rules — auto/manual boundary ("no rule = no auto = default human");
  • rulesets (SB-12 governance_ruleset, unbuilt) — which checks/thresholds apply;
  • label_rules — rule-driven labeling conditions. An agent reads these tables to know what it may do, at what risk, with what handler, requiring what approval — so a new workflow is new rows, not new code. This is the structural answer to "support workflows without hardcoding every workflow."

08.7 The canonical agent loop (topic example, end-to-end)

  1. Discover (read IU bodies / KG) → 2. Propose topic node + candidate assignments (approval_requests + axis_assignment.zone=candidate, with confidence/evidence/provenance) → 3. Validate (AI gate 1: dup/quality/dictionary) → 4. Critique (adversarial: is this too broad? overlapping? contradicted?) → 5. Human/council review (gate 2 + quorum, L1/L2) → 6. Sync (approved DOT applies; L3 build-auth if it COMMITs a born node) → 7. Quality check (scanner re-verifies; raises issues) → 8. Handoff (event_outbox signal to indexing/UI refresh). Steps 1–4, 6–8 are agent-doable; step 5 requires human/council; step 6's COMMIT requires build-auth (doc 02).

08.8 Verdict

RECOMMENDED. Agents are first-class but bounded participants: they propose, validate, critique, sync-on-approval, quality-check, and hand off — all driven by config rows and gated by L0–L4 + the Golden Rule. No agent authors governed truth or self-approves risk; every assertion carries calibrated confidence/evidence/provenance with match_score separated from approval_state. New workflows are new rows, not new code.

Back to Knowledge Hub knowledge/dev/reports/architecture/one-roof-axis-proposal-authorization-operating-substrate-design-2026-06-01/08-agent-workflow-and-review-model.md