[Jammy2211]

Summary

This is B5b-2 of the search-extensibility epic. It closes scored wave 2: it pulls and judges the probe-first remainder (RAL job 409930), publishes the wave-2 records under a sharded summary contract, and applies the catalogue-ordering ruling. Closes #12.

Remainder.

• 409930 ran 20 of 20 array tasks to COMPLETED, from 16:08 to 17:38 UTC (wall 1:30).
• The rows were pulled with a 12-way per-directory tar on the login node (1.9 MB compressed), which brought back 1,000 rows. 980 are new. The other 20 are the probe rows, and they are byte-identical to the committed ones.
• judge_wave2.py admits all 12,750 wave-2 rows at the pin df6d218f10cd, with 0 refused.
• The 13,000 expected runs break down into 11,580 rows, 1,170 failed attempts, 0 missing, 0 operational kills and 250 deferred.
• Every leg is now closed except the deferred blend warm-NUTS leg.

The probe-first legs under gaussian_x3@2:

Leg	Blend	Separated
NSS 50-step (JAX)	158/250 (63 %), 33 s per right answer: #1 evidence	210/250 (84 %), 24 s: #1 evidence
Zeus (JAX)	0/250 (236 fail §4(b)1): unreliable	190/250 (76 %), 136 s: #1 posterior

No run came near its timeout: NSS took at most 29 s against a 600 s timeout, and Zeus at most 131 s against 1168 s.

Ruling 2 (ordering).

• Within one task and one dataset, the ranking now includes only legs with a success rate ≥ 50 % over ≥ 20 attempts.
• The other closed legs are listed under unreliable with their numbers. In the README they show "unreliable" in the # column.
• Every row shows its attempts and its success rate (Wilson 95 %).
• RANK_FLOOR lives in build_catalogue.py.
• Protocol §8 gains a boxed note marked post-hoc, adopted 2026-10-15 after seeing the wave-2 data, plus §11 N1, which explains why the note is not an amendment. The pre-registered rules are untouched.
• Effect on the blend evidence task: DynestyStatic (14 %) no longer leads; it is listed as unreliable.

Ruling 1 (records).

• dashboard/summary.json is now an inference-summary@3 index. Its record_shards list names 101 per-protocol, per-leg files under dashboard/records/, each with its sha256 and record count, and each written one record per line.
• The largest shard is 1.56 MB; all shards together are 66 MB.
• The 223 pilot records keep their @1 verdicts in the gaussian_x3@1 shards.
• The fixture test validates the shards natively when the PyAutoInsight checkout reads @3. Otherwise it validates them as assembled @1 records, which is the case in CI today, against Insight main.

Commits.

• Rows: 96008ba.
• Tooling: 7c7af64.
• Docs: b9f5927.
• Catalogue: c3a81d1.
• Summary: 74b834f.
• Review fixes: 72845c0, 6a22a95, 719c2f3, ed38ade, 035d4f4.
• output/ is never committed.

Decisions taken (decide-and-flag)

1. The contract version is inference-summary@3, not @2. This needs your sign-off. Ruling 1 named @2, but PyAutoInsight's @2 already exists: it is the setups/prepared-problems contract that instance lens is pinned to. Reusing the number would have broken lens. The per-protocol split therefore takes the next free version, @3. It keeps @1's envelope and record contract unchanged and holds the records in shard files. @3 does not include @2's setups.
2. Shards are split per leg, not just per protocol. A single gaussian_x3@2 file would hold 12,750 records and still be far above 50 MB. The ruling allowed "an equivalent per-leg layout", so there is one shard per protocol × dataset × search × settings × config. That gives 101 shards; the largest is 1.56 MB and the total is 66 MB. Each shard is written one record per line, and each shard's sha256 is in the index, so a refresh re-copies only the shards that changed.
3. The Insight pin moves to @3 with migrating_from: inference-summary@1. Without that field, the committed @1 fit snapshot would fail check --offline from the moment the pin moves. With it, the old capture stays valid last-good evidence, labelled "awaiting the first refresh". A fresh fetch must still return @3.
4. The ordering floor is a §8 note plus §11 N1, not an amendment. The note was written after the wave-2 rows existed, so under the change rule it cannot be a criterion, and it is not one: it changes no verdict, threshold, headline number or protocol version.
5. Zero-success closed legs count as "unreliable". They fall below the floor like any other leg under 50 % (rate 0 %, numbers shown). Open legs and legs that cannot be assessed are listed last, with no label.

Order and next steps (human)

Merge in this order: this PR → PyAutoCortex → PyAutoInsight.

• Merge PyAutoInsight right after this PR. Insight's nightly cron (03:55 UTC) still runs the @1 reader. If it runs between the two merges, it records an unsupported receipt for fit and Insight's check --offline goes red until the next refresh.
• The Insight PR's Dashboard Refresh dry run reads this repository's main, so it can only go green after this PR merges.
• When the Insight PR merges, its push-triggered Dashboard Refresh captures fit under @3. Then run bin/pyauto-insight check online and drop migrating_from from Insight's registry.yaml. Ruling 1's "check green online" is therefore not met yet: it is satisfied only by that post-merge capture.

Ship gate

Leg	Result
1 Tests	autofit_inference: 121 passed, against both Insight main and the branch; ruff check and format clean; all 7 --check gates green. PyAutoInsight: 204 passed; ruff clean; check --offline OK; board --offline rendered. PyAutoCortex: 65 passed; cortex.py check OK.
2 Smoke	n/a: no workspace smoke script is touched. check --from fit=<this branch> validates all 12,973 records in 101 shards.
3 Review	Two rounds by independent fresh-context Opus reviewers, each given the diffs only. Round 1: FINDINGS (0 blockers, 3 should-fix, 9 nits), all fixed. Round 2: CLEAN with 5 nits; 4 fixed, 1 left (a reliable leg with no wall estimate would fall through to the unjudged rows; it cannot happen with today's data, and a test catches it).
4 Heart	RED. Development-only override recorded on #12 (quoted below).
Witness	3 of 4 met, 1 partial. ✓ Every row of 409930 (980) pulled and judged under @2 at df6d218f1, and the four probe-sourced legs closed: three positioned, Zeus JAX blend recorded at 0/250, unreliable. ✓ Ordering ruled and protocol amended as a post-hoc §8 note (plus N1 and a state.md ruling line). ✓ Cortex 409930 moved into the log with wall 1:30. ◐ Records reach Insight under the chosen schema: shipped as @3 (see decision 1), with the registry bumped and check --offline green; check online and the fit snapshot refresh from main wait for the merges (human next step).

Heart RED — development-only override (quoted from #12)

Heart at the door: Heart: RED — Release RED; monitoring RED · 10/100 · 415 unresolved; [red] release validation FAILED (stage integrate); [red] PyAutoHands/workflows/Python Version Matrix: failure; [red] PyAutoHeart/workflows/Release Integrate: failure; [red] PyAutoMind/workflows/Lifecycle Drift: failure (cleared 2026-10-15 evening); [red] PyAutoArray/Tests: red; [red] autofit_workspace_test/Smoke Tests: red; [red] autogalaxy_workspace_test/Smoke Tests: red; [red] autolens_workspace_test/Smoke Tests: red; [red] Release validation: NOT release_ready; [red] Worktree drift; [red] autolens_inference: red; [red] autolens_profiling: red; [red] euclid_strong_lens_modeling_pipeline: red. Live human in session 6ffb59e9 answered AskUserQuestion "Yes, override for development (Recommended)" on 2026-10-15 for this launch. Permitted: commit, push, PR-open. Merge is a separate human act; this never reaches a release.

🤖 Generated with Claude Code