# Operator conditions the instruments cannot read (this bench, this laptop)

- 2026-09-21T17:30Z — the operator set the laptop's cooling fan to MAXIMUM by hand ("i'm cranking the fan now") before the 95 W rung's relaunch. This board reports `fan.speed [N/A]`, so no result file can carry the setting; it holds for the 95 W rung and the dynamic-boost posture unless a later line here says otherwise. The 17:27–17:28Z attempt (died on harness defects, no arm measured) ran BEFORE the fan was raised.
- 2026-09-21T19:10Z — HOW the fan was set: the operator's Fn+Up (the laptop's own max-fan key), held for the whole 95 W rung from before its third start (18:43:09Z). The card's own temperature is in every result file; the fan speed is not.
- 2026-09-21T21:00Z — THE DYNAMIC-BOOST PASS WAS RE-RUN, both legs, after its first attempt's render leg refused to start: the system `ollama` held `nomic-embed-text:latest` (610 MiB, keep-alive forever; loaded ~19:51Z by the archive's hourly embed job, i.e. AFTER the 95 W pass and BEFORE the boost pass). The first attempt's LEG 1 ran with that tenant resident and is kept under `harness-llm/results/superseded-tenant-resident-20260921T2024Z/`; the lead unloaded the tenant (`ollama stop`; it reloads on its next call — no data lost) and paused the user timer `scribe-embed.timer` for the window (stopped, never masked; restarted after the pass). The fan stayed at the operator's maximum throughout. No harness file was edited between the passes.
- 2026-09-21T22:05Z — MAINS POWER, read after the passes by the lead: the laptop's AC adapter read online (`/sys/class/power_supply/ADP1/online` = 1) and the battery `Not charging` (full), and upower's charge and rate histories hold NO sample between 18:30Z and 22:00Z — a battery that had discharged would have written some. Both passes ran on mains power; no instrument in the bench reads this, so it is stated here.
- 2026-09-21T22:15Z — CORRECTION to the 21:00Z line above: the tenant was NOT loaded by "the archive's hourly embed job" — that job (scribe-embed.timer) and the archive's summarizer both point at a remote seat, not at this box's :<the runtime's default port>. The system ollama's journal shows ONE local `POST /api/embed` on the loopback at 19:51:10Z that loaded nomic-embed-text; the journal does not name the caller. The pause of scribe-embed.timer for the re-run's window was therefore a precaution, not the cause's removal; the card was verified empty (`/api/ps` = [], no compute apps) at the re-run's open and again at its render leg's gate.
- 2026-09-22T00:57Z — THE SHIPPED PASS (Dynamic Boost running AND the clock lock ON, 1200–2550 MHz, restored by the operator at 23:05Z with `sudo nvidia-smi -lgc 1200,2550`; read back ON-BY-CARD at every gate) ran 00:10:49–00:56:33Z on an empty card (verified at the open and at the render leg's gate; scribe-embed.timer paused for the window and restarted after; a peer session held its local model loads). FAN: the operator's max-fan setting (Fn+Up) from the earlier passes was NOT re-confirmed for this pass — the key's setting persists until changed and the operator did not report changing it; no instrument on this box can read it. Mains power throughout (ADP1 online).
- 2026-09-22T01:35Z — THE FAN FOR THE THIRD PASS, asked directly: the operator answered "i'm not sure" whether the max-fan setting (Fn+Up, set before the first pass) was still in force during the shipped pass (00:10:49–00:56:33Z). So the fan condition for that pass is UNCONFIRMED, not asserted. For what it is worth and no more: the shipped pass's ten-minute arm plateaued at 68.0 °C at 4.6 min and peaked at 70 °C, against the boost pass's 68.0 °C at 5.5 min and 71 °C under the confirmed max-fan setting — consistent with the same fan condition, not proof of it.