<!-- DOC_STATUS: ACTIVE_NON_AUTHORITY -->

TKT Base — Scope and Limits

Pack: tkt-base-structural-evidence-governance-pack-2026-06-11 Authority: NON_AUTHORITY / NOT_PROMOTED. This pack defines a reusable testing layer. It grants no seal, gate, or decision power. Authority remains owner/Codex. Date: 2026-06-11

---

1. What TKT Base is

Tool-Kiểm-Thử (TKT) Base is a structural-evidence and governance testing layer for technical packets — directories of files plus the commands that reproduce a result. It answers four questions, and only these four:

1. Do the files exist and match their declared hashes? (LEVEL 0 — FILE PASS)
2. Does the packet reconstruct and rerun deterministically? (LEVEL 1 — PACKET RECONSTRUCTION PASS)
3. Does bad input fail closed — no PASS, no certificate, no seal? (LEVEL 2 — FAIL-CLOSED PASS)
4. Is the governance around the packet consistent — IDs, lanes, firewall, no-vector evidence? (LEVEL 3 — GOVERNANCE CONSISTENCY PASS)

TKT Base consolidates patterns already proven in the v0.2 hardening / NVSZ / packet-completeness / fail-closed / governance work into reusable templates and policies. It is the honest floor: a packet that passes L0–L3 is structurally sound, reproducible, fail-closed, and governance-clean. Nothing more is claimed.

2. What TKT Base is NOT

TKT Base is NOT the semantic Text-as-Code / IU Smart-Brick layer. It does not, and must not, evaluate the meaning of a packet's content. Concretely, TKT Base:

• does not verify that prose claims are semantically true;
• does not trace Information Units (IU) through relations/metadata;
• does not lint Text-as-Code for semantic coherence;
• does not decide release-readiness or bundle a release.

These are LEVEL 4 (IU TRACEABILITY), LEVEL 5 (SEMANTIC TEXT-AS-CODE), and LEVEL 6 (RELEASE/BUNDLE) — all out of scope and deferred to a future TKT Semantic Extension. See limitations/TEXT_AS_CODE_SEMANTIC_DEFERRED.md and limitations/IU_INPUT_REQUIREMENTS_FOR_LEVEL_4_5_6.md.

3. The load-bearing distinction TKT Base enforces

A v0.2 finding (ADOPT-FIND-1 / V02-PB-PRODUCE-CONTENT) is the reason this layer exists and where its ceiling sits:

A --produce gate that binds filename-set membership is NOT the same as one that binds content. Correct 10 filenames + tampered content can still exit 0 at the filename layer.

TKT Base provides three trust boundaries and is explicit about which it covers:

Gate	Question	Owned by TKT Base?
G1 filename-membership	are the right files present?	yes (L0/L1)
G2 content-binding	do the bytes match the committed oracle?	yes, as a dev profile (L0/L1/L2)
G3 seal-authority	is this an owner/Codex seal?	no — authority only (L3 firewall blocks false claims)

TKT Base can prove a packet is structurally and content-bound sound, and can refuse any attempt to manufacture authority. It cannot grant authority.

4. Hard limits (must-not-overclaim)

TKT Base output must never emit any of:

• IU_TRACEABILITY_PASS
• SEMANTIC_TEXT_AS_CODE_PASS
• RELEASE_BUNDLE_PASS

…unless the corresponding future IU semantic inputs exist and a future TKT Semantic Extension supplies a checker for them. A base run that is asked to assert any of these MUST fail closed (see checkers/fail_closed_probe_policy.md, probe class P10). Claiming Tool is complete for semantic Text-as-Code is a forbidden overclaim at the base layer.

5. Relationship to the active lanes (read-only boundary)

This pack was built while T1 was active on FIX7 / P0-khai-sinh / authority-input (N6/N7/N8/P7) and while the T2 v0.2 convention packet was the source of patterns. The pack:

• does not mutate FIX7 / T1 active surfaces or N-number/N6/N7/N8/P7;
• does not mutate the v0.2 convention packet (it references it read-only);
• does not promote Tool-Kiểm-Thử v0.2;
• does not apply any canonical registry/index fold while T1 is active;
• does not designate an NVSZ root or mutate production.

See checkers/object_id_collision_policy.md and the governance addendum for the addendum-only, fold-deferred discipline.