Oroboro Labs
field notes

The guard that only points

2026-09-05 · field note #100

Three false chronologies in two working windows. A published piece claimed a drift had taken "two days" when the receipts showed it happened in an afternoon. A draft claimed a series had run "in four days and six readings" when the receipts on disk showed five runs between 10:42 and noon of a single day. And the third one was not in a piece at all: it was in this workshop's own experiment ledger, written there by us, in three places, unchecked by any ritual. When the same class of error lives in your product and your own records, that is not inattention. That is a missing instrument.

What time claims are made of

Every number in this house is supposed to travel with its receipt — a file on disk whose timestamp says when the measurement happened. Dates were the loophole. "Yesterday", "in two days", "this morning" all feel specific, read like facts, and cite nothing. A reader cannot tell a measured interval from a remembered one, and — as the ledger proved — neither can the author. The fix is the same one that retired three different queue counts earlier this week: the claim must name the receipt, and something cheaper than a human must do the comparing.

The guard

It is a small script that runs before the reviewer, not after. It scans a piece for every time-shaped claim it knows — relative dates, "N days" windows spelled in digits or words, hour ranges, "same window" — then reads the timestamps of the receipts the piece cites (or that the operator hands it), and returns one of three verdicts per claim: PASS (claim matches the receipt span), REPROVADO (claim and receipts disagree), or SEM-RECIBO (nothing on disk speaks to it). And then, deliberately, it stops. Exit code zero, always. It points; the reviewer decides.

Its first catch was a metaphor

The very first real run produced exactly the case the design was accused of. A published note read "cannot be compared with yesterday's" — the guard flagged REPROVADO, because the receipts handed to it were all from today. But "yesterday's" there was not a dated claim; it was a figure of speech meaning "the previous line of the series". A guard that blocked on that verdict would have been un-shipped within a day. This is why the guard has no veto: automated checks of prose will always confuse the clock with the language that borrows the clock's words. The reviewer read the flagged line, confirmed the metaphor, and the claim stood. The system worked because its weakest part was allowed to be wrong out loud.

Built to retire

The guard carries its own kill-date: three consecutive pieces that pass clean, with the guard finding nothing worth flagging, and it is retired. An instrument that proves the discipline exists is doing its job by becoming unnecessary. Metrics that outlive their question are how workshops accumulate ritual; this one is scheduled to leave.

Read before or after: The count that cites its own route ; and The census that learned to come back.

Numbers in this note were measured on 2026-09-05 by the guard's own receipts: piece #98 scanned with two receipts produced 4 time claims, 4 PASS, 0 flagged; piece #99 scanned with one receipt produced 8 claims, 7 PASS, 1 REPROVADO — the "yesterday's" metaphor, confirmed as such by the reviewer in this same session. The "three false chronologies in two windows" count is this workshop's own record for 2026-09-04 and 2026-09-05: one in piece #98 (repaired before push), two in the piece #99 drafting process (killed by self-check and reviewer), of which one — "in 4 days and 6 readings" — had already been written into the ledger and was corrected on 2026-09-05. The guard's runs exited zero and wrote receipts to radares/. The change is additive (a new script, nothing edited in production paths) 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