R2 — Birth Certify Pipeline / Canonical Stamp Readiness Scope (2026-06-17)
R2 — Birth Certify Pipeline / Canonical Stamp Readiness Scope
Date: 2026-06-17 · Workstream: R2 (first remediation-scoping macro after Phase-1B, run ∥ R1) · Revision: rev1 Class: read-only scoping / runtime-evidence / Owner-decision-prep READ-ONLY · NON-ENACTING · NON-AUTHORIZING · NOT remediation · NOT technical design · NOT implementation · NO blocker resolved.
0. Status and non-authorization
STATUS: PARTIAL (R2 read-only scoping complete on the PostgreSQL substrate; PARTIAL because the root cause of the 2026-03-21 inspection cutover lives in the DOT-runner / cron / log layer outside the read-only query_pg PG-catalog surface and was not inspected, and the live app.birth_gate_mode / app.bypass_birth_gate GUC values remain unreadable through query_pg's safe-param allowlist — same constraint as Phase-1).
This report is the read-only evidence packet for R2 — Birth Certify Pipeline / Canonical Stamp Readiness, run in parallel with R1 under the Owner-gated opening of the R1∥R2 read-only scoping (OD-3 parallel option; OD-6 "authorize R2's read-only diagnostic of the stalled birth-certify pipeline — verify, do not restart"). It is the verify-only diagnostic OD-6 describes. It does not restart the pipeline, does not resolve any blocker, and does not authorize write-enabled remediation.
Non-authorization (explicit). This report does not, and cannot: run any write query / DDL / DML; patch runtime; patch any source law, amendment, rewrite, note, or any prior report; create a current corpus; adopt or enact any draft; resolve any blocker; write full technical design; create schema/table/registry/index; set inspect_pen/inspect_stamp/inspect_gate; set certified=true; trigger birth/certify/promote/repair; materialize BIRTH_STAMP/PROMOTE_STAMP / cell_id / dot_role / canonical_fields; change authority order (CONS-004); change the v0.1 baseline; promote v0.2-hardening. Engineering verification ≠ Authority approval. A GPT/Codex PASS is not an Owner authorization to remediate. Every blocker remains OPEN.
1. Sources read
| # | Source | Status |
|---|---|---|
| 1 | consolidation/phase1b-runtime-truth-blocker-decision-packet-2026-06-17.md (rev1) |
READ |
| 2 | reports/phase1b-runtime-truth-blocker-decision-execution-report-2026-06-17.md (rev1) |
READ |
| 3 | reports/phase1-readonly-runtime-blocker-verification-2026-06-17.md (rev1) |
READ |
| 4 | notes/dieu4-birth-process-compatibility-note.md (rev1) |
READ |
| 5 | amendments/l4-birth-gate-extension-amendment-draft.md (rev1, DRAFT) |
READ |
| 6 | amendments/dieu38-normative-document-law-v3-amendment-draft.md (rev1, DRAFT) |
READ |
| 7 | architecture/birth-registry-law.md (Điều 0-G v1.0, S157, dated 2026-03-21) |
READ |
| 8 | laws/law-04-birth-process.md (rev5, ENACTED) |
READ |
| 9 | LAW_READING_INDEX.md (rev2), pointer-layer, Đ32/Đ35 notes + laws, ssot/operating-rules.md |
READ |
No required R2 source was unreadable.
Baseline expectation carried in (Phase-1B), for R2: births live; certification stalled; inspect stamps absent after 2026-03-21; fn_birth_auto_certify exists; named stamps absent; birth-dependent TD blocked. Control caveat C-2: the stalled birth-certify pipeline is HIGH for birth-dependent / canonical-dependent technical design and MEDIUM for non-birth scopes. Reading rule (Đ4 note / pointer-layer): birth grants identity-root, not canonical status — certified=false ⇒ TEMP_ID/F1; canonical = output at promote (F4); fn_description_birth_guard is a TEMP-stage completeness stamp, not the canonical-birth gate.
2. Runtime command ledger
All commands against database directus via read-only query_pg (AST-validated, READ ONLY txn, role context_pack_readonly, statement_timeout 5s, LIMIT 500). Session anchor 2026-06-17 14:03:41 UTC.
| ID | Query (abbrev.) | Read-only? | Exit | Used for |
|---|---|---|---|---|
| L2 | information_schema.columns incl. birth_registry |
yes | success | §3 |
| L9 | dot_tools column inventory |
yes | success | §6 |
| L14 | birth_registry GROUP BY certified — n, min/max born_at, inspect_* set counts, certified_at set count |
yes | success (2 rows) | §4, §5 |
| L15 | pg_proc WHERE proname LIKE 'fn_birth%' / certify / inspect / fn_iu_enact / fn_description_birth_guard |
yes | success (12 rows) | §6 |
| L16 | pg_trigger⋈pg_class count: birth (enabled/disabled), certify, inspect |
yes | success (1 row) | §6 |
| L17 | pg_trigger⋈pg_class WHERE name auto_certify/inspect |
yes | success (1 row) | §5, §6 |
| L18 | dot_tools WHERE code/name inspect/certif/birth |
yes | success (7 rows) | §5, §6 |
| L19 | birth_registry WHERE certified=true: min/max certified_at, distinct cert-days |
yes | success (1 row) | §7 |
| L20 | pg_proc WHERE prosrc ILIKE '%inspect_pen%' OR '%inspect_stamp%' OR '%inspect_gate%' |
yes | success (1 row) | §5, §7 |
No write, DDL, DML, certify/inspect/promote call was made or prepared.
3. birth_registry inventory
birth_registry columns (L2): id, sort, user_created, date_created, user_updated, date_updated, entity_code, collection_name, species_code, composition_level, dot_origin, born_at, governance_role, inspect_pen (timestamptz), inspect_stamp (timestamptz), inspect_gate (timestamptz), certified (boolean), certified_at (timestamptz), status (varchar), canonical_address (text), owner (text), jsonb_profile (jsonb).
The three inspection columns inspect_pen / inspect_stamp / inspect_gate are timestamps (the PEN→STAMP→GATE certification chain of Đ0-G). New since Phase-1's reported set: status, canonical_address, owner, jsonb_profile — relevant to any future canonical-stamp mapping; currently not used by the certification path.
4. certified vs uncertified breakdown
birth_registry GROUP BY certified (L14):
| certified | rows | first born_at |
last born_at |
pen set | stamp set | gate set | certified_at set |
|---|---|---|---|---|---|---|---|
| false | 1,211,557 | 2026-03-21 23:15 | 2026-06-17 13:30 (today) | 0 | 0 | 0 | 0 |
| true | 1,402 | 2026-02-17 00:22 | 2026-03-21 06:29 | 1,402 | 1,402 | 1,402 | 1,402 |
Total = 1,212,959; certified = 0.1156%. Every certified row has all three inspect stamps + certified_at; every uncertified row has none. The uncertified backlog has grown by ~8 since the Phase-1 morning run (Phase-1 reported 1,211,549) — direct evidence that births continue to fire live while certification does not follow. The certified set's born_at ceiling (2026-03-21 06:29) sits below the uncertified set's born_at floor (2026-03-21 23:15): a clean cutover on 2026-03-21 with no overlap.
5. inspect_pen / inspect_stamp / inspect_gate pipeline
Who sets the inspect columns? pg_proc source search for inspect_pen/inspect_stamp/inspect_gate (L20) returns exactly one function — fn_birth_auto_certify — and that function reads them (the trigger that flips certified=true, certified_at=now() once all three are present). No function and no trigger in the database writes inspect_pen/inspect_stamp/inspect_gate. Trigger census (L16): inspect-named triggers = 0; certify-named triggers = 1 (trg_birth_auto_certify on birth_registry, ENABLED — L17).
Inspector DOTs (L18): DOT-TAC-BIRTH-GATE (data_quality, trigger_type=event) and DOT-TAC-BIRTH-VERIFY (data_quality, trigger_type=cron, cron_schedule='0 6 * * *') are registered but never executed (last_executed=NULL, coverage_status='partial'). Also present and never-run: DOT_BIRTH_BACKFILL, DOT_BIRTH_TRIGGER_SETUP, DOT_SCHEMA_BIRTH_REGISTRY_ENSURE.
Conclusion. The certification chain is half-built: the consumer (trg_birth_auto_certify) is live and atomic per row, but the producer — whatever set inspect_pen/stamp/gate for the 1,402 certified rows on 2026-03-21 — has no live PostgreSQL implementation (no setter function, no setter trigger) and the registered inspector DOTs have never run. The pipeline is starved at the inspection stage. (Answering R2 Q4: inspector DOTs are present but not wired/never executed; the inspection logic is missing from the live PG layer.)
6. birth functions / triggers inventory
Functions (L15, 12 in public): fn_birth_auto_certify, fn_birth_change_flag_matrix, fn_birth_gate, fn_birth_onboarding_full_scan, fn_birth_onboarding_full_scan_hc, fn_birth_policy_decision, fn_birth_register, fn_birth_registry_auto, fn_birth_registry_auto_id, fn_birth_resolve_identity, fn_description_birth_guard, fn_iu_enact. No inspector/certify-producer function (no fn_birth_inspect_*, no fn_certify_*).
Triggers (L16): birth-named = 192 (191 enabled, 1 disabled); certify-named = 1 (trg_birth_auto_certify, enabled); inspect-named = 0. The 192 birth triggers across ~150+ tables are the auto-birth_registry INSERT fabric (fn_birth_registry_auto family + legacy birth_trigger_*) — they keep minting uncertified births live.
Per the carried Phase-1 analysis (function bodies not re-read here; relied on catalog + Phase-1): fn_birth_register(... p_dry_run boolean DEFAULT true ...) is dry-run by default with a live INSERT ... ON CONFLICT DO NOTHING writing certified=false; fn_birth_gate carries a current_setting('app.birth_gate_mode')-default-'warning' mode + an app.bypass_birth_gate kill-switch (warn-mode / fail-open by default; live GUC value unreadable via query_pg). fn_iu_enact is an atomic, fail-closed, post-write-verified promote for the IU lineage (HOLD-2 PARTIAL) — distinct from the birth-certify path.
7. certification stall analysis
birth_registry certified-set certified_at window (L19): first certified_at = 2026-03-21 06:00:38, last certified_at = 2026-03-21 08:00:36, distinct certification days = 1.
Finding (sharper than the carried baseline). Certification was not a continuously-running pipeline that gradually "stalled" — it was a single ~2-hour batch on 2026-03-21 (06:00–08:00 UTC) that certified all 1,402 rows and then never ran again (before or since). 2026-03-21 is also the date Đ0-G v1.0 (birth-registry-law) was written — i.e. the inspection batch coincided with the law's authoring day and appears to have been a one-shot bring-up event, not a steady-state process. Since then the live system has minted 1,211,557 uncertified births (to 2026-06-17 13:30) with zero inspection.
Why it stopped is not determinable from the PG catalog. No setter function/trigger exists to have "broken," and the inspector DOTs never registered an execution. The root cause lives in the DOT-runner / cron / external-process / log layer (e.g. whether DOT-TAC-BIRTH-VERIFY's 0 6 * * * cron was ever wired to a live runner, or the 2026-03-21 run was manual). That layer was not inspected (read-only-but-out-of-scope here) → STATUS PARTIAL; flagged as the next read-only step (§12, R2-OD-a).
8. Mapping live fields to BIRTH_STAMP / PROMOTE_STAMP concepts
The F4 vocabulary tokens BIRTH_STAMP / PROMOTE_STAMP / OWNER_STAMP / GOV_STAMP do not exist as DB artifacts (no such columns/tokens; consistent with Phase-1 §8.3). They are conceptual targets, not real artifacts. The live mechanisms that the concepts must map onto:
| F4 concept | Live birth mechanism | Live IU-lineage mechanism |
|---|---|---|
| TEMP_ID / workspace (F1) | birth_registry row with certified=false at INSERT |
information_unit pre-enact lifecycle_status |
| inspection / completeness | inspect_pen → inspect_stamp → inspect_gate (timestamps) — producer absent |
fn_iu_verify_invariants (fail-closed checker inside fn_iu_enact) |
| BIRTH_STAMP / canonical-at-promote | certified=true + certified_at (set atomically by trg_birth_auto_certify) |
unit_version.enacted_at + iu_lifecycle_log (set atomically by fn_iu_enact) |
| PROMOTE_STAMP / atomic promote (HOLD-2) | no atomic end-to-end birth-certify promote (inspection starved) | fn_iu_enact — atomic + fail-closed + post-write-verified (contradicts "no real transaction"); HOLD-2 PARTIAL |
| canonical_address / owner | birth_registry.canonical_address / owner columns exist but unused |
information_unit.canonical_address |
Reading. There is a real atomic promote — but only for the IU lineage (fn_iu_enact), not for birth-certify. The birth-certify "promote" (trg_birth_auto_certify) is atomic per-row yet inert because its inspection input never arrives. Defining the BIRTH_STAMP/PROMOTE_STAMP ↔ certified/certified_at/inspect_* mapping is a design-direction question that remains gated; no mapping/stamp design is written here.
9. Birth-dependent TD gate
Per C-2, the stalled birth-certify pipeline is HIGH for any birth-dependent / canonical-dependent technical design (1,211,557 uncertified births, 0 inspection): designs that assume certified births, BIRTH_STAMP/PROMOTE_STAMP, or canonical-at-promote (F4) are unsafe until the pipeline is verified/restarted under an Owner gate. It is MEDIUM for non-birth scopes (it does not, by itself, gate scopes that never touch certified-birth status). Birth-dependent / canonical-dependent technical design is therefore BLOCKED. The L4 birth-gate-extension and Đ38 v3.0 amendments remain DRAFT / PENDING_OWNER and explicitly defer BIRTH_STAMP/PROMOTE_STAMP / cell_id / canonical_fields materialization while CONS-003/CELL are open.
10. Findings
| ID | Severity | Summary | Blocks TD? | Blocks impl? |
|---|---|---|---|---|
| R2-F1 | HIGH (birth-dependent; MEDIUM non-birth, per C-2) | 1,211,557 uncertified births (99.88%), 0 inspect stamps, vs 1,402 certified → birth-certify pipeline not running (= PH1-F3) | Yes (birth-dependent) | Yes |
| R2-F2 | HIGH | Certification was a single 2026-03-21 06:00–08:00 batch (1 distinct cert-day); never recurred — a one-shot bring-up, not a steady-state pipeline | Yes | Yes |
| R2-F3 | HIGH | Inspection stage has no live PG producer — no function/trigger sets inspect_pen/stamp/gate (only fn_birth_auto_certify reads them; inspect_trg=0); inspector DOTs DOT-TAC-BIRTH-VERIFY/-GATE registered but never executed; auto-certify trigger enabled but starved |
Yes | Yes |
| R2-F4 | HIGH | Births fire live to today (2026-06-17 13:30) via 192 birth triggers (191 enabled) defaulting certified=false → backlog grows continuously (+~8 since Phase-1 this morning) |
Yes | Yes |
| R2-F5 | MEDIUM/INFO | BIRTH_STAMP/PROMOTE_STAMP are conceptual targets, not artifacts; live = certified/certified_at/inspect_* (birth) + enacted_at/iu_lifecycle_log (IU); fn_iu_enact is a real atomic promote for IU only (HOLD-2 PARTIAL) |
Yes (mapping gap) | Yes |
| R2-F6 | INFO | birth_registry now carries status, canonical_address, owner, jsonb_profile (schema extended beyond Phase-1's set); currently unused by certification — relevant to future canonical-stamp mapping |
No | No |
No finding marked resolved.
Explicit R2 answers (baseline vs live):
- Are births still being created? Yes — last birth 2026-06-17 13:30, today; 192 birth triggers (191 enabled).
- Is certification running? No — last
certified_at2026-03-21 08:00; nothing since. - Which stage is stalled? The inspection stage (
inspect_pen/stamp/gateproducers) — no live PG setter; inspector DOTs never ran. The downstream auto-certify trigger is healthy but starved. - Are inspect stamps ever set after 2026-03-21? No — 0 of 1,211,557 uncertified rows.
- Is there an atomic certify path? For birth-certify: per-row atomic via
trg_birth_auto_certify, but no end-to-end pipeline runs (inspection absent). For the IU lineage: yes —fn_iu_enactis atomic + fail-closed + post-write-verified (HOLD-2 PARTIAL). - Are BIRTH_STAMP/PROMOTE_STAMP real artifacts or conceptual targets? Conceptual targets — no such columns/tokens exist.
- Can birth-dependent TD proceed? No — HIGH-blocked until the pipeline is verified/restarted (Owner-gated) and CONS-003/CELL resolved.
(All match the Phase-1B baseline; R2-F2/F3 sharpen the stall diagnosis.)
11. What remains blocked
Every blocker stays OPEN: HOLD-2 birth/stamp path PARTIAL (named stamps absent; birth-certify stalled), PH1-F3 HIGH (birth-dependent). Birth-dependent / canonical-dependent technical design is GATED. Forbidden until the Owner opens a write-enabled R2 workstream: birth writes; certify execution; setting inspect_pen/stamp/gate; setting certified=true; BIRTH_STAMP/PROMOTE_STAMP materialization; Đ0-G schema change; atomic-promote (re)build; triggering birth/certify/promote/repair. CONS-002/003 + CELL-003/004/007 remain prerequisites to any R2 materialization. Note also the Đ0-G source-recovery caveat (Đ0-G lives in architecture/ as a temporary working source; its Constitution reference law-00g-birth.md is broken) — birth technical design is additionally gated on Owner source-recovery.
12. Owner decisions required
- OD-6 (carried): this run is the read-only verify-only diagnostic OD-6 authorizes (verify, do not restart). The Owner confirms acceptance and decides whether to open R2 as a write-enabled remediation workstream (restart/repair certify) or keep it read-only.
- R2-OD-a (new, read-only next step): authorize a follow-on read-only root-cause inspection of the inspection-stage producer — DOT-runner / cron wiring for
DOT-TAC-BIRTH-VERIFY(0 6 * * *) andDOT-TAC-BIRTH-GATE, docker/runner logs,dot/specs— to determine why the 2026-03-21 batch never recurred (was it manual? a decommissioned external process? an unwired cron?). Still read-only; separately gated; no restart. - R2-OD-b (new, design-direction-gated): decide the
BIRTH_STAMP/PROMOTE_STAMP↔certified/certified_at/inspect_*(+canonical_address/owner) mapping direction, to be designed (not built) only after the package opens; clarify whether birth-certify should reuse thefn_iu_enactatomic/fail-closed pattern. - OD-8 (carried): confirm CONS-002/003 + CELL-003/004/007 resolution remains a prerequisite to any R2 materialization; resolve the Đ0-G source-recovery item before birth TD.
Restart / repair of the certify pipeline = a later, separate, write-enabled workstream. Engineering/Codex PASS ≠ Owner authorization.
13. Next recommended action
- GPT reviews this R2 scoping report (alongside R1 and the combined execution report).
- If accepted, Codex adversarial control review.
- Owner decides OD-6 / OD-8 + R2-OD-a/b: open write-enabled R2, keep read-only (and, if so, authorize R2-OD-a's read-only runner/log root-cause study), or sequence R2 relative to R1.
Default disposition: HOLD. PARTIAL ≠ Owner authorization; no blocker resolved; no birth/certify execution; no stamp materialization; TD remains gated.