# EXTERNAL BAR — `independent-solver-anchors`

## The lab's own F2 line (verbatim, `CROWN_JEWELS_RESOLVED.md:139` at commit `cb6d9d7d`)

> **F2 — what would move the third-party axis to A.** Axis B — a system Genesis does not own already grades this one: Palace 3D-FEM grades our operator under the SEALED bar claims/palace_anchor_prereg_2026_09.json (sealed 2026-09-03, commit b27215b8): median advantage >=2.0x, win fraction >=0.80, >=12 fresh layouts, N in {6,7,8}. CORRECTED sprint S02: this note previously said the floor was hard-coded at verify_operator_vs_palace_gate.py:42 and NOT pre-registered. It was wrong on both counts by then - the floor was at :51, and the prereg had existed since 2026-09-03. What was true is that NOTHING READ IT. S02 wired the gate and the producer to take the bar from the seal and recompute the seal on every run, which surfaced a divergence the seal exists to catch: the producer required win fraction >=0.75 while the sealed bar requires >=0.80. The seal won. The run under this bar has ALREADY MISSED it on sample size - 5 fresh layouts against 12 (NEGATIVE_RESULTS.md N2) - so no new Palace anchor is claimed from it. FastCap 3D-BEM grades the operator under the SEALED bar claims/fastercap_baseline_prereg_2026_07.json (>=80% of layouts AND median >=2.0x) (bar recorded: `sealed (both anchors)`). To reach axis A, that same external system must be run against a bar **pre-registered before the run** and its own output cited. Today only Gate 97 (FastCap) and Gate 133 (Touchstone) sit under a content-sealed bar, and `PEER_REVIEW_2026-09.md:20-23` records axis A = 0 across this register.

## What an independent party would have to do to move this entry to axis A

1. **The bars already exist and are sealed.** The FastCap bar is `claims/fastercap_baseline_prereg_2026_07.json`
   (at least 80% of layouts, median at least 2.0x). The Palace bar is `claims/palace_anchor_prereg_2026_09.json`
   (median advantage at least 2.0x, win fraction at least 0.80, at least 12 fresh layouts, N in {6,7,8}). The lab's
   own F2 line records that the Palace run under that bar has already MISSED it on sample size (5 fresh layouts
   against 12).
2. **Run the external solvers themselves.** On their own machine, with their own FastCap 2.0 and Palace (0.16.0
   here) builds, run the three legs at the named commit. For axis A, run at least 12 fresh Palace layouts, not 5,
   and cite the solvers' own output files.
3. **What they need.** A workstation with FastCap and Palace (Palace needs MPI; the lab used a spack build). The
   clean run takes about 14 minutes here. The data is the files listed in `INPUTS.sha256`.

## What would falsify the claim

- A FastCap or Palace run under the sealed bar in which the operator does not beat pairwise superposition, or wins
  on fewer layouts than the bar requires.
- A live re-derivation of a stored layout that differs from the stored advantage by more than 10%. This packet's
  `DEFECT.json` plants exactly that.
- A reconciliation that cannot account for the absolute BEM-2D/Palace gap. The lab discloses that gap separately,
  and does not gate it.