# Availability record — robber ladder registration #1 (2026-08-20)

ROBBER-LADDER-PREREG.md (pinned 12:56:18Z, amended sha b51ebadd…) named
five candidate vendor tags. All five returned the identical pull error,
verbatim `{"error":"pull model manifest: file does not exist"}`, before any
scored call anywhere:

- gemma4:12b-it-q2_K — UNAVAILABLE
- gemma4:12b-it-q3_K_M — UNAVAILABLE
- gemma4:12b-it-q5_K_M — UNAVAILABLE
- gemma4:12b-it-q6_K — UNAVAILABLE
- gemma4:12b-it-fp16 — UNAVAILABLE

Under that registration's own availability rule (no substitute tags hunted
after the pin), registration #1 therefore has NO runnable ladder beyond the
q4/q8 pair already benched on 2026-08-19, and it closes with this record —
no scored calls, no threshold table.

The vendor's actual 12B ladder, read from the library tags page after the
404s (2026-08-20 ~13:0X UTC): `12b` (=q4_K_M) · `12b-it-qat` (7.2 GB) ·
`12b-it-q4_K_M` · `12b-it-q8_0` (13 GB) · `12b-it-bf16` (24 GB), plus
MLX-runtime variants our daemon does not load. No q2/q3/q5/q6 exist from
the vendor. Registration #2 (ROBBER-LADDER2-PREREG.md) names the four
runnable rungs and was written and pinned before any of them produced a
scored call.

---
CONTENTION RECEIPT, THE OTHER DIRECTION (operator-measured, 2026-08-20,
during the ladder run): the operator asked the live rules product a question from a tablet
WHILE the bench's heaviest rung was decoding, and read the product's own
timing strip back for the record, verbatim: search 82 ms · ask 10,760 ms ·
total 10,845 ms · 35.6 tok/s · 193 output tokens in 5.415 s of generation.
The anatomy the strip shows: retrieval untouched (82 ms), ~5.3 s of the
ask spent waiting for the card the bench was holding, then generation at
35.6 tok/s — "slowed it down, but it still chugged away and answered"
(operator's words). The beside-traffic posture's cost, measured from the
reader's side: a temporarily slower product, never a dark one. Pairs with
the prereg's disclosed contention toward the bench's own rows.

---
RECONCILIATION NOTES (added 2026-08-21, pre-release, after the final audit
pass — each names its subject cold, per the house convention):

1. THE CONTENTION RECEIPT'S PLACE AND ID: the tablet ask above is debug-
   ledger row 4727, written 2026-08-20T13:14:11Z — during ATTEMPT 1
   (13:04–13:25Z), when the card was contended by both the bench and the
   image pipeline's re-grab. Generation ran at 35.6 tok/s; the full wall
   clock was 10.8 s, ~5.3 s of it queued.
2. THE bf16 POSTURE CLAUSE: registration #2 stated "loads alone against
   ≥50 GiB free" as a headroom target. The measured free at the bf16 load
   was 43.6 GiB; the runner's enforced guard was 30 GiB; the seating
   receipt shows the build FULLY seated (22.87 of 22.87 GiB in VRAM) with
   19.6 GiB left. The target was missed, the intent (full residency) was
   met, and both numbers publish.
3. WEEKDAY DRIFT, AGAIN: both pinned registrations say "Friday morning";
   2026-08-20 was a Thursday. The date, not the weekday, is the intended
   thing — the same slip registration #1's appended note corrects in its
   own header, striking twice in one kit.
4. PROSE CLOCKS vs PIN CLOCKS: the registrations' prose times ("~13:05",
   "~12:58") are estimates written by hand; PREREG-INDEX.txt's timestamps
   are the machine record taken at hashing (12:56:18Z, 12:56:37Z,
   12:58:31Z). Where they disagree, the pin index is the record; the
   prose drifted the same direction as the weekday.
5. ATTEMPT 1's EVIDENCE, RESTATED PRECISELY: attempt 1 predates the
   per-load card receipts (the guard was built BECAUSE of it). Its
   partial-residency finding rests on: a live /api/ps read during the run
   showing the bf16 build holding 9.2 of its 24 GB; the rate collapse
   (the resident 4-bit build's own cells falling 125.24 → ~24.7, the
   8-bit to ~5.1, the heaviest rung to 2.67 tok/s); and a driver-level
   free-VRAM reading of 4.3 GiB taken minutes after the run closed,
   before the image pipeline's memory was released at ~13:26Z. An earlier
   copy of the attempt-1 ruling wrote that reading's time as "~13:5X" —
   an estimate error, corrected here; the release copy of the ruling
   carries the corrected text.