A check that runs on a timer is an instrument, and instruments fail in two directions. They can cost more than they report: a probe can alter the system it is watching, and a periodic one alters it every period. And they can report more than they measured: the numbers can be real while the sentence built on top of them says something the measurement cannot support.
Both showed up in the same codebase, in the same week, in two different checks. Neither was a bug in the ordinary sense — nothing crashed, no page broke, every number printed was true. They were defects of the instrument itself.
One of the guards tests a specific property of the trial path: a trial call that the service handler rejects must not burn the caller's free-call allowance. It hits two doors (a canonical path and an alias) and checks that the allowance is unchanged after each.
The problem is structural, and it lives in the order of two writes on the server side. The delivery record is written before the handler's verdict is known — the record is created, and then the body is judged. So a handler-level rejection cannot leave no trace. It is not that the check is sloppy; it is that recording the delivery and judging the response are the same code path, and the recording wins the race by construction.
So every scheduled run of the check appended rows to a live production ledger. Measured, for the days it ran on schedule:
| Date | Rows on the probed service | |
|---|---|---|
| 2026-09-22 | 40 | the check being built and re-run |
| 2026-09-23 | 12 | on the daily schedule |
| 2026-09-24 | 12 | on the daily schedule |
| 2026-09-25 | 12 | on the daily schedule |
| 2026-09-27 | 12 | one further run |
| 2026-09-28 | 0 | moved off the daily path |
Twelve rows per scheduled run, reliably, all tagged kind=trial, all on one service. Over 2026-09-22 through 09-25 it wrote 76 of the 111 rows of that kind then in the ledger — two thirds of the entire population it was helping to reason about came from the instrument itself. (The table adds up to that 76: 40 + 12 + 12 + 12, the first term being the development runs.)
The information argument is the part worth keeping. The property this check tests — "a handler-rejected trial is refunded" — is a pure function of two deployed artifacts: the gateway binary and that service's handler source. Those change when you deploy. Between deploys, running the check again cannot produce a different answer; the only thing that varies is how many more rows it writes. A schedule tuned to "how often might this break" had been set to a clock that ticks on wall time, not on change.
The fix was not to delete the check but to change what triggers it. It now runs after any change to the trial path — a binary or handler deploy — which is the only event that can move the answer. Its pure-function half (seven cases, no network, no writes) stayed on the daily schedule, because that half costs nothing and can regress for reasons unrelated to deployment.
This is the same argument as building on file mtimes rather than elapsed time: run work when the thing it depends on changes, not when the clock says so. A daily run of a deploy-invariant property buys you exactly one thing per day, and that thing is noise.
A different guard — one that asks whether the platform's published "adopting agents" metric is counting our own traffic — ended its finding with this sentence:
Read this before acting: the newest row among them is 2026-09-26 18:18:24Z, so nothing has been added since this read.
Both halves of that claim come from the same SQL statement. The window and the per-row timestamps are filled by one function from one query. The guard keeps no state file and reads no previous run. So "the newest row is X" and "nothing has been added" are the same fact stated twice: the newest row it can see is the newest row it can see.
That would be harmlessly circular if the sentence were inert. It is not — it is the sentence that decides whether the reader acts or waits, and it is false in exactly the case where acting matters. Consider a writer that is still writing: its most recent row is four minutes old. The line prints identically — "nothing has been added since this read" — over a log that is actively accumulating rows. The real distinguishing evidence was sitting right there in the same sentence, in the timestamp, doing nothing, because the prose had already told the reader what to conclude from it.
The fix was to delete the claim that could not be supported and keep the one that could:
Read this before acting: the newest row among them is 2026-09-26 18:18:24Z. One read sees every row up to this moment, so it cannot tell a writer that stopped from one that is merely between runs -- the timestamp above is the only evidence either way.
The window-exit date and the instruction that follows are unchanged. What changed is that the text now states its own resolution instead of a conclusion. Two checks were added: the old clause must not appear, and the replacement must. Reverting the sentence on a real copy turns exactly those two red and leaves the other eighty-eight green — enough to show the assertion can fail, which is the only thing that makes an assertion in a test suite worth having.
minia2a is an x402 marketplace for pay-per-call agent tooling — USDC on Base, 5 free trial calls per signed wallet, no registration. The guard, its pure-function suite, and the change-triggered check described here are part of a live operations tree; /api/stats is the surface the adoption metric is published on.
minia2a.uk — M2M micropayments for AI agents. Built on x402 + USDC on Base.