Incomex AI Portal
KB-139B

Master Design Rev2 — 10 Industrial Birth / Cross-Law / Object-Factory Addendum (rev5 MP-D23..MP-D30)

52 min read Revision 1
master-design-rev2rev5mp-d23mp-d24mp-d25mp-d26mp-d27mp-d28mp-d29mp-d30addendumiu-4motherscross-lawdieu28dieu36dieu37birth-registryobject-factoryassembly-first2026-05-28

Master Design Rev2 — Industrial Birth / Cross-Law / Object-Factory Addendum (MP-D23..MP-D30)

Path: knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/10-industrial-birth-cross-law-addendum.md Status: DRAFT Rev2 (DOCUMENT ONLY) — Revision 5 (MP-D23..MP-D30 industrial-birth / cross-law / object-factory final pre-approval hardening, 2026-05-28). NEW addendum at Revision 5. Companion to 00-master-design-rev2.md; extends 08-… (rev3 MP-D11..MP-D15) and 09-… (rev4 MP-D16..MP-D22). Date: 2026-05-28 (rev5 MP-D23..MP-D30). Macro: IU_4MOTHERS_MASTER_DESIGN_INDUSTRIAL_BIRTH_CROSS_LAW_FINAL_PATCH_DOCUMENT_ONLY_XHIGH. Trigger: GPT cross-law reviews knowledge/dev/reports/architecture/4mothers-preapproval-cross-law-review-mp-d23-d28-gpt-2026-05-28.md (verdict NO_FATAL_CONFLICT_BUT_PREAPPROVAL_CROSS_LAW_PATCH_REQUIRED) + nuxt-template-law-vs-4mothers-master-design-gpt-review-2026-05-28.md (verdict NO_CONFLICT_BUT_NEEDS_TEMPLATE-BINDING_PATCH_BEFORE_FINAL_APPROVAL) + the Rev4 roadmap reviews (Rev4 accepted as document-only baseline with IU-substrate readiness gate). Authority: Hiến pháp v4.6.3 (15 NT) · Điều 7 Assembly First / NT8 · Điều 28 Display/Template Law v2.0 + Appendix A Nuxt/UI Assembly Governance · Điều 0-G Birth Registry Law v1.0 + birth-procedures v3.1 + Species Taxonomy v1.2 · Điều 29 Classification Law v2.0 · Điều 36 Collection Law v5.0 DRAFT · Điều 37 Governance Organization Law v3.3 · Điều 32 Approval Law · Điều 33 PostgreSQL Law v2.1 · Điều 35 DOT Governance Law v5.2 · Điều 30/31 reversibility/integrity. Where a clause below diverges from a live law, the live KB law wins and the divergence is reported in §2.3. Boundary: This is a cross-law hardening patch, not a rewrite. It adds no new law boundary and no new governance machinery — it binds the 4 Mothers' industrial object production onto the existing registries of Điều 28 / 0-G / 29 / 36 / 37 / 32 / 35. All schemas/templates/objects referenced are paper-only unless already verified live. Forbidden in this macro (binding): No PG mutation. No Directus mutation. No Qdrant/vector write or reindex. No migration. No DOT command run. No law enactment/drafting. No implementation. No UI deployment. No final OSS tool selection. No direct raw SQL apply. No changing gates. No schema creation. No collection creation. No template creation. No runtime object creation. No code generation.

§1. Why this addendum exists

The 4 Mothers (MOW / MOT / MOIT / MOUT) are not normal modules and not single-object creators. They are industrial object factories: at maturity they will create or configure a large share of all system objects — workflow definitions, workflow steps, tasks, task templates, input forms, output/reference/report views, proposal records, staging submissions, governance queues, event subscriptions, dashboard products, UI template products, and agent/worker task surfaces.

A single object born wrong can be corrected by hand. But a factory that mass-produces objects wrong produces "đẻ rơi" at industrial scale — orphan objects, wrong-collection ("nhầm chuồng"), wrong species, unregistered UI, duplicate ownership, hardcoded Nuxt, untraceable DB rows, ungoverned events, untestable workflows. The blast radius scales with throughput.

Rev2..Rev4 already say "Nuxt is a render shell," "registries are SoT," "no double ownership." That is necessary but not sufficient for a factory. This addendum makes the factory discipline explicit and machine-checkable by binding every produced object to the laws that already govern birth, collection, species, templates, jurisdiction, and approval — before final design approval, so that downstream implementation cannot drift into bespoke UI, unregistered collections, or object/collection sprawl.

Vernacular vs law terms (binding, see §2.3). "Đẻ rơi" is project vernacular; the law terms for the failure modes are orphan / mồ côi (Điều 0-G §2.5, Điều 36 MT1: an entity in a governed collection with no birth_registry record) and phantom (a birth record whose source entity was deleted), plus nhầm chuồng / mis-classification (Điều 33 / DOT-MISCLASS-SCANNER). Every "đẻ rơi" rule below maps to one of these law terms.

§2. Cross-law constitutional review (pre-patch)

This review is performed before the patch set, per the macro's §2 requirement. It is concrete, not a generic "compatible" statement.

§2.1 Constitutional principle check — Hiến pháp v4.6.3 (15 NT)

Finding (live KB wins): the Constitution defines 15 NT, not 13 or 14 (header "15 NGUYÊN TẮC NỀN TẢNG — CẤM VI PHẠM"; NT14/NT15 added Fix 9/S178). The macro asked us to check "14/13 NT principles actually found"; the actual count is 15. Each is checked against this patch set:

NT Title (verbatim short) This patch's compliance
NT1 LÀM MỘT LẦN, DÙNG MÃI (SSOT duy nhất) Reuses existing registries (design_templates / birth_registry / collection_registry / governance_registry); creates no second SoT.
NT2 TỰ ĐỘNG 100% Birth (fn_birth_registry_auto), template lifecycle (trg_template_lifecycle), health (HC-REG/HC-SCHEMA/DOT-*-health) are automatic gates, not manual review.
NT3 DOT 100% (CÓ NGOẠI LỆ) All factory mutations go through DOT pairs (Điều 35) + APR (Điều 32); no raw psql.
NT4 SẴN SÀNG THAY ĐỔI Every factory output declares a rollback/retire path (Điều 30; collection lifecycle born→active→deprecated→retired soft-delete).
NT5 TỰ PHÁT HIỆN, TỰ SỬA Orphan/phantom/mis-class scanners (DOT-ORPHAN-SCANNER, DOT-MISCLASS-SCANNER, DOT-COL-ORPHAN) detect đẻ rơi; coverage scanner detects un-templated UI.
NT6 5 TẦNG ĐỒNG BỘ — CẤM CODE NUXT UI surfaces are design_templates rows; Nuxt renders only; no bespoke page/component (MP-D23).
NT7 DUAL-TRIGGER Birth + lifecycle triggers paired; event register-before-emit preserved.
NT8 ASSEMBLY FIRST MP-D28 reuse decision tree is the operational form of NT8 / Điều 7.
NT9 KHÔNG CHẮC ĐÚNG = SAI Object not certified (birth_registry.certified=false) / template not 5/5 = not active = not trusted.
NT10 QUẢN LÝ BẰNG PG, KHÔNG BẰNG TEXT Factory definitions, bindings, jurisdiction all live in PG rows, not in Nuxt/yaml/code.
NT11 KHAI TỐI THIỂU, THÔNG TIN TỐI ĐA Inherits MP-D11/MP-D13 input minimalism; birth record is minimal declaration, max governance.
NT12 DOT THEO CẶP (2 CHIỀU) DOT-template-create↔DOT-template-health; DOT-COL-REGISTER↔DOT-COL-HEALTH reused as pairs.
NT13 PG FIRST · PG NATIVE · PG DRIVEN Every binding is a PG row driving runtime behavior; no behavior in code.
NT14 THỰC THI ĐƯỢC NGAY (6-câu readiness) MP-D27 traceability matrix is the operational form of NT14 (see §2.2).
NT15 THIẾT KẾ TRƯỚC TRIỂN KHAI This whole package is document-only design before any implementation.

No NT is violated by the patch set.

§2.2 The constitutional "6 questions" — what they actually are

Finding (live KB wins): the macro listed a hypothetical 6/N-question checklist (PG-first? assembly-first? reversible? auditable? …). That exact list is not an explicit clause in constitution.md. The only explicit constitutional question-set is NT14's six execution-readiness questions: an enacted clause must answer (1) dữ liệu ở đâu · (2) ai thực hiện · (3) khi nào chạy · (4) ngưỡng bao nhiêu · (5) kiểm tra bằng gì · (6) sai thì xử lý thế nào — "không trả lời được 6 câu = chưa ban hành." MP-D27's traceability matrix answers these six for every factory-produced object class. The macro's broader list is honored as known constitutional checks in §2.4.

§2.3 Reported divergences (live KB wins over the macro prompt)

# Macro prompt assumption Live KB reality How this patch resolves it
D-1 Điều 37 defines human org roles (staff / trưởng phòng / super admin / chuyên môn / lĩnh vực) Điều 37 v3.3 is a law→agency→entity governance law. It defines governance_registry.type ∈ {collection, dot, factory}, jurisdiction = "Phạm vi" (law_jurisdiction), relations (owner/depends_on/cooperates/enforces/produces/consumes), contracts. It does NOT define staff/dept-lead/super-admin human roles. MP-D26 binds Mothers + outputs to Điều 37's factory agency + jurisdiction + relations. Human-role org-scope visibility is enforced by the Directus permission/role layer + field allowlist (Điều 28 Appendix §4/§6) gated by Điều 32 approval, backend-filtered before Nuxt (Điều 33 NT6 Cổng). A dedicated human-org-role/permission law is flagged as a future need (future Điều XX or amendment) — it does not exist today.
D-2 DOT-COLLECTION-CREATE exists No such DOT. Điều 36 defines DOT-COL-REGISTER, DOT-COL-HEALTH, DOT-COL-PROPAGATE, DOT-COL-ORPHAN, DOT-COL-LIFECYCLE; creation = "DOT + APR (Điều 32)"; registration via DOT-COL-REGISTER / dot-collection-register (+ dot-species-map). MP-D24's Industrial Birth Contract uses DOT-COL-REGISTER + dot-species-map + DOT+APR, not the non-existent name.
D-3 "Đẻ rơi" is a law term Law terms are orphan/mồ côi and phantom (Điều 0-G/29/36); also nhầm chuồng mis-class. §1 + MP-D29 bind "đẻ rơi" to these law terms.
D-4 artifact_kind is an existing field Not present in Điều 0-G / birth-procedures / species-taxonomy / Điều 36 / Điều 29. The governing columns are species_code, composition_level, collection_name, governance_role. MP-D24 treats artifact_kind as a design-introduced descriptor only, always backed by the real law columns (species_code + composition_level + collection_name). No new law term is asserted.
D-5 "13/14 NT" + a 6-question constitutional checklist 15 NT; the 6 questions are NT14's execution-readiness set. §2.1 + §2.2 above.

These divergences are non-fatal: none blocks the patch. They change which existing law owns each binding, which is exactly what a cross-law patch must get right.

§2.4 Per-law review (what design does / must not do / sentinel / amendment need)

The macro forbids a generic "compatible." Per important law:

Law What this design DOES What this design MUST NOT do Sentinel / verification gate Amendment / future law needed?
Điều 28 Display/Template v2.0 + Appendix A Registers every Mother UI surface as a design_templates row + product-from-template record; routes resolve by registry/config Create a bespoke Nuxt page/component; hardcode route→tableId maps; put business logic in Nuxt DOT-template-coverage target 0 outside registry; DOT-template-health; trg_template_lifecycle (no draft→active skip; 8-key checklist; 5/5 tests) No. Existing law sufficient. (Appendix A is DRAFT — note its testing lifecycle-state discrepancy with main law in §3.)
Điều 0-G Birth Registry v1.0 Every Mother-generated object gets a birth_registry record (PEN/STAMP/GATE → certified) Let any object go active without a birth record (= orphan) fn_birth_registry_auto; DOT-ORPHAN-SCANNER; DOT-BIRTH-ORPHAN-SCAN; universal counter No.
Điều 29 Classification v2.0 Every Mother-generated collection carries the 4 mandatory attributes (governance_role, purpose, species mapping, birth trigger) Create a collection missing any of the 4 ("CHƯA QUẢN LÝ = KHÔNG TIN CẬY") 4-attribute check; governance_role ∈ {governed,observed,excluded} No.
Điều 36 Collection v5.0 DRAFT New collection/table/view/registry via DOT-COL-REGISTER + dot-species-map + DOT+APR Raw SQL CREATE TABLE / admin fallback; unregistered PG table HC-REG (PG table not in collection_registry); HC-SCHEMA (governed table missing description); DOT-COL-ORPHAN Watch: Điều 36 is DRAFT 30%. No enactment here; collections stay paper-only until Điều 36 + APR.
Điều 37 Governance Org v3.3 Registers each Mother as a governance_registry row type='factory' (output_target ∈ user/system/assembly) + governance_relations (produces/owner) edges to outputs; binds jurisdiction (Phạm vi) Assert that Điều 37 owns human org-role permissions (it does not — D-1) Factory agency row exists; produces edge per output class; law_dot_enforcement link Future need: a human-org-role/permission law (future Điều XX or amendment) for staff/dept-lead/super-admin scoping. Flagged, not drafted.
Điều 32 Approval Collection-create, template-activate (council review per Appendix §2), direct-canonicalization-of-approval-required changes go through APR Let a factory self-approve any approval-required effect Every create/promote/retire carries approval_id No.
Điều 35 DOT Governance v5.2 All factory mutations are DOT pairs (create↔health) Mutate without a DOT pair / outside dot_iu_command_run audit mutating flag + paired health DOT No.
Điều 33 PostgreSQL v2.1 (3-layer) Backend filters before Nuxt; Cổng (Nuxt) never touches DB; outputs live in PG SoT Nuxt direct DB access; second SoT in Directus/Nuxt NT6 Cổng/Não/Kho boundary; field allowlist No.
Điều 38/39 IU/KG Factory outputs reference IU; IU-narrative changes route through Điều 38/39 author lifecycle Mutate IU canonical body from a factory/staging/direct path IU body singleton sentinel (00-… §13.2) No.
Điều 45 Queue/Event Factory outputs that emit events register in event_type_registry; queue jobs use executor_class_registry Own the event plane / queue / state authority register-before-emit; executor-class + idempotency + heartbeat No.
Điều 7 / NT8 Assembly First MP-D28 reuse decision tree; PG-first then Directus then OSS then code Create new artifact when reuse/extend/view/adapter suffices Assembly Gate Q0–Q5 documented per new artifact No.
Điều 30/31 Reversibility/Integrity Every output has rollback/retire + audit row Irreversible or unaudited factory output rollback path declared; audit row per birth/mutation No.

Net constitutional verdict: the patch set sits cleanly inside existing law. The only new law need surfaced is a human-org-role/permission law (D-1) — flagged for a future macro, not enacted here.

§3. MP-D23 — Điều 28 template binding for 4 Mothers UI surfaces

Rule (binding). Every 4 Mothers UI surface is a registered Điều 28 template + product, or it does not exist. Verbatim Điều 28 core: "Không có khuôn = không có giao diện. Không có ngoại lệ."

Binding rules (each maps to a live Điều 28 construct):

  1. No template registry row = no UI. Each surface is one design_templates row (code TPL-xxx, config_schema JSONB, component_path, instance_collection FK→collection_registry, checklist_status 8 keys, test_results, status FK→template_statuses, species_code='template'/SPE-TPL, composition_level).
  2. No product-from-template record = no route/product. Each instance of a surface is a product record pointing to (template + config source) per Appendix §3; "Không có registry record = UI product KHÔNG ĐƯỢC tồn tại." A new instance = INSERT config, never new Nuxt code (Appendix §1 NT1).
  3. Route resolution is registry/config-driven, not hardcoded maps (Appendix §5; cấm tableIdMap-style hardcoding).
  4. Coverage scanner target 0 routes/components outside registry (DOT-template-coverage, Điều 28 §VIII).
  5. Template lifecycle gate draft → testing → active (main law template_statuses; note: Appendix §2 omits testing — main law is authoritative, divergence noted) enforced by trg_template_lifecycle / fn_template_lifecycle_guard(): no draft→active skip; active forbidden until checklist_status has all 8 keys ("8 BỘ PHẬN" NT-D5) and 5/5 tests PASS (Validation Gate / Multi-Instance / Resilience / Truth-Check 100% Nuxt-cell=PG / Live-Config). Birth record (checklist key 8) auto via Điều 0-G.
  6. No bespoke UI / repair-the-shared-template. If a surface needs a capability the shared template lacks, STOP and amend/repair the shared template under Điều 28 lifecycle (Appendix §1 NT2/NT3) — never a local workaround / double system.
  7. Unavoidable new renderer code registers in the Custom Code Registry (knowledge/dev/ssot/custom-code-registry.md) with: reason, user/council approval, rollback path, smoke verification (Appendix §7). "Không đăng ký = invisible = vi phạm."
  8. Directus permission + field allowlist (Appendix §4.4/§6/§12): permission allowlist ⊇ registry fields; unsafe-field blacklist (payload, body, raw_payload, safe_payload, correlation_id, causation_id, vector, embedding, secret, token, password, ssn, personal_data) absent from BOTH; admin token never in Nuxt runtime — critical for Governance Cockpit + staging input/audio/attachments.
  9. Nuxt boundary (NT-D1): ĐƯỢC read Directus API / render from template / emit submit-payload; KHÔNG business logic / query DB / component-outside-template / hardcode / coordinate-submit-logic.

§3.1 UI-surface → template/product mapping table (binding)

UI surface (source doc) Điều 28 design_templates family (paper) Product-from-template registry Config source Permission source Health / coverage gate
MOW Hierarchy Canvas T6→T1 (02-… §6.6, 08-… §4) TPL-mow-hierarchy-canvas (display/canvas) product per tenant/domain scope tier_registry + workflow_categories + classification (survey) Directus role + per-tier backend filter (Điều 37 Phạm vi) DOT-template-coverage + DOT-template-health
Personal JFT Dashboard (08-… §7.2) TPL-jft-dashboard (dashboard) product per role/agent scope task_template + assignee_policy recipient permission scope same
MOT Task Envelope 6-region (04-… §4.2/§4.2a) TPL-mot-task-envelope (task surface) product per task_template family task_template matrix row per-task permission_scope_ref same
MOIT Form Renderer (04-… §4.3) TPL-moit-form (form family) product per input_form_registry row (CRS-gated) input_form_registry + field_registry (G7) backend input gateway filter same + field allowlist
MOUT Reference/Report Renderer (04-… §4.4) TPL-mout-block / TPL-mout-table (output family) product per output_table_registry row (CRS-gated) output_table_registry + dot_function_registry (G7) backend read filter same
Governance Cockpit (02-… §7.9, 08-… §7.3) TPL-governance-cockpit (ops/dashboard) product per cockpit scope governance_problem* views + governance_slo_policy super-admin/AI-ops scope; field allowlist strict same + field-leak smoke
AI/Agent Ops Console (08-… §7.4) TPL-agent-ops-console (ops) product per ops scope agent_run + executor_class_registry ops scope; prompts/payloads machine-only (MP-D20) same + field-leak smoke
Inline Kaizen widget (08-… §5) TPL-kaizen-inline-widget (input/widget) product embedded per host surface input_routing_policy + captured_context actor scope same
Staging / input review surface (04-… §4.3a) TPL-staging-review (triage) product per dept triage scope input_submission triage view dept triage scope same
DLQ / replay governance surface (02-… §7.4) TPL-dlq-replay (ops) product per ops scope dlq_replay_request + job_dead_letter ops scope + Điều 32 for replay same

Sentinel (MP-D23). Sentinel grep across Nuxt routes/components: every 4 Mothers surface resolves to a design_templates row + product record; zero surfaces outside registry; zero hardcoded route maps; any new renderer file present in Custom Code Registry. DOT-template-coverage returns 0 outside-registry for the 4 Mothers namespace.

§4. MP-D24 — Điều 36 collection/object birth protocol for Mother-generated artifacts

Rule (binding). Every object/table/view/registry generated by MOW/MOT/MOIT/MOUT must be born under Điều 0-G and registered under Điều 36 + Điều 29 before it is valid. No birth record = orphan = invalid. No collection_registry entry = invalid. No species mapping = invalid. No governance_role = invalid.

§4.1 Per-artifact declaration (every generated artifact must declare)

Each Mother-generated artifact declares, using the real law columns (not invented ones):

Declaration Backing law column / table Notes
artifact_kind (design descriptor) — (design label; always backed by the three below) D-4: not a law term; descriptive only
collection/table/view/registry home collection_registry.collection_name Điều 36
collection_registry entry collection_registry row Điều 36 / 29
birth_registry entry birth_registry.entity_code (PREFIX-NNN) Điều 0-G; UNIQUE
species_code birth_registry.species_code (auto from species_collection_map) + entity_species Điều 0-G / Species Taxonomy; e.g. workflow→SPE-WKF, workflow_step→SPE-WFS, task→SPE-TSK, collection→SPE-COL, dot_tool→SPE-DOT
governance_role birth_registry.governance_role ∈ {governed, observed, excluded} (auto from collection_registry) Điều 29
composition_level birth_registry.composition_level ∈ {atom, molecule, compound, material, product, building, meta} (6+1) Điều 0-G / composition law
owner law (binding metadata; see §5 factory matrix) which law owns the child object
owner Mother (binding metadata) MOW/MOT/MOIT/MOUT
lifecycle state collection: born→active→deprecated→retired (Điều 36 MT7); template: draft→testing→active→deprecated→retired; object: birth certified flag soft-delete only (Luật Bảo toàn)
relation map entity_relations (NĐ-36-01) + governance_relations (Điều 37) parent/child via produces/owner
trace_id / correlation_id (runtime-created) W3C trace fields (00-… §8) for runtime-born objects
created_by process / DOT / proposal birth_registry.dot_origin + dot_iu_command_run Điều 35 audit
approval requirement approval_id (Điều 32) where create/promote/retire requires it
rollback/retire path QT-006 (khai tử → died_at + status='retired') / collection retire Điều 30
health check / scanner HC-REG, HC-SCHEMA, DOT-COL-ORPHAN, DOT-ORPHAN-SCANNER, DOT-MISCLASS-SCANNER Điều 36/0-G

§4.2 Industrial Birth Contract (binding pipeline)

Every factory-produced object MUST traverse this contract — the "quy trình sinh trong viện" applied to mass production:

factory_intent
  → pre-birth declaration (artifact_kind + species_code + collection_name + governance_role + composition_level + owner law/Mother)
  → approval if required (Điều 32 APR — mandatory for collection-create, template-activate council review, approval-required effects)
  → create via DOT/API (Điều 35 DOT pair + Điều 33 "làm qua Directus"; NEVER raw psql / admin fallback)
      · collection: DOT-COL-REGISTER + dot-species-map + (DOT + APR)
      · object row: fn_birth_gate (BEFORE INSERT) refuses un-declared insert
  → birth_registry record (certified=false)
      → Inspector PEN (code/origin/species) → STAMP (name/description/status) → GATE (đúng chuồng/business rules)
      → fn_birth_registry_auto / auto-certify (certified=true)
  → collection_registry / species_collection_map / governance_role assignment (Điều 29 four mandatory attributes)
  → health check (HC-REG no-unregistered-table; HC-SCHEMA description present; DOT-COL-ORPHAN clean)
  → active

Rules. No raw CREATE TABLE (Điều 36 / D-2). New table/view/collection is paper-only until DOT-COL-REGISTER + APR. HC-REG (any PG public table absent from collection_registry → CRITICAL system_issues) and HC-SCHEMA (governed table missing description → CRITICAL) are the standing factory-output integrity gates. Object factories are connected to the in-hospital birth flow: birth-first → inspect → certify → active (QT-002 "khai trước sinh sau" enforced by fn_birth_gate BEFORE INSERT + fn_birth_registry_auto AFTER INSERT).

Sentinel (MP-D24). For every factory-produced object class: a birth_registry declaration exists; collection_registry + species mapping + governance_role present (Điều 29 four-attribute check); HC-REG/HC-SCHEMA clean; zero raw-psql creation path in any implementation artifact.

§5. MP-D25 — 4 Mothers as governed object factories

Rule (binding). MOW/MOT/MOIT/MOUT are governed object factories, not free modules. Each is registered as an Điều 37 governance_registry row with type='factory' and an output_target (user / system / assembly), with governance_relations produces edges to each output class and owner edges where it owns the binding (never the law). This is the strongest assembly-first result of this patch: the factory concept already exists in Điều 37 — the 4 Mothers plug into it; no new factory machinery is invented.

§5.1 Factory matrix (per Mother)

MOW — IU Assembly Orchestrator factory (output_target = assembly)

  • purpose: assemble workflow graphs from IU bricks/bundles.
  • can_create: workflow_def, workflow_step_def, workflow_step_relations, workflow_change_request, hierarchy-node projection, MOW canvas product config.
  • can_reference: IU/bundle (Điều 38/39), executor_class_registry, event_type_registry, state_machine_registry, tier_registry.
  • must_not_own: IU body, executor runtime, event core, queue core, approval law, Nuxt template lifecycle.
  • owner law per child: workflow_def/step/relation → future Điều XX (app layer) + species SPE-WKF/SPE-WFS; state machine → Điều 45; approval → Điều 32; render → Điều 28; birth → Điều 0-G.
  • required contracts: birth (every workflow_def/step gets birth_registry + species) · template (MOW canvas = TPL-mow-hierarchy-canvas) · event (workflow.* register-before-emit) · governance (governance_registry factory row + produces edges) · DOT/API (DOT pair + APR for graph changes via workflow_change_requests).
  • health gates: DOT-ORPHAN-SCANNER (orphan workflows), DOT-template-coverage, HC-REG.

MOT — IU-backed Task Envelope factory (output_target = user)

  • purpose: materialize JFT task instances from task_template × runtime context.
  • can_create: task_template, task_run, task_checkpoint, task_comment, JFT dashboard product config.
  • can_reference: IU/bundle, executor_class_registry, state_machine_registry, MOIT/MOUT contracts, assignee/deadline/escalation_policy.
  • must_not_own: executor, queue core, state machine core, approval law, IU body.
  • owner law per child: task_template/run → future Điều XX + species SPE-TSK; checkpoints/comments → reuse tasks substrate; state machine → Điều 45; render → Điều 28.
  • required contracts: birth (task_template + task_run species/birth) · template (TPL-mot-task-envelope, TPL-jft-dashboard) · event (task lifecycle events) · governance (factory row + produces) · DOT/API (matrix materialization idempotent (task_template_id, trigger_event_id)).
  • health gates: orphan-task scan; coverage; HC-REG.

MOIT — IU-context-aware Input factory (output_target = system)

  • purpose: define input contracts + staging routes.
  • can_create: input contract (input_form_registry row, CRS-gated), field-group binding, staging input route/config (input_routing_policy), input_submission policy.
  • can_reference: field_registry (CRS), IU (per-field link), task_def/step_def context.
  • must_not_own: canonical business table, Nuxt form code, approval law, event core.
  • owner law per child: form/field registries → future Điều XX + Điều 36 collection birth; staging → MP-D11 (mediation, not SoT); render → Điều 28; canonicalization mutation → Điều 35 DOT + Điều 32.
  • required contracts: birth (registries born under Điều 36) · template (TPL-moit-form) · event (input.* refs-only) · governance (factory row) · DOT/API (gateway + canonicalizer gate MP-D19).
  • health gates: field-leak smoke (allowlist), HC-SCHEMA, direct-rejection-rate metric (MP-D20).

MOUT — IU-backed Output/Reference/Report factory (output_target = user)

  • purpose: define read-only projections/report blocks over PG/Directus state.
  • can_create: output/reference/report contract (output_table_registry row, CRS-gated), read-only projection config, report-block product config.
  • can_reference: dot_function_registry (CRS, OD13 naming), iu_sql_link, IU source.
  • must_not_own: canonical data source, mutable workflow state, Nuxt report code, event core.
  • owner law per child: output/report registries → future Điều XX + Điều 36 birth; DOT functions → Điều 35; render → Điều 28.
  • required contracts: birth (registries born) · template (TPL-mout-block/TPL-mout-table) · event (none required; read-only) · governance (factory row) · DOT/API (DOT function registry, read-only mutating=false).
  • health gates: field-leak smoke, coverage, HC-REG.

Cross-cutting boundary (all four): a Mother owns the binding/shape, never the content (IU body — Điều 38/39), the substrate (queue/event/executor/state — Điều 45), the approval (Điều 32), the birth law (Điều 0-G), or the template lifecycle (Điều 28). This is invariant 4 (no-double-ownership) applied at factory granularity.

§5.2 IU relation to factory outputs

Every factory output that carries narrative references an IU/bundle via render_iu_body(...) (04-… §2.3, MP-D6) and never copies body (invariant 1). Factory outputs that propose IU change route through the generic proposal table → Điều 38/39 author lifecycle → new iu_version (never a direct/staging rewrite of IU body; MP-D18/MP-D19). The factory produces shells and bindings; the IU remains the singleton content SoT.

Sentinel (MP-D25). Each Mother has a governance_registry type='factory' row + output_target + produces edges; each output class appears under exactly one owner law; must_not_own lists are grep-checkable (zero IU-body writes / approval logic / queue inserts in MOW/MOT source; zero canonical-table create in MOIT; zero mutable write in MOUT).

§6. MP-D26 — Điều 37 organization / permission / jurisdiction binding

Rule (binding). Every Mother and every Mother-output is bound to organization/jurisdiction. The same UI pattern exposes different slices by backend permission — staff sees only authorized tasks/processes; department lead sees department scope; super admin sees aggregate/cockpit (not necessarily all raw rows by default). Backend filters before data reaches Nuxt (Điều 33 NT6 Cổng). The AI/Agent Ops Console must not leak prompts/payloads/outputs outside authority (MP-D20 machine-only + Điều 28 field allowlist).

Two-layer binding (resolves D-1):

  • Layer A — Điều 37 (law→agency→entity): each Mother is a factory agency in governance_registry; its outputs are linked by governance_relations (produces/owner) and scoped by law_jurisdiction (Phạm vi = domains + collections the factory is responsible for); enforcement via law_dot_enforcement. This is the governance jurisdiction.
  • Layer B — Directus permission/role + Điều 32 (human org-scope visibility): staff / department-lead / super-admin data visibility is enforced by the Directus role + policy + field allowlist layer (Điều 28 Appendix §4/§6; cf. Điều 38 G8A Directus roles work) gated by Điều 32 approval, backend-filtered before Nuxt. Điều 37 does NOT define these human roles (D-1) — a dedicated human-org-role/permission law is a future need (future Điều XX or amendment), flagged here, not drafted.

§6.1 Jurisdiction matrix (binding)

object type → visible_by → editable_by → approvable_by → governance_owner → escalation_owner. (visible_by/editable_by/approvable_by are Directus-role + Điều 32 constructs, Layer B; governance_owner/escalation_owner are Điều 37 constructs, Layer A.)

Object type visible_by (Layer B) editable_by (Layer B) approvable_by (Điều 32) governance_owner (Đ37 agency) escalation_owner
Workflow def / step role w/ workflow read in scope workflow author role workflow owner / Council MOW factory + future Điều XX workflow owner → Council
Workflow change request proposer + reviewers in scope proposer (draft) reviewer (Điều 32 quorum) MOW factory reviewer chain
Task template template admins in scope template admin template owner MOT factory template owner
Task run assignee + dept-lead in scope assignee (state moves) n/a (state via fn_state_transition_validate) MOT factory dept-lead → workflow owner (escalation_policy)
MOIT input contract form admins in scope form admin form owner MOIT factory form owner
Input submission / staging submitter + dept triage dept triage (route) n/a (canonicalizer gate MP-D19) MOIT factory dept triage → governance
MOUT reference/report read-scope role report admin report owner MOUT factory report owner
Governance Problem ops + affected-scope owners assigned owner suppression/waive needs Điều 32 (high/critical) governance agency (Đ37) severity-based escalation chain
Kaizen suggestion submitter + reviewers reviewer (lifecycle) converted proposal → Điều 32 MOIT/governance reviewer chain
AI/Agent Ops item ops scope only (prompts machine-only) ops admin n/a AI-ops agency ops on-call
DLQ replay request ops scope ops admin Điều 32 mandatory Điều 45 substrate + ops ops on-call
Realtime topic subscribers in scope gateway admin n/a gateway agency ops on-call

Sentinel (MP-D26). Every Mother surface fetches via backend gateway with a permission predicate; no Nuxt visibility logic; Governance Cockpit + AI-Ops respect jurisdiction + field allowlist (prompts/payloads/raw bytes machine-only); each object type has a governance_owner agency row and an escalation_owner. Flag: human-role scoping depends on Directus-role layer + a future org-role law (no existing law owns it).

§7. MP-D27 — Constitutional NT14 execution-traceability gate

Rule (binding). For each major surface/object, the design proves it can become runtime without hidden hand-waving — answering NT14's six questions (data-where / actor / when / threshold / verify-with / on-failure). Columns: requirement → Mother/factory → PG table/registry/view → birth/collection/species → Directus/API exposure → Nuxt template/product → DOT/API mutation path → event/queue → approval gate → health/verify gate → rollback/retire.

(Compact form; full per-column detail lives in the cited sections. "CRS" = candidate-requires-survey gated by G7; "paper" = paper-only.)

Object Mother PG table/registry birth/collection/species Nuxt template (Đ28) DOT/API mutation event/queue approval health/verify rollback
MOW Canvas MOW tier_registry+classification template birth (SPE-TPL) TPL-mow-hierarchy-canvas config INSERT n/a n/a coverage+health retire product
Workflow definition MOW workflow_def (reuse workflows) birth SPE-WKF / collection_registry (rendered in canvas) DOT pair+APR via workflow_change_requests workflow.* Điều 32 DOT-ORPHAN-SCANNER deprecate (QT-006)
Workflow step definition MOW workflow_step_def birth SPE-WFS molecule (canvas node) DOT pair step events via change req orphan scan deprecate
Workflow change request MOW workflow_change_requests [VL] governed (proposal UI) INSERT+review proposal.* Điều 32 quorum review_decision reject
MOT Task Envelope MOT task_run/task_def (paper) birth SPE-TSK TPL-mot-task-envelope matrix materialize task events n/a orphan-task scan cancel state
Task template MOT task_template (paper) birth + species (admin template) DOT+APR n/a template owner coverage deprecate
Task run MOT task_run (paper) runtime birth + trace_id (envelope render) fn_state_transition_validate job_queue ref n/a idempotency (template,trigger) cancel
MOIT Input Contract MOIT input_form_registry (CRS) birth Điều 36 TPL-moit-form DOT-COL-REGISTER+APR n/a form owner HC-SCHEMA+field-leak deprecate
Input submission/staging MOIT input_submission (paper) mediation (NOT SoT) TPL-staging-review gateway→canonicalizer gate input.* refs canonicalizer gate (MP-D19) rejection retained purge per retention
MOUT Reference/Report MOUT output_table_registry/dot_function_registry (CRS) birth Điều 36 TPL-mout-block/-table DOT-COL-REGISTER+APR n/a report owner coverage+HC-REG deprecate
Governance Problem gov governance_problem(+links) (paper) birth + species (governed) TPL-governance-cockpit DOT+APR (suppress/waive) *.resolved to auto-resolve Điều 32 (high/crit) no-closed-without-verified resolve/retire
Kaizen suggestion MOIT/gov input_submission+kaizen_lifecycle_state (paper) mediation TPL-kaizen-inline-widget gateway→route input.* converted→Điều 32 dup-cluster reject/merge
AI/Agent Ops item AI-ops agent_run (CRS/survey) birth + species TPL-agent-ops-console executor invoke agent events n/a heartbeat+evidence (MP-D9) stop/retry
DLQ replay request Đ45+ops dlq_replay_request (paper) governed TPL-dlq-replay replay DOT replay job Điều 32 mandatory idempotency abort
Realtime topic gateway realtime_gateway_topic_registry (paper) birth + species (gateway, no UI) register topic SSE push n/a relevance filter deregister

Sentinel (MP-D27). No row in this matrix has a blank "PG table," "birth," "approval," or "health" cell that is silently hand-waved; CRS/paper status is explicit; every runtime-mutating row names a DOT/API path (never raw psql) and a verify gate. This matrix is the machine-checkable proof that the design can become DDL/config/DOT/verification.

§8. MP-D28 — Assembly-first reuse decision tree for Mother-generated artifacts

Rule (binding). Before creating ANY new artifact, the factory (and the implementer) must walk the decision path. Default = reuse/extend. This is Điều 7 / NT8 ("PG → Directus → nguồn mở → code") + Assembly Gate Q0–Q5 applied to factory outputs.

1. Does an existing PG table/view/registry/template/DOT/event type already cover it?      → reuse
2. Can we extend an existing object by config/registry (column/row/vocab)?                 → extend
3. Can a PG VIEW/projection solve it without a new table?                                  → view
4. Can an adapter / shape-adapter solve it (bounded, SoT-pointback)?                       → adapter
5. Is a survey required first (CRS / tier / governance-ops)?                               → survey, then re-enter
6. Is a new paper-only artifact justified (none of 1–4 fit)?                               → paper-only, declare
7. Is a new runtime artifact approved through birth/collection/template/DOT law?           → DOT+APR + birth, else REFUSE

§8.1 New paper-only artifacts introduced by Rev2–Rev5 (reuse audit)

The full catalogue lives in 06-… §S18 (Rev2–Rev4) and is not re-listed here; this patch annotates it with the cross-law verdict and adds only the Rev5 binding artifacts. Key principle: Rev5 introduces no new tables of its own — it reuses Điều 28/0-G/29/36/37 registries; the only "new" rows are binding records in those existing registries.

Artifact (Rev5 binding) Why existing artifact insufficient Reuse candidate checked Survey? Owner law Duplicate-ownership risk Gate
Mother factory agency rows need each Mother registered as a factory REUSE governance_registry (type='factory') Governance-Ops survey confirms shape Điều 37 none (reuses agency table) DOT+APR
produces/owner relation edges link factory→output classes REUSE governance_relations same Điều 37 none DOT+APR
Per-surface design_templates rows (10 surfaces §3.1) each surface must be a template REUSE design_templates + product registry Candidate-registry survey (form/output) Điều 28 none trg_template_lifecycle
Per-output birth_registry declarations each output must be born REUSE birth_registry + species_collection_map none (law live) Điều 0-G none fn_birth_registry_auto
Jurisdiction bindings (Layer A) scope each output REUSE law_jurisdiction Governance-Ops survey Điều 37 none enforcement link
Human-org-role visibility (Layer B) staff/dept/super-admin slicing EXTEND Directus roles/policies survey + future law future Điều XX (D-1) flagged: no current law owner Directus permission + Đ32

Everything else (workflow_def, task_template, input_submission, governance_problem, etc.) is already catalogued paper-only in 06-… §S18; MP-D28's verdict for each is "reuse existing substrate + birth under Điều 0-G/36 when promoted."

Sentinel (MP-D28). No new runtime table is proposed by Rev5; every binding is a row in an existing law registry; any future factory artifact must show its Q0–Q7 walk before DDL. The one flagged duplicate-ownership risk (human-org-role law) is explicitly assigned to a future macro, not silently absorbed by Điều 37.

§9. MP-D29 — Industrial factory safety gates / no "đẻ rơi" invariant

Rule (binding). For every Mother-generated object the following gates fire in order; failing any gate refuses the object (it never reaches active):

  1. pre-birth validation (fn_birth_gate BEFORE INSERT — declaration complete?)
  2. birth registration (birth_registry row, certified=false)
  3. collection/species/governance assignment (Điều 29 four attributes)
  4. relation registration (entity_relations / governance_relations)
  5. lifecycle state set (born)
  6. template/product registration if UI (Điều 28 design_templates + product)
  7. event registration if event-emitting (event_type_registry)
  8. DOT/API origin recorded (birth_registry.dot_origin + dot_iu_command_run)
  9. audit row (Điều 31)
  10. inspect → certify (PEN/STAMP/GATE → certified=true)
  11. health check pass (HC-REG/HC-SCHEMA/orphan scan) → active
  12. rollback/retire path declared (Điều 30; QT-006)

§9.1 Hard invariants

  • MOW/MOT/MOIT/MOUT cannot create "anonymous" objects — every object has entity_code + species_code + collection_name.
  • No object becomes active without birth + collection/species + owner law.
  • No UI product becomes active without Điều 28 template lifecycle (draft→testing→active, 8-key checklist, 5/5 tests).
  • No runtime event emits without event_type_registry (register-before-emit).
  • No queue job exists without executor_class_registry + retry/idempotency policy.
  • No mutable change bypasses Điều 32 / DOT where required.
  • No object enters production as UNKNOWN (no NULL species/collection/governance_role at active).

§9.2 Factory rejects list (the object is refused if it is missing …)

missing owner law · missing species (species_code NULL) · missing collection (no collection_registry entry → HC-REG CRITICAL) · missing template (UI surface not in design_templates) · missing event type (emitter not in event_type_registry) · missing permission scope (no jurisdiction/Directus scope) · missing health check (no scanner coverage) · missing rollback (no retire path) · missing traceability (cannot fill the MP-D27 row).

Each reject maps to a live detector: orphan → DOT-ORPHAN-SCANNER/DOT-COL-ORPHAN; unregistered table → HC-REG; missing description → HC-SCHEMA; wrong chuồng → DOT-MISCLASS-SCANNER; un-templated UI → DOT-template-coverage; un-certified → birth_registry.certified=false.

Sentinel (MP-D29). The reject list is a standing CI/scanner contract: at no point does a factory output reach active while any reject condition holds. "Đẻ rơi" (orphan/phantom/nhầm chuồng) count target = 0 for the 4 Mothers namespace.

§10. MP-D30 — Agent self-review / double-check gate

Self-review of this patch against MP-D23..MP-D29 acceptance, every law read, the 15 NT, no-double-ownership, no bespoke Nuxt, no unregistered collection/object, no missing birth path, no hidden second SoT, no implementation.

§10.1 PASS/PARTIAL/BLOCKED per MP

MP Status Note
MP-D23 Đ28 template binding PASS 10-surface mapping table bound to design_templates + product + lifecycle + coverage; Appendix testing-state divergence noted.
MP-D24 Đ36 collection/object birth PASS Per-artifact declaration on real law columns; Industrial Birth Contract uses DOT-COL-REGISTER+dot-species-map+APR (not the non-existent DOT-COLLECTION-CREATE); HC-REG/HC-SCHEMA bound.
MP-D25 factories PASS Each Mother = governance_registry type='factory' + can_create/can_reference/must_not_own + owner-law-per-child + contracts + health gates.
MP-D26 Đ37 jurisdiction PARTIAL Layer A (Điều 37 factory/jurisdiction/relations) fully bound. Layer B (human staff/dept/super-admin roles) bound to Directus-role + Điều 32, because Điều 37 does not define human org roles (D-1). A human-org-role/permission law is a flagged future need — exact gap in §10.2.
MP-D27 NT14 traceability PASS 15-row matrix; no hand-waved cells; CRS/paper explicit.
MP-D28 assembly-first tree PASS Q0–Q7 tree; Rev5 adds no new tables (reuse-only); duplicate-ownership risk flagged once (Layer B).
MP-D29 no-đẻ-rơi PASS 12-gate pipeline + 7 hard invariants + 9-item reject list, each mapped to a live detector.
MP-D30 self-review PASS This section.

Overall: PARTIAL (one exact gap, non-blocking).

§10.2 Unresolved concerns / exact gaps

  1. (MP-D26 exact gap) No existing law defines human org roles (staff / trưởng phòng / super admin / chuyên môn / lĩnh vực) and their data-visibility scope. Điều 37 governs law→agency→entity, not people→data. Today this is enforceable only via the Directus role/policy + field-allowlist layer (Layer B) + Điều 32. Recommended: a future macro to draft a human-org-role/permission law (future Điều XX clause or Hiến pháp amendment), then re-bind MP-D26 Layer B to it. Until then, Layer B is an implementation-layer (Directus) concern, not a law-owned one.
  2. (Điều 36 maturity) Điều 36 is DRAFT 30%; collection birth for Mother outputs is sound but the law is not enacted. No enactment here; collections stay paper-only until Điều 36 + APR mature.
  3. (Điều 28 Appendix divergence) Main law lifecycle includes testing; Appendix A (DRAFT) omits it. Implementation must follow the main law's draft→testing→active + 5/5 gate; Appendix to be reconciled when it leaves DRAFT.
  4. (CRS dependency) MOIT/MOUT registries (field_registry/input_form_registry/output_table_registry/dot_function_registry) remain G7-gated; factory birth of these registries cannot proceed past paper until the Candidate Registry Survey returns verified_live.
  5. (ai_tasks/agent_run survey) AI/Agent Ops factory outputs depend on a table whose live existence is unconfirmed (09-… §S23) — Governance Ops Survey resolves.

§10.3 Verdict for GPT/user

Recommend APPROVE this cross-law patch as the document-only baseline, with the one flagged future-law need (human-org-role/permission, §10.2.1) tracked as a separate macro. No re-patch required for MP-D23/24/25/27/28/29/30. MP-D26 is intentionally PARTIAL by law reality, not by omission. No implementation should begin until the IU-substrate readiness gate (iu-4mothers-master-design-rev4-gpt-review Gate A) + the three surveys (Candidate / Tier / Governance-Ops) close.

§11. Law / no-double-ownership matrix per MP (MP-D23..MP-D30)

MP Primary law(s) reused New ownership introduced? No-double-ownership check
MP-D23 Điều 28 (+Appendix A) none UI lifecycle stays Điều 28; Mothers own meaning, not template lifecycle
MP-D24 Điều 0-G / 29 / 36 / 35 / 32 none birth stays Điều 0-G; collection stays Điều 36; classification stays Điều 29
MP-D25 Điều 37 (factory agency) none factory pattern pre-exists in Điều 37; child objects keep their own owner law
MP-D26 Điều 37 (Layer A) + Directus/Điều 32 (Layer B) flagged future human-org-role law Layer A = Điều 37; Layer B = Directus+Đ32 until future law; no overlap asserted
MP-D27 Hiến pháp NT14 none traceability is a gate, not an owner
MP-D28 Điều 7 / NT8 none reuse-first; no new substrate
MP-D29 Điều 0-G / 28 / 36 / 45 / 32 none safety gates are unions of existing law gates
MP-D30 — none self-review only

Future Điều XX (4 Mothers application layer) remains the only new concern referent — unchanged from Rev2 invariant 4. This patch adds one future-law candidate (human-org-role/permission), explicitly separate from Điều XX.

§12. Cross-document anchors (this addendum points back to / is pointed to by)

  • 00-… §3 invariants 34–41 (MP-D23..D30) + §13 sentinels 14–16 + §0/companion list (doc 10 added).
  • 02-… §6.6 (MOW canvas template binding) + §7.9 (four surfaces jurisdiction) + acceptance.
  • 04-… §4.7 (Mothers as governed object factories — can_create/must_not_own) + acceptance A12.
  • 06-… §S18 (paper-artifact catalogue annotated) + §S20.1 (cross-law survey added) + §S24 (MP-D23..D30 readiness).
  • 07-… §16 (Revision 5 patch log) + §1 status + §2 file-touch.
  • 08-… §15 cross-link (staging/Kaizen surfaces = Điều 28 templates; their outputs follow Điều 36/0-G birth).
  • 09-… §4.8 (governance_problem/ops objects bound to birth/collection/species + Điều 37 jurisdiction).
  • 05-… §7 note (any adopted UI/governance/observability OSS tool that renders UI passes Điều 28; any that creates a collection passes Điều 36/0-G birth).

§13. Acceptance for this addendum

A1. MP-D23..MP-D30 all applied (§3–§10). A2. Laws read and cited with exact names: Hiến pháp 15 NT, Điều 7, Điều 28 (+Appendix A), Điều 0-G, birth-procedures, Species Taxonomy, Điều 29, Điều 36, Điều 37, Điều 32/33/35/30/31/38/39/45. A3. Each Mother formalized as governed object factory (§5), mapped onto Điều 37 factory agency. A4. Each Mother-generated object has a birth/collection/species/governance/lifecycle path (§4, §9). A5. Every UI surface bound to Điều 28 template/product lifecycle (§3.1). A6. Every new table/view/registry is paper-only or birth/collection-governed (§4, §8). A7. Điều 37 jurisdiction/permission matrix exists (§6.1), with the human-role divergence (D-1) reported and a future law flagged. A8. NT14 traceability matrix exists (§7). A9. Assembly-first reuse decision tree exists (§8). A10. No "đẻ rơi" invariant explicit (§9), mapped to law terms orphan/phantom/nhầm chuồng. A11. Agent self-review/double-check present (§10): overall PARTIAL with one exact gap. A12. No implementation; no final OSS selection; no law enactment; no schema/collection/template creation; forbidden compliance per header + 07-… §16.

End industrial-birth / cross-law / object-factory addendum (MP-D23..MP-D30).

Back to Knowledge Hub knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/10-industrial-birth-cross-law-addendum.md