Writing up an evidence-producing system when the evidence is not there
The only data available locally was a seed fixture of 5 devices and 1 audit with zero pallets, lots, products or activity, so the paper states outright that this supports no analysis, labels every synthetic chart at source, and lists each analysis deliberately not performed with what performing it would require.
Status
Shipped, 27 September 2026.. 42 pages, 26 figures, verified clean.
Supersedes the demonstration role of 2026-09-25-whole-system-paper.md, which
stands as the architecture-and-findings account. This is the demonstrable one.
The problem
The operator's brief: the paper was too high-level, described the implementation rather than demonstrating how the system works, and contained no visual evidence. He asked for screenshots, workflow and architecture diagrams, the two data methods documented separately, an honest assessment of whether the dataset supports analysis, and charts only where the evidence carries them.
The governing instruction was to investigate the system and data first, not to expand the existing text.
Why it matters
A paper about an evidence-producing system that offers no evidence of itself is the defect this project keeps finding, one level up. The previous draft asserted that the system worked; it never showed it.
What was built
The system, running locally. Postgres in Docker, 62 migrations, seed, API on
3001 against the local database, web app on 3000 pointed at it, and the kiosk
preview on 8765. The web app's .env.local points at production; it was
overridden to localhost and the absence of production traffic verified by
network inspection before any screenshot was taken.
Three new tools, all reproducible, all standard library:
| Tool | What it does |
|---|---|
capture-screens.py | Drives Chrome over the DevTools Protocol to screenshot the signed-in app. Minimal WebSocket client written by hand — no Playwright, no Puppeteer, no repo dependency change. Refuses any host that is not localhost. |
make-demo-data.py | Deterministic synthetic dataset. Refuses to load over anything larger than a seed fixture. |
make-charts.py | Charts via Pillow, each stamped REAL or DEMO on its face. |
md-to-pdf.py gained figures with numbered captions, and code blocks that fit
the page height as well as width.
The paper: eleven sections to the operator's structure. 17 screenshots, 3 diagrams (architecture, data flow, full audit process), 9 charts.
The finding that shaped section 7
The only data available locally was the seed fixture: 5 devices, 1 audit, and zero pallets, lots, products or activity. No export existed anywhere on the machine, and the production database is on a private network — unreachable, and not something to connect a paper to.
That supports no analysis and cannot demonstrate half the system. §7.1 says so outright, and §7.7 lists every analysis deliberately not performed with what would be required to perform it.
The operator chose a labelled synthetic dataset. Findings are therefore drawn only from the three real bodies of evidence — the schema, the repository history, and the 32-row defect catalogue — and every chart from the demonstration database carries an amber SOURCE line.
What was deliberately NOT built
No manufactured analysis. Grade distributions, sales figures and engine failure rates are shown as system output, never as findings. §7.7 is the list of what was refused.
No new dependency. Playwright would have been easier than hand-writing a WebSocket client; matplotlib easier than drawing bars in Pillow. Both were rejected: this repo's own kiosk work established that a dependency you have to install is one you do not have.
Pre-existing untracked files were not committed. Four files in tools/
(s.c, autorun.txt, autostart.mode, a PDF) were staged by a broad git add
and unstaged again. They are not this work.
The figures are gitignored — 7.9MB of regenerable PNGs. The PDF is tracked.
How it was proved
verify-pdf.py: 66 headings present and monotonic, 399 table cells present, 136
code lines present, 0 characters lost, 0 margin overflow, 23 images embedded.
VERDICT: clean.
Every schema figure in the paper was read from the live database, not recalled: 47 audit variables, 17 pallet-line variables, 25 tables, 317 columns, 0 duplicate tags, 82 of 345 devices awaiting audit, 175 of 176 certificates carrying a predecessor hash.
Open questions
- A real export would change sections 7 and 8 entirely. If production data can be exported with customer identifiers removed, the analysis becomes operational rather than demonstrative. This is the single biggest available improvement.
- The demo dataset's proportions were chosen, not observed. They were picked to look like a plausible intake. Nothing should ever be inferred from them, and §7.7 says so.
- Whether the two papers should merge. There are now two: the whole-system account (25 Sept) and this demonstrable one. They overlap in the findings and differ in purpose; the operator may want one document.
- Per-device timings are not captured, so throughput remains unmeasurable. The schema could already hold them.
A published copy. Commit references and internal identifiers have been removed and the operator is not named; the engineering, the counts and the stated limits are unchanged.