04 — Law Placement Analysis (A–E)

Date: 2026-05-26 | Scope: Should queue rules be added to an existing law, or get their own (Điều 45)? Note: This survey does NOT amend any law. Decision belongs to user + GPT council.

---

§1. The five options

Option A — Add to Điều 35 (DOT Governance)

Điều 35 governs DOT (Domain Operation Tool) lifecycle, registration, run modes, and integrity. The DOT category vocab already includes {collection, piece, lifecycle, read, health}.

Pros

• DOT runs are queue-like (each run has a planned → applied → verified lifecycle in dot_iu_command_run).
• DOT registry already tracks mutating, reversible, target_functions per command.

Cons

• DOT is one type of executor. The queue must also serve non-DOT executors: Hermes batch, Agent jobs, vector sync, staging cleanup, MOT workflows, generic worker tasks.
• DOT category vocab does not have a queue/scheduler dimension.
• Forcing queue invariants into Điều 35 would dilute its DOT-governance identity.

Verdict: ❌ Too narrow.

---

Option B — Add to Điều 36 (Collection Protocol)

Điều 36 governs Collection birth, registry, gates, no-vector-staging-zone, and species mapping.

Pros

• The no-vector-in-transient rule (NVSZ) is already a Điều 36 invariant; the queue inherits it naturally.
• Birth-gate machinery (birth_registry, tac_birth_gate_config) is queue-like.

Cons

• Collection birth is one source of queue work, not the queue itself.
• Routing, retry, dead-letter, lease, and worker observability have no Collection-Protocol home.
• Tasks, messages, Agent jobs, DOT runs are not Collection events.

Verdict: ❌ Too narrow.

---

Option C — Add to Điều 31 (System Integrity)

Điều 31 governs contract-driven integrity, 3-loop validation, regression protection (with Điều 30), and "đúng / đủ / sạch / sống" health properties.

Pros

• Queue dead-letter, retry, and "sống" (liveness) are integrity-adjacent.
• The "no payload secret / no vector" CHECK already enforces a Điều 31-style contract.
• system_issues (the heaviest current event traffic, 131k rows) is integrity-driven.

Cons

• Điều 31 is contract-validation framework; queue is execution substrate. Different concerns.
• Putting "how a worker drains events" into an integrity law makes the law over-broad.
• Better placement is: queue interacts with Điều 31 (issue-opened/resolved events) and exposes telemetry to Điều 31, but does not live inside it.

Verdict: ⚠️ Adjacent but wrong-shape.

---

Option D — Extend Điều 44 Implementation

The current event substrate (event_outbox, event_pending, iu_route_*, iu_staging_*, dot_iu_runtime_lease) lives entirely inside dieu44-trien-khai/ docs. P3D4C0X is a Điều 44 sub-design.

Pros

• Lowest-friction path: just add §X / §Y to Điều 44 implementation tree.
• All design docs are already there; no new top-level law needed.
• No risk of orphaned cross-references.

Cons

• Điều 44 is the implementation pack for IU-0. A system-wide queue serves all 13 laws, not just Điều 44.
• Naming: "Điều 44 chứa hàng đợi cho hệ thống" reads as a category error; future readers will look for queue in a top-level law slot.
• Making Điều 44 own queue invariants couples queue evolution to IU-0 evolution. Bad for both.

Verdict: ⚠️ Acceptable as interim (keep current docs where they are while design progresses), not as the long-term home.

---

Option E — New Điều 45 "Luật Hàng Đợi & Điều Phối Tác Vụ PG-native"

Possible scope:

• §1 Định nghĩa (queue / event / job / staging / lease / worker / dead-letter)
• §2 Substrate bắt buộc (event_outbox shape, payload classification, vocab whitelists)
• §3 Lifecycle hợp đồng (state transitions cho event / staging / run)
• §4 Idempotency + retry + dead-letter
• §5 Lease + advisory lock + worker observability
• §6 Trigger-IN (SQL → event) + Trigger-OUT (event → action) hợp đồng
• §7 Scheduler boundary (pg_cron yes/no/when; external invocation contract)
• §8 No-vector-in-transient (ratify NVSZ at law level)
• §9 Inclusion criteria (governance-significant — port doc 23-P3D4C0X §M.3)
• §10 Cross-references to D22, D28, D30, D31, D35, D36, D37, D43, D44

Pros

• Single owner for queue invariants across 13 laws.
• Clear law-level home matches the "candidate Điều 45" already noted in 23-P3D4C0X §K.
• Allows the queue substrate to evolve without amending Điều 44.
• Makes the scheduler-boundary explicit (forces the pg_cron / no-pg_cron decision to be law-level, not implementation lore).
• Allows cross-references from every other law that emits or consumes events.

Cons

• New law text requires Council review (Gemini + GPT) per existing law-issuance practice.
• May overlap with Điều 35 / 36 / 31 unless cross-references are tight.
• Risk of premature codification — only Phase 2 PoC has shipped; Phase 3+ may shift invariants.

Verdict: ✅ Recommended target, BUT with two preconditions:

1. Author a draft Điều 45 first (not enact). Get GPT + user review.
2. Decide whether pg_cron is in scope before the draft enters Council review — that single decision shapes §7 of the law.

---

§2. Scoring matrix

Criterion	A (D35)	B (D36)	C (D31)	D (D44 ext)	E (D45 new)
Queue scope cross-domain (≥3 laws affected)	✗	✗	~	~	✓
Queue invariants are own (idempotency, retry, dead-letter)	✗	✗	✗	~	✓
Governs Agent/DOT/worker/Hermes uniformly	✗	✗	✗	~	✓
Treated as core architecture, not impl detail	~	✗	✓	✗	✓
Minimizes coupling to one domain	✗	✗	~	✗	✓
Council review effort	low	low	medium	low	medium-high
Risk of premature codification	low	low	low	low	medium

---

§3. Answers to the mission's law_placement_questions

queue_scope_crosses_how_many_domains: 8
  # iu, birth_registry, governance, tac, kg, system, dot, health
  # plus piece (sub-domain), staging (sub-domain) — 8 governance domains + 2 sub-domains

queue_requires_own_invariants_or_not: yes
  # idempotency, retry, dead-letter, lease, payload-classification, no-vector-transient
  # cannot be expressed cleanly inside D31's contract-validation framing

queue_must_govern_agent_DOT_worker_Hermes_jobs_or_not: yes
  # mission explicitly enumerates 11 use cases beyond DOT
  # Hermes/Agent jobs have no current PG-native home; queue law must define the seam

queue_is_core_architecture_or_implementation_detail: core_architecture
  # substrate is already 131k rows + active worker + dead-letter primitive
  # this is foundational substrate, not configurable detail

recommended_law_placement: new_dieu45_AFTER_design_pack
  # interim: leave current docs under Điều 44; design pack produces draft Điều 45;
  # ratification happens after Council review and pg_cron decision

required_cross_references:
  - dieu22-system-issues  # heaviest event traffic source
  - dieu28-display        # exposure rule for event boards
  - dieu30-regression     # event stream regression-test contract
  - dieu31-integrity      # liveness / dead-letter as integrity signals
  - dieu35-dot-governance # DOT runs as queue producers/consumers
  - dieu36-collection     # birth gate + NVSZ + staging records
  - dieu37-governance-org # agency/role routing in event_subscription
  - dieu39-knowledge      # KG provenance events (planned)
  - dieu43-context-pack   # system events feed red_zones
  - dieu44-iu-impl        # IU events are the largest non-system traffic

---

§4. Recommendation gist

Recommend Option E (new Điều 45), with these guardrails:

1. Do not enact yet. Author a draft, route to Council, then ratify.
2. Decide pg_cron scope first. The presence/absence of pg_cron changes §7 (scheduler boundary) materially.
3. Decide event-only vs event+job substrate first. This changes §1 (definitions) and §2 (substrate) materially.
4. Keep current substrate untouched during drafting. No DDL, no rename, no migration.
5. Cross-references must be exhaustive because the queue touches every domain.

Until then, treat current docs as Điều 44 sub-design (Option D interim), per the 23-P3D4C0X §K original recommendation.