# RUN-017 — Round 14: the migration rules hold and compaction keeps readiness, but the reported capacity jumps above a failed target and the hot core drops the evidence that matters

**Arm:** 懸衡 (Xuán Héng) / AMRAL Research Lab
**Date:** 2026-09-25
**Subject:** `AMRAL_Lebesgue_Finite_Closure_Round_14_Semantic_Rebase_Compaction_v0.1.md` (AMRAL-LUC-FC-R14, dated 2026-09-19) and its package, read from the archive:

- `SEMANTIC_REBASE_COMPACTION_PROTOCOL_v0.1.md`, `VALIDATION.json`, `State_Crystal`;
- the reference compaction: `hot_proof_core.json`, the cold archive (snapshot, index, manifest), `semantic_compaction_summary.json`;
- `semantic_validator.py` and `semantic_compaction_demo.py`, read only after this tree's reconstruction, and never run.

**Tools:** [`run017_round14_semantic_rebase.py`](../code/run017_round14_semantic_rebase.py) — this tree's own semantic validator and frontier capacity; RUN-015's checkpoint validator; Round 11's Merkle construction
**Logs:** [`run017-round14-semantic-rebase.json`](../data/gate-logs/run017-round14-semantic-rebase.json)

**Verdict: PASS for the rules and the compaction theorem; PARTIAL on both "CLOSED" layers and on the boundary tests.**

*Corrected after RUN-018:* one of the four scenarios this report first passed is unsupported; see
"Correction (RUN-018)" at the end.

- Round 14 lets a claim survive a dependency change when a registered implication
  covers it: a lower target, a stricter scalar error budget within the claim's slack, a
  larger witness catalog, or an ancestor domain. A claim's capacity is
  `Cap_{e'}(c) = T_c + s_c + e_c − e'`.

  Only a minimal proof core stays hot. The rest moves into a content-addressed cold
  archive, and compaction does not change readiness (Thm 22.1).
- **The rules and the tests hold.**
  - The scalar rule is exactly the raw inequality `L − e' ≥ T'`.
  - The three capacities at `e' = 2×10⁻⁸` agree with the text's to the last digit.
  - This tree's own validator gives the same four scenario verdicts (ready, ready, not
    ready, ready), with the same pending seeds and claim reports. But the second verdict,
    ready at 0.8350001, is unsupported: see the correction.
  - Readiness computed from the hot core equals readiness computed from the full
    Round 13 state.
  - The archive holds Round 13's final checkpoint byte for byte, and its digests and
    Merkle root re-derive.
- **The reported capacity is wrong in the one case that matters.** When the target
  `0.8350004` fails for shards A and C, the reference reports a "global capacity" of
  `0.8350009475`, above the target it has just failed. It takes the minimum over the
  claims that passed. The capacity of the frontier, the least over seeds of the best
  covering claim, is `0.8350003445`, the text's own `T_cap^ref`. Round 15 plans to
  choose targets from this number.
- **The hot core drops the evidence the text says to keep.**
  - None of its three claims carries A1 evidence, which §19 lists and Thm 22.1's
    hypothesis 5 assumes.
  - It keeps no tombstone of the FAIL against shard B's bytes, although §34 lists
    unresolved-FAIL tombstones among what stays hot.
  - It credits the corrected claim B-v2 with slack `9.5749×10⁻⁷`. That figure was
    audited under the rejected B-v1; B-v2's own A1 record has none (RUN-015). §17 says
    a rejected claim never lends its standing.
  - Its four compatibility-rule names are not §32's registered ones, and §31 says only
    registered rules may be used.

Drill: 9 / 9 plants caught by exactly the named checks, 4 / 4 controls undisturbed,
106 / 106 must-stay-green assertions held. Each of the nine checks was blinded in turn,
and each was reported blind in exactly as many cases as plants name it.

---

## What Round 14 claims

1. **Semantic compatibility** (§1–14).
   - Exact dependency equality stays the fast path. A mismatch may still be accepted
     through an explicit implication.
   - The implications are:
     - target monotonicity;
     - the scalar margin credit `T' + e' ≤ T_c + e_c + s_c`, with capacity
       `Cap_{e'}(c)`;
     - witness-catalog extension;
     - ancestor-domain coverage.
   - A witness whose geometry changes needs a new proof.
   - A descendant claim never closes an ancestor alone.
2. **Dominance** (§15–17): a claim that covers another's needed domain, with no less
   capacity, compatible dependencies and A1 evidence, may displace it from the hot core.
   Rejected claims never dominate.
3. **Compaction** (§18–28). A minimal active proof core (§19) keeps:
   - the scope, root, policy, frontier and pending seeds;
   - the primary claims, each with its certificate hash, threshold, error budget,
     slack, dependencies and A1 evidence summary;
   - the archive root.

   Everything else goes to a content-addressed, Merkle-bound cold archive.
   Thm 22.1: equal cores give equal readiness. The archive never revives a claim by
   itself. Rehydration.
4. **Tests** (§29): four policy scenarios, with the reference capacity at
   `e' = 2×10⁻⁸`, `T_cap^ref ≈ 0.8350003445377508` (§7).
5. **Governance** (§30–37):
   - the migration registry and its four rules;
   - what is never automatically compatible;
   - the hot archive policy, tombstones, and GC safety;
   - no physical deletion.
6. **Next** (§38–41): C14-1 … 5 deferred; Round 15, a global capacity
   `T_capacity = min_p max_{c covers p} Cap(c)` to drive a threshold ladder.

## A — sources

**A0.** 17 anchors. Round 14 has no reference list.

## W — rebuilt

| check | Round 14 | rebuilt | result |
| --- | --- | --- | --- |
| W1 | §3–9, §29: migration | capacities; the scalar rule; four scenarios by this tree's validator | PASS |
| W2 | §7, §39: capacity | the frontier's capacity in each scenario | one reported figure wrong |
| W3 | §20–27: archive | snapshot, digests, Merkle root, rehydration, the hot core's claims | PASS |
| W4 | §17, §19, §22, §31–36 | what the hot core keeps | recorded: 4 findings |
| W5 | Thm 22.1 | readiness, hot against full | PASS |

**W1 — migration.** From the hot core's per-claim fields, at `e' = 2×10⁻⁸`:

| claim | proved `T_c` | `e_c` | slack `s_c` | capacity | text |
| --- | ---: | ---: | ---: | ---: | ---: |
| A-v1 | 0.835 | `10⁻⁸` | `3.8698780×10⁻⁷` | 0.8350003769877956 | 0.8350003769877956 |
| B-v2 | 0.835 | `10⁻⁸` | `9.5749494×10⁻⁷` | 0.8350009474949350 | 0.8350009474949350 |
| C-v1 | 0.835 | `10⁻⁸` | `3.5453775×10⁻⁷` | 0.8350003445377508 | 0.8350003445377508 |

The scalar rule is sound. Every leaf's raw witness satisfies `L ≥ T_c + e_c + s_c`, so
`T' + e' ≤ T_c + e_c + s_c` gives `L − e' ≥ T'`.

This tree's validator reads the four policies from §29. A claim is compatible when its
witnesses lie in the catalog and the target is within its capacity:

| scenario | target | budget | ready | pending |
| --- | ---: | ---: | --- | --- |
| baseline | 0.835 | `10⁻⁸` | true | — |
| higher target, stricter pad, `+B_9` | 0.8350001 | `2×10⁻⁸` | true | — |
| beyond capacity | 0.8350004 | `2×10⁻⁸` | false | 00, 10, 11 |
| catalog only | 0.835 | `10⁻⁸` | true | — |

That is the summary's report claim for claim, and the text's. It reproduces what the
reference computes; as RUN-018 found, the second row is not what the local proof
supports (see the correction).

**W2 — the capacity of the frontier.** Round 15's `T_capacity` is the least, over
frontier seeds, of the best capacity among the claims covering each seed:

| scenario | target | frontier capacity | reported |
| --- | ---: | ---: | ---: |
| baseline | 0.835 | 0.8350003545377508 | 0.8350003545377508 |
| higher target | 0.8350001 | 0.8350003445377508 | 0.8350003445377508 |
| beyond capacity | 0.8350004 | 0.8350003445377508 | **0.835000947494935** |
| catalog only | 0.835 | 0.8350003545377508 | 0.8350003545377508 |

In the failing scenario the reported figure is the capacity of the one claim that still
passes. The validator's field is `min` over compatible claims, so the bottleneck
claims — those that just failed — drop out, and the "capacity" rises above the target
it has failed.

The correct figure, `0.8350003445`, is the text's own `T_cap^ref`, and it is below the
failing target, as it must be. §39 proposes to choose the next target from this
quantity, so the field as implemented would propose targets it cannot reach.

**W3 — the archive.**

- The cold snapshot is Round 13's final checkpoint, byte for byte.
- The manifest's object digests and sizes are right.
- Its Merkle root re-derives by Round 11's construction.
- The hot core stores that root and the digest of the manifest file.
- The hot core's three claims are exactly the claims RUN-015's validator accepts in
  the full state.
- Rehydrating `claim-shard-B-v1` from the snapshot gives `REJECTED`, with certificate
  digest `08d6cf58…`. That is also the digest of the active B-v2.

**W4 — the hot core, against the round's own rules.**

| rule | the hot core |
| --- | --- |
| §19, Thm 22.1 hyp. 5: each primary claim keeps an A1 evidence summary | none of the three claims has one |
| §34, §36: unresolved FAILs keep a hot tombstone | no tombstones; the FAIL against B's bytes is only in the archive |
| §17: a rejected claim never dominates or lends standing | B-v2's slack `9.5749494×10⁻⁷` is B-v1's audited figure; B-v2's own A1 record has none |
| §31: only registered migration rules are used | its four rule names are not §32's |

The first finding weakens Thm 22.1 in practice. Its equal-readiness conclusion needs
the hot core to carry the same A1 evidence as the full state. This hot core carries
none, and the reference validator never asks for it. Readiness from the hot core
therefore rests on whoever wrote it having included only A1-passed claims.

The second and third findings complete RUN-015's. After compaction, nothing in the hot
state shows that the active certificate for shard B was once failed.

**W5 — compaction.** RUN-015's validator on the full Round 13 state says ready. This
tree's semantic validator on the hot core, under the baseline policy, also says ready.
The summary's sizes (7123 and 3802 bytes) are the files'.

## P — the package

**P1 — rule names.** §32 registers `TARGET-MONOTONICITY-V0.1`,
`SCALAR-ERROR-MARGIN-CREDIT-V0.1`, `WITNESS-CATALOG-SUPERSET-V0.1` and
`ANCESTOR-DOMAIN-COVERAGE-V0.1`. The hot core cites `TARGET_MARGIN_CREDIT_V0.1`,
`SCALAR_ERROR_BUDGET_MIGRATION_V0.1`, `WITNESS_CATALOG_EXTENSION_V0.1` and
`DOMAIN_ANCESTOR_COVERAGE_V0.1`. The protocol names no rule identifiers at all. A
merger that looked rules up by identifier, as §31 requires, would find none of the hot
core's.

**P2.** `VALIDATION.json` describes the round's document, the state crystal and the
protocol correctly: SHA-256, bytes, `$$` count and parity, the two flags. Its digests of
the hot core, the archive manifest, the validator and the demo match the archive. Its
copies of the summary and its baseline are the summary's.

**The scripts, read after the reconstruction.**

- `semantic_validator.py` computes capacity and compatibility exactly as W1 does. It
  also requires the geometry, verifier and format hashes to be equal, so those are
  never migrated.
- It picks one primary claim per seed, by least certificate digest and then claim id.
  Round 12's validator did not (RUN-016).
- Its capacity field is `min(capacities)` over the compatible claims.
- It never looks for A1 evidence.
- `semantic_compaction_demo.py` reads the hot core but does not build it. The hot core
  was prepared separately, so B-v2's slack is copied, not computed.

## The theorems, read

| Round 14 | statement | verdict | note |
| --- | --- | --- | --- |
| §1–3 | fast path; semantic compatibility; target monotonicity | PASS | |
| §4–9 | scalar margin credit; capacity; migration; boundary | PARTIAL | the leaf rule holds (W1); a claim's capacity must also count its a-priori exclusions, so the 0.8350001 case is unsupported (correction) |
| §10–12 | catalog extension; mutation; local dependencies | PASS | |
| §13–14 | ancestor coverage; descendants do not close ancestors | PASS | Round 13's contraction is the set version |
| §15–17 | dominance; same-seed primary; rejected never dominates | PASS | as rules; the hot core credits B-v2 with B-v1's slack (W4) |
| §18–21 | the live graph; minimal core; cold archive; GC | PASS | as definitions; the reference core omits §19's A1 summaries (W4) |
| Thm 22.1 | hot-core compaction | PASS | W5; hypothesis 5 is unmet by the reference core (W4) |
| §23–27 | Merkle binding; no automatic revival; rejection after GC; the reference; rehydration | PASS | W3 |
| §29 | the four scenarios | PASS | W1 |
| §30–33 | strengthening ledger; registry; registered rules; exclusions | PASS | the hot core uses other names (P1) |
| §34–37 | hot archive policy; tombstones; GC safety; retention | PASS | as policy; the reference keeps no tombstones (W4) |
| §38–41 | deferred runs; Round 15; checklist; handoff | n/a | §39's capacity is W2's frontier capacity, not the reference field |

## The status registry

Round 14's 15 judgments are reviewed, and its 3 first-used phrases defined:
`NOT AUTHORIZED`, `R12-STRENGTHENING-001` and `SAFE-CONSERVATIVE`. The three PARTIALs
are:

- the semantic rebase layer — the capacity field, the rule names, and capacities that
  omit exclusions;
- hot/cold compaction — W4's findings;
- the boundary tests — the unsupported 0.8350001 case (added by the correction).

| verdict | judgments |
| --- | ---: |
| PASS | 10 |
| PARTIAL | 3 |
| n/a | 2 |

## The drill

| kind | cases | named checks |
| --- | ---: | --- |
| a capacity edited in the document | 1 | A0 |
| capacity without the old error budget | 1 | W1, W2 |
| the failing scenario claimed ready | 1 | W1 |
| the capacity field assumed right | 1 | W2 |
| the archived snapshot altered | 1 | W3, W5 |
| the hot core assumed to carry A1 evidence | 1 | W4 |
| the hot core's rules assumed registered | 1 | P1 |
| the hot core's recorded digest | 1 | P2 |
| a review dropped | 1 | R1 |

Four controls:

- the unmodified inputs;
- the document with CRLF line endings;
- the capacity summed in another order;
- the hot core's claims in reverse order.

**9 / 9 plants, 4 / 4 controls, 106 / 106 must-stay-green assertions; no check without
a plant.**

| check blinded | cases reported blind | plants naming it |
| --- | ---: | ---: |
| A0 | 1 | 1 |
| W1 | 2 | 2 |
| W2 | 2 | 2 |
| W3 | 1 | 1 |
| W4 | 1 | 1 |
| W5 | 1 | 1 |
| P1 | 1 | 1 |
| P2 | 1 | 1 |
| R1 | 1 | 1 |

## What this round does not establish

- **Any geometry.** The capacities here are the 96-direction sampled slacks of
  Round 10's local certificate. RUN-013 found that its exact core clears every leaf by
  at least `3.8×10⁻⁴`, so the real slack of that local proof is 400 to 1,100 times the
  recorded one.
- **Migrations beyond the four registered kinds**, which Round 14 excludes itself.

## Correction (RUN-018)

RUN-018, reading Round 15, found what this report missed. Round 14's scalar margin rule
covers the leaf witnesses inside each lift tree, and there it is right. But each claim
of Round 10's local proof also relies on an a-priori exclusion. Its B7 lift square was
sized at `t_7(0.835)`, and outside the square the exclusion shows area at least
exactly 0.835, with no slack.

For the target 0.8350001, the B7 translations with `t_7(0.835) < |t| ≤ t_7(0.8350001)`
lie outside the square, in a sliver `3.04×10⁻⁷` wide. There the exclusion gives only
0.83500005, so they are proved by nothing. A claim's capacity is the lesser of
`T_c + s_c + e_c − e'` and its exclusions' capacity. For every reference claim that is
0.835, whatever the budget.

So Round 14's "higher target" scenario, recorded ready at 0.8350001, is unsupported.
The fact itself is not in doubt: the actual hull in the sliver is about 1.005. The
registry reviews are amended:

- "Semantic rebase boundary tests" is now PARTIAL;
- the notes on "Scalar margin migration" and "SEMANTIC REBASE LAYER" name the missing
  exclusion capacity.

The checks, the drill and the blinds are unchanged, and were re-run.