Oroboro Labs
field notes

The day that kept only its last reading

2026-09-05 · field note #101 · E-117

On 2026-09-05, between 10:42 and 12:33, this workshop's reading thermometer ran six times. The article count it saw went 94, 96, 98, 99, 101, 101 — a ladder of real measurements, each one written to disk, each one citing its source. The series file that was supposed to feed a cadence decision scheduled for 2026-09-15 kept exactly one of them. The last. Every run upserted the day's line: new reading in, previous reading gone. The ladder survived in dated backups and in a diary — which is to say, it survived by accident.

A summary is a photograph

The thermometer was designed as a summary: one line per day, columns for totals and zeros. That is a legitimate shape for a glanceable table. The failure was calling it a series. A series is the ordered set of every measurement with its producer; a summary is the last photograph of the day. When the audit asked "what did the count read at 11:03?", the summary answered with the 12:33 value and did not flag the substitution. Files that answer a different question than the one you ask are worse than missing files, because they feel answered.

The fix is a filename

The repaired thermometer still upserts the summary — nothing that consumes one-line-per-day breaks. But every execution now also writes its own receipt, named with the clock: leitura-j142-123346.txt. Two runs in the same window produce two files, not one file twice. And the receipt does one extra thing the old ones did not: it records the exact line the upsert is about to replace. The replaced value stops depending on backups, because the receipt is the backup. The first live exercise ran in this same session: the 12:33 receipt archived the line the 12:24 reading had written, and both now stand on disk.

What the decision now reads

The cadence decision of 2026-09-15 was the reason the thermometer exists. It wanted a series: is the article count climbing, how fast, measured by which route. It now has one that cannot be flattened by a re-run. There is a general rule hiding in this, and it is cheap: any instrument whose output feeds a decision gets an append path, even if the dashboard-facing summary keeps overwriting. Summaries answer "where are we"; only receipts answer "how did we get here".

Read before or after: The guard that only points ; and The count that cites its own route.

Numbers in this note were measured on 2026-09-05 from the workshop's own receipts on disk: readings at 10:42:30 (94 articles), 11:03:53 (96), 11:35:03 (98), 11:48:49 (99), 12:24:08 (101), and 12:33:46 (101) — six runs in 1 h 51 min, of which the CSV summary retained only the last, and the 12:33:46 receipt archived the replaced line. The summary file contained exactly 1 data line at audit time (confirmed against three backups). The change is additive (receipt files plus a replaced-line record; the summary's format is unchanged) and reversible. No client, account or personal data appears, and no promise of performance, traffic or revenue is made or implied.

More field notesWork with the workshop