{
 "_": "THE EXPERIMENT LOG. Faraday numbered every paragraph of Experimental Researches in Electricity continuously, 1 to 3430, across thirty years and thirty series, so that any later paragraph could cite any earlier one by its number alone. He dated them, wrote them in plain first person without mathematics, and recorded the failures. This is that instrument. Numbers are never reused and never renumbered.",
 "title": "Faraday",
 "lede": "A numbered, dated log of what was actually done and what was actually observed. Failures are recorded, because an experiment that showed nothing is a result. Numbers run continuously and are never reused.",
 "method": [
  "Number continuously. An experiment keeps its number forever, so anything can cite anything by number alone.",
  "Date it. A measurement without a time is not a measurement.",
  "Say what was asked before saying what was found.",
  "Record the apparatus: the command, the machine, the version. Someone must be able to repeat it.",
  "Quote what was observed, verbatim where possible, before interpreting it.",
  "Record NO EFFECT and REFUTED as readily as CONFIRMED. Faraday's null results are half the value of his notebooks.",
  "Name the law it tests, or say that it tests none yet."
 ],
 "results": {
  "CONFIRMED": "the thing held up under the test",
  "REFUTED": "the thing was shown to be false, and something changed as a result",
  "NO EFFECT": "the test ran and found nothing. Recorded anyway, because it rules something out",
  "INCONCLUSIVE": "the test ran and did not settle the question"
 },
 "experiments": [
  {
   "n": 1,
   "date": "2026-09-19",
   "title": "The instrument printed COMPLETE over an empty frame",
   "question": "The page said it had drawn 37,796,045,093 particles. Had it?",
   "apparatus": "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.",
   "did": "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.",
   "observed": "{\"lost\":true, hud:\"showing 37,796,045,093 of 37,796,045,093 lines · COMPLETE in 34.0 s\"} and the centre pixels all zero. The canvas was black and the instrument said it had finished.",
   "shows": "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.",
   "law": "L19",
   "result": "REFUTED",
   "keys": [
    [
     "the page's own claim",
     "commit 28cfd61, Ventusltd/cosmic"
    ],
    [
     "the fix",
     "webglcontextlost is caught, stated on screen, and stops the exposure; commit cc7a807"
    ]
   ]
  },
  {
   "n": 2,
   "date": "2026-09-19",
   "title": "The timer measured how fast commands were queued, not how much was drawn",
   "question": "After the context loss was fixed, the page reported a full exposure of 37.8 billion points in 0.8 seconds. Is that possible?",
   "apparatus": "Same page and machine. Arithmetic, then a GPU fence.",
   "did": "Divided the claimed population by the claimed time.",
   "observed": "37,796,045,093 in 0.8 s is 47 billion points per second. Repeating the run gave 9.7 s, then 34.0 s, for the same work, which is not how a fixed amount of drawing behaves.",
   "shows": "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.",
   "law": "L19",
   "result": "REFUTED",
   "keys": [
    [
     "the fix",
     "gl.fenceSync and clientWaitSync pace the exposure; commit cc7a807"
    ]
   ]
  },
  {
   "n": 3,
   "date": "2026-09-19",
   "title": "More silicon was printed than the wafer contains",
   "question": "tools/wafer.py computed the printed area of a 300 mm wafer. Does the answer make physical sense?",
   "apparatus": "tools/wafer.py, first run. Inputs: 300 mm diameter, 3 mm edge exclusion, 26 by 33 mm reticle field, 0.08 mm scribe.",
   "did": "Read the output before publishing it, and compared two numbers in the same JSON object.",
   "observed": "printed_um2 83,226,000,000 against wafer_area_um2 70,685,834,706. The printed silicon exceeded the wafer by 18%.",
   "shows": "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.",
   "law": "L13",
   "result": "REFUTED",
   "keys": [
    [
     "the impossible figure",
     "tools/wafer.py first run, Ventusltd/cosmic"
    ],
    [
     "the check",
     "derived.checks.printed_le_usable in wafer.json; commit e493bfe"
    ]
   ]
  },
  {
   "n": 4,
   "date": "2026-09-19",
   "title": "A law written in the morning was broken the same day",
   "question": "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?",
   "apparatus": "Ventusltd/cosmic scan mode, 1120 by 1064 window, Chrome, WebGL2.",
   "did": "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.",
   "observed": "SCAN, shown 27,720,288 of 37,929,011,953, 40,248 per frame at 5.5 px spacing, nothing shares a pixel, 5.11 million per second, 2.1 hours remaining.",
   "shows": "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.",
   "law": "L12",
   "result": "REFUTED",
   "keys": [
    [
     "the law as first written",
     "Ventusltd/law, commit fbf1285"
    ],
    [
     "the amendment",
     "Ventusltd/law, commit f8e7b6e"
    ]
   ]
  },
  {
   "n": 5,
   "date": "2026-09-19",
   "title": "How fast this machine can actually draw",
   "question": "A good game runs on a cheap phone. Was the hardware ever the limit here?",
   "apparatus": "Ventusltd/cosmic, x-ray mode, collapsed into one repository so most of the population falls outside the viewport.",
   "did": "Read the exposure counter and the elapsed time off the instrument at depth, and separately at full field where every point is rasterised.",
   "observed": "17.43 billion of 35.56 billion drawn in 2.8 seconds with most points culled in the vertex stage, about 6.2 billion per second. Fully rasterised on screen, about 125 million per second.",
   "shows": "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.",
   "law": "L18",
   "result": "CONFIRMED",
   "keys": [
    [
     "the measurement",
     "read from the instrument's own HUD, which is fence paced and therefore reports retired work"
    ]
   ]
  },
  {
   "n": 6,
   "date": "2026-09-19",
   "title": "Two independent walks of the estate agreed to the digit",
   "question": "Does the estate's line count reproduce when measured twice by different code?",
   "apparatus": "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.",
   "did": "Ran both and compared the totals without adjusting either.",
   "observed": "37,929,011,953 lines and 15,065,506 entries from both, independently.",
   "shows": "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.",
   "law": "L14",
   "result": "CONFIRMED",
   "keys": [
    [
     "both runs",
     "belt-meta.json in Ventusltd/cosmic"
    ]
   ]
  },
  {
   "n": 7,
   "date": "2026-09-19",
   "title": "The estate grew while it was being measured",
   "question": "Is the count stable between measurements taken 36 minutes apart?",
   "apparatus": "tools/clusters.py at 11:24:27+01:00 and tools/web.py at 12:00:07+01:00.",
   "did": "Compared the repository counts from the two runs.",
   "observed": "67 repositories at 11:24 and 68 at 12:00. The difference was caused by cloning a new repository into the working directory, which is to say by the act of doing this work.",
   "shows": "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.",
   "law": "L13",
   "result": "CONFIRMED",
   "keys": [
    [
     "both runs",
     "belt-meta.json and web-meta.json"
    ]
   ]
  },
  {
   "n": 8,
   "date": "2026-09-19",
   "title": "The routing table was incomplete, so it was not used",
   "question": "estate-index.tsv lists blob identity, line count, repository, commit and path. Can the belt be built from it?",
   "apparatus": "estate-index.tsv in Ventusltd/cosmic, compared against the distinct blob count at HEAD from the earlier runner pass.",
   "did": "Counted its distinct rows before building anything on it.",
   "observed": "17,599 distinct blobs in the file against 19,304 distinct blobs at HEAD. It covers 91% of them, and the per repository totals it gives are 25,323,372 lines against a measured 25,335,587.",
   "shows": "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.",
   "law": "L14",
   "result": "NO EFFECT",
   "keys": [
    [
     "the file",
     "estate-index.tsv, Ventusltd/cosmic"
    ]
   ]
  },
  {
   "n": 9,
   "date": "2026-09-19",
   "title": "A public file named private repositories",
   "question": "belt.tsv was published to a public repository. Were all 67 of the names in it mine to publish?",
   "apparatus": "gh repo list Ventusltd --limit 200 --json name,visibility, compared against the names in belt.tsv.",
   "did": "Asked the question after publishing rather than before, which is the error.",
   "observed": "Four repositories named in the public file are PRIVATE, and two are not under the organisation at all. The commit shard headers carried the same names.",
   "shows": "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.",
   "law": "grid L6",
   "result": "REFUTED",
   "keys": [
    [
     "the redaction",
     "commit d672e69, Ventusltd/cosmic"
    ],
    [
     "still exposed",
     "commits cc7a807, 188fb5b, e493bfe"
    ]
   ]
  },
  {
   "n": 10,
   "date": "2026-09-19",
   "title": "Every drop is the ocean, timed: a Merkle walk against brute force",
   "question": "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?",
   "apparatus": "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.",
   "did": "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.",
   "observed": "\"matched_exactly\": 9869, \"differed\": 0, \"brute_force_seconds\": 565.2, \"merkle_walk_seconds\": 4.9, \"merkle_arithmetic_seconds\": 0.21, \"only_in_brute_force\": 0, \"only_in_merkle\": 0",
   "shows": "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.",
   "law": "L14",
   "result": "CONFIRMED",
   "keys": [
    [
     "the run",
     "E:/particles-runs/trees.err on the measuring machine; tools/trees.py in Ventusltd/cosmic"
    ]
   ]
  },
  {
   "n": 11,
   "date": "2026-09-19",
   "title": "Any key, chosen at random, followed to the actual line of text",
   "question": "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?",
   "apparatus": "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.",
   "did": "Drew keys uniformly from all issued lines, about two a second, and logged every one.",
   "observed": "{\"state\": \"RUNNING\", \"keys_proved\": 558, \"wafer_keys\": 37929255811} at 12:58Z, and still running. For example key 45,108,233,899 resolved to globalgrid2050 / b1c4ec082c6d / data/generation/archive/2022/elexon_generation_sources_2022-09.csv line 37939, and printed the line.",
   "shows": "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.",
   "law": "L23",
   "result": "CONFIRMED",
   "keys": [
    [
     "the log",
     "E:/particles-runs/prove-keys.log and PROVE-KEYS.json"
    ],
    [
     "published",
     "proof 1 on globalgrid2050.com, commit 99bb7965"
    ]
   ]
  },
  {
   "n": 12,
   "date": "2026-09-19",
   "title": "The first one-wafer drawing was true and dead",
   "question": "With every line placed by one law and repositories as rings, does the whole estate look like the CPU wafer it was modelled on?",
   "apparatus": "Ventusltd/kuiper-belt index.html, first version: keys issued repository by repository, a ring drawn wherever one repository or commit ended.",
   "did": "Looked at it.",
   "observed": "A flat, featureless disc. 42.5 thousand keys per pixel, the account correct, and not one ring visible: one repository holds 94% of the keys and no commit is wide enough to show at full field, so the ring rule correctly drew nothing.",
   "shows": "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.",
   "law": "L22",
   "result": "REFUTED",
   "keys": [
    [
     "the second version",
     "Ventusltd/kuiper-belt commit 0755869; tools/wafer_keys.py"
    ]
   ]
  },
  {
   "n": 13,
   "date": "2026-09-19",
   "title": "Two local models hunted the law book for unexplained symbols",
   "question": "The law book promises that every symbol is named. Is that true?",
   "apparatus": "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.",
   "did": "40 readings, 20 laws by 2 models.",
   "observed": "5 claims survived the mechanical check. 4 were noise: a multiplication sign, the word whole, the word child. 1 was real: pi, used in two laws and explained in neither.",
   "shows": "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.",
   "law": "L19",
   "result": "REFUTED",
   "keys": [
    [
     "the audit",
     "E:/particles-runs/LAW-AUDIT-LATEST.md"
    ],
    [
     "the fix",
     "Ventusltd/law commit 675717e"
    ]
   ]
  },
  {
   "n": 14,
   "date": "2026-09-19",
   "title": "A command that killed itself",
   "question": "Will stopping every process whose command line contains key.py stop the old proof loop?",
   "apparatus": "A PowerShell filter on Win32_Process CommandLine, run from a shell whose own command line contained the text key.py.",
   "did": "Ran it.",
   "observed": "Exit code 255 and no output. The filter matched the shell that was running it, and everything queued after it died with it.",
   "shows": "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.",
   "law": "none yet",
   "result": "REFUTED",
   "keys": [
    [
     "the transcript",
     "session of 2026-09-19"
    ]
   ]
  },
  {
   "n": 15,
   "date": "2026-09-19",
   "title": "The binding constraint was money, and it was measurable",
   "question": "What actually limits this work this afternoon?",
   "apparatus": "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.",
   "did": "Divided money spent by minutes elapsed, then by steps taken.",
   "observed": "1.04 pounds a minute with two agents running; 0.40 pounds a minute after they were stopped; about 0.45 pounds a step, because each step rereads the whole conversation, and nothing at all while idle. The machine under the desk, its GPU and its two local models cost nothing.",
   "shows": "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.",
   "law": "L18",
   "result": "CONFIRMED",
   "keys": [
    [
     "the readings",
     "screenshots supplied by the account holder, 13:40 to 13:58 London time"
    ]
   ]
  },
  {
   "n": 16,
   "date": "2026-09-19",
   "title": "Eight dots add one and one",
   "question": "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.",
   "apparatus": "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.",
   "did": "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.",
   "observed": "Rows as read from the cells: 0 and 0 give sum 0 carry 0; 0 and 1 give sum 1 carry 0; 1 and 0 give sum 1 carry 0; 1 and 1 give sum 0 carry 1. Identical with the cache off. The slowest row settled at tick 3. The planted fault was caught.",
   "shows": "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.",
   "law": "L26",
   "result": "CONFIRMED",
   "keys": [
    [
     "the apparatus and the command",
     "Ventusltd/faraday, apparatus/cells.mjs and apparatus/cells.test.mjs; run: node apparatus/cells.test.mjs; the numbers are in apparatus/cells.result.json"
    ]
   ]
  },
  {
   "n": 17,
   "date": "2026-09-19",
   "title": "Sixty nine dots add any two numbers up to fifteen",
   "question": "Does it scale by composition alone, with no new kind of cell?",
   "apparatus": "The same two rules as entry 16. A four bit adder written as a program of 69 cells, 60 of them gate cells.",
   "did": "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.",
   "observed": "0 of 256 wrong. Examples as read from the cells: 6 + 3 = 9 (settled at tick 9); 7 + 9 = 16 (settled at tick 15); 15 + 15 = 30 (settled at tick 5). The slowest sum settled at tick 16: the carry has to travel from the lowest bit to the highest, one cell per tick.",
   "shows": "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.",
   "law": "L26",
   "result": "CONFIRMED",
   "keys": [
    [
     "the apparatus and the command",
     "Ventusltd/faraday, apparatus/cells.mjs and apparatus/cells.test.mjs; run: node apparatus/cells.test.mjs; the numbers are in apparatus/cells.result.json"
    ]
   ]
  },
  {
   "n": 18,
   "date": "2026-09-19",
   "title": "The answer is never there before the pulse could have reached it",
   "question": "Does a change travel through the cells at a finite speed, as the pulse on the screen does?",
   "apparatus": "The half adder of entry 16. The carry cell is two gate cells away from the inputs.",
   "did": "Switched both inputs on at tick 10 and read the carry cell at every tick from 8 to 16.",
   "observed": "Carry first lit at tick 12: two ticks after the inputs, one tick per cell, never sooner.",
   "shows": "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.",
   "law": "L11",
   "result": "CONFIRMED",
   "keys": [
    [
     "the apparatus and the command",
     "Ventusltd/faraday, apparatus/cells.mjs and apparatus/cells.test.mjs; run: node apparatus/cells.test.mjs; the numbers are in apparatus/cells.result.json"
    ]
   ]
  },
  {
   "n": 19,
   "date": "2026-09-19",
   "title": "Two dots remember, with nothing stored in either",
   "question": "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?",
   "apparatus": "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.",
   "did": "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.",
   "observed": "After reset: 0. During set: 1. Twenty six ticks after the set pulse ended: 1. After the second reset: 0. Never reset: 10101010, lit and dark in turn for ever. Questions asked: 25 for tick 12, 49 for tick 24.",
   "shows": "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.",
   "law": "L26",
   "result": "CONFIRMED",
   "keys": [
    [
     "the apparatus and the command",
     "Ventusltd/faraday, apparatus/cells.mjs and apparatus/cells.test.mjs; run: node apparatus/cells.test.mjs; the numbers are in apparatus/cells.result.json"
    ],
    [
     "the earlier view, now corrected",
     "working notes of 19 Sept 2026, about 22:50 London: 'remembers only when a latch passes, and that day nothing stored per dot must be dropped'"
    ]
   ]
  },
  {
   "n": 20,
   "date": "2026-09-22",
   "title": "The published path answers; spare capacity remains unknown",
   "question": "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?",
   "apparatus": "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.",
   "did": "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.",
   "observed": "All 9 tests passed. The independent graph audit agreed on 1645 site-and-voltage queries; 974 found a published path within 12 edges. The nearest mapped 132 kV candidate was West Burton, 6.62001574277686 km away. The one-edge path WBUR11 to WBUR41 uses published transformer row 1262, rated 274 MVA. The entered demands correspond to 105.26315789473685 MVA and 315.7894736842105 MVA: the first is below that nameplate and the second exceeds it. Available headroom remains null in both results. All three planted unsupported connections were refused. The maximum distance discrepancy over 29 source fixtures was 1.1368683772161603e-13 km.",
   "shows": "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.",
   "law": "Published-edge and declared-input invariants, tested here; no new physical law claimed",
   "result": "CONFIRMED",
   "keys": [
    [
     "the apparatus",
     "<a href=\"apparatus/grid-finder-README.md\">Instructions and source attribution</a>; <a href=\"apparatus/grid_finder.py\">Python engine</a>"
    ],
    [
     "the repeatable experiment",
     "python apparatus/test_grid_finder.py; <a href=\"apparatus/grid-finder-test-results.json\">measured results</a>"
    ],
    [
     "the public source revision",
     "Ventusltd/data-grid-gb, 5181de3423e4fe50c77c568b9f3066c61a1d9e41; source file hashes travel in apparatus/grid-finder-data.json"
    ]
   ]
  }
 ]
}