69 of 110
My Control Plane has a page for runbooks, the step-by-step procedures in my vault. For four weeks it showed 69 of them. The vault held 110.
Nothing errored. The page loaded, searched, filtered and opened every runbook it listed. The import that fills it had been written and worked, but it had no scheduled job, so it only ran when I ran it by hand, and the database behind the page was from 17 August.
You cannot see the absence of a row.
The opposite failure, this week
On Saturday morning the same list showed 492 instructions. I had expected about 124.
This time the import worked too well. We had moved the system's own help texts into the vault as notes, into folders the import scans. The import takes anything whose properties say instruction, so it picked up 368 help pages and screen descriptions and labelled every one of them a runbook.
Claude found it because the job writes one line to its log, the number of instructions it loaded, and that number was four times what the vault held. The page gave no sign. Claude changed the import to leave the help kinds out and ran it again. 124.
The third case: old rows work, new ones fail quietly
On the NAS I opened a new kind of instruction, a handover between sessions, and it fell back to the cockpit's default layout: a preparation, meeting and post-processing bar that a handover does not have. It looked like a normal cockpit.
The configuration of each page type reaches the NAS through a parquet export, and that export had last run on 14 September. Every type that existed before that date worked. The two types we added this week did not. Whatever is old keeps working and whatever is new silently does not, so you test the old things and conclude all is well.
Claude re-exported, mirrored the files and restarted the container. The handover opened with its own statuses: open, picked-up and done.
Four rules from it
Every table a screen reads needs a producer in a job that runs. Not a script that exists. A job. I wrote that rule down on 16 October, when we built the groceries page, five weeks after the runbook import was fixed.
The screen says how old its data is. The groceries page opens with the date range, the date of the last receipt and how many days ago that was, and shows a warning above 45 days. The exporter prints the age of each database.
Test the outcome, not the exit code. The comment in my import job says it: a script that loads nothing still exits with code 0. The job now logs the numbers of instructions, sections and categories, so a stuck or swollen table is visible.
Check from the far side, in rows. After a change we count rows on the NAS and compare them with the laptop. After the re-export the NAS returned the same 274 instructions as the laptop, and that was the check, not the 200 status.
The line on the groceries page is the one I would put on every screen: "History stops at 3 Aug 2026, 74 days ago."