Chapter 6 · Living chapter

Chapter 6 — The Verification Pipeline: How This Book Checks Its Own Claims

Book 1: Geometric Power Topologies for FPGAs — the machinery behind the evidence.

This book has made you a promise in every chapter so far: no claim without evidence, no evidence without reproduction, and no correction hidden. This chapter is the receipt. It documents the pipeline that turns a netlist into a published, panel-backed claim — and it proves the pipeline works using the one thing skeptics respect: the pipeline's own public failure, caught and fixed.

6.1 Two roads, and no silent merge

Every number on this site travels one of two roads:

The evidence road: netlist → simulation run → trace extraction → verification → publication. The reader road: run → explore → compare → stop.

The roads never merge silently. A reader's live run in a panel is exploration, tagged READER_EXPERIMENT, grey on every chart, stored only in the reader's browser. It cannot become evidence by any automatic path — not a button, not a heuristic, not time. If a reader's experiment deserves a place in the book, it walks the evidence road from the start: a fresh run in the verification pipeline, a new manifest, new hashes, a new version. There is no promotion without re-verification, because a chain of custody that can be upgraded in a browser click is not a chain of custody.

6.2 Step by step

1. Netlist creation. Every simulation begins as a text netlist — versioned, and from that point forward byte-frozen. The SHA-256 hash of the exact bytes is recorded before anything is run. Readers download those same bytes; hashing the download must reproduce the number on the page.

2. Simulation run. The solver regime is frozen before the run and documented with the evidence: the analysis directive (.TRAN 1n 900n for the Chapter 3 transients; .AC DEC 50 100k 1G for the Chapter 4 divider sweep), the simulator version (ngspice-39 for the evidence runs), the default tolerances, and a hard timeout. Freezing the regime is what makes "reproducible" a checkable statement instead of a hope.

3. Trace extraction. The run's output becomes the trace artifact — the printed table or raw file, converted to the data the panels display. The trace is hashed alongside the netlist. From here on, the pair (netlist hash, trace hash) identifies the evidence the way a fingerprint identifies a person.

4. Verification. This is where most publishers stop and this book starts. A fresh run is executed against the same netlist and compared point-by-point to the published trace. The metrics that appear in prose — a droop value, a ring frequency, a return-current share — are recomputed from the raw data and cross-checked against hand-math where physics provides a closed form. The verification record states who verified, when, and what matched. Bit-exact is the goal; where print rounding intervenes, the tolerance and its reason are stated rather than waved off.

5. Publication. The evidence ships as a bundle — netlists, results, hashes, solver metadata, a reproduction script — and the panel renders its chain-of-custody block from that bundle's real values. The panel's provenance footer states the panel version, the pattern version, and the last update, so drift is visible instead of silent.

6. Correction. When verification fails — and it has — the erratum is published on the same page as the claim it corrects, with the reason, the re-run that exposed it, and the corrected numbers. The correction ledger and the Reader Trust Index update with it. A publisher's credibility is not the absence of errors; it is the visible, low-latency handling of them.

6.3 The pipeline's proof of function: a real failure

On 2026-10-02, during the build of this book's first interactive panel, the pipeline caught an error that had already been published. The original results file for Chapter 3 carried a metric labeled v_midstep_460n — the rail voltage 460 ns into the load step. A fresh reproducibility re-run of all three Case netlists matched the original simulations bit-for-bit: every v_min, every end-of-window value, identical to six decimal places. But the re-run's true 460 ns values did not match the published column. The published "460 ns" figures (−410, −355, −16 mV) were actually the end-of-window (900 ns) values, mislabeled by an indexing error in the original extraction script.

What happened next is the pipeline working, not the pipeline failing:

• The chapter's figures were corrected to the true 460 ns values (−439, −417, −50 mV).
• An erratum was published on the chapter page, visible, explaining exactly what was wrong and how it was found.
• The results file was re-versioned (pdn_model_v2) with honest field names — v_at_460n and v_end_900n — and the superseded file kept in the bundle for the record.
• The correction ledger and the trust index recorded one erratum, dated — the Reader Trust Index moved from zero errata to one, and that number is on every page of the site.
• The shipped bundle (spice-models-v2.zip) was re-issued with the corrected results and a REPRODUCE.txt script, so a reader re-running the netlists today gets exactly the corrected self-check values.

The chapter's conclusions never moved — the ordering of Cases A, B, C and the physics of the 74 MHz ring were unchanged — but a book that cannot distinguish "the rail at 460 ns" from "the rail at the end of the window" is not measuring; it is decorating. The error was small, the fix was public, and every artifact a reader downloads today is self-consistent. That is the standard.

6.4 What verification cannot do

Honesty about the pipeline's limits is part of the pipeline. Verification proves that a simulation is reproducible — that the netlist, regime, and trace agree with each other and with hand-math. It does not prove the model matches physical copper. Chapter 3's lumped RLC network is verified as a simulation and explicitly labeled as trustworthy only to a few hundred MHz. Chapter 5's hypotheses are verified as falsifiable, not as true. The only machine that can settle whether the geometry matters on real boards is the measurement campaign — controls, same-lot boards, acceptance criteria — and until those measurements exist, the book's status boxes say so in plain text.

This is the division of labor: simulation narrows the search and earns its claims exactly as far as its models reach; measurement settles what simulation cannot; and the verification pipeline guarantees that neither ever claims more than it earned.

6.5 The reader's part

Every panel is also an invitation to break the book's claims. Download the bundle. Hash the netlist and compare it to the chain-of-custody block. Re-run the netlist in free ngspice with the shipped REPRODUCE.txt script and check the self-check values. If your numbers differ beyond print precision, the contact page is the erratum pipeline's front door — and a confirmed discrepancy becomes a published correction with your contribution acknowledged. The readers most likely to catch the next error are the ones running the simulations, which is precisely why the simulations are downloadable.

A book that can be checked is a book that can be trusted. This one asks to be checked.

Chapter 6 — draft of 2026-10-02. The pipeline described is the one actually used for this book's evidence: netlists and traces are hash-identified in the published bundles (spice-models-v2.zip, divider-sweep-v1.zip), the evidence runs used ngspice-39, and the Chapter 3 erratum of 2026-10-02 (mis-indexed 460 ns metric, corrected to pdn_model_v2) is the worked example of Step 6 in operation. Reader runs are local-only by design and are never promoted to evidence without a verified pipeline re-run.