Rubbersheet polyfit: a 1/32 px offset change can discontinuously alter the final inlier set at critical_value=0.1

[s-sasaki-earthsea-wizard]

Summary

Under the settings the NISAR rubbersheet workflow passes to it (critical_value=0.1 and max_iterations=len(data); the function's own default budget is 50), isce3.math.offsets_polyfit.polyfit_offsets can turn a change of one correlation-grid step (1/32 px) in a single input offset into a wholesale change of the final inlier set and a fitted-surface jump three orders of magnitude above the continuous response. The module is byte-identical on develop and v0.25.16 (last touched by PR #173), so this is not a regression report. The question we would most like answered: is crit_value = 0.1 intended as a threshold on the componentwise standardized w-test statistic (classically of order unity to several), or was "0.1 px" the intent — and is the full rejection budget intentional? We sketch a few directions below and welcome comments; if useful, we can implement the ones you prefer and report comparative results.

Minimal reproduction (self-contained)

"""One-quantum (-1/32 px) change of ONE input offset discontinuously
changes the final inlier set of the isce3 rubbersheet polyfit
(pinned synthetic case; production fit settings)."""
import numpy as np
from isce3.math import offsets_polyfit as op

GRID = (41040, 52906)             # full radar grid of the real pair
SENSOR = dict(prf=1520.0, abw=1263.68013808518,
              rsr=48000000.0, rbw=40000000.0)  # workflow-call values
Q = 1.0 / 32.0                    # Ampcor correlation-grid quantum
CL = (0.4, 1.2, -0.6, 0.3, -0.2, 0.15)    # degree-2 truth, azimuth
CP = (-0.2, 0.5, 0.8, -0.25, 0.1, -0.3)   # degree-2 truth, range

# 30x30 sample grid; the driver sits at the node nearest the real
# driver's radar position and carries its real corr_peak 0.9485.
rng = np.random.default_rng(29)   # pinned existence-proof seed
lines = np.linspace(0, GRID[0] - 1, 30).round()
pixels = np.linspace(0, GRID[1] - 1, 30).round()
driver = int(np.argmin(abs(lines - 23405))) * 30 \
    + int(np.argmin(abs(pixels - 42589)))
ll, pp = (a.ravel() for a in np.meshgrid(lines, pixels, indexing="ij"))
n = ll.size
A = op.build_design_matrix(ll, pp, 2, 0, GRID[0], 0, GRID[1])
tl, tp = A @ np.array(CL), A @ np.array(CP)

coh = np.zeros(n, bool)           # small coherent elite in a junk
coh[rng.choice(n, size=int(round(0.08 * n)), replace=False)] = True
coh[driver] = True                # majority, as in production
dl = np.where(coh, tl + rng.normal(0.0, 0.02, n),
              tl + rng.uniform(-20.0, 20.0, n))
dp = np.where(coh, tp + rng.normal(0.0, 0.02, n),
              tp + rng.uniform(-20.0, 20.0, n))
w = np.where(coh, rng.uniform(0.3, 0.8, n),
             rng.uniform(0.02, 0.15, n))
dl[driver], dp[driver], w[driver] = tl[driver], tp[driver], 0.9485
dl = (np.round(dl / Q) * Q).astype(np.float32).astype(np.float64)
dp = (np.round(dp / Q) * Q).astype(np.float32).astype(np.float64)
w = w.astype(np.float32).astype(np.float64)
data = np.column_stack([np.arange(n, dtype=float), ll, pp, dl, dp, w])


def fit(d):                       # the production call shape
    return op.polyfit_offsets(
        d.copy(), degree=2, crit_value=0.1, max_iterations=len(d),
        minL=0, maxL=GRID[0], minP=0, maxP=GRID[1], **SENSOR)


base = fit(data)
flipped = data.copy()
flipped[driver, 3] -= Q           # THE perturbation: one azimuth
flip = fit(flipped)               # offset of one sample, one quantum

inl_b = set(base["inliers"][:, 0].astype(int))
inl_f = set(flip["inliers"][:, 0].astype(int))
gl, gp = np.meshgrid(np.linspace(0, GRID[0], 101),
                     np.linspace(0, GRID[1], 101), indexing="ij")
jl, _ = op.predict_offsets(gl, gp, flip["coefL"] - base["coefL"],
                           flip["coefP"] - base["coefP"], 2,
                           0, GRID[0], 0, GRID[1])
it = (flip["removed_indices"].index(driver)
      if driver in flip["removed_indices"] else None)
print(f"baseline: {len(base['removed_indices'])}/{n} removed, "
      f"driver {'IN the final inliers' if driver in inl_b else 'OUT'}")
print(f"flip    : driver removed at index {it} of "
      f"{len(flip['removed_indices'])} removals (0-based), "
      f"final inliers {len(inl_b)} vs {len(inl_f)}, "
      f"common {len(inl_b & inl_f)}")
print(f"jump    : induced azimuth-surface RMS "
      f"{np.sqrt(np.mean(jl.ravel() ** 2)):.3e} px")

Output (isce3 0.26.0-dev at 2919e1c97, numpy 1.26.4, thread env pinned to 1):

baseline: 868/900 removed, driver IN the final inliers
flip    : driver removed at index 832 of 870 removals (0-based), final inliers 32 vs 30, common 25
jump    : induced azimuth-surface RMS 2.751e-02 px

The only difference between the two fits is flipped[driver, 3] -= Q: one azimuth offset of one high-weight sample, moved by exactly one Ampcor correlation-grid step. Everything else — all 900 samples, all weights, all fit settings — is bit-identical. The script needs an isce3 Python environment (NumPy, and SciPy — the module under test imports it transitively); nothing else. An extended version of this case with 8 pass/fail checks lives in our benchmark repository: repro_polyfit_quantum_membership.py (8/8 PASS in the two software environments we tested on the same host — numpy 1.26.4 and 2.2.6 — with an identical discrete removal chain; coefficient tails differ by up to ~2 ULP; other CPU architectures and BLAS implementations are untested). The pinned seed is an existence proof found by a documented 40-seed calibration hunt; no prevalence claim is made.

The synthetic case and the recorded real-data replay show the same discrete signature

Check	Synthetic-900	Recorded 40k replay
Baseline retention	3.6% (868/900 removed), driver survives	4.2%, driver survives
Flip -1/32 px at the driver	removed at index 832 of 870 removals (0-based) = 95.6% of the chain	removed at index 36,565 of 38,465 (0-based) = 95.1%
Final membership	32 vs 30 inliers, 25 common	1,677 vs 1,535, 985 common
Induced azimuth jump	RMS 2.75e-2 px (max 0.106 px)	RMS 3.60e-2 px
Tolerance bound vs half-quantum	0.0132 px < 0.0156 px	same (production kwargs)

Mechanism: two-stage amplification

1. Quantizer (subpixel argmax). The correlation-surface argmax maps input differences to "exactly zero or at least one grid step": whenever two implementations rank neighboring grid points differently — and cross-backend bit identity (e.g. CPU vs GPU Ampcor) is not generally guaranteed — the returned offset moves by at least q = 1/32 px. The quantizer is not the defect; the question is the robustness of the downstream removal chain to such small, valid input perturbations.
2. Membership amplifier (sequential worst-outlier removal). Each iteration refits, then removes the sample with the largest combined squared standardized residual (argmax(wL² + wP²)); the stop test is componentwise (max(|wL|, |wP|) <= crit_value). The fit response to an input offset is piecewise-smooth: linear while the removal chain is unchanged, with discontinuous jumps where a removal decision flips. Chains fork from perturbations as small as ~1e-4 px and almost always re-converge benignly; across a membership boundary, the jump is neither proportional nor monotone in the perturbation (3.6e-2 px from one quantum on the recorded data, vs the ~1e-5 px continuous-response scale).

A simple condition exposes the susceptibility:

crit_value * sigmaL / w  =  0.1 * 0.1247 / 0.9485  =  0.0132 px
   <  q/2  =  1/64  =  0.0156 px
   (half-bin bound on the nearest-grid quantization error)

The exact stop tolerance at a sample is crit_value * sigma * sqrt(1/w² - h_ii), bounded above by crit_value * sigma / w, so a sufficiently high-weight sample can fail the stop test on quantization error alone. This is a property of the high-weight tail — at the survivor-median weight 0.56 the bound is 0.0223 px and the inequality reverses — and it neither forces a deep purge nor guarantees a membership jump. On the recorded data the susceptibility was realized: 95.8% of the 40,000 samples were removed and the fit was decided by a ~4% high-weight elite (a crit_value sweep shows the flip response dropping 160-fold already at 0.2).

Questions and possible directions

The main question is the one in the Summary: the intended statistical interpretation of crit_value = 0.1, and the intent of the full rejection budget (max_iterations = len(data)). Beyond the synthetic case, we hit the mechanism in production form as a CPU-vs-GPU product-level difference (see "How we found it" below). The sketches below are for discussion, not a pre-made PR — we would rather agree on a direction first, and we are happy to implement the candidates you prefer and evaluate them comparatively on the synthetic reproducer and the recorded case.

Direction sketches (semantics calibration, observability, quantization-aware deadband, stable trimming, smooth losses)

1. Confirm and calibrate the crit_value semantics. The stop test compares componentwise standardized w-test statistics |e| / (s * sigma) against crit_value. Classical w-test critical values are typically of order unity to several, depending on the significance design (e.g. Baarda's B-method); for high-weight, low-leverage samples a threshold of 0.1 corresponds to demanding residuals at roughly one tenth of the prior noise level. If a re-calibration is considered appropriate, we can implement candidate calibrations and report their effect on both the reproducer and the recorded case.
2. Observability and guardrails — report n_removed / the inlier fraction next to the coefficients the workflow already prints, warn on extreme retention, optionally a max-rejection / min-inlier policy. Detection, not a cure; a min-inlier cap trades off stopping before the w-test criterion is met.
3. Quantization-aware residual model / deadband. The offsets entering the fit are quantized at a configuration-known q (the Ampcor correlation-surface oversampling), so q is available to the fit. Numbers from the recorded case: adding q²/12 to the prior variance alone moves sigmaL from 0.124705 to 0.125031 px (+0.26%) and the driver tolerance bound from 0.013148 to 0.013182 px — still below q/2 = 0.015625 px, so it is nearly ineffective by itself. An explicit tolerance floor at q/2 (deadband on the stop test) is the variant that bites; the crit-0.2 sweep point (160-fold response drop) is adjacent empirical support.
4. Batch / stable trimming instead of one-at-a-time hard deletion — reduces the sensitivity of the chain to a single flipped decision.
5. Comparative evaluation of smooth robust losses (convex Huber-class IRLS): a unique convex solution avoids hard membership deletion and is expected to remove this jump class, but is a broad behavior change; Tukey-style non-convex losses can retain basin sensitivity, so no blanket guarantee is claimed — an evaluation candidate, not a promise.

Where the relevant pieces live

• Function defaults crit_value=0.1, max_iterations=50: python/packages/isce3/math/offsets_polyfit.py#L192-L199; stop test and removal at #L325-L343.
• Workflow call with critical_value from the runconfig and max_iterations=len(data): python/packages/nisar/workflows/rubbersheet.py#L169-L177.
• Runconfig default critical_value: 0.1: share/nisar/defaults/insar.yaml#L609; the schema constrains it only as num(min=0) (share/nisar/schemas/insar.yaml#L602).

Code excerpts (pinned at 2919e1c97)

# python/packages/isce3/math/offsets_polyfit.py, L192-199
def polyfit_offsets(
    data,degree=2,
    crit_value=0.1,
    max_iterations=50,
    minL=None, maxL=None,
    minP=None, maxP=None,
    prf=None, abw=None,
    rsr=None, rbw=None):

# python/packages/isce3/math/offsets_polyfit.py, L325-343 (trimmed)
        # w-test
        s = np.sqrt(diag_Qe)
        wL, wP = (eL[:, 0] / (s * sigmaL)), (eP[:, 0] / (s * sigmaP))
        max_any = max(np.abs(wL).max(), np.abs(wP).max())
        if (max_any <= crit_value) or (iteration >= max_iterations):
            return { ... }

        # Remove worst outlier
        worst = int(np.argmax(wL * wL + wP * wP))
        removed_indices.append(int(data[worst, 0]))
        data = np.delete(data, worst, axis=0)
        A = np.delete(A, worst, axis=0)

# python/packages/nisar/workflows/rubbersheet.py, L169-177
results = offsets_polyfit.polyfit_offsets(
    data,
    degree=rubbersheet_params['polyfitting']['degree'],
    crit_value=rubbersheet_params['polyfitting']['critical_value'],
    max_iterations=len(data),
    minL=minL, maxL=maxL,
    minP=minP, maxP=maxP,
    prf=prf, rbw=rbw,
    abw=abw, rsr=rsr)

How we found it (recorded production comparison)

This is not hypothetical: we first hit the mechanism as a ~3.6e-2 px RMS difference between the CPU and the GPU InSAR workflow products on a NISAR L-SAR pair, and a controlled replay of the production fits attributed that difference to exactly one such quantum flip. In the extracted sample sets, ~99.97% of the 40,000 sample rows were bit-identical between the CPU and GPU runs, and every difference was at least one quantum. The full report, the recorded artifacts and the replay harness are public: report · artifacts · replay/probe harness.

The synthetic reproducer above is independently runnable by anyone. The real-data replay results are public recorded evidence: the source rasters and the extracted sample matrices are not published; we can archive the extracted matrices in a DOI-backed repository (e.g. Zenodo) after confirming redistribution and citation metadata.

Recorded 40k replay: transplanting one sample row reproduces the logged coefficient delta

Dataset context: ascending track 139, frame 019 (L1 RSLC), processed once with the CPU and once with the GPU InSAR workflow. The two runs' RIFG pixelOffsets layers differ by a smooth ~3.6e-2 px RMS degree-2 bowl; a linear regression on the offsets difference explains ~99.5% of the unwrapped phase-difference variance between the runs.

Sample-set counting: two independent CPU-Ampcor runs were each compared against the GPU-Ampcor baseline on the production sample grid (run A: 10 of 40,000 rows differ; run B: 9 rows; the union is 12 changed rows, 7 common to both).

All replay fits are CPU-only and thread-count controlled; A/A reruns are bit-identical.

Result	Value
Self-consistency gate	the replayed fit reproduces the on-disk culled surfaces to 6.1e-15 px and the logged coefficients to print precision (4.1e-9)
Full-input swap (controlled CPU-Ampcor offset set into the GPU baseline)	reproduces the observed CPU-minus-GPU coefficient target: cosine 1-6e-15; the replayed coefficients match the CPU run's logged values at max abs diff 5.0e-8
Channel attribution	offsets-only = full target; weights-only (38.5k float32 epsilons in corr_peak) forks at iteration 468 and re-converges benignly (2.4e-9 px)
Minimal destructive set	ONE sample row (corr_peak 0.9485, azimuth offset differing by exactly -1/32 px, no range difference) — necessary (complement transplants change the coefficients by exactly zero) and sufficient (the single transplant = full target) within the observed difference sets; the other 11 rows of the 12-row union, including a 5.6/13.9 px (azimuth/range) outlier row, change nothing
Perturbation basin at the driver	only the exact -1/32 px value lands in the target basin; -1e-5 px does not fork the chain; -1e-4 px and ±2-quantum deltas fork and re-converge benignly
Endgame membership	final inliers 1,677 (GPU baseline) vs 1,535 (CPU-offsets), 985 common; the driver is removed at index 36,565 of the 38,465-removal sequence (0-based; 95.1% of the chain); the amplification curve stays at 1e-5..1e-3 px mid-run and explodes over the last ~2,000 iterations

The endgame-membership figures are recorded in the membership summary JSON in the artifact directory; the remaining table entries map to the replay/probe JSONs there.

Scope and limitations

• Single dataset, single pair; replay determinism claims are same-environment claims. "Exact" means exact to the available production log precision.
• The real-data evidence is a controlled substitution on recorded rasters. The actual production CPU run's raw offsets were not reconstructed; "the one flip existed in the actual CPU run" is consistent with the coefficient-level evidence (the replayed coefficients land on the CPU run's logged values at 5.0e-8) but is not established.

Further limitations

• Pairwise interaction of the 12 changed rows was not enumerated (the complement probes close the necessity question for the observed sets).
• The synthetic two-population weight structure is a simplification of the production corr_peak distribution, not a quantitative match.
• Why the CPU and GPU correlation surfaces rank neighboring grid points differently in that one window (the origin of the argmax flip) is out of scope here.
• The mechanism is an existence result under production kwargs; on this very dataset 11 of the 12 changed rows and all 38.5k weight epsilons were benign.

Appendix: docstring mismatch in the same module

The polyfit_offsets docstring describes minL/maxL (minP/maxP) as bounds on acceptable offsets ("Points with dL outside [minL, maxL] are removed before fitting") and removed_indices as including points removed "by hard bounds". The implementation uses these parameters only as coordinate-normalization bounds for the design matrix (defaulting to the data's line/pixel coordinate range); no pre-fit removal by offset bounds exists. Happy to fold a docstring fix into whatever comes out of the discussion, or file it separately.

---

Disclosure: The diagnosis and harness were written with assistance from AI agents. I ran the diagnostic scripts myself and reproduced the reported numbers before posting.

[s-sasaki-earthsea-wizard]

Follow-up context, not a request for action. After filing this I went back and read #173, the PR that introduced offsets_polyfit. Three things there speak directly to the questions above, so I am recording them here to keep the discussion in one place.

1. The intended semantics of the w-test is documented — and it is the classical one. The theory deck attached to the PR description (Polynominal_Fitting.pptx) defines the test as

w_i = e_i / (sigma_0 * sqrt(q_e,ii))

with sigma_0 = "a priori standard deviation (estimated from system parameters)", and states: "If |w_i| > critical value, that point is likely an outlier." That is Baarda-style data snooping on a standardized residual, and it answers the first half of my Question 1: crit_value is a threshold on a standardized statistic, not a tolerance expressed in pixels. It sharpens the second half rather than removing it — critical values for that statistic are conventionally of order unity to several (about 3 for common significance designs), while the shipped default is 0.1.

2. "Too few points remain" is in the documented stop set, but not in the code. The same deck lists three stopping conditions for the loop: all |w| <= threshold, too few points remain, or max iterations reached. In the implementation the only size guard is Nobs <= Nunk, which raises ValueError rather than stopping the loop with the current fit; there is no min-inlier or max-rejection policy. So the guardrail sketch (direction 2 above) is closer to completing a documented part of the design than to adding a new one.

3. Batch removal was already proposed during review (#173 (comment)):

In the future, I think you could change the algorithm to discard some small fraction of outliers each iteration (say max(1, 1/2500 * n)), which I'd expect would have similar performance to discarding one point at a time for a 50*50 grid.

It was raised for runtime rather than for stability, but it is the same change as direction 4 above, and reducing one-at-a-time hard deletion is precisely what would damp the membership jump reported here. The two motivations are independent and both live at the shipped samples_along_*: 200 default: in our recorded production-shaped replay the loop performed 38,323 sequential refits and took ~110 s on a single desktop-class host (two recorded runs: 109.3 s, and 107.1 s with 16 OMP threads — see gate.upstream_fit_seconds in replay_real40k.json and replay_gate_omp16.json in the same directory). The stability side of the same change is what this issue is about; it only became visible to us because a CPU-versus-GPU Ampcor difference happened to move one input by one quantum — the backend difference is the detector here, not the cause. If batch removal is the direction you prefer, I am happy to implement it and report comparative results on both the synthetic case and the recorded one.

Two smaller notes in the same spirit:

• Using the full offset set is a deliberate choice (review comment: "I don't see why we should need to subsample the data. Let's just use it all if we can."), so I am not proposing subsampling as a mitigation.
• The module's unit tests build noiseless tie points with equal weights, so once the injected outliers are removed the residuals are essentially zero and the stop test passes for any crit_value; the retained fraction is not asserted. A test on noisy input that pins the retained fraction would fail loudly on this class of behavior change — I can contribute one alongside whichever direction you choose.

Disclosure: as with the issue body, this write-up was prepared with assistance from AI agents; I checked every quote and link against the PR myself before posting.

[s-sasaki-earthsea-wizard]

For reference: I implemented and measured the directions sketched above. Benchmark-side only — the isce3 source tree is untouched; every variant lives in a mirror of the fit loop that is bit-identical to polyfit_offsets with its policy disabled (tested), the final protocol (candidates, metrics, 200 fresh synthetic seeds, perturbation manifests) was frozen before any confirmatory or comparative result was computed, and the direction remains open. Details: report · pre-registration · artifacts (pinned container: isce3 2919e1c97, numpy 1.26.4, threads 1).

The short version:

• @bhawkins — your Add Polyfitting to compute the range and azimuth offsets for the fine resampling #173 batch-removal idea works as advertised for runtime. Implemented literally (max(1, floor(n/2500)), current-n): 3.61× faster on the recorded 40k production case (73.5 → 20.4 s, 38,324 → 9,118 refits; single pinned run) with drift 4.0e-6 px (azimuth) / 5.9e-5 px (range) and a stability profile identical to baseline (on the synthetic arena that identity is by construction — n = 900 keeps the batch at k = 1).
• But no mechanical variant fixes the instability this issue is about — they move it. To restate what that instability is and why it matters: each refit deletes the single worst point, and near the stop threshold a 1/32 px change of one input — the exact size of difference a CPU-vs-GPU correlation argmax produces — can flip one removal decision; the cascade then re-selects the final inlier set and moves the fitted offset surface product-wide by ~3.6e-2 px RMS, ~10³× the continuous response. That single mechanism produced the entire smooth CPU-vs-GPU pixelOffsets difference reported above: it is what makes reprocessing and cross-backend runs disagree far above the noise floor. Against that: the literal formula leaves the recorded jump untouched (its endgame is sequential); a min-batch-2 variant, the batch+deadband combination and the quantization deadband each suppress the recorded jump — yet on fresh seeds the rates remain far above the frozen ≥10× reduction target (the deadband modestly reduces the rate, the min-batch-2 variant sits slightly above baseline), and the paired records show the min-batch-2 variant introducing more new jump events than it resolves (13 resolved vs 19 introduced, uniform estimand).
• The tested candidates that strongly suppress the class change the estimator. A retention guard and a convex Huber-IRLS reference (the only candidate with zero observed material events in all reported arenas) suppress it to essentially zero — at 1.6–2.5× the truth-surface error, because they retain junk influence the current fit purges.
• So my concrete suggestion is modest, in two parts. Under the acceptance criteria I froze in advance, no behavior-changing candidate qualified, and the registered rule for that outcome is an observability-only first step: report n_removed / the inlier fraction next to the coefficients the workflow already logs, distinguish w-test convergence from budget exhaustion and failure in a stop reason, and add a noisy-input retention test (the "too few points remain" stop is in the Add Polyfitting to compute the range and azimuth offsets for the fine resampling #173 design deck but not in the code). That exposes the 4%-retention regime instead of changing it. Separately — outside that stability decision, on runtime grounds alone — I'd be happy to shape the batch-removal change into a PR if drift at that level is acceptable to the maintainers. And if you would rather see different candidates or different metrics evaluated, the harness makes that cheap now.

Supporting numbers and provenance (for readers who want the detail)

Baseline sensitivity is structural. Under production kwargs, 1.7% (34/2,000) of sampled uniform and 2.15% (43/2,000) of sampled weight-stratified single-node 1/32 px perturbations change the fitted surface by more than 1e-2 px RMS (200 seeds × 10 flips per estimand); a flip at the high-weight driver node is material in 26.5% of seeds (53/200). The random-flip p50 and p90 are exactly zero — 94.65% / 94.20% of flips produce exactly zero response in both bands — while the tail reaches several 1e-2 px: a point mass at exact zero with a rare boundary-crossing tail, consistent with the discrete-membership mechanism of the original report. The 1–2% rate holds across four generator-variant robustness cells.

Case-level suppression vs class-level removal. The deadband takes the recorded driver flip from 3.60e-2 px to below 8e-4 px in both bands (9.6e-5 azimuth / 7.9e-4 range) — and on fresh seeds retains 72–74% of the baseline jump rate (paired difference −0.53 pp, 95% seed-cluster CI [−0.95, −0.10]). The min-batch-2 variant likewise kills the recorded case (≤1.9e-5 px) while its ensemble rate lands slightly above baseline (+0.27 pp [−0.18, +0.73]). Membership boundaries move; the discontinuity set does not disappear — sampled boundary events are both resolved and introduced.

The trade-off is sharp. The hard-deletion family (baseline, deadband, batching) stays at truth error 1.17–1.22e-2 px (azimuth medians) with jump rates 1–2.4%; the retention guard and the IRLS reference invert that — near-zero jump rates at truth error 2.6e-2 / 3.1e-2 px (azimuth medians). On this generator the current elite-only fit occupies the high-accuracy/low-stability corner; nothing met the frozen ≥10× stability target while remaining within the truth-error gate. (I had pre-registered acceptance criteria to keep myself honest about this; no behavior-changing candidate met them — details in the report. The crit_value recalibration direction from the issue was not part of this roster and remains an unevaluated hypothesis.)

One provenance note for completeness: the scheduled run crossed a reporting-only commit boundary — the results aggregator and its tests; 72/400 seed records report one HEAD, 328/400 the next, and the tracked generating inputs have identical blob IDs across both — and 46 records carry an uncaptured-dirty-worktree flag; the report states the full limitation.

Disclosure: as with the issue body, the implementations and this write-up were prepared with assistance from AI agents; I ran the pre-registered evaluation myself and verified the reported numbers before posting.