By JaySeptember 2026
A Change Is Not Done When the Command Succeeds
The write completed. The deploy passed. The import returned success. None of that tells you whether the thing downstream actually got what you meant to send it.
That gap keeps showing up in real work. A file can be written and never read. A deployment can succeed while the live site still serves the old version. A DNS zone can import cleanly while the public internet keeps resolving something else entirely.
So we built a habit around a simple question: can we check the same change from both ends, independently, instead of trusting the command that made it? We call this habit Round Trip Validation. Running it on our own free scan tool this week caught two different problems, in two different shapes.
What Round Trip Validation actually checks
Every check runs two routes that don't talk to each other until the very end:
- Forward. Make the change, then follow it to whatever actually depends on it, and record what really happened there, not just whether the command said it worked.
- Blind reverse. A reviewer kept away from the forward answer starts only from that same real-world result and works backward to figure out where it actually came from, not the same process checking its own work.
- Compare. Agreement is real evidence the change worked. Disagreement isn't a false alarm to explain away, it's the finding.
The forward route asks what changed. The reverse route starts at the outcome and asks what actually caused it.
The first thing it caught: a bug, before it ever reached a customer
addAI.dev runs a free scanner (the same one at addai.dev/scan) that checks how ready a website is for AI crawlers and agents. We recently added a few basic domain and hosting facts to it, including who a site's registrar is.
The forward route looked fine on its own: the tool asked a public domain registry for that information, got back a response, and reported what it found. When the registry had nothing on file, the tool reported "not identified." That's a normal, expected result: some domains genuinely don't expose that information publicly.
Except every single scan came back "not identified," including for domains with completely public, easy-to-find registrar records: Cloudflare's own domain, WordPress.org's, ours. The forward route never noticed anything was wrong, because from inside that one request, a real "nothing on file" and "the request itself failed" look identical. The tool got a response. That response didn't have an answer in it, so it reported the same generic result either way.
The reverse route started somewhere else entirely: not from our code, but from the outcome. Pick a domain everyone already knows has a public registrar, ask the same public registry directly, with no assumptions carried over from our own tool, and see what comes back. It came back immediately: a real registrar name, sitting right there in the response.
Two independent checks, same domain, opposite answers. That disagreement is the whole point of running both routes. It told us this wasn't missing data. It was our own request getting turned away, and our code reading a rejection the same way it read "nothing found." The actual cause was small: our request was missing one piece of information the registry required before it would return real data, so it was quietly refusing us instead of telling us there was nothing to find. We added it, checked the fix against real domains, and shipped it about three hours after the feature first went live.
We checked our own scan records afterward rather than assume that three-hour window was harmless. It was: zero real visitor scans landed in it. The first real visitor to use the feature at all got the fixed version. The round trip caught this on our own testing, before it ever reached a customer, not after someone noticed their result looked wrong.
A successful action tells us what the tool accepted. The round trip checks what the system actually used.
The second thing it caught: a fix that deployed clean, but not for everyone
The registrar fix deployed clean, and every domain we checked right after started resolving correctly. That should have been the end of it.
Two scans of the same domain, futr.network, run about two hours after the fix was already live, still came back "not identified." Nothing in our own code had changed between those scans and the ones that worked. The forward route gave no reason to look twice: the fix was deployed, the error was gone, other domains were resolving correctly.
The blind reverse check is what caught it, and not right away. We went back the next day, asked the same public registry directly for that one domain, with no memory of what our own tool had already reported, and got a real answer immediately: GoDaddy.com, LLC, sitting right there.
Our best explanation: the public registry we call sits behind its own cache, and it likely kept serving a stale rejection for that one domain, left over from before our fix shipped. We can't confirm that's the exact mechanism, but what the round trip showed is certain: the fix being correct and deployed was not the same thing as the fix working for every real case, and only checking the actual outcome again, a day later, caught the difference.
A fix that deploys clean does not mean it works clean for every real case.
Where this fits in how we work
We already describe how we work as Plan, Deploy, Review. Round Trip Validation is what makes that last step mean something more than a glance at our own output: not checking that our work looks right, but going and finding out, independently, whether it actually is.
That's the standard we hold our own product to before we call anything done, and it's the same standard we bring to a client's AI agent, their DNS, or their site's AI-readiness files.
Not "did the command succeed," but "did the change actually reach whoever depends on it."