# NEGATIVE_RESULTS — f2 (video codec discovery foundry)

Results that failed their sealed bar, recorded with the same care as a pass. A bar never moves after a miss; spending on the candidate stops at the miss. Every line carries the seal commit, the run receipt and the verify output.

## 2026-09-02 — S06 candidate 2: the inference floor on 24 real GLM-5.2 guards — seal VIOLATED on 1 of 6 keys

- Seal: `artifacts/seals/glm_inference_floor_2026-09.seal.json`, committed at `3a3c6e23` before the run (the experiment `experiments/13_s06/run_inference_floor_glm.py` is fixed in the same commit).
- Run: `make inference-floor-glm`, 1.7 s, $0, no model calls (`out/c2_inference_floor_glm_run_2026-09-02.log`); artifact `artifacts/crs/inference_floor_glm.json`; result commit `50d597e6`.
- Verify (`out/seal_verify_glm_inference_floor_2026-09.txt`): 5 keys HELD — 10 unsound candidates; the uniform k-sample judge falsely accepts every unsound guard at k = 8, 32, 128, 512 (measured 1.0, closed form 1.0); the Farkas witness accepts 0 of 10 unsound. 1 key VIOLATED — `bar_witness_false_reject_zero`: the witness rejected 3 of 14 sound guards.
- Which three and why: `(overhead, slack, op)` = (2, 0, lt), (3, 1, lt), (4, 2, lt). Each is `p - r + 2 < 0`, which over the integers is exactly `p - r + 3 <= 0` (in_bounds), but the rational Fourier-Motzkin decider (`formal/decision_procedure.py`) cannot use integrality, so no Farkas certificate exists over Q. This is the documented sound-but-conservative behaviour of rank 14 (`artifacts/crs/mutation_campaign_summary.json :: random.conservative_false_rejects = 13`), now exhibited on vendor-model output and caught by a seal I wrote before seeing it.
- What stands: the separation the theorem predicts (judge blind at every feasible k; witness false-accept 0) is measured on real model output and matches the closed form. What does not stand: "false-reject 0" for this witness on this population.
- What would settle it, with a NEW seal: integer tightening of strict unit-coefficient atoms (`< 0` over integers becomes `<= -1`) before elimination — a one-line normalisation in the decider; product code, not an S06 edit. Predicted effect: false-reject 0 on these 24 with soundness unchanged.
- Control that ran: the canonical guard certifies, and a Farkas certificate with one multiplier zeroed fails the re-check (`control.control_passed = true`).

## 2026-09-02 — S06 candidate 10: second GLM-5.2 census at temperature 0.3 — NOT RUN, provider balance zero

- Seal: `artifacts/seals/glm_census_temp_2026-09.seal.json`, committed at `4bf9a0a3` before the attempt (the `CENSUS_TEMPERATURE` / `CENSUS_TAG` routing is in the same commit so the registered live artifact can never be overwritten by a re-run).
- Attempt: `CENSUS_TEMPERATURE=0.3 CENSUS_TAG=temp python -m foundry.crs.gameability_census --live` returned HTTP 429 from the z.ai endpoint, code 1113 "Insufficient balance or no resource package" in 3.45 s (`out/c10_census_temp_attempt_2026-09-02.log`). No candidates were produced, no artifact was written, $0 was spent.
- Standing: the seal is intact and untouched; the run is re-issuable the day the account carries balance. The claim it would earn is already bounded by the lane note: a temperature change is the same vendor, not a second one.

## 2026-09-02 — S06 candidate 3 (first seal): browser stranger verifier — seal VIOLATED on 1 of 7 keys, caused by a no-op mutant in my own generator

- Seal: `artifacts/seals/browser_verifier_2026-09.seal.json`, committed at `8d0afc26` before the run with the module, page and receipt script.
- Run: `make browser-verifier` under Node v25.1.0 WebCrypto, 0.10 s (`out/c3_browser_verifier_run_2026-09-02.log`): 6/6 corpus certificates accepted; forged example rejected; decoder self-hash, Ed25519 signature and outcome-trace Merkle root (2,000 leaves, canonical re-serialisation) all re-derive; 0 network requests. Mutants: 30 of 36 rejected.
- Verify (`out/seal_verify_browser_verifier_2026-09.txt`): 6 keys HELD, `bar_mutants_ge_30_all_rejected` VIOLATED.
- Cause: the six survivors are all `index_swap`, on certificates whose two Farkas multipliers are equal (`{"3":[1,1],"5":[1,1]}`); swapping them yields a certificate byte-identical to the original, so the verifier accepting it is correct. The defect is a corruption that is a no-op — the exact class this lane recorded on 2026-08 for the F2-07 LEG B gate ("all 9 failing rows leave the artifact byte-identical; replace the mutation, don't add a pin"). The verifier is not implicated; the generator is.
- Handling: this seal is not moved. The generator now refuses to emit a mutant canonically identical to its original (falls back to a value perturbation and records that it did), and the corrected experiment runs under a NEW seal `browser_verifier_2026-09b` with the same seven predictions.

## 2026-09-02 — S06 candidate 5: two 2025 CVE fixes under seal — VIOLATED on 1 of 14 keys (an online-resolution key)

- Seal: `artifacts/seals/cve_2025_guards_2026-09.seal.json`, committed at `e03558de` before the run with the checker `formal/check_upstream_guard_2025.py`, the two CBMC harnesses under `formal/cbmc/cve2025/` and the bar derivation.
- Run: `make upstream-guard-2025`, 4.5 s including six CBMC runs, $0 (`out/c5_upstream_guard_2025_run_2026-09-02.log`); artifact `artifacts/crs/upstream_guard_2025/summary.json`; result commit `781e0b9d`.
- Verify (`out/seal_verify_cve_2025_guards_2026-09.txt`): 13 keys HELD — every prediction about the two guards (libxml2 xmlBuildQName sound only under lenp <= SIZE_MAX-1, counterexample lenn=0 lenp=2^32-1; OpenSSL kek_unwrap_key sound, tight, equal to the bounds predicate; pre-fix check unsound with counterexample inlen=2, tmp[0]=4; all six CBMC twins as predicted). 1 key VIOLATED — `bar_both_fix_refs_verified_online`: the checker's in-run GET of the GitHub commits API for `9c462be2` returned HTTP 403 "rate limit exceeded" (the libxml2 GitLab resolution succeeded). The mathematics did not miss; my bar bundled a network receipt with the proofs.
- Handling: the bar is not moved. The diff of the OpenSSL fix fetched earlier the same day is committed as the receipt (`out/c5_openssl_9c462be2_fetched_2026-09-02.diff`, 13 lines, the two changed lines quoted in the class file). A future seal that wants an online key should predict it separately from the proof keys.

## 2026-09-02 — S06 candidate 4: rank 1 re-pinned to today's Cilium under seal — VIOLATED on 1 of 8 keys (a bar-derivation key), after two runs that reached no kernel

- Seal: `artifacts/seals/bpf_repin_2026-09.seal.json`, committed at `16a3df33` before the run with the environment overrides (`BPF_FOREIGN_CILIUM_COMMIT`, `BPF_FOREIGN_OUT`) and the bar derivation.
- Runs, all under the same seal and all on the record: run 1 (`out/c4_repin_run_2026-09-02.log`, artifact copy `out/c4_repin_run1_artifact_2026-09-02.json`, verify `out/seal_verify_bpf_repin_2026-09_run1.txt`) and run 2 (`out/c4_repin_run2_2026-09-02.log`) built every object and proved the same goals but the kernel runner exited 100: the colima docker disk was 100% full, so apt inside the privileged container could not verify any repository signature. Their kernel leg reads UNAVAILABLE, which the artifact itself says is neither a pass nor a fail, and the sealed key `bar_kernel_state_all_measured_ok` read false. After inspecting and pruning only dangling images, build cache and stopped containers (no tagged image, no volume), run 3 (`out/c4_repin_run3_2026-09-02.log`) reached the 6.8.0-117-generic verifier: 12 of 12 measured properties agree, 22 of 34 never reached the verifier, and that key held.
- Verify on run 3 (`out/seal_verify_bpf_repin_2026-09.txt`): 7 of 8 HELD. 1 VIOLATED — `predicted_pins_report_corpus_fingerprint_differs`: the bar required `pins.pinned == false`, but the pipeline reports a fingerprint mismatch as `pinned: true, checked: false, reason: corpus-fingerprint-differs` (`scripts/bpf_foreign_reach.py`). The prediction's substance (the pins are not consulted for a new corpus) is what the artifact says; the key I sealed read the wrong field. The bar is not moved and no second seal is written: the outcome is known, so a re-seal would not be forward.
- Commit message `bf408594` says "seal verified" for run 1; the receipt it names shows VIOLATED on 2 keys for that run. History is not rewritten (I6); `STALE_CLAIMS.md` §H-14 records the overstatement.
- What stands: at Cilium main of 2026-09-02, 7 of 7 objects build, 620 goals prove with 452 witnesses, the anchor accepts 34 of 34, the kernel agrees on every measured property. What does not stand: an 8-of-8 seal, and any reading of the kernel leg as discriminating evidence (the artifact's own `product_domain_finding` says why).

## 2026-09-04 — S08 O6: f5's `sf_gate.bpf.o` on this lane's live 6.8 kernel — seal VIOLATED on 1 of 8, and the result f5 needs is the rejection

- Seal: `artifacts/seals/f5_gate_kernel_2026-09.seal.json`, committed at `7bdf235f` before the run with the probe, the two control programs and the bar derivation.
- Run: `make foreign-object-kernel-probe`, $0 (`out/o6_f5_gate_kernel_run_2026-09-04.log`); artifact `artifacts/crs/foreign_object_kernel_probe.json` carries every log verbatim, as the staging manifest requires.
- Controls first, both fired: an unchecked packet read written in this lane was REJECTED by the verifier (`invalid access to packet, off=64 size=1`, `-13`) and its bounds-checked twin was ACCEPTED (`processed 12 insns`). A runner that cannot produce both verdicts is not measuring the verifier; this one can.
- The staged object was not modified: sha256 `e3533620…` before and after, equal to the manifest's.
- Verify (`out/seal_verify_f5_gate_kernel_2026-09.txt`): 7 keys HELD. 1 VIOLATED — `predicted_xdp_gate_accepted_by_verifier`: `xdp_gate` was never reached, because `bpftool prog loadall` aborts the whole object at the first program that fails, and the first program failed.
- Two beliefs I wrote into the seal note were wrong, and neither was keyed, so I state them here rather than let them pass: (1) I expected libbpf 1.x to refuse the legacy `classifier` section name — it did not, it mapped both sections and found both programs; (2) I therefore expected a loader error, and got a genuine verifier verdict instead. The classifier distinguished them correctly, which is the one thing that had to work.
- What the kernel actually said, and it is a result rather than a failure: `sf_served_mask_bpf` was REJECTED with `R2 !read_ok` at instruction 0 (`0: (bf) r0 = r2`), verification time 7 usec, `processed 1 insns`, `failed to load: -13`. A BPF program is entered with exactly one initialised register, R1 = ctx; `sf_served_mask_bpf(u64 hashMatch, u64 notDeleted, u64 isPublicBit, u64 tenantMatch)` reads its second argument, so as a *program* it reads an uninitialised register. The object is a compiled **function**, not a loadable **program**. Nothing here contradicts f5's differential-fuzz result about the function's logic; the two statements are about different objects.
- What would settle `xdp_gate`, and it is f5's call, not mine: stage `xdp_gate` in its own object, or set `autoload=false` on the function program, and this rig will re-run under a new seal. `bpftool` alone cannot select one program from a multi-program object, so no measurement of `xdp_gate` exists today and none is claimed.

## 2026-09-04 — S08_2: f3's monitor under a relocating loader — seal VIOLATED on 2 of 11, and I was wrong in the direction that flattered nobody

- Seal: `artifacts/seals/perprogram_probe_2026-09.seal.json`, committed at `bf524c89` before the run with the loader, the probe and the bar derivation.
- Run: `make foreign-object-perprogram-probe`, $0 (`out/o6b_perprogram_probe_run_2026-09-04.log`); artifact `artifacts/crs/foreign_object_perprogram_probe.json`, every log verbatim.
- Verify (`out/seal_verify_perprogram_probe_2026-09.txt`): 9 keys HELD, 2 VIOLATED — `predicted_monitor_still_rejected_under_a_relocating_loader` and `predicted_monitor_failure_mentions_a_loop`.
- What I predicted and why: the monitor's disassembly has four backward jumps, including an unconditional one at instruction 111, and the loop's progress variable lives in the 12-byte `.bss` the verifier tracks as an unknown scalar. I reasoned that the state at the loop head would be identical on re-entry, that the verifier would report `infinite loop detected`, and that f3's original verdict would therefore survive its own retraction. I sealed that against the easy answer and said so.
- What happened: the kernel **ACCEPTED** it. `processed 182 insns`, `total_states 17`, every back-edge closing with `from N to M: safe`. State pruning converged where I expected it to diverge. The mechanism half of my reasoning was right — the loops are the only thing that could have failed once the relocations were applied — and the conclusion was wrong.
- The third key, `predicted_monitor_failure_is_not_the_instruction_6_zero_load`, reads HELD but holds **vacuously**: there was no failure to be at instruction 6 or anywhere else. It is counted in the 9 and it should not be read as a successful prediction.
- What this settles, and it is f3's result, not mine: all 12 `R_BPF_64_64` relocations were applied and the `.bss` map was synthesised (`map 'f3_monit.bss' … created successfully, fd=3`, `ks=4, vs=12`); instruction 4 became `r3 = map_value(map=f3_monit.bss)` and instruction 6 — the one that failed under f3's raw loader — read `*(u8 *)(r3 +5)` cleanly. **f3's retraction was right.** The kernel does not refuse the monitor; it refused a loader that had not applied the relocations. The original headline does not survive under a faithful loader, and the estate now has the clean version of that sentence with a receipt.

## 2026-09-04 — S12: the paid model census (D25) is still blocked, and the $5 stays unspent

- The orchestrator approved roughly $5 for the second GLM-5.2 census and said to run it only if it produces a receipt this lane would cite. Whether it can run at all was decided by probe rather than by assumption: one minimal request to the provider, rejected before any tokens were billed.
- Result: HTTP 429, `code 1113`, `"Insufficient balance or no resource package. Please recharge."` — the same condition recorded on 2026-09-02, unchanged two days later.
- So: **not run, $0 spent, and the $5 is kept.** The seal `artifacts/seals/glm_census_temp_2026-09.seal.json` remains armed and untouched, and the run is re-issuable the day the account carries balance. The claim it would earn is still bounded by what S06 recorded: a temperature change is the same vendor, not a second one.