D2 — dot-kg Process Family: SOP & Operating Runbook

STATUS: DRAFT / CANDIDATE. Operating guide for the 36 DOT_KG_* DOTs reconstructed from dieu39-knowledge-graph-law.md §6/§7 and live dot_tools evidence. Do not execute these DOTs manually — they have never run (0 executions) and their downstream effects (KG edge writes, quarantine, weight updates) are governed. This SOP documents what they are and how to verify them, not how to trigger them. No process is registered or born. Authored 2026-06-04.

1. What the dot-kg process is

The dot-kg family is the automation layer of the Knowledge Graph (Điều 39). 36 DOTs implement the KG's 10 operating processes (A–J) as 18 producer/verifier pairs: a producer (Cấp B) writes/derives KG content on an event; its verifier (Cấp A) audits that content on a schedule. Design principle: "Cấp A IDLE = Cấp B đúng = thiết kế tốt." All run as PG functions reading PG config each invocation (no hardcode, no external script).

2. What it does (by process)

proc	does	cron
A formation	rows → entities/edges, classify to species, validate→quarantine	02:00
B business	capture intent, recommend, update journeys; recalc weights	04:00
C feedback	apply corrections, similarity; scan orphans, health	05:00
D monitoring	completeness/consistency/timeliness/orphan/health snapshot	06:00–07:00
E scaffold	build scaffold subgraph from Đ38 (partial, dirty flag); validate→clear	on Đ38 enact
F priority	project scope (person+role+goal), decompose goal→HTN; verify/recalc	daily
G discovery	bottom-up discover→propose (APR); constraint-check gate	weekly
H eviction	scan stale → verify → soft-delete (hidden from AI)	monthly
I self-learning	self-score outcomes → bounded weight update + snapshot	weekly
J conversational	extract from chat → verify (auto per `kg_auto_approve_rules` or APR)	daily
gov	provenance tag/audit, override log/audit, explain/verify	cron

3. Inputs / outputs

Inputs: PG row changes (A), chat/forms (B/J), Đ38 enacted regulation (E), goals/context (F), schedules (D/G/H/I), plus 14 PG config tables read every run: kg_thresholds, kg_signal_config, kg_constraint_config, kg_acl_config, kg_auto_approve_rules, kg_source_authority, kg_priority_templates, scaffold_dependency_map, kg_weight_snapshots, kg_model_versions, etc.
Outputs: universal_edges (+provenance JSONB), Qdrant entity_embeddings, kg_quality_log, kg_evolution_snapshots, APR rows for TBox proposals. Quarantine on missing provenance / failed trust gate.

4. Components (36 DOTs / 18 pairs)

See doc 04 §4.1 for the full pair table. Producers = the 18 on-demand DOTs; verifiers = 15 cron + 3 dual. Live codes: DOT_KG_EXTRACT … DOT_KG_OVERRIDE_AUDIT.

5. Expected run sequence

There is no single linear run. The cluster is a continuous 24/7 loop of 10 independently-triggered processes. Within a process, the contract is producer (event) → verifier (cron audit). The daily monitoring chain D is the most sequential: COMPLETENESS 06:00 → CONSISTENCY 06:10 → TIMELINESS 06:20 → ORPHAN 06:30 → HEALTH 07:00 (snapshot). The trust survival gate runs before any edge is trusted (see D1 §5).

6. Triggers / queues / events

Triggers: dot_tools.trigger_type — on-demand (producers), cron (verifiers), dual (VALIDATE, EXPLAIN-VERIFY, SELF-LEARN). Cron schedules live in the law text, not populated in dot_tools.cron_schedule yet (gap).
Queues: none — dot-kg uses no job_queue rows (job_queue currently holds only cut.*). KG runs are intended via dot_iu_command_run, but 0 KG runs exist.
Events: 0 KG events registered in event_type_registry (gap — the event-driven producers have no declared event types).

7. How to verify (when execution begins)

Did a DOT run? SELECT * FROM dot_iu_command_run WHERE command_name ILIKE '%kg%' ORDER BY created_at DESC; (today: 0 rows).
Is a verifier idle (good)? Verifier produced no findings → kg_quality_log clean for that dimension → producer is correct (design intent).
Cluster health: DOT_KG_HEALTH monthly Gold-Standard mode (random sampling → COMPLETENESS+CONSISTENCY+PROVENANCE-AUDIT on sample → kg_quality_log); human reviews the report only (NT2/NT3).
Coverage: SELECT * FROM v_process_discovery_orphan_components WHERE candidate_code='PROC-CAND:dot:kg'; → today returns the 18 orphaned producers.

8. How to detect stuck / failed

Today there is no runtime to be stuck (0 executions). When live: a stuck producer = event arrived but no dot_iu_command_run row; a failing verifier = repeated findings in kg_quality_log with no producer correction; a broken trust gate = surge in quarantined edges. Watch last_executed going stale vs the cron schedule, and run_status in dot_iu_command_run.

9. Known gaps

0 executions ever — the whole family is declared but never run. 2. No script_path/file_path — execution_engine=pg_function declared but the functions are not evidenced. 3. cron_schedule empty in dot_tools (schedules only in law text). 4. 0 KG events registered. 5. No cross-DOT correlation (dot_iu_command_run.run_id is per-command). 6. 18 producers orphaned from the process inventory. 7. KG owner not registered in governance_registry.

10. What NOT to execute manually

Do not invoke any DOT_KG_* by hand. Producers write to universal_edges and can quarantine/auto-link at scale; SELF-LEARN mutates weights (bounded but real); EVICT soft-deletes knowledge; SCAFFOLD-BUILD marks subgraphs dirty (blocks the compliance gate). All effects are governed (Đ37) and the auto/manual boundary lives in kg_auto_approve_rules — read that table before any write, per the law.

11. Relation to process discovery & future birth/governance

This family is the TYPE_1_DOT_CONTAINED population. Process discovery (this macro) scores it strong_candidate_structural — born-worthy on structure, blocked on runtime/correlation evidence. Future birth/registration (owner-gated) would: register the KG owner in governance_registry; declare KG event types; add cross-DOT correlation; then let the discovery engine promote it to verified_candidate. See doc 06 (engine) and doc 08 (scoring).

12. Candidate-status disclaimer

Reconstructed from law text + structural evidence; no runtime evidence exists. Per-DOT input/output are hypotheses. Nothing here authorises execution, registration, or birth. Live-verified 2026-06-04; 0 production mutation by this document.