# PRE-REGISTRATION — one NVIDIA GeForce RTX 5090 Laptop GPU 24 GB, on the box it is soldered to *Written 2026-09-21, before the first measured arm. What is registered here is what the bench will do; what it FINDS is `RESULTS.md`'s business. Every number in this document that describes the board was READ off the card, in the same call as `date -u`, and the reading is named.* --- ## §0 · WHAT THIS BENCH IS, AND THE HOLE IT FILLS **For a reader who scrolled straight here.** This is the fifth board measured by one instrument in one ladder: two GeForce RTX 3080 10 GB in a pair, one RTX 3090 24 GB, one RTX 3090 Ti 24 GB, one RTX 3080 Ti 12 GB — and now a **mobile** part, an NVIDIA GeForce RTX 5090 Laptop GPU 24 GB soldered into a laptop. It runs the same two legs the desktop 24 GB cards ran: **LEG 1**, the eleven-arm language bank, and **LEG 2**, the render bench (arms R1 and R4). **The hole, precisely.** The hardware roster already carries two identities for this machine. `rtx-5090-laptop` has **sixteen** published rows and **all sixteen are diffusion**, every one with `cap: "not stated"`. `rig-b-the-laptop` carries **fourteen language rows** for the same machine, and its own published ids say what they are: > *"Rig B — the laptop: 24G-VRAM class, GPU deliberately unused here."* > *"a 24G-VRAM-class GPU present and parked"* · `cpu-laptop` **Every `gemma4:26b` and `mistral-small3.2:24b` figure this shelf has ever published for this machine was measured on its CPU with the card parked.** This card has never carried a language row, never carried a stated power cap, and never carried a training row. That is the bench. **The question it is here to answer, and it is not "is a laptop slower".** Every desktop board of this ladder was measured at 250–450 W. This board's **maximum is 175 W** and its default is 95 W — its whole envelope sits below the lowest column the comparison piece has. The finding is a ratio, not a deficit: *a part allowed a fifth of the power does this much of the work.* Which means the cap prints beside every figure this bench produces, in the cell, always. --- ## §1 · THE BOARD, READ (2026-09-21T14:52Z) | | | |---|---| | name (driver string) | `NVIDIA GeForce RTX 5090 Laptop GPU` | | UUID | `GPU-edff232c-7dbf-2bac-07fb-921a7c9eecff` | | bus | `00000000:01:00.0` · **soldered**; there is no seat and no card to swap | | compute capability | 12.0 (Blackwell, `sm_120`) · VBIOS `98.03.A2.00.21` | | driver / CUDA | 595.91.07 / 13.2 | | VRAM | 24,463 MiB | | memory | **GDDR7**, 256-bit (width read from NVML per UUID) | | `power.limit` | **`[N/A]`** — no limit has ever been SET on this board | | `enforced.power.limit` | 150.00 W | | default / max / min power limit | **95.00 W** / **175.00 W** / 5.00 W | | `fan.speed` | **`[N/A]`** — the driver reports no fan for this board | | `temperature.memory` | `[N/A]`, as on every board of this ladder | | idle | 11.85 W, 47–51 °C, P5, 0 % util over five consecutive samples | --- ## §2 · THE THREE PRECONDITIONS, EACH AN OPERATOR PASTE None of them is something a bench lane does, and every gate in both legs refuses without them. 1. **`nvidia-powerd` STOPPED.** NVIDIA Dynamic Boost floats this board's TGP between 95 W and 175 W against the CPU's draw, continuously, and has been running since 2026-09-08. With it up the cap is a *signal*, not a setting: every capped arm would refuse on its own read-back or, worse, would not, and a figure would carry a cap it was not measured at. 2. **The clock lock RELEASED (`nvidia-smi -rgc`).** `ai-perf.service` on this box runs `nvidia-smi -lgc 1200,2550` at boot — added deliberately for ComfyUI's first-load latency. benchbox, which produced the rows this bench compares against, runs no such lock. **A floored clock changes what a power cap MEANS**: the board cannot drop below 1200 MHz to stay inside 95 W. Every result file records `clocks.sm` min and max so the confound is visible; a block that runs with the lock active writes `results/-clock-lock-ACTIVE-w.txt` and its figures are **not** like-for-like with the desktop rows. 3. **The cap SET to the rung's wattage.** ⚠ **Whether `nvidia-smi -pl` is permitted on this board is an OPEN QUESTION at the time this document is written.** `power.limit` reads `[N/A]` and `enforced.power.limit` reads a number; privileged NVML writes demonstrably succeed here (`ai-perf.service` runs `-pm 1` and `-lgc` with `status=0/SUCCESS`), but `-pl` itself has not been tried. **Step 1 of `RUNSHEET.md` is the one paste that decides it.** **If `-pl` is refused, this bench has ONE POSTURE AND NOT A LADDER.** `params.sh` must then be re-cut to say so: the posture is `dynamic-boost`, its cap cell is the RANGE plus the mean enforced limit over the run derived from the 2 Hz trace, and never a single number. Nothing here guesses which of the two it will be. --- ## §3 · THE CAP LADDER — two rungs, both READ off the card | rung | what it is | |---|---| | **175 W** | the board's `power.max_limit`. ⚠ On a **desktop** board this ladder calls max_limit an overclock and refuses it as a rung (the 3090 Ti's ruling: *"'Uncapped' = 450 W, not 480"*). On a **mobile** board it is not: NVIDIA's own Dynamic Boost reaches it during ordinary use, on mains, unasked — the enforced limit read 150 W at recon with nothing running. So it is the ladder's top rung, and the reason is written down rather than assumed. | | **95 W** | the board's `power.default_limit` — the floor NVIDIA ships. | **The run order is 175 first**, and that is a fact about this box: 175 W is reachable only once Dynamic Boost is stopped, so the operator's one sudo paste stops it, releases the clock lock and sets 175 W in a single step. The 95 W rung is then a **queued unit that WAITS** for the card to read 95 — it never sets a cap. **`dynamic-boost` is registered as a POSTURE, not a rung.** It is how the machine actually ships and is arguably the headline a reader wants. Its cap cell is a range; a single wattage typed into a cap column for it would be a fabrication. ⚠ **NO ROW FROM THIS BENCH CAN FILL A CAP-KEYED CELL.** The comparison tables key their columns on 250/300/350/400/450/600 W. This board's entire envelope is below the lowest of them, so a row from here fills **zero** cells however well the bench runs. `CAP_AXIS_NOTE` rides every scored file so a reducer that tried could not do it quietly. The comparable form is a table whose columns are readings with the cap in the cell — **a ruling the operator owes**, carried in the recon as ⧖ L-1. --- ## §4 · LEG 1 — the eleven-arm language bank, in this order, at every rung | # | arm | what it measures | 3090's minutes @ 350 W | |---|---|---|---| | 1 | `card-mapping` | loads a small model and watches **which card's memory rises** | 0.13 | | 2 | **A** | `gemma4:26b`, 4,096 → 131,072, KV `q8_0`; headline = the largest window held WHOLE | 10.00 | | 3 | **A2** | `f16` and `q4_0` beside `q8_0` at A's headline rung | 1.32 + 1.32 | | 4 | **A3** | fills 75 % of the headline window: cold prefill, TTFT at depth, decode at depth | 2.72 | | 5 | **D** | `mistral-small3.2:24b`, the same ladder | 7.78 | | 6 | **D-probe** | only if the planner spilled with room: `--num-gpu 99` | 1.35 + 0.18 | | 7 | **E** | 1 / 2 / 4 streams on `gemma4:26b` at `num_ctx` 4,096 | 2.15 | | 8 | **G2** | the doorman: one caller then four, `OLLAMA_=4`; median + p95 | 1.07 | | 9 | **G3** | `minicpm-v4.5:latest`, **TEXT path only — no image is ever read or sent** | 1.03 | | 10 | **G4** | `nomic-embed-text:latest`, 64-text batch × 5 | 0.72 | | 11 | `idle` | draw with the model resident and not generating, 30 s | 1.30 | | | **one bank** | | **≈ 32 min** | **The fit rule is the STRICT one**, inherited unchanged from the one-3090 bench: a rung FITS when `/api/ps` reports `size_vram == size` — every byte on the card, nothing in host RAM. The 10 and 12 GB legs of this ladder use a looser `any-vram` rule because nothing in the bank fits those boards; this board is 24 GB and both bank models fit it whole, so that rule is **not** in play and inheriting it would have let a spilled figure be published in a column headed by a whole one. The measured 3090 headlines to compare against: `gemma4:26b` → **131,072**, `mistral-small3.2:24b` → **65,536**. **Arms that do not exist on a single card** are written as NOT APPLICABLE rather than omitted: G1 (two seats vs one split), arm C (what a second card buys), the x16-vs-x4 slot arm. `bench_two_seats.py` is deliberately absent from this directory. --- ## §5 · LEG 2 — the render bench, two arms at every rung | arm | what it is | 3090's wall clock | |---|---|---| | **R1** | 3 graphs × (3 warm-up + 6 timed images) at batch 3 → 1 warm submit + **2 timed submits, n=2**, median | ≈ 2.5 min | | **R4** | sustained heat, batch 1, **ten minutes** of continuous drawing; the image count is the measurement | ≈ 10.5 min (602 s, 311 images) | | | **one rung** | **≈ 13 min** | **R4 runs LAST at every rung, deliberately.** `STOP_CORE_TEMP_C = 83.0`, and a mobile cooler under ten minutes of continuous drawing is the single most likely place in this whole bench for a self-abort. Running it last means a stop costs that rung's R4 and nothing else. **If it stops, the stop IS the measurement** — that is what a laptop does — and it is recorded as one, with the minutes and the image count it reached. **The threshold is never raised to get a longer number.** **The pins**: ComfyUI **0.21.1**, in a second checkout at `26515acd`, because this box's live checkout is 0.11.1 and the render tables pin 0.21.1. The three klein-4b model files (16.13 GB) were read from another box over the private network and **sha256-verified at both ends**. **There is no control seat.** Every earlier leg had one — the board that came out of the same slot. This card is soldered. `CONTROL_SEAT` is `None`, no seat in the file is clean including this bench's own, and no desktop seat shares either rung (95/175 against 250–450), so `seats_at_cap` answers with an empty list and a reason per seat at both rungs. That is a result. --- ## §6 · ARM T — THE TRAINING ARM IS A SECOND TRAIN, AND THIS IS ITS STATED ABSENCE **It is not run in this bench, and the reason is not the hardware.** The card is more than capable and the software stack is an exact match: `/workshop/music/ACE-Step-1.5/.venv` carries torch `2.10.0+cu128` with `sm_120` **compiled in** (no PTX-JIT fallback), which is the *same torch build the 3090 reference run used*; the reference peaked at 5.7 GiB allocator / 6,636 MiB card-side against 24 GB here. **What blocks it: the corpus is on another box, and that box is off.** `bench_train_ace.py` replays a run rather than re-preprocessing a corpus, and it refuses by design without the preprocessed tensor set: `TENSOR_DIR = /workshop/music/tensors/house-wide/20260906T092541Z-house0` and `REF_LOG = /workshop/music/out/house-wide/.../train.log`. Neither is on this box — only the finished adapter is, and its tfevents file is named `…tfevents.1788688329.benchbox.2045014.0`: **the run happened on benchbox**, which was reachable at 14:58Z and `Connection timed out` at 15:03Z and 15:05Z on 2026-09-21. Under the estate's own precedent the bench box is powered on demand, so that is a state rather than a fault. **Legs 1 and 2 do not depend on it and are not held for it.** Arm T is a **second train**: it runs when benchbox is up and the tensor set (331 stems) plus `train.log` and `run_train.sh` have been copied across. Its own second blocker — `guard_card()` refuses because it reads `power.limit`, which is `[N/A]` here — is closed by the same two-field cap reader §2 installed, but the arm still refuses first on the absent corpus, which is correct: the precedent is that the training arm **refuses rather than measures a false OOM**. --- ## §7 · THE INSTRUMENTS THIS BOX DOES NOT HAVE — three stated absences Each one names what was asked and what answered. A bench that is silent about a missing instrument publishes a gap; a bench that states it publishes a fact. | instrument | asked | answered | consequence | |---|---|---|---| | **whole-box watts** | `which upsc`; `systemctl is-active nut-server nut-monitor`; `/sys/class/power_supply/BAT1/power_now`; `/sys/class/powercap/intel-rapl:0/energy_uj` | not found; inactive; absent; root-only | Whole-box watts and joules-per-1,000-tokens are **WITHHELD with this reason**, and the receipt (`results/-ups-gate-w.txt`) is written at every block's open and must be **read and quoted**, not merely produced. **Board watts are the measured quantity in every table this bench fills** — the same absence the desktop bench box published its entire 24 GB ladder under. | | **fan speed** | `--query-gpu=fan.speed` | `[N/A]` | the `fan-drawing` cell is **structurally unfillable** from this bench: a declared non-figure with this reason, never a gap filled later from another board's row. | | **memory-die temperature** | three NVML paths, as on every leg | `[N/A]` | the memory-temperature stop cannot arm; the core stop and the driver's own thermal-slowdown reasons are the thermal instrument. | A fourth absence is **derived, not missing**: the peak bytes-per-second ceiling is WITHHELD on this board because it is GDDR7 and the harness's two-bits-per-clock formula is a GDDR6/GDDR6X fact checked against three published bandwidths. The memory **clock** is a reading and prints. See `INSTRUMENT-DELTA.md` §2. --- ## §8 · THIS BOX IS NOT A QUIET BOX, AND THE BENCH DOES NOT MAKE IT ONE The workflow's standing law is *"lanes never touch live worlds/ports/DBs"*. This laptop serves `:8898`, `:8899`, `:8900`, `:8902` and four Postgres containers, and the **system ollama holds `nomic-embed-text` resident by its own unit's `OLLAMA_KEEP_ALIVE=-1`**. The bench does not have to stop them and must not starve them. * The bench instance is a **separate** `systemd-run --user` transient on **:11470** with `OLLAMA_KEEP_ALIVE=0` and the pinned 0.32.13 binary. `:` is refused by name and the system unit is never started, stopped or reconfigured. * The resident embedder is a **DISCLOSED TENANT**, not an evicted one. Unloading another service's pinned model to flatter a bench is not a measurement; it is a change to the thing being measured. * **The contention gate is left strict.** It refuses a scored run when mean GPU utilisation exceeds 5 % over a 10 s window at 2 Hz, and six refusals void an arm. On a box with a desktop session that is a real risk, and the right behaviour is to let it refuse — not to loosen it. Five consecutive samples read 0 % at recon, so a quiet desktop passes. * **The memory guard is quieted for the window, and put back.** `memshed.timer` fires every 30 s here and shed 16 times on 2026-09-20 alone with no bench running. It **cannot kill this bench** — its ComfyUI matcher is the literal `main.py --listen 127.0.0.1 --port 8188` and its ollama half curls `:`, while this bench runs on `:18190` and `:11470`; that was checked rather than assumed. But its `--deep` path `ollama stop`s whatever the SYSTEM instance holds, which would evict the disclosed tenant **mid-arm** and move the card's memory baseline under a measurement. So the wrapper **stops** the timer for the window and starts it again on the way out. It is never **masked**: the unit file is a symlink into `~/estate/systemd/` and `mask --force` destroys it. --- ## §9 · THE VERSION PINS, AND WHY NEITHER IS WIDENED `compare_cards.py` fills a cell **only** from a row satisfying every stated condition; a row for the right card that misses one gets a dagger and a footnote, not a value. | the table demands | this box has | what this bench does | |---|---|---| | ollama **0.32.13** | 0.32.14 | a **pinned binary** in the bench directory, whose own client version is READ BACK before anything starts. The live service is untouched. | | ComfyUI **0.21.1** | 0.11.1 | a **second checkout** at `26515acd`. The live checkout stays on its tag. | | quant `Q4_K_M` | `gemma4:26b` is Q4_K_M | ✓ | **Neither tuple in `compare_cards.py` is widened to make a number fit.** That is the whole point of a pin. --- ## §10 · THE DRY RUN IS THE LAW BEFORE THE FIRST LAUNCH Ratified by the operator on **2026-09-21**, the same day, *"after a night where a wrapper's first real launch was its first execution"*: > **A NEW CONFIGURATION GETS A DRY RUN OF THE WHOLE WRAPPER PATH — EVERY STAGE, ONE RUN, THE > SMALLEST TAG, EVERY FILE OPENED — BEFORE THE FIRST REAL LAUNCH.** A laptop bench is a new configuration by every measure: new box, new board, new board class, a cap mechanism nobody has walked, and three absent instruments. `dry-run-laptop.sh` walks every stage, writes only into `results/dryrun-/`, suffixes every file `-dryrun`, never sets a cap, never touches a live unit, never pulls a model and never sudoes. `dry_run_check.py` opens every file it produced and asks four questions of each: is it a result at all; is it about THIS leg; if it measured nothing does it SAY WHY; and did the model sit on the card. **D9 is the only verdict that counts.** --- ## §11 · WHAT WOULD MAKE THIS BENCH WRONG Registered in advance, so none of them can be discovered afterwards and called a nuance. 1. **A cap that moved under an arm.** Every stage reads the cap at its open and again at its close and STOPS rather than relabels. With Dynamic Boost stopped it cannot move by itself — which is exactly why a move means something set one under the bench, and the stage is void rather than slow. 2. **The clock lock left on.** Then the figures are not like-for-like with the desktop rows, a receipt file says so by name, and no cell from that rung may sit beside a benchbox row. 3. **A desktop 5090's name passing as this one's.** `NVIDIA GeForce RTX 5090` is a **prefix** of this board's name, so the substring match every earlier leg used would pass it. Both legs compare the product name by **exact equality**. 4. **A figure from another leg's file.** Every result file carries the cap in its name and this leg's `box_class` inside it; two rungs write into one `results/` directory and a suffix that did not name the watts would let them collide. 5. **A number in a cap-keyed cell.** See §3. `CAP_AXIS_NOTE` rides every scored file. 6. **An arm that measured nothing and did not say why.** The dry run's checker exits non-zero on exactly that, and it is the reason the rehearsal exists. --- # AMENDMENT 3 — the cap ladder is WITHDRAWN; two postures replace it (2026-09-21, ~17:20Z) **What this amendment is about, for a reader who scrolled straight to it.** This pre-registration committed the bench to a two-rung power ladder on one NVIDIA GeForce RTX 5090 Laptop GPU — 175 W then 95 W, §3 — with the rungs to be set by an operator paste. **Window: the read-back at 2026-09-21 ~17:20Z UTC, before any measured arm had run.** Nothing had been measured under the old §3 when it was withdrawn, so no published figure changes; what changes is what the bench is allowed to claim from here. **The read-back that ended it.** The operator's Step 1 paste answered: ```text Changing power management limit is not supported for GPU: 00000000:01:00.0 ``` With `nvidia-powerd` stopped the board then read **Current 95.00 W = Default 95.00 W, Max 175.00 W**. So this board refuses to have a power limit SET, at any wattage. §3's ladder was built on a mechanism this board does not have. ## §3-amended · TWO POSTURES, NOT TWO RUNGS | posture | mechanism | what its cap cell is allowed to say | |---|---|---| | **fixed, 95 W** | `nvidia-powerd` STOPPED. The board enforces its own `power.default_limit` and nothing moves it. | the number **95 W**, read back at every stage open and close, and a change STOPS the stage | | **dynamic-boost** | `nvidia-powerd` RUNNING, no cap set (none can be). The board floats its TGP between its default and its maximum against the CPU's draw. **This is how the machine ships.** | a **RANGE** — min/median/max of `enforced.power.limit` over the stage, **with its sample count** — and never a single wattage | **The 175 W rung is withdrawn rather than renamed.** 175 W is reachable on this board only by letting Dynamic Boost float the limit up to it. A file called `...-175w...` would be claiming a setting that was never made. Its wrapper is deleted rather than left runnable. **Three things the boost posture is forbidden to do**, registered here so none of them can be discovered afterwards and called a nuance: 1. **Print a flat limit as a span.** If every sample reads the same wattage, `cap_witness.py` records `limit_moved: false` and the cell reads `"95 W, flat"` with a note saying a flat limit under this posture is a FINDING — most likely that `nvidia-powerd` was not floating anything. `95–95 W` is never printed. 2. **Report a range without its n.** Every range carries `n=`. A range over one sample is a number wearing a range's clothes. 3. **Treat a moved board ENVELOPE as a wide range.** The enforced limit moving between 95 and 175 W is the posture; the 95 or the 175 *itself* moving means the board is not the board this file describes, and the stage is void rather than wide. **§11 gains a seventh way this bench could be wrong:** *a single wattage typed into the boost posture's cap column.* There is no such number. Every cell from that pass is a range out of the run's own 2 Hz trace, or it is withheld with its reason. --- ## Q-BOOST-1 · A REGISTERED QUESTION, NOT A RULING — which posture is "how this laptop ships"? **This lane does not decide this. It is recorded so the decision is made once, by its owner, and in the open.** Both of this bench's passes run with the GPU clocks **UNLOCKED**. The operator released this box's boot-time lock (`ai-perf.service`, `nvidia-smi -lgc 1200,2550`) with `-rgc` in Step 1, and the runsheet re-applies it only in its LAST step. That choice was made for comparability: benchbox, which produced the desktop rows this bench is set beside, runs no clock lock at all, and a board that cannot clock below 1200 MHz is not honouring a power posture the way an unlocked one does. **The question.** The dynamic-boost pass is justified in this amendment as *"how the machine ships"*. But this box does not boot with Dynamic Boost alone — it boots with Dynamic Boost **and** the 1200–2550 MHz clock lock, because `ai-perf.service` applies the lock at every boot for ComfyUI's first-load latency. So there are two defensible readings and they answer different questions: * **unlocked boost** (what this bench measures) — *what this silicon does at a floating TGP*, comparable with the desktop rows, and the only one of the two that can be set beside benchbox. * **shipped boost** (Dynamic Boost on **and** the lock on) — *what this machine does for its owner on an ordinary day*, comparable with nothing else in the estate, and arguably the more honest headline for a page about a laptop. **What it would cost to answer both:** a third pass, about 45 minutes of card time, one extra operator paste (`sudo nvidia-smi -lgc 1200,2550` before it and nothing after, since the restore re-applies the lock anyway). Every result file already records the lock's verdict **read from the card**, so a third pass would be distinguishable from the other two without a new label. **What this lane did instead of deciding:** built the boost pass unlocked, said so in the wrapper's own header, and wrote this. If the answer is "measure the shipped posture too", it is a third pass and not an edit to either of the two. --- # AMENDMENT 4 — a THIRD POSTURE, `shipped`: Dynamic Boost AND the clock lock (2026-09-21, ~23:2xZ) **What this amendment is about, for a reader who scrolled straight to it.** This pre-registration governs a bench on one **NVIDIA GeForce RTX 5090 Laptop GPU 24 GB**, soldered into the laptop it measures. Amendment 3 withdrew the planned power ladder — the board refuses `nvidia-smi -pl` at any wattage — and replaced it with two POSTURES, `fixed · 95 W` and `dynamic-boost`, both of which were then measured with the GPU clocks RELEASED. **This amendment registers a THIRD posture, `shipped`: `nvidia-powerd` running AND this box's own boot-time GPU clock lock (`ai-perf.service`, `nvidia-smi -lgc 1200,2550`) IN FORCE — what this laptop does for its owner on an ordinary day.** **Window, at both ends, UTC.** The two measured passes finished at **2026-09-21T18:43Z** (the fixed 95 W rung) and **2026-09-21T21:02Z** (dynamic-boost). This amendment was written at **2026-09-21 ~23:2xZ**, after both and **before the third pass had run**. Nothing measured changes: the two passes' result files are untouched, every one still records the posture it was measured under, and no file in this leg carries the token `shipped` yet. **The comparison to the prior readings, in one sentence.** Against the two passes already on the page, the shipped pass changes exactly one condition — the clock lock goes from released to in force, with `nvidia-powerd` running in both — so its rows are a like-for-like reading of *what this machine's own boot-time lock costs or buys* and of nothing else. ## Who asked for it, and what was asked `Q-BOOST-1` above is a REGISTERED QUESTION, not a ruling: *which posture is "how this laptop ships"?* It named two defensible readings — **unlocked boost**, comparable with benchbox's unlocked desktop rows, and **shipped boost**, comparable with nothing else in the estate — and priced the answer at a third pass of about 45 minutes plus one operator paste. **an operator ruled it on 2026-09-21 at about 23:10Z: *"roll with the rec"*.** The rec was: measure the shipped posture too, **as a THIRD PASS and never as an edit to either of the two**. So: * `leg-laptop-shipped.sh` is a new wrapper. `leg-laptop-95w.sh` and `leg-laptop-boost.sh` are unchanged and are not re-run. * Every file the third pass writes carries **`shipped`** exactly where the other two passes' files carry `95w` and `dynboost` — result files, witness traces, witness envelopes, the per-stage logs, the clock-lock receipt and the pass receipt (`RUNG-SHIPPED-RECEIPT.txt`, or `-FAILED.txt`). Three passes write into ONE `results/` directory and a suffix that did not name the posture would let them collide, with the survivor labelled by nothing but its mtime. * Its cap cell is **the same RANGE with its `n`** that the boost posture's is, out of its own 0.2 Hz witness and its own 2 Hz traces. The limit floats identically; §3-amended's three prohibitions (never a flat span, never a range without its `n`, never a moved envelope treated as a wide range) apply to it unchanged and per posture — one range is never pooled across two. ## §4-amended · WHAT THE `shipped` POSTURE'S ROWS MAY AND MAY NOT BE SET BESIDE | may be compared with | may NOT be compared with | |---|---| | **this machine's other two postures** — `fixed · 95 W` and `dynamic-boost`, measured on the same board, the same day, the same instrument, the same pinned ollama and the same pinned ComfyUI. The lock is the only condition that differs from the boost pass. | **any benchbox row, any desktop row, any cap-keyed cell.** **PREREG §11.2 STANDS AND IS NOT WEAKENED BY THIS AMENDMENT**: a board that cannot clock below 1,200 MHz is not honouring a power posture the way an unlocked one does, benchbox runs no clock lock at all, and no cell from a locked pass may sit beside a benchbox row. That is why the first two passes released the lock, and it is why this pass's figures are not offered for those tables. | | **nothing else in the estate, for the lock question.** No other box carries this part and no other box in the ladder runs a clock lock, so there is no second reading of "what a lock costs" to compare with. That is a stated absence, not a gap. | **its own prior self.** There is no earlier `shipped` reading of this board. The 16 published diffusion rows and 14 published language rows for this machine were measured with the card either unstated or deliberately parked (§0); none is this posture. | **The one thing it is FOR.** A page about a laptop wants to know what the laptop does. This pass is the only row in this bench that answers that without a footnote — and the two unlocked passes are the only rows that can be set beside a desktop board. Both are needed and neither replaces the other, which is precisely why the ruling was a third pass. ## §11-amended · WHAT WOULD MAKE THE `shipped` PASS WRONG — registered in advance §11's six ways this bench could be wrong, and Amendment 3's seventh, all still apply. The shipped pass adds three of its own, and each is a REFUSAL in the harness rather than a caveat in prose. 1. **The clock lock reading OFF.** The lock is not a confound this pass tolerates; it is the posture's DECLARED CONDITION. A `shipped` file measured with the clocks released would be the `dynamic-boost` pass wearing a third name — and its rows would then be compared against themselves, which is the one thing this pass exists not to be. `clocklock.sh`'s `clock_lock_require_on` REFUSES on `OFF-BY-CARD` **and on `UNDETERMINED`**: a posture whose whole claim is "the lock was in force" may not claim a lock nobody proved. The inverse gate, `clock_lock_require_off`, refuses the other two passes on a decided `ON`. The receipts gate refuses afterwards too, so a file that somehow got written is caught by the reducer. 2. **`nvidia-powerd` not running.** Then the board sits flat at its own default limit, which IS the fixed rung, and this pass would re-measure that rung and file it under a range — and a range whose ends are the same number is a fabrication dressed as a reading. `cap_require_powerd_running` is this pass's first gate, exactly as it is the boost pass's. 3. **A file without `shipped` in its name.** Three passes share one `results/` directory. The token is built from the posture in one place per writer (`LABEL` in the driver, `$(cap_posture)` in the witness, `CLOCK_LOCK_VERDICT` + `LABEL` in the lock receipt), and a test asserts each. **And a fourth, which is about the READER rather than the run:** a table that pooled the two floating postures' ranges into one cell, or filled the shipped column from the boost pass's witnesses. Both reducers take the posture as an argument and a fence asserts the two postures' witness files are disjoint. ## ⚠ THE MEASUREMENT THAT CHANGED THE INSTRUMENT: 1,192 MHz, not 1,200 **Read this even if you skipped the rest, because it nearly published a false refusal.** The only falsifiable signal for the clock lock is `clocks.sm` against the lock's floor, and until now the probe's rule was *a reading below the floor proves the lock is off*. Read on this card at **2026-09-21T23:13Z**, with the lock in force and the box idle: ```text clocks.sm 1192 MHz · clocks.max.sm 3090 MHz · utilization.gpu 0 % · memory.used 15 MiB twelve consecutive reads, all 1192 ``` **`ai-perf.service` asks for 1,200 and the driver SNAPS the floor to the nearest supported SM clock — eight MHz, 0.67 %, BELOW the request.** A probe testing `clocks.sm < floor` would therefore have answered `OFF-BY-CARD` on the very pass whose identity is the lock, and refused it with a paste that had already been applied. So three things are registered: * the floor carries a **quantization tolerance** (25 MHz, three times the measured snap, and nowhere near what an unlocked card reads), and `OFF-BY-CARD` now needs a reading below `floor − tolerance`; * the decisive ON verdict is **`ON-BY-CARD`**: the card **AT REST** (`utilization.gpu` 0 % across every sample) with `clocks.sm` pinned at that floor. Unlocked and at rest this board reads **180 MHz** (18:11Z) and **232 MHz** (17:30Z); merely HOLDING A MODEL RESIDENT puts it at **1,590 MHz** with the lock OFF (18:05Z) — which is why a busy card decides nothing in either direction and why the at-rest requirement is load-bearing rather than tidy; * **`clocks.max.sm` never reports the lock on this board.** It reads 3,090 MHz — the board's own unlocked maximum — with the lock released (17:30Z) AND with it in force (23:13Z). The `ON-CONSISTENT` verdict is kept because it is correct for a board that reports a ceiling, and it is recorded here as **measured never to fire on this one**. Both measured passes' clock-lock receipts read `clocks.sm` **180 MHz** over twelve reads, far below any tolerance, so their `OFF-BY-CARD` verdicts are unchanged by this and no published figure moves.