KB-1A56

Birth Embedded Check — Điều 0 / 0-B / 0-G vs TEMP_ID / BIRTH_STAMP / Canonical-at-Promote (2026-06-17, PARTIAL, read-only)

10 min read Revision 1
laws-newnewlawsreportbirthdieu0dieu0bdieu0gtemp-idbirth-stampcanonical-at-promotepartialread-onlynon-authorizing2026-06-17

Birth Embedded Check — Điều 0 / 0-B / 0-G

Goal C of Law Revision Workstream A. READ-ONLY · NON-AUTHORIZING. 2026-06-17, rev1. STATUS: PARTIAL. Reason: the task asked to read Điều 0 / 0-B / 0-G as embedded in the Constitution, but they are not embedded there. The Constitution only references them (via files that are absent from laws/). The operative texts were located in knowledge/dev/architecture/ and read in full; answers below are grounded in those texts, with the location caveat carried throughout. The Điều 4 disposition is kept conservative (KEEP+NOTE), as instructed.

0. Source-location finding (why PARTIAL)

  • knowledge/dev/laws/constitution.md (v4.6.3, rev44) does NOT embed the Đ0/0-B/0-G article text. Its MỤC LỤC references law-00-entity.md (Đ0), law-00b-composition.md (Đ0-B), law-00g-birth.md (Đ0-G).
  • Those three files are ABSENT from knowledge/dev/laws/ (a list_documents on knowledge/dev/laws/law-00 returns only law-00h-5layer-sync.md).
  • The operative texts were found in knowledge/dev/architecture/, which knowledge/dev/laws/existing-law-references.md designates as the "detailed reference" home of foundational laws:
    • Điều 0 = architecture/information-atom-law.md — "Luật Thực thể Được Quản trị" v2.0 (S111), rev18, len 17712.
    • Điều 0-B = architecture/composition-level-law.md — "Luật Phân tầng Cấu tạo Vật chất Thông tin" v3.1 (S111), rev22, len 12146.
    • Điều 0-G = architecture/birth-registry-law.md — "Luật Khai Sinh — Birth Registry Law" v1.0 (S157), rev2, len 11681.
  • Recommendation: an Owner-gated source-recovery pass should (a) confirm whether the architecture/ versions are the authoritative current texts, (b) reconcile the Constitution's broken law-00*.md references, and (c) feed CONS-003 resolution (rooted in Đ0-B + species-taxonomy).

1. What does Điều 0 say? (paraphrase; source = architecture/information-atom-law.md)

Điều 0 = the identity / recognition law ("Luật NHẬN DIỆN"). A managed entity = (1) unique ID PREFIX-NNN, never reused; (2) registered in a queryable registry; (3) carries minimum metadata (name, description, classification, status, owner); (4) obeys the 8 relation rules; (5) has a "Lớp 3" page. meta_catalog = the periodic table of entity types. Conservation principles: ID never reused, relations don't self-destruct (deprecate→migrate→retire), metadata only grows, registry never shrinks. Lifecycle = draft→active→deprecated→retired, with approval gates (Agent creates draft; Supervisor approves active). It uses no TEMP_ID / BIRTH_STAMP / canonical-birth terminology.

2. What does Điều 0-B say? (paraphrase; source = architecture/composition-level-law.md)

Điều 0-B = the composition / layering law. Two meta_catalog fields: identity_class (managed / native / sub-atomic — the Đ0 axis) and composition_level (6 Lớp: atom, molecule, compound, material, product, building — the Đ0-B axis). Three management classes (Managed Entity / Native-managed Resource / Sub-atomic Artifact). Tier changes are "CHỈ NÂNG, KHÔNG HẠ" (upgrade-only). 4-layer enforcement (DB CHECK / DOT flag / Directus validation / CI guard). Important for CONS-003: Đ0-B defines 6 Lớp of composition; the "7 dimensions" of the Registries view = those 6 Lớp plus species as a meta-layer (per architecture/species-taxonomy-complete.md). This 6-vs-7 framing is the root of CONS-003.

3. What does Điều 0-G say? (paraphrase; source = architecture/birth-registry-law.md)

Điều 0-G = the Birth Registry law. Every INSERT into a governed collection fires a PG trigger (fn_birth_registry_auto) that auto-inserts a birth_registry record with born_at = now(), certified = false, ON CONFLICT (entity_code) DO NOTHING. Certification is a separate, later, asynchronous pipeline: DOT Inspector PEN (code/origin/species present?) → DOT Inspector STAMP (name/description/status present?) → DOT Inspector GATE (valid species / business rules?) → an AFTER-UPDATE auto-certify trigger sets certified = true, certified_at = now() only when all inspect_* are non-null. It also provides the universal counter, orphan/phantom detection, and cleanup. (Schema is documentary v1.0; runtime catalog is the real source of truth.)

4. Does Điều 0-G conflict with TEMP_ID-at-birth?

No. The birth_registry record created at INSERT is uncertified (certified=false). That "born but not yet certified" state maps cleanly to the new model's TEMP_ID / workspace stage (F1). Caveat (a vocabulary mapping, not a conflict): the id assigned at birth is the permanent PREFIX-NNN identity-root (Đ0/Đ2 say ID is never reused), so "TEMP_ID" here denotes the uncertified stage, not a throwaway id value. A note must state the mapping: {PREFIX-NNN + certified=false} = identity-root at the TEMP stage; the certified flag is the later gate.

5. Does Điều 0-G conflict with BIRTH_STAMP-at-promote?

No — it supports it. certified=true / certified_at is reached only after PEN+STAMP+GATE pass — a post-INSERT, separately-gated event. That maps to BIRTH_STAMP / PROMOTE_STAMP at promote (F4 output): the certificate exists at birth but is stamped certified later. The difference to flag is mechanism, not shape: Đ0-G certifies via asynchronous DOT inspectors (eventual), whereas the new model requires an atomic, fail-closed promote checker + Owner gate (Mức 3 / Đ32) for canonical/kernel/enacted entities — and the atomic promote transaction does not yet exist (HOLD-2).

6. Does Điều 0-G force canonical birth at INSERT?

No — the opposite. The record is explicitly certified=false at INSERT and becomes certified only after the inspector pipeline passes and auto-certify fires. Canonical/certified status is therefore not at INSERT. The naive reading "a birth_registry INSERT = canonical birth now" is rejected by the law's own pipeline. (This directly refutes the listed bad reading "Birth registry insert means canonical birth now.")

7. Is Điều 4 KEEP+NOTE still enough, or should Birth move to AMEND?

KEEP+NOTE is still enough; Birth need not move to AMEND on the strength of Đ0-G / Đ4. Reasoning: Đ0-G already encodes the birth(uncertified) → certify(later) split the new model needs, and it does not force canonical-at-INSERT; Đ4's fn_description_birth_guard is a BEFORE-INSERT completeness gate (completeness ≠ canonical), i.e. a TEMP-stage stamp. A compatibility note that supplies the lifecycle split is sufficient — no clause edit to Đ4 or Đ0-G is required. The genuine AMEND pressure lives elsewhere: L4 — Birth Gate Extension (catalog record #5, AMEND) front-loads completeness + reuse-decision + human-approval at INSERT (that does conflict with canonical-at-promote), and Điều 38 v3.0 (record #6, AMEND) carries "DOT 100% auto-fix" / auto-output-regen. Keep Điều 4 conservative = KEEP+NOTE (consistent with the catalog).

The following is a draft recommendation only (not enacted; the actual note is written later under Owner gate, in newlaws/):

"Birth (Điều 4 + Điều 0-G) issues an identity-root at INSERT and an uncertified birth_registry record (certified=false); it does not confer canonical status at INSERT. Canonical/certified status is a later, separately-gated event. The new model maps {PREFIX-NNN + certified=false at INSERT}TEMP_ID / workspace stage (F1) and {certified=true / certified_at}canonical birth output at promote (F4). Điều 0-G's asynchronous DOT-inspector certification (PEN→STAMP→GATE→auto-certify) is the documentary ancestor of the F4 promote checker; under the new model, certification of canonical / kernel / enacted entities must pass the fail-closed promote checker + Owner gate (Mức 3 / Đ32), not async auto-certify alone. No clause forces canonical-at-INSERT, therefore Điều 4 = KEEP+NOTE (no amendment); the AMEND targets are L4 (relocate INSERT-time completeness/reuse/approval to the promote checker) and Điều 38 v3.0."

This wording is mirrored in notes/dieu4-birth-process-compatibility-note.md §3.

9. Held blockers touching Birth (carried, not resolved)

  • HOLD-2 — atomic promote transaction does not exist; blocks the canonical / BIRTH_STAMP write at promote.
  • RISK-BYPASSfn_birth_gate (Đ35-scope) warn-mode + kill-switch co-resides with fn_description_birth_guard; live fn_auto_approve_add bypass (160 unvoted) at the governance layer.
  • CONS-003 — 6 Lớp (Đ0-B) vs 7-dimension Registries view; blocks cell_id.
  • CELL-003 / 004 / 007 — birth CELL (layer × species × store × domain) unmaterialized = the only canonical matrix.
  • Source-location — Đ0/0-B/0-G in architecture/, not laws/; Constitution law-00*.md references broken.

10. What was NOT done

No guessing beyond the located source texts. No live DB/runtime query, no Phase-1, no schema/registry inspection, no canonical-birth materialization, no amendment/rewrite, no technical design, no resolution of CONS/CELL/HOLD/RISK. The PARTIAL verdict stands on the source-location finding; a source-recovery pass is recommended before any birth-related technical design.

Birth embedded check rev1 | 2026-06-17 | PARTIAL | read-only · non-authorizing | Đ0-G insert = uncertified, not canonical · Đ4 stays KEEP+NOTE

Back to Knowledge Hub knowledge/dev/laws-new/newlaws/reports/birth-embedded-dieu0-dieu0b-dieu0g-check-2026-06-17.md