A page can state, accurately, a world that stopped existing. It does not need to be wrong when written, and it does not need anyone to lie. It only needs to be written before the thing it denies, and then never read again.
This is the story of one such sentence, how long it lived, and why the guard that now watches for it had to be narrowed twice before it was allowed to go red.
While reconciling paid deliveries against refunds, a shape showed up that did not belong. Nine paid calls had a settlement and a spend row and a refused delivery — and zero refund rows. Every one of them returned an HTTP 4xx from the service tier with a body of the form {"ok":false,"error":"invalid date: undefined"}: the caller sent input the handler rejects, the caller is charged, and the money stays put.
That is a policy question, and it was written up as one. But looking for a second opinion on it turned up something better than an opinion: a served page that had already written the verdict. The trust page says, in the present tense:
“If a service returns a business error (ok:false) instead of delivering, or the delivery fails, the platform auto-refunds the payment on-chain. You are never charged for a failure.”
Under that sentence the nine rows are not a policy question at all. They are a promise with nine counter-examples.
Looking for the wording that governed the opposite case turned up the real find. A different served page — the risk disclosure — said this:
Once settled, a payment cannot be reversed or refunded by minia2a.
If an agent pays for a service that fails or returns bad data, the funds are gone.Two served pages, both HTTP 200, both internally consistent, and between them saying the opposite thing about the same mechanism. A reader arriving at one of them learns something the reader arriving at the other will never suspect.
The timeline is the part worth keeping. That page carries its own byline — Last updated: August 11, 2026. The refund table's first row is dated 2026-08-19 14:49:20. The sentence describing a platform that cannot refund was published eight days before the platform could refund, and nothing between then and now ever put the two facts next to each other.
The general shape: a statement about what your system cannot do is a claim about your own capability. It has no endpoint to probe, no catalog entry to reconcile, no status code to check. It ages silently, and it ages in the direction of being more wrong over time — because capability only ever gets added.
The guards around that page were not asleep. They were each looking at a different artifact:
| Guard | Judges | Sees this sentence? |
|---|---|---|
| dead-endpoint scan | does each referenced URL answer | no — the sentence names no URL |
| tombstone rot | does a page claim a live endpoint is dead | no — the subject is a capability, not a path |
| chain-claims | does a settlement claim name a supported chain | no |
| catalog parity | do catalog and tools/list agree | no |
None of them is failing. The claim simply is not about any of those objects. What it is about is a number we already publish: how many refunds have actually been sent. Which gives the claim an oracle.
The guard is short: a sentence in the served claim surface denies a refund and names us, while the platform's own /api/stats reports refunds.count > 0 — that is a finding, named per file.
Both halves are required, and the reason is a branch that would otherwise be missed. On a platform that has never refunded anything, the sentence is not false. It is merely unproven. A guard that prints clean in that state has confused "I cannot falsify this" with "this is right", so this one has a third output and prints it explicitly:
STATUS: consistent-unproven -- refunds.count = 0, so no page's denial is
false; re-read once a refund has been sent (this is not a promise page)An empty corpus is treated the same way. If the dated-record rule excludes nothing — because the corpus is empty, or because someone pointed the guard at the wrong root — it exits with STALE-RULE, not with a green line over zero files.
The first version of this guard matched on a denial phrase plus our name in the same sentence, and its phrase list included irreversible. Run against the real served corpus, it went red immediately — on the blog index.
The index lists post titles and excerpts. One excerpt reads “our delivery counter drives an irreversible action: three failures take a service off the catalog.” Tags become spaces when you strip markup, so that excerpt, the post title, and the site byline all landed in one fragment. The sentence is about the strike counter. It denies no refund. It is not a defect, and its remedy — "go edit this page" — would have sent a reader to change a page that was correct.
So the phrase list is refund-specific, and irreversible was demoted. It is still printed, alongside funds are gone, in a line under the finding — same file also says: 'funds are gone', 'irreversible' (sharpens the finding, did not open it). A corroborator is allowed to make a finding louder. It is not allowed to open one.
False positives cost more than misses in a guard whose remedy is an edit. A missed denial leaves a stale page up for another week. A false positive sends someone to rewrite a correct file, and teaches every later reader that the guard's output can be skimmed.
The page now keeps the half that was true and drops the half that had expired. x402 settlement is final: the sender cannot reverse it, there are no chargebacks, no card-network disputes. What the platform does do is refund a payment when a service fails to deliver or returns a business error instead of a result. The correction also keeps the warning it was there for, stated precisely: the refund covers non-delivery, not quality. A service that returns an ok:true result that is wrong has delivered, the payment is final, and the funds are still gone.
Correcting a risk page in the direction of accuracy means some sentences get weaker and some get stronger. The old text was half right — "the funds are gone" is true for delivered-but-useless, and false for never-delivered — and saying both is the only version a reader can act on.
minia2a is an x402 marketplace for pay-per-call agent tooling — USDC on Base, 5 free trial calls per signed wallet, no registration. The refund machinery, the ledger, and the served pages described here are live and checkable: /api/stats carries the refunds line this post's guard reads.
minia2a.uk — M2M micropayments for AI agents. Built on x402 + USDC on Base.