RS-TKT-1-PATCH1B · 03 Total Brick and Contract Coverage Ledger
RS-TKT-1-PATCH1B · 03 — Total Brick and Contract Coverage Ledger
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 F5 (coverage not proven) and F6 (per-brick contract completeness not mechanical). Merges and strengthens patch1/02 (coverage) + patch1/03 (280 contract fields) into one ledger and adds the five LEGO boundary present-checks.
Required brick set = union of 03 §6 (base levels + four L3 bricks) and 08 §6 (seven RS groups) = 14 bricks, in the macro §4.3 order. Fixtures are referenced from catalog 02.
1. Brick coverage + contract ledger (macro §4.4 columns)
CFT = contract_fields_total · CFP = contract_fields_present · CFM = contract_fields_missing · boundary columns: B=birth T=test C=change R=rollback K=composition.
| brick_id | brick_type | design_file | contract_file | positive_fixture_id | negative_fixture_id | adversarial_fixture_id | CFT | CFP | CFM | B | T | C | R | K | coverage_status |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| TKT-L0-FILE | BASE_LEVEL | 02 §2 / 03 | PATCH1 07 (P7) | POS-L0-001 | BAD-L0-001 (+002/003/004) | BAD-PROP-001 | 20 | 20 | 0 | YES | YES | YES | YES | YES | COVERED |
| TKT-L1-PACKET | BASE_LEVEL | 02 §3 | PATCH1 04 (P4) | POS-L1-001 | BAD-L1-002 (+BAD-L1-001 HOLD) | — | 20 | 20 | 0 | YES | YES | YES | YES | YES | COVERED |
| TKT-L2-FAIL-CLOSED | BASE_LEVEL | 02 §4 / 04 | PATCH2 01 (P1) | BAD-FC-003 (+BAD-FC-005) | BAD-FC-001 (+002/004/006/007/008) | BAD-PROP-001/002 | 20 | 20 | 0 | YES | YES | YES | YES | YES | COVERED |
| TKT-L3-AUTHORITY-FIREWALL | L3_BRICK | 05 §1 | PATCH1 02 (P2) | POS-L3-AF-001 | BAD-L3-AF-001 | BAD-L3-001 / BAD-RS-001 | 20 | 20 | 0 | YES | YES | YES | YES | YES | COVERED |
| TKT-L3-CLAIM-AUDIT | L3_BRICK | 05 §2 | PATCH1 02 (P2) | POS-L3-CA-001 | BAD-L3-CA-001 | BAD-L3-001 | 20 | 20 | 0 | YES | YES | YES | YES | YES | COVERED |
| TKT-L3-IDENTITY | L3_BRICK | 05 §3 | PATCH1 02 (P2) | POS-L3-ID-001 | BAD-L3-ID-001 (+002) | BAD-L3-001 | 20 | 20 | 0 | YES | YES | YES | YES | YES | COVERED |
| TKT-L3-NVSZ | L3_BRICK | 05 §4 / 07 | PATCH1 05 (P5) | POS-L3-NVSZ-001 | BAD-NVSZ-001 (+002 ESCROW_E9) | BAD-L3-002 / BAD-NVSZ-003 (Phase 3) | 20 | 20 | 0 | YES | YES | YES | YES | YES | COVERED |
| RS-GROUP-A PACKAGE | RS_GROUP | 08 §6 | PATCH2 02 (P6) | POS-RS-A-001 | BAD-RS-A-001 | — | 20 | 20 | 0 | YES | YES | YES | YES | YES | COVERED |
| RS-GROUP-B GATE | RS_GROUP | 08 §6 | PATCH2 02 (P6) | POS-RS-B-001 | BAD-RS-B-001 | BAD-RS-001 | 20 | 20 | 0 | YES | YES | YES | YES | YES | COVERED |
| RS-GROUP-C SCOPE_LIFECYCLE | RS_GROUP | 08 §6 | PATCH1 06 | POS-RS-C-001 | BAD-RS-C-001 | — | 20 | 20 | 0 | YES | YES | YES | YES | YES | COVERED |
| RS-GROUP-D QUORUM | RS_GROUP | 08 §6 | PATCH1 06 | POS-RS-D-001 | BAD-RS-D-001 | — | 20 | 20 | 0 | YES | YES | YES | YES | YES | COVERED |
| RS-GROUP-E REPLAY_IDEMPOTENCY | RS_GROUP | 08 §6 | PATCH1 06 | POS-RS-E-001 | BAD-RS-E-001 | — | 20 | 20 | 0 | YES | YES | YES | YES | YES | COVERED |
| RS-GROUP-F COUNT_ORACLE | RS_GROUP | 08 §6 | PATCH1 06 | POS-RS-F-001 | BAD-RS-F-001 | — | 20 | 20 | 0 | YES | YES | YES | YES | YES | COVERED |
| RS-GROUP-G CODEX_PACKET | RS_GROUP | 08 §6 | PATCH1 06 | POS-RS-G-001 | BAD-RS-G-001 | — | 20 | 20 | 0 | YES | YES | YES | YES | YES | COVERED |
The
adversarial_fixture_idcolumn references the cross-cutting ADVERSARIAL-typed fixtures (catalog02 §7) that exercise a design-wide invariant touching that brick. These are NOT part of the 14-brick positive/negative coverage count (a brick is COVERED by its own positive + negative fixtures); one ADVERSARIAL fixture may relate to several bricks.—= the brick's own NEGATIVE fixtures already serve as its attack set (e.g. L2's BAD-FC-001/002/004/006/007/008).
2. The 20 mandatory contract fields (03 §1) and their per-brick source
Verified for each of the 14 bricks (14 × 20 = 280 field checks). Each ✓ in the completeness matrix below = field defined for that brick, traceable to the source.
| # | field_name | base (L0/L1/L2) source | L3 bricks source | RS groups source |
|---|---|---|---|---|
| 1 | checker_id | 03 §6 | 03 §6 | 03 §6 / 08 §6 |
| 2 | component_id | 03 §6 | 03 §6 / 05 | 03 §6 / 08 §6 |
| 3 | purpose | 02 §2/§3/§4 | 05 §1–§4 | 08 §6 |
| 4 | scope | 02 (packet surface per level) | 05 (input contract) | 08 §6 |
| 5 | input contract | 02 §2/§3/§4 | 05 §1–§4 | 08 §6 |
| 6 | output contract | 03 §3 (shared schema) | 05 §1–§4 + 03 §3 | 03 §3 |
| 7 | dependency | 02 §1 (L0→L1→L2→L3) | 05 (L0+L1+L2 PASS) | 08 §7 (run order on Base) |
| 8 | bad input | 04 §8 / 02 | 05 §1–§4 | patch1b 02 §5 + 08 §6 |
| 9 | expected reject | 04 §7 / 02 | 05 §1–§4 | patch1b 02 §5 |
| 10 | failure code | 04 §7 / 02 §2 | 05 §1–§4 / 07 §2 | patch1b 01 §3 (RS_*) |
| 11 | hold code | 04 §7 (HOLD_OUTPUT_SURFACE_UNAVAILABLE) |
05 (same) | patch1b 01 §3.1 (same) |
| 12 | evidence requirement | 03 §3 (path#line/count/sha256/quote) | 03 §3 + 05 | 03 §3 + 08 §6 |
| 13 | out-of-scope | 02 (per level) | 05 §1–§4 / §7 | 08 §7 / 01 §7 |
| 14 | birth boundary | 02 (born from level policy) | 05 (born from policy) | 08 (born from 06/PATCH2 02) |
| 15 | test boundary | 02 / patch1b 02–03 (pos+neg) | 05 + patch1b 02 | patch1b 02 §5 + 03 |
| 16 | change boundary | 03 §1 (predicate only) | 05 (rule set only) | 03 §1 (predicate only) |
| 17 | rollback boundary | 03 §1 / 02 (read-only ⇒ discard) | 05 (rollback=discard) | 03 §1 (discard) |
| 18 | composition contract | 03 §3/§7 (shared schema only) | 05 (no cross-brick read) | 03 §7 / 08 §7 |
| 19 | authority_effect | 03 §3 (NONE) | 05 (NONE) | 03 §3 (NONE) |
| 20 | registration_effect | 03 §3 (NONE) | 05 (NONE) | 03 §3 (NONE) |
3. Completeness matrix (brick × field — ✓ = present and traceable; 14 × 20 = 280 cells)
| brick_id | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| TKT-L0-FILE | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| TKT-L1-PACKET | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| TKT-L2-FAIL-CLOSED | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| TKT-L3-AUTHORITY-FIREWALL | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| TKT-L3-CLAIM-AUDIT | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| TKT-L3-IDENTITY | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| TKT-L3-NVSZ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| RS-GROUP-A PACKAGE | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| RS-GROUP-B GATE | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| RS-GROUP-C SCOPE_LIFECYCLE | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| RS-GROUP-D QUORUM | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| RS-GROUP-E REPLAY_IDEMPOTENCY | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| RS-GROUP-F COUNT_ORACLE | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| RS-GROUP-G CODEX_PACKET | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Fields 8/9/10/11/15 for the RS groups were previously implicit (only
08 §6purposes). PATCH1B (via catalog02 §5and registry01 §3) additively supplies them — design-doc completion of an already-governed contract; no runtime/authority created.
4. LEGO boundary present-check (each brick can be born / tested / changed / rolled back / composed separately)
birth boundary : every brick is born from its own level/group policy (02 / 05 / 08) — not a mega-birth pipeline. present = 14/14
test boundary : every brick has its own positive + negative fixtures (catalog 02; §1 here). present = 14/14
change boundary : every brick changes only its own rule set / predicate (03 §1; 05). present = 14/14
rollback boundary : every brick is read-only ⇒ rollback = discard local result; no shared mutable state (03 §1). present = 14/14
composition contract : bricks compose ONLY through the shared output schema (03 §3/§7); no cross-brick internal read (05 §6). present = 14/14
⇒ LEGO separability holds for all 14 bricks. No mega-registry / mega-graph / mega-birth introduced (mega_system_drift_findings = 0, see 07).
5. Effects spot-check (fields 19/20 constant NONE)
Every brick: authority_effect = NONE (field 19), registration_effect = NONE (field 20).
Source: 03 §3 ("authority_effect and registration_effect are ALWAYS the constant NONE") + 05 per-brick "NONE / NONE".
bricks_with_non_NONE_effect = 0.
6. Numeric rollup (counted in 07)
total_bricks_required = 14 (3 base levels + 4 L3 bricks + 7 RS groups; union 03 §6 ∪ 08 §6)
total_bricks_covered = 14
uncovered_bricks = 0
missing_positive_controls = 0
missing_negative_fixtures = 0
bricks_classified_HOLD_no_positive= 0 (every brick has a paper positive control over inert fixtures)
mandatory_fields_per_brick = 20
total_contract_field_checks = 280
present_field_checks = 280
missing_mandatory_contract_fields = 0
birth/test/change/rollback/composition boundaries present = 14/14 each (70/70 boundary checks)
authority_effect_not_none = 0 · registration_effect_not_none = 0
⇒ brick coverage + contract completeness + LEGO boundaries COMPLETE. If any count above were nonzero, the verdict would drop to RS_TKT_1_PATCH1B_HOLD_COVERAGE_INCOMPLETE.