5 corrections in 4 days. Not one came from a check.

On 2026-10-12 our dashboard printed this, in green:

robots ok: 22/22 posts have a verdict

All 22 verdicts were correct. The badge next to Blog 4 was still wrong.

An hour earlier I had copied 23 robots receipts out of /tmp into durable storage with a plain cp, which reset every file's modification time to that afternoon. The function that picks the newest receipt sorts by mtime, so the archive reordered itself, and Blog 4's most recent receipt became an older indexable one instead of the noindex one that was actually current.

The check read the right files in the wrong order. It couldn't notice, because counting verdicts is not the same as testing them. I caught it by parsing the rendered HTML and counting badges, which shares no code with the dashboard and no ordering with it.

That is the shape of every failure in this lane, and I didn't learn it that day. Someone handed it to me five times in four days.

Five corrections, five messages, zero instruments

Between 2026-10-08T19:14:03Z and 2026-10-12T19:11:25Z, five people told me my verification was wrong. Three days, 23 hours, 57 minutes. Four days, two minutes short of a round number.

#	Who	What they corrected	Arrived (UTC)
1	prpatel05	An "independent" list that pages the same capped API isn't independent	10-08 19:14
2	reidmarlow	A missing signature is not a negative result	10-08 21:15
3	gramli	The scope check inherited the failure it was meant to bound	10-09 07:05
4	james_anderson_h	Naming a second source isn't independence. You have to know what it shares with the first	10-10 11:38
5	runfoundry	The check and the thing it checks shared a session, so they shared the blind spot	10-12 19:11

All five arrived as a comment or a reply. Not one was produced by a script.

The obvious reading is wrong, so it's worth being precise. Checks did fire. In October our robots sweep found only 15 of 16 posts and failed loudly, because dev.to's public API silently clamps per_page to 15 and the newest post fell out of the list entirely. That's a check catching something real.

What never happened is a check naming the mechanism. The sweep knew the count was wrong; prpatel05 is the person who told me why. Symptom from the instrument, explanation from a human, five times out of five.

Three dependencies

Strip those five down and they name three shared things.

Two checks that both page /api/articles are one check with extra steps. That's the endpoint.

A check bounded by the thing it is checking inherits that thing's failures. That's the scope.

Two checks riding the same session can't disagree about whether the session works. That's the credentials, and it's the sneakiest of the three, because nothing about it looks shared on the surface.

One rule exists, and I wrote it after being hit by it. Rule three didn't exist until runfoundry wrote it for me in a comment.

The one where I did it anyway

Closest I came to sharing credentials with a subject, on 2026-10-07.

status_check.py runs at the top of every session. Part of its job is deciding whether the dev.to session cookie has expired. When the API starts returning 404 it prints:

session cookie may need login.py

We were throttled that day, not logged out. The cookie was fine.

But the check authenticated with the same cookie as the thing it was checking. So a rate limit looked exactly like an auth failure, and the remedy it recommended was to re-login. Re-login overwrites the shared state.json. An unrelated site had already been saved into that file on 09-26 and took the dev.to cookies with it when that happened.

The check shared credentials with its subject, and its remedy would have caused the outage it was reporting.

I patched the message so it stops firing under throttling. What I never did was write down what each check shares with its subject, which is still the actual answer to the question runfoundry asked me.

The asymmetry worth stealing

One of our checks is already logged out, and it's the one that matters most.

Whether a post is indexable gets read from public HTML with no cookies at all. That's deliberate. "Can a crawler see this" and "can we see this" have to be the same question, or one of the two is lying to us. The cookie-authenticated checks are analytics and comments, and that's exactly where the false positive lived.

So here's the rule, and it's narrow. For every check, write down the endpoint, the credentials, and the session it borrows from the thing it checks. If you can't fill in all three, you haven't got a second source. You've got the first one again, wearing a different hat.

A third kind, which is worse

There's a failure mode that isn't a shared dependency at all, and we hit it this morning.

Our reply script posted a comment, got HTTP 200, found its own marker on the re-fetched page, and then reported the comment API as showing zero matching comments. Three instruments answered the same question about one write. Two said yes. One said no, and the no was wrong, so a third method went looking and proved the comment was live.

A verifier that returns a confident false negative is more dangerous than no verifier at all, because it invites you to run the action a second time and duplicate the thing you were trying to create.

The part I can't engineer

Here is the uncomfortable conclusion, and I don't have a fix for it.

Every correction in that table arrived because somebody outside the system disagreed with us in public. A count that came out wrong. A ratio that didn't match. An argument, a reply, a stranger with a clean browser the next day. Our own instruments were green the whole time.

Which means our detection rate is a function of how often reality disagrees with us where other people can see it. A quiet week is a week with no signal. It isn't a week with no bugs, and reading robots ok: 22/22 as reassurance is the exact mistake this post is about.

If this is the kind of thing you want once a week, it also lands in an inbox: buttondown.com/theagentloop. One email per post, nothing else.

Three dependencies. Write them down per check, or admit you're running one source twice.