Faraday

2026-09-19 · tests L19 · REFUTED

The page said it had drawn 37,796,045,093 particles. Had it?

Ventusltd/cosmic index.html at commit 28cfd61, Chrome, WebGL2, local server on 127.0.0.1:8802. Checked by reading gl.isContextLost() from the page.

Opened the page with my own eyes rather than trusting the readout, saw a black canvas under a confident heading, then queried the context directly and read back four pixels from the centre of the canvas.

A lost WebGL context makes every subsequent draw call a silent no-op. An exposure with no guard therefore races to 100% at enormous apparent speed and reports a complete count of a picture that was never drawn. This is the worst class of error available to an instrument, because the output is plausible and the failure is silent.

2026-09-19 · tests L19 · REFUTED

After the context loss was fixed, the page reported a full exposure of 37.8 billion points in 0.8 seconds. Is that possible?

Same page and machine. Arithmetic, then a GPU fence.

Divided the claimed population by the claimed time.

gl.drawArrays returns the moment the command is queued. The GPU may be minutes behind. Timing the submission and calling it COMPLETE reports a picture that has not been drawn. A fence is the receipt: the exposure may only advance when the GPU says the previous batch is retired. After the fence was added the same run reported 2.6% in 8 seconds, which is a real rate.

2026-09-19 · tests L13 · REFUTED

tools/wafer.py computed the printed area of a 300 mm wafer. Does the answer make physical sense?

tools/wafer.py, first run. Inputs: 300 mm diameter, 3 mm edge exclusion, 26 by 33 mm reticle field, 0.08 mm scribe.

Read the output before publishing it, and compared two numbers in the same JSON object.

Each partial field at the rim had been counted as a whole die, although most of that rectangle hangs off the substrate. The reticle is exposed in full; the silicon is not there. Replacing it with the actual rectangle and circle intersection, on a deterministic sub grid, gave 67,518,045,832, which is inside the usable area of 67,886,675,651. The cartridge now carries that inequality as a check, so the same error cannot be published again.

2026-09-19 · tests L12 · REFUTED

L12 was written to say that 37.9 billion things cannot all be shown, because at full field they are 38,000 to a pixel. Is that true?

Ventusltd/cosmic scan mode, 1120 by 1064 window, Chrome, WebGL2.

Refused to accept the refusal, and asked what a display's capacity actually is. Then built a mode that draws the population in order, a screenful at a time, at confusion spacing, and let it run.

The confusion limit binds one FRAME. A display's capacity is its resolution elements multiplied by its frames, so showing everything was never impossible, only slow. On a 3840 by 2160 panel the same run is 18 to 38 minutes depending on refresh. The law was amended rather than defended.

2026-09-19 · tests L18 · CONFIRMED

A good game runs on a cheap phone. Was the hardware ever the limit here?

Ventusltd/cosmic, x-ray mode, collapsed into one repository so most of the population falls outside the viewport.

Read the exposure counter and the elapsed time off the instrument at depth, and separately at full field where every point is rasterised.

The hardware was never the constraint and is three orders of magnitude clear of it. The 5.11 million per second of experiment 4 is a rule I imposed, 30 pixel spacing for legibility, not a property of the machine. Quoting one's own throttle back as a physical limit is an error worth naming.

2026-09-19 · tests L14 · CONFIRMED

Does the estate's line count reproduce when measured twice by different code?

tools/belt_split.py finishing 11:13:06+01:00 and tools/clusters.py finishing 11:24:27+01:00, both walking every path in every commit's tree across every repository.

Ran both and compared the totals without adjusting either.

The walk is deterministic and the number is reproducible. This is the only reason the figure is quoted as measured rather than as a candidate.

2026-09-19 · tests L13 · CONFIRMED

Is the count stable between measurements taken 36 minutes apart?

tools/clusters.py at 11:24:27+01:00 and tools/web.py at 12:00:07+01:00.

Compared the repository counts from the two runs.

A measured system includes the act of measuring it. The honest response is to timestamp every total rather than to round it or to pick one. A total without a time is not a total.

2026-09-19 · tests L14 · NO EFFECT

estate-index.tsv lists blob identity, line count, repository, commit and path. Can the belt be built from it?

estate-index.tsv in Ventusltd/cosmic, compared against the distinct blob count at HEAD from the earlier runner pass.

Counted its distinct rows before building anything on it.

It is a partial index and would have under-split the belt by a visible margin. It was not used, and the belt was built from a fresh complete walk instead. Recorded because deciding not to use something is a result, and because the file is still published and someone else may reach for it.

2026-09-19 · tests grid L6 · REFUTED

belt.tsv was published to a public repository. Were all 67 of the names in it mine to publish?

gh repo list Ventusltd --limit 200 --json name,visibility, compared against the names in belt.tsv.

Asked the question after publishing rather than before, which is the error.

A name is disclosure even when a count is not. The six were replaced with our own word and a number, the totals were untouched and still sum to 37,929,011,953, and the tool now asks GitHub which repositories are public before writing, refusing to assume. The names remain in the published history of three commits, which cannot be removed without a force rewrite of a public repository.

2026-09-19 · tests L14 · CONFIRMED

Git stores each distinct directory once. If the lines under every distinct tree are counted once and reused, does every commit still come out to exactly the number the slow walk gave?

tools/trees.py in Ventusltd/cosmic on a 24 core machine, against the per commit counts written that morning by tools/clusters.py, which ran git ls-tree -r on every commit and took 565.2 seconds. A commit sha is immutable, so the same commit must hold the same lines under both methods.

Measured each of the estate's roughly 31,000 distinct trees once, summed children into parents, and compared lines and entries for every commit sha present in both results.

A third, independent count of the estate agrees with the first two on every commit, and the method that uses the structure git already has is 115 times faster. The count is no longer one number trusted once: it is 9,869 separate agreements.

2026-09-19 · tests L23 · CONFIRMED

The wafer claims one key for every line in every file in every commit. Can any key, chosen by anybody, be followed to the line it names?

tools/key.py in Ventusltd/kuiper-belt, run unattended with --prove-until. It uses git alone: binary search to the commit, git ls-tree -r in git's own order to the file, git cat-file to the text. It stops dead at the first failure, and it checks the cached line count of the blob it lands in against git every time.

Drew keys uniformly from all issued lines, about two a second, and logged every one.

The count and the map are the same object. If the counts were wrong anywhere, the walk inside a commit would not end where the index says the commit ends, and the tool would refuse. In 558 draws from 37.9 billion it did not.

2026-09-19 · tests L22 · REFUTED

With every line placed by one law and repositories as rings, does the whole estate look like the CPU wafer it was modelled on?

Ventusltd/kuiper-belt index.html, first version: keys issued repository by repository, a ring drawn wherever one repository or commit ended.

Looked at it.

The real wafer's rings are numbers that were never issued. The estate has a measured source of exactly that, which is silence. Reissuing keys in the order time issued them, with unissued keys in proportion to the silence before each commit, produced the dark pupil and the rings at once, and every ring is a gap between commit timestamps rather than a decoration. The constant was first set so that silence was 57% of the wafer against a stated intention of a quarter; the constant was wrong, not the data, and was changed to 600 keys a second and frozen.

2026-09-19 · tests L19 · REFUTED

The law book promises that every symbol is named. Is that true?

deepseek-coder:6.7b and qwen2.5-coder:14b under Ollama on one RTX 5070 Ti, both loaded at once, each shown every law's equation and symbol list. A model's answer was treated as a candidate and then checked mechanically: a symbol counts only if it is in the equation and nowhere in the explanations.

40 readings, 20 laws by 2 models.

The promise was false in one place, and the place is instructive: pi is exactly the kind of symbol a textbook treats as too obvious to mention. A small local model found it for nothing; the mechanical check is what made its answer usable, since four fifths of what survived was still wrong.

2026-09-19 · tests none yet · REFUTED

Will stopping every process whose command line contains key.py stop the old proof loop?

A PowerShell filter on Win32_Process CommandLine, run from a shell whose own command line contained the text key.py.

Ran it.

A pattern that selects by description selects the describer. The same mistake is available to any rule written in the language of the thing it governs. The old loop did stop, which is the least interesting fact about it.

2026-09-19 · tests L18 · CONFIRMED

What actually limits this work this afternoon?

Five readings of a prepaid balance between 13:40 and 13:57 London time, with two subordinate agents running for the first three minutes and stopped thereafter.

Divided money spent by minutes elapsed, then by steps taken.

L18 held on the day it was written: the physics was not what limited the work. The constraint was the cost of rereading context, so the cure was fewer and larger steps, work moved to the local machine, and stones to carry context instead of the transcript.

2026-09-19 · tests L26 · CONFIRMED

Can the dots compute anything at all, or can they only be lit? The claim under test was made the same evening: every dot can be programmed like a transistor.

A cell is one dot with a permanent key and no other property. It is dark or lit. A program gives each cell one rule, and there are only two kinds: an input cell is lit when the visitor says so; a gate cell is lit UNLESS both of the two cells it answers to were lit one tick earlier. That second rule is the gate from which every other logic gate can be made. Nothing is stored per cell: the state of a cell at a tick is worked out backwards from that tick to tick nought, when every gate cell is dark.

Wrote a half adder as a program of 8 cells (2 inputs, 6 gate cells, one kind of gate only). Ran all four input rows. The check reads the lit or dark state of the sum cell and the carry cell after they settle; it never looks at the wiring. Ran it again with the cache switched off, so nothing at all is kept between one question and the next. Then planted a fault (the carry cell rewired) and ran the same check.

A cell whose rule answers to the OUTPUT of other cells is a logic gate, and cells so wired compute. One and one make two, read off the dots. The word that was honest before this entry was 'programmable'. After it, for this apparatus, 'computes' is also honest. It is a statement about cells run by this rule. It is not a statement that any published page computes anything.

2026-09-19 · tests L26 · CONFIRMED

Does it scale by composition alone, with no new kind of cell?

The same two rules as entry 16. A four bit adder written as a program of 69 cells, 60 of them gate cells.

Set the eight input cells to every pair of numbers from 0 to 15, which is 256 pairs. For each, waited for the five output cells to settle, read them as a binary number, and compared it with ordinary addition.

Composition is enough. Nothing was added between entry 16 and this one except more cells obeying the same rule. Since every Boolean function can be built from this one gate, any finite calculation can in principle be laid out as a program of cells; what it costs is cells and ticks, and 38 billion cells is a large budget of the first.

2026-09-19 · tests L11 · CONFIRMED

Does a change travel through the cells at a finite speed, as the pulse on the screen does?

The half adder of entry 16. The carry cell is two gate cells away from the inputs.

Switched both inputs on at tick 10 and read the carry cell at every tick from 8 to 16.

Propagation delay is a property of the rule, not an effect added for show. What a cell shows at a tick is the past of the cells it answers to. This is L11 for the cells, and it is what gives the pulse a front.

2026-09-19 · tests L26 · CONFIRMED

A working view earlier the same evening was: the day a latch is wanted, one bit must be kept per dot, and 'nothing stored per dot' must be dropped. Is that so?

Two gate cells, each answering to the other, and two input cells (set and reset, where OFF means 'do it'). Same two rules as entry 16. Still nothing stored per cell.

Held reset for ticks 0 to 5. Gave a three tick set pulse at ticks 10 to 13. Left both inputs idle and read the output cell 26 ticks later. Gave a reset pulse at ticks 40 to 43 and read again. Separately: never reset it, and read it for eight ticks. Separately: counted how many questions the backwards working asks for tick 12 and for tick 24 with the cache off.

The earlier view was wrong and is corrected here. The latch remembers, and neither cell stores anything: the memory is in the HISTORY OF THE INPUTS, which is part of the program, and the state at any tick is recomputed from it. What remembering costs is time, not storage: the work grows with the tick asked for. A real page would keep a frame to save that time; that is a cache and can be thrown away and rebuilt, which a stored bit cannot. Also recorded because it is true: a latch that is never reset does not settle, it flickers. A memory must be started in a known state, in cells as in silicon.

2026-09-22 · tests Published-edge and declared-input invariants, tested here; no new physical law claimed · CONFIRMED

Can I start from a place, find nearby mapped substations, follow only published voltage-consistent connections, and test entered demand against a real published rating without turning that rating into spare capacity?

The offline grid finder in apparatus/grid_finder.py; source-hashed public data from Ventusltd/data-grid-gb at commit 5181de3423e4fe50c77c568b9f3066c61a1d9e41. The graph contains 886 candidate sites, 489 mapped locations, 2679 nodes, 1392 existing circuits and 1472 transformers. Geometry originates with OpenStreetMap contributors; network records are NESO ETYS 2025.

I queried latitude 53.3, longitude -0.8 at 132 kV. I compared every declared site-and-voltage starting condition with an independent reverse traversal from all validated 400 kV nodes. I checked 29 distance fixtures produced by the existing GridAtlas geodesy. I then entered 100 MW and 300 MW, each at power factor 0.95, against the published West Burton transformer found by the query. I also planted an illegal circuit voltage change, an unknown-voltage edge and a missing internal site connection.

The apparatus computes geographic ordering, published connectivity and entered-demand comparisons on real source records. Nearness is not connectivity, a site name is not an internal bus tie, and a published nameplate is not available connection capacity. I do not infer existing loading, power sharing, queue position or an offer. Missing coordinates remain missing and unknown node voltages are not decoded from names.