Incomex AI Portal
KB-418E

F1 Birth / Identity Root + Registries / Matrix Classification — Reuse Survey Packet (read-only, non-authorizing)

18 min read Revision 1
laws-newmatrix-assemblystamp-governancef1birth-identityregistriesmatrix-classificationreuse-firstreuse-surveyprogram-packageread-onlynon-authorizingdraftnot-enacted2026-06-16

F1 — Birth / Identity Root + Registries / Matrix Classification — Reuse Survey Packet

Ngày: 2026-06-16 · Soạn: Claude Code CLI (read-only AgentData KB) · Track: knowledge/dev/laws-new/ Control basis: technical-slice-framework.md rev56 §6c. Evidence basis: F0 execution report rev1 + f0-owner-decision-record-2026-06-16.md. Layer: F1 — Birth / Identity Root + Registries / Matrix Classification (one layer above F0 in the §6c build/dependency order; sits below F2).

1. Status / non-authorization banner

STATUS: PREPARATION PACKET — NON-AUTHORIZING. This is a read-only program package that prepares the F1 layer. It is not an F1 execution, not a Phase-1 survey, not an implementation authorization. It performs no live DB / runtime query, mutates nothing, creates no schema/table/registry, and writes no canonical birth. It is structured around the same 3 reuse-first Owner questions as F0 and is intended for GPT → Codex → Owner review before any F1 read-only execution is authorized.

Boundary invariants (carried from rev56 + F0 decision record):

  • F1 ≠ canonical birth write. "Birth" at F1 = minimal identity root (e.g. TEMP_ID / candidate identity). Canonical birth is OUTPUT at the promote boundary → F4, never F1.
  • No governance stuffing into birth P0 (rev56 §6c, D2, hostile ca 23). Birth P0 = minimal identity only.
  • No registry / table / schema / index creation by default. Any such change is Owner-gated detailed design, out of this packet.
  • Documentary ≠ live proof · Prior-session ≠ current proof · Engineering PASS ≠ Authority PASS · Reuse-now ≠ live-proven.

2. Owner View — 3 câu hỏi reuse-first

Đọc riêng mục này là đủ để Owner/GPT thấy F1 định khảo sát cái gì để dùng lại — chưa làm gì cả. Chi tiết kỹ thuật ở §4–§11. Mục này không ủy quyền bất cứ điều gì.

Q1 — Cái gì đang có và (giả thuyết) dùng lại được ngay? (reuse-now — documentary candidates)

Tất cả mục dưới là ứng viên documentary (framework rev56 §4), chưa live-proven. F1 execution phải pin bằng chứng cho từng dòng; nếu bằng chứng yếu thì rớt xuống Q2.

  • birth_registry — ứng viên documentary cho identity/birth substrate (KHÔNG live-proven). [GR] ~1.21M rows, 22 cột, cols inspect_pen/stamp/gate + certified.
  • fn_birth_register / fn_birth_gate — ứng viên documentary (gated). fn_birth_register dry_run-default; fn_birth_gate mode=warning + kill-switch.
  • meta_catalog / collection_registry — ứng viên registry/classification (nguồn "Tầng" và "Kho" cho cell_id). [GR] ~169 / ~168 rows.
  • dot_tools — chỉ ứng viên documentary classification/DOT (KHÔNG patch schema). [GR] ~309 rows; báo cáo chưa có cột dot_role/cell_id.
  • universal_edges — ứng viên relationship/graph (KHÔNG phải chiều ma trận). [GR] ~2,199 rows.
  • Khái niệm cell_id sẵn có từ framework/de-bai (tầng × loài × kho × miền, mô hình thuộc tính khái niệm, read-only).
  • F0 frozen source baseline (12 nguồn đã pin rev+length+sha256, đã được Owner chấp nhận tại decision record).

Q2 — Cái gì đang có nhưng cần sửa / kiểm chứng mới dùng lại được? (repair / verify-before-reuse)

  • birth_registry live schema / row / cách dùng CHƯA được chứng minh — chỉ documentary; cần Phase-1 read-only verify (Owner-gated), không query ở packet này.
  • birth_gate warning/bypass risk — mode=warning ("đếm được, chưa chặn được") + kill-switch app.bypass_birth_gate = bề mặt BYPASS (RISK-BYPASS). Phải kiểm soát + audit trước khi tin dùng.
  • Phân biệt TEMP_ID (kho tạm) vs BIRTH_STAMP (tại promote) — phải giữ rõ; F1 chỉ chạm TEMP_ID/candidate identity, không đóng BIRTH_STAMP.
  • cell_id chưa hiện thực hóa vật lý — là mô hình thuộc tính khái niệm; chưa là cột/metadata trên bảng nào (CELL-003/004/007 chưa resolve).
  • CONS-003 (6-vs-7 tầng) — xung đột cấu tạo (drafts 6 tầng vs constitution rev44 / skill 7 composition levels). CONFLICT, Owner-gated; chặn survey cell.
  • dot_tools thiếu cột dot_role/cell_id — gắn thêm = schema change, out-of-frame, Owner-gated; KHÔNG làm ở F1.
  • Checkout / runtime sync vẫn chưa được chứng minh (CONS-005 caveat) — baseline chỉ phủ KB; không suy ra runtime hiện trạng.
  • Governance KHÔNG được nhồi vào birth P0 — birth P0 = minimal identity; governance/canonical-birth ở biên promote (D9/D10).

Q3 — Cái gì thật sự phải làm thêm (chỉ khi reuse không đủ)? (add-later — future Owner-gated)

  • Detailed F1 execution report (sau khi packet này được duyệt + F1 read-only execution được ủy quyền).
  • Possible cell_id mapping design — thiết kế mapping nhẹ (không ontology), future Owner-gated, chỉ sau khi chứng minh reuse không đủ.
  • Possible birth identity wrapper — wrapper nhẹ quanh substrate hiện có, future Owner-gated.
  • Possible metadata/schema changes — chỉ sau khi có bằng chứng reuse-insufficiency; mặc định KHÔNG.
  • No new birth registry / matrix registry by default — không tạo sổ mới.
  • No canonical birth write in F1 — canonical birth là output tại promote (F4), không thuộc F1.

3. F1 scope and non-scope

In-scope (read-only, when F1 execution is later authorized)

  • Confirm and pin the documentary state of birth/identity substrate, classification registries, and the cell_id concept from KB sources only (framework §4, de-bai §V, catalog reuse rows) — unless Owner separately authorizes a Phase-1 read-only DB survey.
  • Classify each candidate asset into Q1 reuse-now / Q2 repair-verify / Q3 add-later with an evidence pin and a clear "documentary vs live" label.
  • Restate the F1 identity-root boundary: TEMP_ID / candidate identity only; canonical birth deferred to F4.
  • Surface the open conflicts that gate F1 (CONS-003 6-vs-7 tầng; CELL-003/004/007 cell_id; HOLD-1 iu_staging_*; HOLD-2 atomic promote) as carried obligations, not resolutions.

Non-scope (forbidden at F1 by default)

  • ❌ Canonical birth write / BIRTH_STAMP close (that is F4 output at promote).
  • ❌ Stuffing governance into birth P0.
  • ❌ Creating any birth registry, matrix registry, table, schema, index, DOT, checker, scanner.
  • ❌ ALTER/ADD COLUMN on meta_catalog / collection_registry / dot_tools to materialize cell_id/dot_role.
  • ❌ Resolving CONS-003 / CONS-004 / CONS-005 / CELL-003/004/007 (Owner-gated).
  • ❌ Live DB / runtime / Directus / PG query (Phase-1 is separately Owner-gated).
  • ❌ Selecting a pilot slice; writing detailed design.

4. Reuse-now inventory template (Q1 detail)

F1 execution fills Reuse verdict + Evidence pin (this-pass). Until then every row is a documentary candidate, not a reuse decision. Status column quotes framework rev56 §4.

Asset Documentary status (rev56 §4) [GR] documentary count Reuse-now hypothesis Catalog reuse Q Reuse verdict (F1 fills) Evidence pin (F1 fills)
birth_registry DOCUMENTARY_ONLY (reported LIVE/GOVERNED) ~1.21M rows, 22 cột BIRTH_STAMP post-promote substrate; minimal birth core BIRTH-REUSE-001 (BLOCKER) TODO TODO
fn_birth_register DOCUMENTARY_ONLY (gated, dry_run-default) — register fn reuse via wrapper BIRTH-REUSE-001 TODO TODO
fn_birth_gate DOCUMENTARY_ONLY (gated, mode=warning) — gate reuse — only after bypass control BIRTH-REUSE-001 TODO TODO
meta_catalog DOCUMENTARY_ONLY ~169 rows, cột layer "Tầng" source for cell_id CELL-REUSE-001 (BLOCKER) TODO TODO
collection_registry DOCUMENTARY_ONLY ~168 rows "Kho" dimension for cell_id CELL-REUSE-001 / COL-REUSE-001 TODO TODO
dot_tools DOCUMENTARY_ONLY (no dot_role/cell_id col reported) ~309 rows classification/DOT candidate via wrapper, no schema patch REG-REUSE-001 / REUSE-013 TODO TODO
universal_edges DOCUMENTARY_ONLY ~2,199 rows governance relationship graph (NOT matrix dim) GOV-REUSE-001 (BLOCKER) TODO TODO
cell_id concept conceptual attribute model (read-only hypothesis) n/a tầng×loài×kho×miền light mapping CELL-REUSE-002 TODO TODO
F0 source baseline accepted freeze-candidate (12 sources pinned) 12 + pkg reuse pinned sources as authority basis F0 decision record §4 TODO TODO

Reuse-first gate (catalog §2c): before proposing anything new, F1 must answer Decision Rule 1→7 and prove all 5 no-new-creation conditions (existing registry/metadata insufficient · iu_staging_* insufficient · IO Contract 5-field insufficient · scanner/report insufficient · reuse slower than new). Nhóm 0 baseline REUSE-001..015 applies, scoped to the F1 slice only (catalog §2e Pilot-Slice-First).

5. Repair / verify-before-reuse inventory template (Q2 detail)

Item Why not reuse-now Verification needed (Owner-gated) Conflict/HOLD ref
birth_registry live schema/row/use Only documentary; live state unproven Phase-1 read-only survey (separate Owner gate) — not at F1 —
birth_gate warning + bypass mode=warning ⇒ counts, doesn't block; kill-switch = BYPASS surface Confirm gate behavior + bypass control + audit before trust RISK-BYPASS
TEMP_ID vs BIRTH_STAMP Must not conflate temp identity with canonical birth Keep F1 to TEMP_ID/candidate; BIRTH_STAMP only at promote de-bai §V.3/5/10; D10
cell_id not materialized Concept only; not a column/metadata anywhere Resolve dimension sources read-only; no schema change CELL-003/004/007
6-vs-7 tầng composition drafts 6 tầng vs constitution rev44 7 composition levels Owner decision before any cell survey CONS-003 (CONFLICT)
dot_tools lacks dot_role/cell_id columns reported absent Attaching = schema change, Owner-gated detailed design D3 forbidden ALTER/ADD COLUMN
checkout/runtime sync baseline covers KB only not provable without runtime read (Owner-gated) CONS-005 caveat
governance in birth P0 anti-pattern the frame must block keep governance/canonical-birth at promote boundary D2 / hostile ca 23

6. Add-later-only-if-needed template (Q3 detail)

Nothing here is authorized. Each is future Owner-gated, and only if the reuse survey proves reuse is insufficient.

Possible future item Precondition to even propose Default
Detailed F1 execution report This packet reviewed + F1 read-only execution authorized not yet started
cell_id mapping design (light, no ontology) Reuse of existing dimension sources proven insufficient NO by default
Birth identity wrapper (light) Existing fn/registry reuse proven insufficient NO by default
Metadata / schema change Reuse-insufficiency proof + Owner-gated detailed design NO by default
New birth registry / matrix registry All 5 no-new conditions proven NO (no new sổ)
Canonical birth write n/a — belongs to F4 (promote boundary) NEVER at F1

7. F1 evidence obligations

F1 execution (when authorized) must produce, for the deep layer, evidence covering sources · evidence · authority · conflict · runtime · provenance · safety lock:

  1. Sources — pin each F1 asset to its KB source (framework §4 row / de-bai §V / catalog reuse row), with rev + this-pass currency.
  2. Evidence — per-asset documentary-vs-live label; row counts marked [GR] documentary unless a separately-authorized Phase-1 proves live.
  3. Authority — apply the CONS-004 working precedence (KB practical authority for laws-new docs; enacted principles higher; VPS/PG for runtime/data); flag any cross-class overlap to Owner.
  4. Conflict — carry CONS-003 (6-vs-7 tầng), CELL-003/004/007, HOLD-1 (iu_staging_*), HOLD-2 (atomic promote) as unresolved obligations, not decisions.
  5. Runtime — record what is NOT proven without Phase-1 (live schema/rows/gate behavior); do not infer runtime from documentary.
  6. Provenance — distinguish current-pass vs prior-session evidence; carry OBL-R2 disposition (Codex-rev56 relay accepted).
  7. Safety lock — restate F1 boundary (TEMP_ID only; no canonical birth; no governance in P0; no schema/registry); state where execution must STOP.

8. Known risks / stop conditions

  • RISK-BYPASS — fn_birth_gate warning + app.bypass_birth_gate kill-switch: reuse of the gate must not be trusted as a block until bypass is controlled + audited.
  • HOLD-1 (iu_staging_record / iu_staging_payload) — UNKNOWN→likely-LIVE CONFLICT; "HOLD FOR SYSTEM CHECK". F1 must not query or assume; staging reuse stays a Phase-1 obligation.
  • HOLD-2 (atomic promote) — BLOCKED, no transaction; relevant only as the reason canonical birth stays at F4, not F1.
  • CONS-003 (6-vs-7 tầng CONFLICT) — blocks cell/matrix survey until Owner resolves.
  • CELL-003/004/007 — cell_id dimension sources unresolved.

Stop conditions (F1 must STOP and report BLOCKED / Owner-decision-needed):

  • if any step would require a live DB/runtime read (→ Phase-1, separate Owner gate);
  • if any step would materialize cell_id/dot_role as a column (→ schema change, Owner-gated);
  • if any step would write canonical birth or BIRTH_STAMP (→ F4 only);
  • if resolving CONS-003/004/005 or CELL-003/004/007 is required to proceed;
  • if an asset cannot be classified honestly into Q1/Q2/Q3 from available KB evidence.

9. Bad-input / adversarial checks

F1 execution must reject (fail-closed) the following bad assumptions — each must resolve to "rejected", not to a PASS-to-act:

  1. "Documentary row counts / reported-LIVE labels prove the substrate is live." → REJECT (documentary ≠ live).
  2. "F1 may write canonical birth because it's the 'birth' layer." → REJECT (canonical birth = F4 output at promote).
  3. "Identity root needs governance, so put governance into birth P0." → REJECT (anti-pattern; governance at promote boundary).
  4. "cell_id exists, so add the column to make it real." → REJECT (concept only; schema change Owner-gated).
  5. "dot_tools should get dot_role/cell_id now." → REJECT (out-of-frame schema change).
  6. "birth_gate blocks, so reuse it as the canonical guard." → REJECT (warning-mode + bypass kill-switch).
  7. "TEMP_ID is the same as canonical birth." → REJECT (temp vs canonical distinction).
  8. "Baseline accepted ⇒ runtime/checkout is in sync." → REJECT (CONS-005 caveat: KB only).
  9. "Reading runtime config is fine because it's read-only." → REJECT (Phase-1 separately Owner-gated).
  10. "Create a new registry/manifest to organize F1." → REJECT (no new sổ by default; prove 5 conditions first).
  11. "CONS-003/004/005 can be resolved inside F1 prep." → REJECT (Owner-gated).
  12. "An unreadable/absent source can be assumed PROVEN." → REJECT (absent ≠ proven; e.g. canonical_fields is ABSENT, not a table).

Pass criterion: no bad assumption leads to a PASS-to-act or a forbidden action → F1 is not fail-open.

10. Expected F1 execution report format

When F1 read-only execution is later authorized, its report should mirror the F0 report shape:

  • §0 STATUS (one line): PASS / PARTIAL / BLOCKED, honest.
  • §1 Owner View — the 3 reuse-first questions (Q1/Q2/Q3) answered at the control surface.
  • §2 F1 scope confirmation (in/non-scope restated).
  • §3 Reuse-now classification — Q1 table filled with verdict + evidence pin (documentary/live label per row).
  • §4 Repair/verify list — Q2 with verification obligations (Owner-gated, not performed).
  • §5 Add-later list — Q3 future Owner-gated only-if-needed.
  • §6 Evidence table — sources/evidence/authority/conflict/runtime/provenance/safety-lock (§7 obligations discharged or carried).
  • §7 Conflict/HOLD log — CONS-003, CELL-003/004/007, HOLD-1, HOLD-2 carried forward.
  • §8 Adversarial check — §9 bad-input results (all rejected).
  • §9 Self-check + non-authorization confirmation.
  • §10 Next-gate recommendation (feeds F2).

PARTIAL is acceptable and honest where evidence is documentary-only or a verification is Owner-gated. Engineering PASS ≠ Authority PASS.

11. How F1 feeds F2

F2 in the §6c order = Information Unit / Smart Brick + Temp Store / Candidate. F1 hands F2:

  • a confirmed minimal identity root (TEMP_ID / candidate identity) for a brick to "stand" on before lifecycle — without canonical birth;
  • the classification registries reuse map (meta_catalog "Tầng", collection_registry "Kho", dot_tools classification candidate) needed to place a brick;
  • the cell_id-as-attribute hypothesis (read-only) and the unresolved dimension conflicts (CONS-003, CELL-003/004/007) as explicit obligations F2 must respect, not inherit as solved;
  • the carried HOLD-1 (iu_staging_* candidate store) note — the natural F2 temp-store candidate — pinned as a Phase-1 obligation, not a reuse decision.

F2 preparation must again preserve the 3 reuse-first Owner questions and remain non-authorizing until its own GPT → Codex → Owner gate.

12. Self-check (packet discipline)

  1. Preserved the 3 Owner questions (Q1 reuse-now / Q2 repair-verify / Q3 add-later) — ✅
  2. Kept F1 as preparation only (no execution) — ✅
  3. No live DB / runtime touched — ✅
  4. No canonical birth write (deferred to F4) — ✅
  5. No governance stuffed into birth P0 — ✅
  6. No new registry / table / schema created — ✅
  7. Documentary vs live proof distinguished throughout — ✅
  8. Owner/GPT kept as the only phase authority; Codex review is the next gate — ✅