# A laptop, asked the desktop's questions — data kit

**What this directory holds.** Every receipt behind the exhibit *A laptop, asked
the desktop's questions*
(https://research.strata2signal.com/a-laptop-asked-the-desktops-questions/): one
laptop graphics part at three postures on one night, the render bench that ran
beside it, and the desktop result files the page's comparison tables read.

The part is an **NVIDIA GeForce RTX 5090 Laptop GPU with 24 GB**, soldered to the
mainboard of an **MSI Raider 16 Max HX (B2WJ-002US)** with 64 GB of system
memory, on mains power throughout. It refuses a power cap outright, so the
planned two-rung ladder was withdrawn before a single arm ran and three
**postures** replaced it: its fixed 95 W default; NVIDIA's Dynamic Boost left to
float the budget, which it held between 140 and 150 W; and the machine's own boot
state, boost and a clock lock together.

The three passes' windows, at both ends:

| pass | opened (UTC) | closed (UTC) |
|---|---|---|
| 95 W, fixed | 2026-09-21T18:43Z | 2026-09-21T19:34Z |
| Dynamic Boost | 2026-09-21T21:01Z | 2026-09-21T21:50Z |
| boost + clock lock (the shipped posture) | 2026-09-22T00:10Z | 2026-09-22T00:56Z |

A **fourth** window is in here too, and it is a set-aside rather than a result:
the first attempt at the boost pass opened **2026-09-21T20:24Z** and had to be
abandoned when the render leg's own gate refused to start on a card another
process was holding. Its language leg is kept in full under
`results/superseded-tenant-resident-20260921T2024Z/` as a replication — it agrees
with the re-run within nine-tenths of a token a second at every window of the
mixture model — rather than deleted.

**Licence: CC BY 4.0.** Take these rows, re-plot them, check our arithmetic,
publish what you find. Attribution: strata→signal research,
research.strata2signal.com. If you find an error in any of this, we want to hear
about it: hello@strata2signal.com.

Machine readers start at `index.json`, which lists every file with its byte count
and its sha256. `provenance.json` is the other half: it names every rule applied
to every file, with the count of times each one fired, and both digests of each
file a rule touched.

## What is in here

| path | what it is |
|---|---|
| `PREREG.md` | The pre-registration, written before the first arm: the arms, the refusals, the counting rules, and both dated amendments — the one that withdrew the power ladder when the board refused a cap, and the one that registered the third posture. |
| `RESULTS.md` | The measurement record. Every figure the page prints, with the result file it was read from named beside it, and the comparisons this data does not support. |
| `OPERATOR-CONDITIONS.md` | What an operator did to the machine for each pass, in order, with the moment of each: the fan, Dynamic Boost, the clock lock, and the guards paused for the window. |
| `INSTRUMENT-DELTA.md` | What changed in the instrument between the desktop legs and this one, and which ratios carry that difference. |
| `RUNG-95W-RECEIPT.txt`, `RUNG-DYNBOOST-RECEIPT.txt`, `RUNG-SHIPPED-RECEIPT.txt` | Each pass's own receipt, as the harness printed it. |
| `results/gpu-5090-laptop-24g-*.json` | The language bench's result files: the arm's identity and posture, its own UTC window, the instance's environment, the runtime's version answer, the card's identity, the frozen prompt's sha256, and every scored run's first-token wait, decode rate, watts, joules, clocks and temperature. |
| `results/cap-witness-*.csv` | The cap witness for each arm: the board's power limit, clocks and temperature at 2 Hz through every scored run, one row per sample. |
| `results/*-clock-lock-*.txt`, `results/*-ups-gate-*.txt` | The gate readings taken at each pass's open and close — the clock lock read off the card, and the power supply's state — as the tools printed them. |
| `results/instance-env-one-*.json` | One reading of the serving instance per configuration: its port, its own environment, the runtime's pinned version, the card it was pinned to, and the co-resident tenant it disclosed. |
| `results/superseded-tenant-resident-20260921T2024Z/` | The superseded first attempt at the boost pass, in full, with its own README saying what it is and is not. |
| `logs/rung-95w.log`, `logs/rung-dynboost.log`, `logs/rung-shipped.log` | Each pass's complete log, start to finish: every gate, every refusal, every wait for the card to come free, and every arm in the order it ran. |
| `render/RESULTS.md` | The render bench's measurement record: the three certified recipes, the images each arm drew, and the desktop rows they are set beside. |
| `render/INSTRUMENT-NOTE-2026-09-21.md` | The render instrument's own note: the checkout, the torch build, and why these ratios are read as a box-and-board comparison rather than a like-for-like one. |
| `render/results/*.json` | The render arms' result files: the recipe, its bytes' hash, the checkout's version answer, and every image's queue, execution and total seconds with the card's watts, clocks and temperature. |
| `render/logs/*` | Each render arm's log, as the harness printed it. |
| `references/desktop-*.json`, `references/render-*.json` | The eighteen desktop result files the page's comparison tables read, from the three benches that measured them, republished so the comparison rows can be checked against the files they were read off rather than taken on trust. |

**The reference names carry their bench, and that is not decoration.** Four of
the eighteen collide on basename — `r1-350w.json` and `r4-350w.json` exist in two
of the render benches — so a flat copy would have published sixteen files where
eighteen were listed. Every reference file is therefore prefixed with the bench
that produced it, and the documents that cite them cite these names.

**One citation points outside this kit**, and it is named here rather than left
to be discovered: `RESULTS.md` cites another bench's own `RESULTS.md` for a
median wattage over a whole configuration. That document is a different
exhibit's record and is not in this folder. Every figure this page reads from
that bench is in `references/`.

## The rules you need to recompute anything here

1. **Three runs, then the median.** Every rung is three scored runs of one frozen
   prompt. A first-token or decode figure the page prints is the **median** of
   the three, and the spread beside it is those three runs' own range. No run was
   dropped and none was re-run for a better number.
2. **The watts are the card's.** Board power, clocks, temperature and the
   enforced power limit were sampled at **2 Hz** through every scored run, and
   the limit was read again at the open and the close of every stage. Every watt
   in these files is read from the driver, off the card — never the wall's, and
   never the whole machine's. Under the fixed posture a change in the limit would
   have voided the stage, and none happened; under the two floating postures the
   readings are the ranges the wattage cells print.
3. **A busy card does not start a run.** A contention gate refused to start any
   scored run that found the card more than 5 per cent busy over the ten seconds
   before it, on the registered rule that six refusals in a row void the arm. It
   found the card busy on **23 of its 77 checks** across the three passes and
   waited — the busiest read 99 per cent — and no run needed more than three
   tries, so nothing was voided. What the gate reads is the card; what the
   processor was doing during a run is not gated, and under the two floating
   postures the processor's draw is what moves the board's budget.

## Sanitised at the pen, not copied

These files were written on the machine that ran the bench, by tools that print
absolute paths, host names, a daemon port and the wall clock they were handed.
None of that is published here. **Every change is a named mechanical rule applied
by one program**, in a fixed order, and `provenance.json` records each rule, what
it does, and how many times it fired on each file, with both digests of every
file a rule touched. Nothing was reworded, nothing was "cleaned up", no line was
dropped from inside a file, and no file was edited by hand. **93 of the 180 cut
files are byte-identical to the private record** — no rule fired on them at all.

The rules, in the order they run:

| rule | what it does |
|---|---|
| `reference-path-to-kit-path` | A document citing a desktop bench's own result file is re-pointed at this kit's copy of that file, under the public name it ships as, relative to the citing document. Nothing but the path changes. |
| `home-path-to-workshop` | An absolute path into a private home directory becomes the neutral root `/workshop`. The path's remaining segments, the file it names and every byte around it are unchanged. |
| `box-name-to-role-*` · `desktop-box-name-to-role*` · `second-box-name-to-role` | A machine name becomes the role that machine played — in prose, in an identifier, in a filename, in a directory name and in a system configuration path. This shelf publishes what a bench measured, never which box ran it. Hardware is a different matter and is named in full. |
| `host-name-to-this-laptop` | The host name the harness stamped on each rung becomes the machine as the page names it. |
| `operator-name-to-role` | The operator named in a ruling or a note becomes "an operator". |
| `daemon-port-to-role` | The port a co-resident copy of the runtime listens on becomes the role that number played. The colon is kept, so a reader still sees that it was a port. |
| `parallel-env-to-role` | The **name** of the runtime environment variable that sets how many requests the instance serves at once is generalised to the role it plays. **Its value is untouched** — it is one of this bench's own settings, the concurrency arm turns on it, and the value is what a reader needs. |
| `local-offset-to-utc` | An instant written with a local UTC offset is re-stated as **the same instant** in UTC and Z-stamped. The sub-second digits are carried across untouched. |
| `zone-abbrev-to-utc` | A wall clock stamped with a zone abbreviation — the shape the service manager prints — is re-stated as the same instant in UTC, with the weekday recomputed where a date is present. |

**No figure was touched, and that is a measurement rather than a promise.** The
program that cut these files carries a fence that re-reads every numeric token on
both sides of every file and refuses on any difference. It reads clean over all
180 files and **241,988 numeric tokens**. The only digits any rule moves are the
ones inside the **41 instants** that carried a local offset or a zone
abbreviation; each of those is parsed on both sides and must name the same
moment, and each of the 41 does. A second fence refuses any substitution that
landed a role word against a run of digits, which is how a sanitiser destroys a
measurement rather than hiding a name.

**About the timestamps.** Almost every instant in these files was already written
in UTC by the harness. The 29 that were not are the serving instance's own
model-expiry stamps, which the runtime writes in the host's local clock; the 12
others are the service manager's, which prints a zone abbreviation. All 41 are
converted and none is deleted: deleting an offset would silently re-label a local
clock as UTC and move the moment by hours.

## What is deliberately not here

- **The frozen prompt file, the render inputs and the harness code.** The
  prompt's sha256 and each recipe's hash are in every result file that used them,
  so a holder of the same bytes can prove they are the same bytes. The harness
  itself carries the private vocabulary this kit exists to keep out, and
  sanitising code is a different job from sanitising a record.
- **The dry-run directories and the progress journal.** Four dry-run passes and a
  progress log that record the rehearsal of the instrument rather than any
  measurement on the page.
- **The rendered images.** The render arms' figures are seconds and watts; the
  pictures they drew are the print lab's own surface.

Each of those is named here rather than implied by its absence.

## What these rows will and will not tell you

They will tell you what one laptop part did on one night, at three postures, on
this bench's own frozen runtime and prompts, against desktop boards measured by
the same instrument — and they will tell you the conditions each figure was taken
under, because every figure has a file and every file has its window.

They will not tell you what a different laptop carrying the same GPU name does:
the part's budget is the chassis's to set, and this one's is this one's. They will
not tell you the machine's draw at the wall. They will not settle the render
ratios as a like-for-like card comparison — `render/INSTRUMENT-NOTE-2026-09-21.md`
says why in the instrument's own terms — and they will not tell you how much of a
two-second run the board actually spent at its budget, because eight samples
cannot say.

## Not a standard

This is one part in one chassis on one night. It is a reading, not a rating.
