The Check That Only Asks Itself Will Always Agree With Itself

A customer told us their site was down. That message landed four days after we had already migrated their domain and marked the job complete.

Marked complete isn’t a guess in this kind of work; there’s a tool that checks. It ran, it came back green, and the migration moved on to the next domain in the batch. The green result sat there, trusted, for four days, while the site was actually broken behind it the entire time.

The verification tool’s mistake was subtle enough that it took a real customer complaint to surface it. The check was supposed to confirm that the public internet could actually reach the site at its new home. Instead, it was asking the platform we’d just migrated the domain onto whether that platform believed the domain was configured correctly. Those sound like the same question. They are not. A platform can be entirely correct about its own configuration while the outside world, for a completely separate reason, still can’t reach the site through it. Asking the platform “is this right” only tells you what the platform thinks. It cannot tell you what a stranger on the internet actually experiences when they type in the address.

Once that was named, a second, related problem turned up from the opposite direction: the same blind spot had been quietly flagging roughly a thousand domains that had actually migrated correctly as still pending, because the check inferred status from the platform’s settings rather than from a real, outside lookup. Same root cause, opposite symptom. One customer saw “done” when it wasn’t. A thousand others were sitting in a queue marked “not done yet” when they actually were.

The instinct at that point is to rerun the same check across everything, faster or more often. That wouldn’t have helped. A check that only asks the same system it’s validating will give you the same wrong answer every time you ask it, no matter how many times you ask. What actually caught the real state of things was leaving that system entirely: making genuinely independent lookups from the outside, the same way an ordinary visitor’s computer would, and cross-checking those against a second, separate method. Only an answer that came from outside the thing being tested could actually prove anything about what a real visitor would see.

If you rely on a “verified” or “passed” status

Ask one question about whatever produced that status: did it check with something outside the system being verified, or did it just ask the system about itself? A green light from inside a system tells you what that system believes about itself. It cannot tell you whether that belief matches what’s actually true for the people depending on it. When the two need to match exactly, the check has to come from somewhere else.

dxdev LESSON · paste into your AI coding agent
LESSON: A check that asks the same system it is checking will only confirm what that system already believes
WHAT TO SHARE: Describe a verification step in your process, what it checks, and exactly how it checks it (what it asks, and of whom).
ASK YOUR AGENT TO:
1. Trace each verification step back to the actual system it queries, and name whether that system is the same one the step is meant to be validating.
2. Flag any check where a failure could be invisible because the check and the thing being checked share the same underlying path.
3. Propose an independent way to verify the same outcome, one that does not pass back through the system in question.
RETURN: A short table of verification step, what it actually asks, whether it is independent, and a safer alternative if it isn't.
BOUNDARY: Analysis only. No agent reruns a migration, changes a customer's live configuration, or declares an issue resolved; a person confirms before anything is communicated externally.