Incomex AI Portal
KB-1694

03 — DOT Birth / Governance / Registration Path Reconstruction (2026-06-22)

10 min read Revision 1

03 — DOT Birth / Governance / Registration Path Reconstruction

Macro: DOT_MANAGE_LEGO_TRANSITION_SURVEY_FOR_C1_DRYRUN · Date: 2026-06-22 · Read-only reconstruction (no path invented).

Answers macro §3.2. The KB documents two distinct "births" that must not be conflated:

  • Path A — DOT-tool lifecycle: how a new DOT (bin/dot-*) becomes a runtime-registered, runnable tool in dot_tools. (This is the path C1's producer/verifier/schema DOTs must travel.)
  • Path B — object birth/admission: how any governed entity row gets a birth_registry record (the birth_admission_permit machinery; the proposed dot-birth-admit entrypoint). (Relevant because a C1 vocab row insert would pass through it.)

Field legend per stage: implementer · input · output · authority · status · registered? · wired? · runnable? · safe-for-LEGO? · what-must-change-for-LEGO.

Path A — DOT-tool lifecycle (idea → registered → runnable)

A1. DOT idea / spec / contract

  • Implementer: KB spec docs (e.g. Macro-9B contract + 4 guard contracts + reference validator).
  • input: requirement → output: SPEC artifact (candidate-born). authority: engineering.
  • status: authored · registered: no · wired: no · runnable: no · safe-for-LEGO: yes (this is where C1 DOT specs already are).
  • change for LEGO: author C1 producer/verifier + schema-ensure + preflight + harness + rollback specs (largely DONE in the C1 packages / sandbox).

A2. Birth/admission record (KB-level, anti-orphan)

  • Implementer: Macro-9B1 anti-orphan patch → dot-manage/admission/…birth-admission….md.
  • input: spec artifacts → output: KB admission record candidate-born / engineering-admitted. authority: engineering admission only (NOT_OWNER_AUTHORIZED).
  • status: done for Macro-9B artifacts · registered: no (KB doc only) · wired: no · runnable: no · safe-for-LEGO: yes (required to avoid orphans).
  • change for LEGO: every new C1 DOT MUST get its own admission record or it is an orphan ("must not be called usable/registered/active/authorized").

A3. Deploy to governed filesystem path

  • Implementer: bin/dot-* deployed under /opt/incomex/dot/bin/.
  • status: done for 289 FS files (recon) · n/a registered/wired/runnable at this stage · safe-for-LEGO: yes (operator deploy).
  • change for LEGO: deploy the C1 DOT executables (must be authored first — they are not, beyond the pure validator).

A4. Contract registration into dot_tools ← the lawful registrar

  • Implementer: dot-dot-register (code DOT-REGISTER, §5.3 row 247, bin/dot/dot-dot-register.ts, domain monitoring.dot, op register) — "the only governed registrar … registers via the Directus REST API".
  • input: untracked bin/dot-* files → output: new dot_tools rows. authority: Directus admin creds + Owner-gated + dry-run-gated.
  • status: STAGED, not executed — creds ABSENT (config/credentials.local.json absent; DIRECTUS_ADMIN_TOKEN/DOT_TOKEN unset; "a real access blocker, not a choice") · registered: the tool exists in dot_tools (live probe) but cannot run here · wired: — · runnable: no (here) · safe-for-LEGO: yes (this IS the lawful path).
  • change for LEGO: operator supplies admin creds + Owner Phase-2 open → register the C1 DOTs through this path (NEVER by hand).

A5. CAT-006 / dot_tools catalog sync

  • Implementer: dot-catalog-sync (DOT-015; on-deploy FS scan); per CAT-006 record.
  • input: dot/bin/ scan → output: dot_tools rows + CAT-006 record_count. authority: operator/deploy.
  • status: LIVE · registered: yes (CAT-006 active) · wired: yes · runnable: yes · safe-for-LEGO: yes. This is the only Path-A stage that is currently registered + wired + runnable.
  • change for LEGO: none structurally; will pick up C1 DOTs after A4.

A6. Handbook / ledger update

  • Implementer: DOT Usage Handbook §5.3 + law_dot_enforcement mapping.
  • status: handbook rev12 / §5.3 = 309 rows · registered: KB doc · safe-for-LEGO: yes.
  • change for LEGO: add C1 DOT rows to handbook after registration; add C1 to enforcement law.

A7. Dispatcher / executor wiring

  • Implementer: fn_process_agent_api_dispatch(...) (generic, fail-closed; raises on REAL_RUN by design) + agent-api executor POST …:8090/dispatch (DRY_RUN/PLAN_ONLY) + dot_agent_api_contract.
  • input: registered DOT + contract → output: dispatchable contract. authority: Owner gate.
  • status: only 2 contracts bound (the DOT_KG_EXPLAIN pair) · registered: 2 rows · wired: partial (dry-run only) · runnable: dry-run only · safe-for-LEGO: yes (dry-run is the goal).
  • change for LEGO: bind the C1 producer/verifier pair following the KG precedent.

A8. Preflight / verify

  • Implementer: paired producer/verifier convention (DOT_KG_EXPLAIN + _VERIFY); preflight view v_dotkg_realrun_preflight.
  • status: v_dotkg_realrun_preflight = REALRUN_BLOCKED_MULTI_GATE · runnable: read-only · safe-for-LEGO: yes.
  • change for LEGO: author a C1 preflight (DOT_C1_PREFLIGHT, 7 checks — designed in C1 packages) + a v_c1_*_preflight view.

A9. Runtime gate open + real-run registration

  • Implementer: DOT-REGISTER invoked at Owner Phase-2 open; dot_config execute gates.
  • status: gates SHUT (real_run_enabled=false, execute_enabled=false, dry_run_only=true) · registered/wired/runnable: no · safe-for-LEGO: yes (Owner act).
  • change for LEGO: Owner authorization + gate flips — only needed for REAL_RUN, not for a governed DRY_RUN.

A10. Rollback / retire / supersession

  • Implementer: set status='archived'/delete on the dot_tools row via governed Directus path (RP-03); DOT-314 dot-matrix-retire; DOT-112 dot-entity-retire; §13 freeze list.
  • status: defined; not run · safe-for-LEGO: yes.
  • change for LEGO: extend DOT-062 dot-rollback for the C1 rollback step (not clone).

Path B — Object birth / admission (the birth_registry machinery)

Stage Implementer Status reg / wired / runnable safe-for-LEGO / change
B1. One entrypoint dot-birth-admit (PROPOSED; domain birth; paired with dot-dot-register) SPEC / author-mode ONLY — no production DOT registered no / no / no spec only; would need authoring + registration
B2. Permit reservation birth_admission_permit table (created empty, fail-closed) + fn_birth_permit_request() table empty; request fn = design partial fine as design; not needed for a C1 dry-run
B3. BEFORE-insert gate fn_birth_gate() on 16 tables (incl. dot_tools) → fn_pre_birth_check ADVISORY ONLY (app.birth_gate_mode='warning'; "gate never blocks in production today") live / yes / warning-only a real C1 row insert would only be warned, not blocked — note for REAL_RUN, not dry-run
B4. AFTER-insert auto-birth fn_birth_registry_auto() (166 triggers) live; has single-column-unique structural defect live unchanged; out of C1 scope
B5. Shared register path fn_birth_register(p_collection,p_row,p_dry_run=true,p_dot_origin) live; dry-run default; proven net-0 via BEGIN..ROLLBACK live / partial / dry-run reusable as the dry-run register primitive pattern
B6. Finalize-at-commit proposed DEFERRABLE CONSTRAINT TRIGGER (modeled on live IU layer-2) pattern exists for IU; not built for birth no not needed for dry-run
B7. Governance handoff cursor-tail registry_changelog → event_pending; event registered active=false OSPA=0 ⇒ NO-GO inactive / no / no gated by build-authorization; operator/Owner act
B8. Retire/supersede fn_retire_gate_check() live; status-transition fn + vocabulary absent safety check live; transition missing partial / check-only extend for C1 retire

The lawful registrar — one-line truth

  • dot-dot-register (DOT-REGISTER) is a REAL governed tool (present in dot_tools) but cannot run here (admin creds absent; live registration = Owner Phase-2, dry-run-gated).
  • dot-birth-admit is author-mode SPEC only — there is NO registered tool literally named dot-birth-admit, and NO separate "lawful registrar" beyond dot-dot-register.
  • Forbidden substitutes (RP-03 + handbook §3): manual INSERT INTO dot_tools, psql/docker exec psql, hand-written DDL/DML against directus.public, Directus generic collection-create, minting/borrowing a Directus admin token. These are not standing operator paths.

Net assessment for C1

The DOT-tool lifecycle is fully specified and partly live (A1–A3, A5, A6, A8 ready; A7 has a working precedent; A10 extendable). The ONLY blocked links are A4 (register: creds absent) and A9 (gate/Owner: shut) — both are operator/Owner Gate-B actions, not engineering gaps. The object-birth path (B) is mostly advisory/dry-run and not on the critical path for a C1 dry-run (it matters at REAL_RUN). No new birth path needs to be invented; the existing path must be unblocked at A4/A9 by the operator.

Back to Knowledge Hub knowledge/dev/laws-new/reports/dot-manage-lego-transition-for-c1-dryrun/03-dot-birth-governance-registration-path-reconstruction-2026-06-22.md