KB-3FBA

RS-TKT-1-PATCH1 · 01 Canonical Fixture / Oracle Schema

23 min read Revision 1
tool-kiem-thulegolaws-newrs-tkt-1phase1-designpatch1canonical-fixtureoracle-schemanon-authorizing2026-06-22

RS-TKT-1-PATCH1 · 01 — Canonical Fixture / Oracle 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 · PATCH1 (design-only / 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 NEED_RS_TKT_1_PATCH1_NEGATIVE_FIXTURE_MATRIX_INCOMPLETE findings #1 (status/outcome conflation), #2 (dual L3 code), #3 (two namespaces in one fixture), #4 (prose-only codes).

This file is the canonical oracle: a normalized schema plus the complete normalized fixture catalog. Every fixture in Phase-1 file 17 and construction-blueprint 12 is re-expressed here with separated status/outcome fields and exactly one canonical outcome code. No fixture is executed; this is the committed oracle shape only.


1. Canonical fixture schema (every fixture row defines all fields)

fixture_id            : stable id (POS-* positive control, BAD-* negative 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)
target_contract       : the governed contract section the fixture proves
fixture_type          : POSITIVE | NEGATIVE
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 etc.)
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
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 #1)
R2 one canonical code        : exactly one canonical_outcome_code per fixture — no parenthetical alternative,
                               no "A / B", no prose-only, no blank. A fixture with two possible codes is itself a defect. (closes #2, #4)
R3 one namespace per fixture : a fixture emits a code from exactly one validator_namespace.
                               Cross-namespace cases are SPLIT into separate fixtures (e.g. ESCROW_E9 vs ROOT_E4). (closes #3)
R4 one layer per fixture     : a design-static lint case and a future-runtime case are SEPARATE fixtures with separate codes and phases. (closes #2)
R5 effects constant          : authority_effect = registration_effect = NONE on every fixture, positive or negative.

2. Status vs outcome — the conflation that PATCH1 removes

expected_check_status  = the level_status (06) that this single input drives at its target brick/level.
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 (was the 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.

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

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

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 — verbatim)
  SAFE_REJECT                      — all six §1 conjuncts hold (clean rejection).
  FAIL_UNSTRUCTURED_FORBIDDEN_TOKEN— 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 #3).

namespace RS_PROFILE  (source 08 §6; canonical codes ADDITIVELY DEFINED by this PATCH 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 is upgraded (Group G).

namespace DESIGN_LINT  (source: this PATCH; 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. PATCH1 additively supplies those four fields for the seven RS support bricks via the RS_* codes above and the BAD-RS-{A..G}-001 fixtures in §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)

The macro listed generic semantic names. They are recorded here as aliases of the namespaced codes for cross-reading only; no fixture row uses an alias, so no dual code exists:

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)

4. Normalized fixture catalog

For every family the per-family header fixes the constant fields; each row then carries the variable fields. Every row: authority_effect = NONE, registration_effect = NONE.

4.1. Family FAIL_CLOSED — target L2 TKT-L2-FAIL-CLOSED

target_contract = 04 §1/§7 · validator_namespace = TKT_L2_FAILCLOSED · source_design_file = 04 · source_construction_file = 12 · source_contract_file = PATCH2 01 (P1) · phase_applicability = PHASE2_DRY_RUN

fixture_id type input_shape check_status probe_outcome canonical_outcome_code
BAD-FC-001 NEGATIVE bare PASS to stdout + exit 3 FAIL unstructured grant-like token detected FAIL_UNSTRUCTURED_FORBIDDEN_TOKEN
BAD-FC-002 NEGATIVE cert/seal/authority-digest artifact + exit 3 FAIL forbidden authority artifact created FAIL_FORBIDDEN_AUTHORITY_ARTIFACT
BAD-FC-003 POSITIVE ORACLE_CLAIMS_SEAL_REJECTED, event_type=REJECTION, authority_effect=NONE, exit 3, no artifact PASS clean structured rejection SAFE_REJECT
BAD-FC-004 NEGATIVE invalid input exits 0, no token/artifact FAIL nonzero-exit conjunct violated FAIL_INVALID_EXIT_ZERO
BAD-FC-005 POSITIVE exit≠0, no grant token/artifact, structured REJECTION/NONE PASS all six conjuncts hold SAFE_REJECT
BAD-FC-006 NEGATIVE bare SEMANTIC_TEXT_AS_CODE_PASS + exit 3 FAIL L5 overclaim token FAIL_UNSTRUCTURED_FORBIDDEN_TOKEN
BAD-FC-007 NEGATIVE result.md with REGISTRATION_CAN_PROCEED = YES + exit 3 FAIL registration-open token FAIL_UNSTRUCTURED_FORBIDDEN_TOKEN
BAD-FC-008 NEGATIVE scan surface absent (stdout/stderr/result missing) HOLD missing visibility HOLD_OUTPUT_SURFACE_UNAVAILABLE

Status fix: 17 §1 previously put SAFE_REJECT in the status column for BAD-FC-003/005. Here their expected_check_status = PASS and SAFE_REJECT lives only in probe_outcome/canonical_outcome_code. BAD-FC-003/005 double as the L2 positive controls (they prove the safe-rejection-context guard does not false-positive).

4.2. Family L0_FILE — target TKT-L0-FILE

target_contract = 02 §2 · validator_namespace = TKT_L0 · source_design_file = 02/03 · source_construction_file = 12 · source_contract_file = PATCH1 07 (P7 chain) · phase = PHASE2_DRY_RUN

fixture_id type input_shape check_status probe_outcome canonical_outcome_code
POS-L0-001 POSITIVE intact packet; ledger + tree-pin consistent; all files present + hashes recompute PASS L0 passes PASS_POSITIVE_CONTROL
BAD-L0-001 NEGATIVE a listed file is absent FAIL missing file L0_FILE_MISSING
BAD-L0-002 NEGATIVE a file's bytes changed; hash will not recompute FAIL hash mismatch L0_HASH_MISMATCH
BAD-L0-003 NEGATIVE sha256(hash_manifest.sha256) ≠ packet_tree.sha256 FAIL tree-pin mismatch L0_TREE_PIN_MISMATCH
BAD-L0-004 NEGATIVE a governed file is unlisted in the ledger FAIL unlisted governed file L0_UNLISTED_GOVERNED_FILE

4.3. Family L1_RECONSTRUCT — target TKT-L1-PACKET

target_contract = 02 §3 + PATCH1 P4 · validator_namespace = TKT_L1 · source_design_file = 02 · source_construction_file = 10/11 · source_contract_file = PATCH1 04 (P4) · phase = PHASE2_DRY_RUN

fixture_id type input_shape check_status probe_outcome canonical_outcome_code
POS-L1-001 POSITIVE inert recipe re-runs in a fresh workspace; regenerated anchor byte-identical to pin PASS reconstruction matches PASS_POSITIVE_CONTROL
BAD-L1-001 NEGATIVE reconstruction requires subject-under-test runtime HOLD SUT runtime ⇒ Phase 4 HOLD_RUNTIME_SURFACE_REQUIRED
BAD-L1-002 NEGATIVE regenerated verdict-anchor pin ≠ published pin FAIL reconstruction drift L1_RECONSTRUCT_DRIFT

4.4. Family L3_GOVERNANCE — four independent bricks (05)

source_construction_file = 10 · source_contract_file = PATCH1 02 (P2 split) · all phase = PHASE2_DRY_RUN except the runtime cross-read fixture noted.

fixture_id target brick type input_shape check_status probe_outcome canonical_outcome_code ns
POS-L3-AF-001 TKT-L3-AUTHORITY-FIREWALL POSITIVE packet self-describes NON_AUTHORITY; no seal PASS firewall clean PASS_POSITIVE_CONTROL TKT_L3
BAD-L3-AF-001 TKT-L3-AUTHORITY-FIREWALL NEGATIVE a dev fixture claims a Codex/owner seal FAIL authority claim refused L3_AUTH_CLAIM_REJECTED TKT_L3
POS-L3-CA-001 TKT-L3-CLAIM-AUDIT POSITIVE every load-bearing claim recomputes against cited files PASS claims verified PASS_POSITIVE_CONTROL TKT_L3
BAD-L3-CA-001 TKT-L3-CLAIM-AUDIT NEGATIVE a prose-only PASS / a cited hash that will not recompute FAIL claim unverified L3_REPORT_CLAIM_UNVERIFIED TKT_L3
POS-L3-ID-001 TKT-L3-IDENTITY POSITIVE IDs unique, no orphan, routed to one-roof PASS identity clean PASS_POSITIVE_CONTROL TKT_L3
BAD-L3-ID-001 TKT-L3-IDENTITY NEGATIVE an id in an existing/reserved range FAIL id collision L3_OBJECT_ID_COLLISION TKT_L3
BAD-L3-ID-002 TKT-L3-IDENTITY NEGATIVE a NEW TKT-owned registry is proposed FAIL anti-mega-registry trip L3_NEW_REGISTRY_PROPOSED TKT_L3
POS-L3-NVSZ-001 TKT-L3-NVSZ POSITIVE escrow records complete {hash,pointer,regen_cmd,determinism,root=false} PASS nvsz records complete PASS_POSITIVE_CONTROL TKT_L3
BAD-NVSZ-001 TKT-L3-NVSZ NEGATIVE a raw log placed in a vector-KB path FAIL raw log in vector KB ESCROW_E5 NVSZ_ESCROW
BAD-NVSZ-002 TKT-L3-NVSZ NEGATIVE an agent-designated NON_VECTOR_ROOT (escrow-validation view) FAIL invented root (escrow) ESCROW_E9 NVSZ_ESCROW

Namespace fix (#3): 17 §3 previously wrote ESCROW_E9 / ROOT_E4 in one cell. Here BAD-NVSZ-002 expects only ESCROW_E9 (escrow validator, Phase 1/2). The root-provisioning case is split into BAD-NVSZ-003 below (§4.7), Phase 3.

4.5. Family L3 cross-brick read — design-static vs future-runtime split (#2)

target brick = L3 split invariant (05 §6) · source_design_file = 05 · source_contract_file = PATCH1 02

fixture_id type layer input_shape check_status probe_outcome canonical_outcome_code ns phase
BAD-L3-001 NEGATIVE design-static a design recombines the four L3 concerns / one brick reads another's internals FAIL mega-system drift (design review) REJECT_MEGA_SYSTEM_DRIFT DESIGN_LINT PHASE1_DESIGN
BAD-L3-002 NEGATIVE future-runtime at RUNTIME an L3 brick reads another L3 brick's internals FAIL cross-brick internal read (runtime) FAIL_L3_CROSS_BRICK_INTERNAL_READ TKT_L3 PHASE2_DRY_RUN

Was: BAD-L3-001 = FAIL / design REJECT, code L3 boundary FAIL · REJECT_MEGA_SYSTEM_DRIFT (dual, two layers). Now one layer + one code per fixture.

4.6. Family RS_PROFILE — seven support bricks (08)

validator_namespace = RS_PROFILE · source_design_file = 08 · source_construction_file = 10 · source_contract_file = PATCH2 02 (P6) + PATCH1 06 · phase = PHASE2_DRY_RUN

fixture_id target brick type input_shape check_status probe_outcome canonical_outcome_code
POS-RS-A-001 RS-GROUP-A PACKAGE (TKT-RS-PACKAGE) POSITIVE complete, non-empty, non-truncated, additive package PASS package complete PASS_POSITIVE_CONTROL
BAD-RS-A-001 RS-GROUP-A PACKAGE NEGATIVE a package that overwrites a prior package / is truncated FAIL non-additive package RS_PACKAGE_NOT_ADDITIVE
POS-RS-B-001 RS-GROUP-B GATE (TKT-RS-GATE) POSITIVE REGISTRATION_HOLD present + CAN_PROCEED=NO + 0 mutations + no register_dot PASS gate clean PASS_POSITIVE_CONTROL
BAD-RS-B-001 RS-GROUP-B GATE NEGATIVE packet lacks REGISTRATION_HOLD / asserts CAN_PROCEED=YES / opened register_dot FAIL gate violated RS_GATE_REGISTRATION_HOLD_ABSENT
POS-RS-C-001 RS-GROUP-C SCOPE_LIFECYCLE (TKT-RS-LIFECYCLE) POSITIVE activation only post-registration; no implicit inherit PASS lifecycle clean PASS_POSITIVE_CONTROL
BAD-RS-C-001 RS-GROUP-C SCOPE_LIFECYCLE NEGATIVE activation before registration / implicit inherit FAIL premature activation RS_LIFECYCLE_PREMATURE_ACTIVATION
POS-RS-D-001 RS-GROUP-D QUORUM (TKT-RS-QUORUM) POSITIVE total Q-order Q00<…<Q50; lowest matching wins; eval-unit defined PASS quorum clean PASS_POSITIVE_CONTROL
BAD-RS-D-001 RS-GROUP-D QUORUM NEGATIVE Q-order not total / two matching Q-codes / eval-unit undefined FAIL non-total order RS_QUORUM_ORDER_NONTOTAL
POS-RS-E-001 RS-GROUP-E REPLAY_IDEMPOTENCY (TKT-RS-REPLAY) POSITIVE G02a/G02b/G02c disjoint; domain-restricted PASS replay clean PASS_POSITIVE_CONTROL
BAD-RS-E-001 RS-GROUP-E REPLAY_IDEMPOTENCY NEGATIVE G02a/b/c not disjoint / in-flight used as a code FAIL non-disjoint classes RS_REPLAY_CLASS_NONDISJOINT
POS-RS-F-001 RS-GROUP-F COUNT_ORACLE (TKT-RS-COUNT) POSITIVE 84−1+3=86; one canonical code per scenario; filename↔title numeric consistent PASS count clean PASS_POSITIVE_CONTROL
BAD-RS-F-001 RS-GROUP-F COUNT_ORACLE NEGATIVE count ≠ 86 / dual code / filename↔title numeric mismatch FAIL non-canonical count oracle RS_COUNT_ORACLE_NONCANONICAL
POS-RS-G-001 RS-GROUP-G CODEX_PACKET (TKT-RS-CODEX-PACKET) POSITIVE verdict/gate/count/next-step identical across index↔decision↔packet↔rollup; links resolve PASS packet consistent PASS_POSITIVE_CONTROL
BAD-RS-G-001 RS-GROUP-G CODEX_PACKET NEGATIVE verdict/gate/count/next-step inconsistent / broken link / a PASS upgraded FAIL packet inconsistent RS_CODEX_PACKET_INCONSISTENT

4.7. Family DESIGN_LINT + cross-cutting + Phase-3 split

validator_namespace as noted · these are cross-cutting invariants (not a single base/RS brick) and the Phase-3 root split.

fixture_id target type input_shape check_status probe_outcome canonical_outcome_code ns phase
BAD-RS-001 RS provenance / no-auto-promote (08 §5) NEGATIVE RS5B BI0x draft promoted/applied as a generic, validated rule FAIL RS5B draft promoted FAIL_RS5B_DRAFT_PROMOTED DESIGN_LINT PHASE1_DESIGN
BAD-PROP-001 aggregate combiner / truth table (06) NEGATIVE an L0 HOLD treated as PASS FAIL HOLD treated as PASS FAIL_HOLD_TREATED_AS_PASS DESIGN_LINT PHASE1_DESIGN
BAD-PROP-002 aggregate combiner / truth table (06) NEGATIVE an out-of-scope N/A used to upgrade the aggregate FAIL N/A upgrades aggregate FAIL_NA_UPGRADES_AGGREGATE DESIGN_LINT PHASE1_DESIGN
BAD-NVSZ-003 root-provisioning (07 §2, Phase 3) NEGATIVE an agent-invented root at root acceptance FAIL invented root (root-provisioning) ROOT_E4 NVSZ_ROOT PHASE3_NVSZ

BAD-PROP-001/002 and BAD-RS-001 previously carried prose/config-error results (Codex #4). They now carry one DESIGN_LINT code each. They are also enforced at runtime by the Phase-2 combiner per the 06 truth table (row 2 for HOLD; rows 9/10 for N/A no-upgrade); the canonical fixture is the design-review-time lint with a single code.


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

The oracle maps each fixture_id → exactly one canonical_outcome_code (this file, §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 (RS_COUNT_ORACLE_NONCANONICAL analog). Count of such defects in this catalog = 0 (see patch1/06).
No fixture file or oracle file is created in Phase 1. NOT_IMPLEMENTED · NOT_AUTHORIZED_FOR_RUNTIME.
The authoritative catalog for review is THIS file; it additively supersedes the outcome cells of 17 and 12 (which remain revision 1).
Back to Knowledge Hub knowledge/dev/laws-new/tool-kiem-thu-lego/phase1-design/patch1/01-canonical-fixture-oracle-schema-2026-06-22.md