06 — Controlled Proof Results

Mutation policy honored: 0 production writes. Live-write rollback proofs were declined by design — the directus/workflow_admin write channel (ssh docker exec psql) was reachable, but (a) default-no-mutation; (b) the forbidden list bars manual INSERT to dot_tools/pivot_definitions and any manual/fake birth; (c) read-only evidence proves the holes more decisively than a write proof — proving detection failure needs catalog diffs, not new objects. Each proof below is satisfied by read-only means or safely blocked with reason.

Proof A — correct-process birth (auto-birth works)

Method: function-body determinism + live coverage diff (read-only), not a live write.

• fn_birth_registry_auto deterministically inserts a birth row on INSERT into any triggered collection (synthetic-code fallback covers null-code rows).
• Live confirmation: every current dot_tools row has a birth row (dot_tools_without_birth = 0); 1,116,379 birth rows across 79 collections track the triggered tables.
• Result: PASS — automatic birth on the correct (DB-row) path is live and works. Not proven by mutation; proven by the universal coverage on triggered tables + the trigger definition.

Proof B — wrong-process unborn/orphan detection (does the system catch it?)

Method: existing live evidence + catalog diff (the mission's sanctioned alternative when creating a bypass object is unsafe/forbidden).

• pivot_definitions: 22/37 rows have no birth row, yet the live orphan metric meta_catalog.CAT-024.orphan_count = 0. → the unborn rows are NOT detected.
• dot_iu_command_catalog: 54 rows, 0 on every axis (trigger/registry/species/meta/birth) → NOT detected by any live mechanism.
• dot_tools: 283 phantom birth rows → phantom condition NOT surfaced (orphan_count measures metadata, =0/140 unrelated).
• Result: FAIL (detection absent) — wrong-process / unregistered objects are not labelled unborn/orphan/illegal by any live, scheduled mechanism.

Proof C — DOT-specific path (dot-pivot-update)

Method: read-only filesystem inspection (ssh) + registry lookup.

/opt/incomex/dot/bin/dot-pivot-update : PRESENT  (root:root, -rwxr-xr-x, 14441 bytes, mtime 2026-06-03 07:19)
sha256 = 3313c057caaf1c72e30465354ee9cff0866e0dc3e7205a2c84c3c849284effc5   (matches prior package record)
dot_tools row for dot-pivot-update    : ABSENT  (only DOT-113/114/307/308 pivot DOTs exist)
birth_registry row                    : ABSENT  (no dot_tools row → no birth)
detected as orphan anywhere            : NO

• Read-only gate simulation (no write): SELECT * FROM fn_pre_birth_check('dot_tools','DOT-310','dot-pivot-update','manual-audit-readonly') → checks 1–4 PASS, check 5 FAIL ("Code DOT-310 đã tồn tại"). Confirms the gate logic evaluates correctly (would catch a duplicate code) — but per doc 02, a FAIL only warns.
• Result: dot-pivot-update is an unregistered filesystem artifact (staged) — currently invisible/unmanaged, not flagged as orphan. Full classification in doc 07.

Proof D — governance onboarding after birth

Method: view definitions + live counts (read-only); a safe born-object test is impossible because (i) the layer is inert and (ii) the model is collection-granular.

• Even a hypothetical newly born governed object would not enter governance_candidate_object/_state (scan_run=0, cursor=0, no birth→candidate worker) and would not appear in v_object_owner_gap unless it were a registered governed collection (the inventory is built from collection_registry, not birth).
• Result: FAIL (onboarding inert + wrong granularity) — no automatic onboarding of a born object; the only live gap signal is the gated-closed 210 collection-ownership gap.

Proof artifacts / hashes

• dot-pivot-update sha256: 3313c057caaf1c72e30465354ee9cff0866e0dc3e7205a2c84c3c849284effc5
• Key read-only SQL is embedded in docs 02–05. No SQL was executed that performed writes; query_pg runs as a read-only role inside a READ ONLY transaction.