Inspectors would record the seal numbers and photographs when the capture equipment is installed, then compare them and the camera record at each inspection. A broken seal, a gap in the camera record or an unexplained door opening means requests from that period may be missing from the record. Every route that carries covered traffic would need the same protection.

These seals, the camera and the inspection routine are designed, not installed or qualified. A clean record cannot exclude every physical attack. Preview

This illustration shows one operator-operated hall. The declaration covers its whole operator-controlled compute pool, not only the ten foreground serving racks. Verifier-controlled equipment is listed separately and is not credited as the operator’s computing capacity. The inventory must identify the machines, GPU models and counts, locations and applicable time interval. Filing this record is distinct from an independent physical inspection; completeness remains an assumption unless supported by further evidence. In a shared cloud or colocation site, the declaration must name the operator’s specific compute pool; other customers’ equipment is outside that pool.

The capacity record names the GPU pool, the time interval and the computing rate used for each device. The checker’s accounting software stores capacity records in a database; these are records about the chips, not software installed on each chip. Today the capacity input is entered by hand, and no inspection establishes that every GPU has been listed. The proposed on-site checker is the rack shown here. A credible upper limit must include possible higher clock speeds. Work and capacity must describe the same machines, interval and arithmetic unit. The accounting unit is an integer multiply-accumulate operation: multiplying numbers and adding the results. The chart’s values are illustrative.

A fingerprint is a cryptographic hash of the model weights—the numbers that define the model. Proofs are checked against the checker's own fingerprint; that it fingerprinted the real published checkpoint is a premise. The proof covers an integer version of the model. On 17 test sequences it picked the same next token as the released model 90.8% of the time when both read the same text, and 3 of 17 free replies came out identical. That is no guarantee for other prompts. A verifier flaw found on 29 Sep is fixed (reviewed), and earlier proofs are being re-checked with the fixed verifier; until then they count 0 bitsRe-check pending.

The verifier keeps the capture path and its signing keys under separate custody. Each entry seals the one before it, so an edit breaks every later seal. Today the log and its signed checkpoints stay inside the recorder: outside witnesses are built but not tested yet. Traffic that skips the recorder isn't covered.

The verifier supplies fresh random selection only after the recorder has sealed the batch.

The proof computer proves the specified integer-model calculation. This is extra work, separate from serving the answer. Proof generation cost depends on the model, statement and proof system.

Our zero-knowledge proof of a 7B model took 50 min on an 8-core cloud CPU.

For each selected answer, the proof binds the recorded input, output and approved model fingerprint. A valid computation proof establishes this mathematical relation under the proof system’s assumptions; it does not establish that the answer is true, useful or safe.

One server would check proofs and act as the location landmark from a trusted position. It would send an unpredictable work challenge, time the reply committing to its result, then check the matching work evidence afterward. Timing would use a dedicated fast path so proof checking does not delay the measurement. A signed reply alone places the key holder; fresh work tied to the reply is needed to bound where computation happened. Light covers about 150 km per millisecond of round trip, so a 0.30 ms deadline allows at most 45 km. Computation and network delays enlarge that bound. The combined deployment has not been measured on the planned cluster: these are sizing numbers.

Useful inference would count toward a work target below the capacity ceiling. When demand falls, fresh verifiable filler could supply the shortfall, including when inference is idle. That filler path is proposed, not implemented in this demo. Keeping a GPU busy is not enough: credited work must be fresh, not counted twice, and consume the resource being bounded. Hardware overclocking can raise the ceiling; it does not itself establish more credited work. The bound still needs a complete GPU list, no outsourcing, recorder coverage and compatible units in the same pool and time window. It bounds other uses of the chips; inference itself can still contribute to capability development. Publishing to outside witnesses is built but not tested yet.