RS-TKT-1 (Phase 1) · 01 — TKT Base Design Blueprint: Scope and Boundary

Lane: RS-TKT-1 — Phase 1 TKT Base Design Package (design-only) Date: 2026-06-22 Gate: REGISTRATION_HOLD · REGISTRATION_CAN_PROCEED = NO · 0 runtime mutations (KB design-doc writes only) Authority: NON_AUTHORITY · may_gate=false · decision_effect=NONE · design-only

This is the design blueprint of what the TKT Base is. It is paper. It defines the target shape; it builds nothing. The future construction blueprint (how it would later be built) is 09–15 and is also paper.

---

1. What TKT Base is

TKT Base is a support checker for a laws-new candidate/RS packet — a directory of inert files plus the recipe that reproduces a result. It answers four mechanical questions and only these four:

• L0 — FILE PASS — every load-bearing file exists at its declared path and hash; nothing load-bearing is missing or unlisted.
• L1 — PACKET RECONSTRUCTION PASS — the packet reconstructs from its governed source and re-verifies deterministically to the same verdict anchor, over inert fixtures only (PATCH1 P4).
• L2 — FAIL-CLOSED PASS — invalid input is rejected and produces no PASS, no certificate, no digest, no seal-like output, structured or unstructured (PATCH2 P1).
• L3 — GOVERNANCE CONSISTENCY PASS — governance around the packet is consistent across four independent one-concern bricks: authority firewall, claim audit, identity, NVSZ (PATCH1 P2).

Role, restated verbatim from the base pack: support checker · evidence verifier · approval accelerator · structural/governance checker.

2. What TKT Base is NOT (hard boundary)

TKT Base is NOT a final authority.
TKT Base is NOT a semantic authority.
TKT Base is NOT a production gate.
TKT Base is NOT a runtime executor.
TKT Base is NOT a registration authority.

It carries the base pack self-description: authority = NON_AUTHORITY / NOT_PROMOTED, may_gate = false, decision_effect = NONE. It can refuse a false authority claim; it can never grant authority. (R-TKT-6 verdict-only, R-TKT-8 no overclaim.)

3. Allowed Base levels (in scope for Phase 1 design)

L0 FILE PASS
L1 PACKET RECONSTRUCTION PASS
L2 FAIL-CLOSED PASS
L3 GOVERNANCE CONSISTENCY PASS

These are cumulative and ordered (02 defines the state machine). The highest honest Base verdict is L3.

4. Future-only levels (OUT of scope, deferred — design must never claim them)

L4 IU TRACEABILITY PASS   — needs a checker-consumable IU graph (New IU thin Subject Contract). DOES NOT EXIST.
L5 SEMANTIC TEXT-AS-CODE PASS — needs a semantic linter + grammar + controlled vocab + committed semantic oracle. DOES NOT EXIST.
L6 RELEASE/BUNDLE PASS    — needs L0–L5 + release policy + bundle manifest + Owner/Codex authority. DOES NOT EXIST.

The boundary is enforced, not declared: the L2 fail-closed contract treats asserting SEMANTIC_TEXT_AS_CODE_PASS / IU_TRACEABILITY_PASS / RELEASE_BUNDLE_PASS with no inputs as a forbidden token (04). Building a PASS on absent inputs is the exact fail-open TKT exists to prevent.

5. What a TKT PASS does NOT mean (required statements)

TKT PASS does NOT mean Codex PASS.
TKT PASS does NOT mean authority PASS.
TKT PASS does NOT mean implementation PASS.
TKT PASS does NOT mean runtime PASS.
TKT PASS does NOT mean production PASS.
TKT PASS does NOT mean registration can proceed.

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

6. LEGO governance the blueprint obeys (R-TKT-1..10)

• No mega-system. No mega-checker that "understands the whole system"; one brick = one concern; reads one packet bound by candidate_id+packet_hash (R-TKT-1).
• No mega-registry / no mega-graph / no mega-birth pipeline. TKT creates no registry, no graph, no birth pipeline; identity routes to one-roof (R-TKT-3).
• No hidden authority / no hidden production gate. may_gate=false, decision_effect=NONE; the aggregate is advisory (R-TKT-6/8).
• Explicit contracts only. Bricks communicate only through the shared output schema; no brick reads another's internals (R-TKT-2).
• Each brick can be born / tested / changed / rolled back separately (03 per-brick boundaries).

7. Scope fence (one line)

IN  : L0, L1, L2, L3 design contracts + RS pre-Codex profile design + NVSZ evidence design + the future construction blueprint (paper).
OUT : L4/L5/L6; any runtime; any code/CLI/runner/validator/registrar; any PG/Directus/registry mutation; any authority/registration effect.

If any subpart of the design would require runtime execution to be specified, that subpart stops at HOLD_RUNTIME_SURFACE_REQUIRED and the rest of the design continues (see 15).