Incomex AI Portal
KB-3975

RS-TKT-0A · 03 TKT Base L0–L3 Conversion Plan

7 min read Revision 1
tool-kiem-thulegolaws-newrs-tkt-0atkt-basel0-l3conversion-plannon-authorizing2026-06-21

RS-TKT-0A · 03 — TKT Base L0–L3 Conversion Plan

Lane: RS-TKT-0A · Date: 2026-06-21 Gate: REGISTRATION_HOLD · REGISTRATION_CAN_PROCEED = NO · 0 runtime mutations (KB writes only) Authority: NON_AUTHORITY · may_gate=false · decision_effect=NONE · design-only

This plan defines how the old TKT Base (the …/base/tkt-base-structural-evidence-governance-pack-2026-06-11/ layer) converts into a laws-new LEGO Tool-Kiem-Thu Base: a small set of support-checker blocks that verify structure, reproduction, fail-closed behaviour, and governance consistency of a laws-new candidate/RS packet — and nothing more.

1. TKT Base purpose

TKT Base answers four questions about a packet (a directory of files plus the commands that reproduce a result), and only these four:

  • L0 — FILE PASS: every load-bearing file exists at its declared path and matches its declared hash; no load-bearing file is missing.
  • L1 — PACKET RECONSTRUCTION PASS: the packet reconstructs from its governed source and reruns deterministically to the same verdict.
  • L2 — FAIL-CLOSED PASS: invalid input is rejected and produces no PASS, no certificate, no digest, and no seal-like output.
  • L3 — GOVERNANCE CONSISTENCY PASS: the governance around the packet is consistent — IDs (no orphan/collision, routed to one-roof), lane boundaries, authority firewall holds, no-vector evidence has hash + pointer + regen.

Role: support checker · evidence verifier · approval accelerator · structural/governance checker.

2. TKT Base non-purpose (hard)

TKT Base is not: a final authority, a semantic authority, a production gate, a runtime executor, a registration authority. It carries the base pack's self-description verbatim: authority = NON_AUTHORITY / NOT_PROMOTED, may_gate = false, decision_effect = NONE. It can refuse a false authority claim; it can never grant authority.

3. The level model (cumulative, ordered, capped)

Levels are cumulative and ordered: L(n) may be claimed only if L0..L(n) all pass. A FAIL at L(n) caps level_reached at L(n-1); higher levels report N/A, never PASS.

Level Name What a PASS means Old asset reused
L0 FILE PASS files present + hash-match + tree-pin ok manifest_file_presence, packet_tree
L1 PACKET RECONSTRUCTION PASS clean-room rerun → same verdict commands.sh/RERUN.sh skeleton
L2 FAIL-CLOSED PASS bad input → no PASS/cert/seal (exit==0 rule) fail_closed_probe P1–P10
L3 GOVERNANCE CONSISTENCY PASS IDs/lanes/firewall/NVSZ consistent authority_firewall, report_vs_file_audit, object_id_collision, nvsz_no_vector

Future, out of scope for Base (defer):

  • L4 — IU TRACEABILITY PASS — requires an IU graph (ids, metadata, relations, traversal checker). The New IU thin Subject Contract must exist first.
  • L5 — SEMANTIC TEXT-AS-CODE PASS — requires a semantic linter + grammar/schema + controlled vocab + committed semantic oracle. This lane must NOT claim it.
  • L6 — RELEASE/BUNDLE PASS — requires L0–L5 + release policy + bundle manifest + owner/Codex authority.

The boundary is enforced, not declared: the old base pack's probe P10 makes "assert SEMANTIC_TEXT_AS_CODE_PASS with no IU inputs" a fail-closed condition. The laws-new Base must keep that probe.

4. Reporting shape (the only verdicts TKT Base may emit)

TKT_BASE_RESULT:
  packet: <name>
  authority: NON_AUTHORITY / NOT_PROMOTED
  level_reached: L0 | L1 | L2 | L3
  L0_file:        PASS|FAIL        (n/n files present, n/n hash-match, tree_pin ok)
  L1_reconstruct: PASS|FAIL|N/A
  L2_fail_closed: PASS|FAIL|N/A    (probes p/p, any_fail_open=false)
  L3_governance:  PASS|FAIL|N/A
  forbidden_overclaim_emitted: false   # MUST be false

Forbidden verdict tokens (overclaim guard): IU_TRACEABILITY_PASS (L4), SEMANTIC_TEXT_AS_CODE_PASS (L5), RELEASE_BUNDLE_PASS (L6). The highest honest Base verdict is L3.

5. PASS-level policy — what a TKT PASS does and does NOT mean

A TKT Base PASS is the honest floor: structurally sound, reproducible, fail-closed, governance-clean. Explicitly (required statements):

  • TKT PASS does not mean Codex PASS. TKT catches what Codex would catch before Codex; it does not pre-empt Codex's judgment.
  • TKT PASS does not mean authority PASS. Authority remains Owner/Codex; decision_effect=NONE.
  • TKT PASS does not mean implementation PASS. Design/packet structure ≠ working implementation.
  • TKT PASS does not mean production PASS. No production touch is implied or permitted.
  • TKT PASS does not mean registration can proceed. REGISTRATION_HOLD stays active; CAN_PROCEED=NO is unaffected by any TKT verdict.

This is the laws-new ladder restated: Documentary ≠ live proof · Engineering PASS ≠ Authority PASS · Registered ≠ executed ≠ live · KB admission ≠ runtime registration. A TKT PASS is an engineering/structural PASS only and is never upgraded.

6. Review lane workflow (Claude / GPT / Codex / User roles)

Step Actor Action Output
1 Claude (read-only KB) assemble candidate/RS packet; run TKT Base checks (design-only here); record findings TKT_BASE_RESULT + packet
2 GPT first review of the packet (completeness, reasoning) review notes / NEED_PATCH
3 Codex adversarial re-review; issues ACCEPT_* / REJECT_* / NEED_*_PATCH verdict + STATUS
4 Owner / User authority/scope decision; may authorize a later runtime-touching phase authorization (separate)

TKT Base sits before step 2/3 as an accelerator: it mechanically catches the file/packet/fail-closed/governance defects so GPT and Codex spend their attention on judgment, not bookkeeping. A clean TKT result is engineering PASS only; it does not substitute for, or bind, any reviewer or the Owner.

7. What converts vs what is new

  • Converts as-is (REUSE): the four-level model, the cumulative-cap rule, the four checker policies behind L0–L3, the reporting shape, the overclaim guard, the authority firewall.
  • Converts with change (REUSE_WITH_CHANGE): the packet skeleton (commands.sh/RERUN.sh/exit_codes.json) re-targeted to a laws-new candidate packet; object-ID policy routed to one-roof.
  • New (NEW_NEEDED): the RS pre-Codex profile (06) layered on top of Base for RS-series packets; the staging/delete-fast binding (R-TKT-4/5).
  • Deferred (DEFER): L4–L6; the harness implementation (Python) — this lane is design-only.

No build is authorized by this plan. It defines the target. REGISTRATION_HOLD remains active.