RS-TKT-1-PATCH1B · 01 — Canonical Fixture / Oracle Master Schema

NON_EXECUTABLE_DESIGN_EXAMPLE
FUTURE_DRY_RUN_BLUEPRINT_ONLY
NOT_IMPLEMENTED
NOT_AUTHORIZED_FOR_RUNTIME

Lane: RS-TKT-1 — Phase 1 TKT Base Design Package · PATCH1B (dry-run readiness preflight / proof-doc-only) Date: 2026-06-22 Gate: REGISTRATION_HOLD · REGISTRATION_CAN_PROCEED = NO · 0 runtime mutations Authority: NON_AUTHORITY · may_gate=false · decision_effect=NONE Closes: Codex F1 (status/outcome conflation), F2 (dual code), F3 (two namespaces), F4 (prose/missing codes). Inherits & strengthens: phase1-design/patch1/01 (the committed oracle shape). This file is the master schema; the full normalized catalog of all 46 fixtures is in 02.

This is the canonical oracle schema: the field definitions, the hard rules that make the four Codex closures mechanical, the status-vs-outcome separation, and the complete canonical outcome-code registry. The fixtures themselves (one canonical code each) are catalogued in 02.

1. Canonical fixture schema (every catalog row in `02` defines all of these fields)

fixture_id            : stable id (POS-* positive control, BAD-* negative/adversarial fixture)
fixture_family        : FAIL_CLOSED | L0_FILE | L1_RECONSTRUCT | L3_GOVERNANCE | NVSZ | RS_PROFILE | DESIGN_LINT | POSITIVE_CONTROL
target_level_or_brick : the ONE brick/level the fixture exercises (03 §6 / 05 / 08 §6)
target_contract       : the governed contract section the fixture proves
fixture_type          : POSITIVE | NEGATIVE | ADVERSARIAL          (exactly one — see §1.2)
input_shape           : the inert input the fixture presents
scan_surface          : the surface the checker reads (04 §6) — NEVER the subject-under-test runtime
expected_check_status : PASS | FAIL | HOLD | N/A                   (ENUM — nothing else may appear here)
expected_probe_outcome: the human-readable observation (MAY contain SAFE_REJECT, "drift", "collision", …)
canonical_outcome_code: EXACTLY ONE code from §3 (no dual, no prose-only, no blank)
validator_namespace   : TKT_L0 | TKT_L1 | TKT_L2_FAILCLOSED | TKT_L3 | NVSZ_ESCROW | NVSZ_ROOT | RS_PROFILE | DESIGN_LINT | POSITIVE_CONTROL
source_design_file    : phase1-design design file (01–08)
source_construction_file : phase1-design construction-blueprint file (09–15)
source_contract_file  : the accepted PATCH1/PATCH2 contract the fixture inherits
stop_state_if_failed  : the verdict/stop-state that fires if this fixture's contract is unmet (09 / 15 §4)
authority_effect      : NONE  (constant — every fixture)
registration_effect   : NONE  (constant — every fixture)
phase_applicability   : PHASE1_DESIGN | PHASE2_DRY_RUN | PHASE3_NVSZ | FUTURE_L4_L6

1.1. Hard rules (the four Codex closures, made mechanical)

R1 status/outcome separation : expected_check_status ∈ {PASS,FAIL,HOLD,N/A} ONLY.
                               SAFE_REJECT is NOT a status; it may appear ONLY in expected_probe_outcome or canonical_outcome_code. (closes F1)
R2 one canonical code        : exactly one canonical_outcome_code per fixture — no "A / B", no parenthetical alternative,
                               no prose, no blank. A fixture with two possible codes is itself a defect. (closes F2, F4)
R3 one namespace per fixture : a fixture emits a code from exactly one validator_namespace. Cross-namespace cases are
                               SPLIT into separate fixtures (ESCROW_E9 escrow view vs ROOT_E4 root-provisioning view). (closes F3)
R4 one layer per fixture     : a design-static lint case and a future-runtime case are SEPARATE fixtures, separate codes, separate phases. (closes F2)
R5 effects constant          : authority_effect = registration_effect = NONE on every fixture (positive, negative, adversarial).
R6 one brick per fixture     : a negative/positive fixture targets exactly one brick; cross-cutting invariants are typed ADVERSARIAL (§1.2)
                               and tracked separately so no fixture is double-counted across bricks.

1.2. fixture_type partition (no fixture has two types — closes any "is it negative or adversarial?" ambiguity)

POSITIVE    : a positive control whose expected_check_status = PASS — proves the brick is not trivially always-fail. (15 fixtures)
NEGATIVE    : a fail-closed fixture targeting ONE brick's own failure/hold mode (expected_check_status ∈ {FAIL,HOLD}). (25 fixtures)
ADVERSARIAL : a cross-cutting fixture that probes a DESIGN-WIDE invariant (recombination, runtime cross-read, draft promotion,
              HOLD→PASS, N/A-upgrade, invented root) rather than one base/RS brick's own contract. (6 fixtures)

Partition is total and disjoint: 15 POSITIVE + 25 NEGATIVE + 6 ADVERSARIAL = 46 fixtures (catalogued in 02; counted in 07).
The "adversarial preflight probe battery" in 06 is an OPERATIONAL VIEW that selects fixtures (of ANY type) to run as attacks;
it is NOT a third type assignment. Each fixture still has exactly one fixture_type. (no dual classification ⇒ no defect)

2. Status vs outcome — the conflation PATCH1B removes (F1)

expected_check_status  = the level_status (06) this single input drives at its target brick/level. ENUM {PASS,FAIL,HOLD,N/A}.
expected_probe_outcome = what the probe/checker OBSERVES (free text; may name SAFE_REJECT, "drift", "collision", …).
canonical_outcome_code = the single machine code emitted (§3).

Mapping rule for SAFE_REJECT inputs (this was the exact bug in 17 §1):
  a clean structured rejection (event_type=REJECTION, authority_effect=NONE, exit≠0, no artifact) means the
  fail-closed brick HANDLED the input correctly ⇒ expected_check_status = PASS,
  expected_probe_outcome = SAFE_REJECT, canonical_outcome_code = SAFE_REJECT.
  SAFE_REJECT NEVER appears in expected_check_status. (PASS-of-a-safe-reject ≠ authority PASS — effects stay NONE.)

3. Canonical outcome-code registry (one code = one meaning = one namespace)

Codes are the exact namespaced codes the governed contracts emit (Codex §8: "Phase-1 L3 fixture must expect ESCROW_E9"), not generic paraphrases. Each is defined once.

namespace POSITIVE_CONTROL
  PASS_POSITIVE_CONTROL            — valid input the brick must PASS (proves not trivially always-fail). source 12 §1.

namespace TKT_L0  (source 02 §2)
  L0_FILE_MISSING                  — a listed file is absent.
  L0_HASH_MISMATCH                 — a file hash does not recompute.
  L0_TREE_PIN_MISMATCH             — sha256(hash_manifest.sha256) ≠ packet_tree.sha256.
  L0_UNLISTED_GOVERNED_FILE        — a governed file is not in the ledger.

namespace TKT_L1  (source 02 §3, PATCH1 P4)
  L1_RECONSTRUCT_DRIFT             — regenerated verdict anchor ≠ pinned anchor.
  L1_NONDETERMINISTIC              — regeneration is non-deterministic.
  HOLD_RUNTIME_SURFACE_REQUIRED    — reconstruction needs subject-under-test runtime ⇒ HOLD (Phase 4), never PASS.

namespace TKT_L2_FAILCLOSED  (source 04 §7, PATCH2 P1 §8 — verbatim)
  SAFE_REJECT                      — all six §2 conjuncts of PATCH2 01 hold (clean rejection).
  FAIL_UNSTRUCTURED_FORBIDDEN_TOKEN— a bare reserved grant-like token outside a valid safe-rejection context.
  FAIL_FORBIDDEN_AUTHORITY_ARTIFACT— cert/seal/authority-digest artifact, or a structured GRANT event.
  FAIL_INVALID_EXIT_ZERO           — exited 0 on invalid input.
  HOLD_OUTPUT_SURFACE_UNAVAILABLE  — scan surface incomplete; could not assess safely.

namespace TKT_L3  (source 05)
  L3_AUTH_CLAIM_REJECTED           — authority/seal/gate/promotion claim refused (AUTHORITY-FIREWALL).
  L3_REPORT_CLAIM_UNVERIFIED       — a load-bearing claim cannot be recomputed from reality (CLAIM-AUDIT).
  L3_OBJECT_ID_COLLISION           — object id collides with an existing/reserved id (IDENTITY).
  L3_ORPHAN_OBJECT                 — born object with no one-roof entry (IDENTITY).
  L3_NEW_REGISTRY_PROPOSED         — a TKT-owned registry is proposed; anti-mega-registry trip (IDENTITY, R-TKT-3).
  L3_NVSZ_RECORD_INCOMPLETE        — escrow record missing a required field (NVSZ; pairs with an ESCROW_E* below).
  FAIL_L3_CROSS_BRICK_INTERNAL_READ— at RUNTIME an L3 brick reads another L3 brick's internals (Phase 2+ runtime layer).

namespace NVSZ_ESCROW  (source 07 §2 — emitted by TKT-L3-NVSZ in Phase 1/2)
  ESCROW_E5                        — raw log placed in a vector-KB path.
  ESCROW_E9                        — agent-invented NON_VECTOR_ROOT (escrow-validation view).
  (ESCROW_E2/E3/E4/E6/E7/E8 defined in 07; not needed as Phase-1 fixtures here.)

namespace NVSZ_ROOT  (source 07 §2 — root-provisioning validator, Phase 3 ONLY)
  ROOT_E4                          — agent-invented root at root acceptance (Phase 3; SPLIT from ESCROW_E9 per Codex F3).

namespace RS_PROFILE  (source 08 §6; codes ADDITIVELY DEFINED for the RS support bricks — see §3.1)
  RS_PACKAGE_NOT_ADDITIVE          — package overwrites a prior package, or is empty/truncated (Group A).
  RS_GATE_REGISTRATION_HOLD_ABSENT — packet lacks REGISTRATION_HOLD / asserts CAN_PROCEED=YES / opened register_dot (Group B).
  RS_LIFECYCLE_PREMATURE_ACTIVATION— activation before registration, or implicit inherit (Group C).
  RS_QUORUM_ORDER_NONTOTAL         — Q-order not total / two matching Q-codes / eval-unit undefined (Group D).
  RS_REPLAY_CLASS_NONDISJOINT      — G02a/G02b/G02c not disjoint, or in-flight used as a code (Group E).
  RS_COUNT_ORACLE_NONCANONICAL     — count ≠ 84−1+3=86 / dual code / filename↔title numeric mismatch (Group F).
  RS_CODEX_PACKET_INCONSISTENT     — verdict/gate/count/next-step differ across index↔decision↔packet↔rollup, or a PASS upgraded (Group G).

namespace DESIGN_LINT  (source: this lineage; design-review-time invariants, Phase-1)
  REJECT_MEGA_SYSTEM_DRIFT         — a design recombines the four L3 concerns / reads another brick's internals (05 §6 anti-recombination).
  FAIL_HOLD_TREATED_AS_PASS        — a design/aggregate treats HOLD as PASS (06 §1/§8).
  FAIL_NA_UPGRADES_AGGREGATE       — a design lets an N/A upgrade the aggregate (06 §3/§5).
  FAIL_RS5B_DRAFT_PROMOTED         — RS5B BI0x draft auto-promoted to generic/validated (08 §5; MCB-1).

3.1. RS_PROFILE codes are an additive design completion (not invention of authority)

Phase-1 08 defined the seven RS group PURPOSES but not a per-group canonical failure code. 03 §1 requires every brick to
define failure code / hold code / bad input / expected reject. PATCH1B additively supplies those four fields for the seven RS
support bricks via the RS_* codes above and the BAD-RS-{A..G}-001 fixtures (02 §4.6). This is design-doc COMPLETION of an
already-governed contract (08 §6 purposes → one code per purpose); it creates no runtime, no authority, no new registry.
Hold code for every RS brick = HOLD_OUTPUT_SURFACE_UNAVAILABLE (scan surface unreadable).

3.2. Documentation-only aliases (NEVER used as a fixture's canonical_outcome_code)

FAIL_FILE_MISSING        ≡ L0_FILE_MISSING
FAIL_HASH_MISMATCH       ≡ L0_HASH_MISMATCH
FAIL_PACKET_TREE_MISMATCH≡ L0_TREE_PIN_MISMATCH
FAIL_RAW_LOG_IN_VECTOR_KB≡ ESCROW_E5
FAIL_INVENTED_NVSZ_ROOT  ≡ ESCROW_E9 (escrow view) / ROOT_E4 (root-provisioning view, Phase 3)
No fixture row uses an alias; aliases exist only for cross-reading, so no dual code is introduced.

3.3. Code uniqueness invariant (machine-checkable)

Every code in §3 maps to exactly one (namespace, meaning). No code appears in two namespaces.
distinct_codes(§3) = 30 ; namespaces = 9 ; codes_with_two_meanings = 0 ; codes_with_two_namespaces = 0.
ESCROW_E9 and ROOT_E4 are DIFFERENT codes in DIFFERENT namespaces (the F3 split), not one code reused.

4. Oracle determinism statement (closes 12 §2 ambiguity)

The oracle maps each fixture_id → exactly one canonical_outcome_code (catalog 02 §4).
The oracle is a committed DATA shape (would live under contracts/ or fixtures/, versioned); it is NOT runtime logic.
A fixture with two possible codes is itself a defect; count of such defects in the catalog = 0 (07).
No fixture file or oracle file is created in Phase 1. NOT_IMPLEMENTED · NOT_AUTHORIZED_FOR_RUNTIME.
The authoritative catalog for review is 02; it additively supersedes the outcome cells of 17 and 12 (which remain revision 1).