You ask:

Is this ready?

And the answer comes back:

Yes. All tests pass. The implementation is safe and ready for production.

That sounds useful.

But there is a subtle problem:

What was actually observed, and what was inferred beyond the evidence?

Those are not the same thing.

A simple example

Suppose an agent modifies a feature and reports:

All 42 tests pass. The implementation is safe.

The first sentence may be directly supported by evidence.

The second may not be.

A more precise review might look like this:

Observed
- 42 configured tests passed.

Supported
- The tested paths behaved as expected under those test conditions.

Not established
- All runtime paths are safe.
- Unknown inputs cannot violate the boundary.
- Production deployment is safe.

Nothing here says the implementation is bad.

The issue is the scope of the claim.

The evidence may be correct while the conclusion is broader than what the evidence actually establishes.

Why this matters more with AI agents

Human developers do this too.

AI systems can compress many observations into a short conclusion before a person has inspected the full chain of evidence.

A coding agent may inspect files, run tests, modify code, read logs, and then compress everything into:

Done.

That compression is convenient.

It can also hide an important distinction:

“I observed enough to support this limited claim”

versus

“The system is generally safe/correct/complete.”

When agents are given more autonomy, this distinction becomes especially important.

A useful question before accepting a claim

When an AI system says something is:

• done

• safe

• correct

• verified

• production-ready

• fully implemented

• compliant

• fixed

ask:

What evidence would have to exist for that exact claim to be true?

Then compare that requirement with what was actually observed.

A tiny review can help separate the result into three layers:

1. Observed

What happened directly?

Tests passed.
A request returned 200.
A file changed.
A provider call count was zero.
A particular runtime path was exercised.

2. Supported

What conclusion is reasonably supported by those observations?

The tested behavior worked.
The inspected path did not call the provider.
The specific regression appears fixed.

3. Not established

What still exceeds the available evidence?

All possible inputs are safe.
Every runtime path behaves identically.
The system is production-ready.
The implementation satisfies every external requirement.

That last category is important.

“Not established” does not mean false.

It means the available evidence does not yet justify claiming it as true.

This is really a boundary problem

I started thinking about this while building AI-assisted systems.

The difficult part was often not getting the AI to do something.

It was determining exactly what had been established after it did it.

The system might correctly observe several facts and still produce a conclusion whose scope was too large.

So I started reviewing claims as boundaries:

Evidence
   ↓
Observed fact
   ↓
Supported claim
   ↓
Boundary
   ↓
What remains unproven

The goal is not to make AI less useful or force every task into formal verification.

It is simply to avoid silently converting:

“This worked here.”

into:

“This works everywhere.”

A small checklist

I turned this into a small free checklist for reviewing AI-generated technical claims.

It is meant for moments when an AI, agent, or development workflow says something has been verified, completed, fixed, or proven.

Before accepting the claim, the checklist asks you to look at things like:

• What was directly observed?

• What evidence supports the claim?

• Does the claim extend beyond that evidence?

• Which conditions were actually tested?

• What remains explicitly unproven?

It is deliberately small.

The point is not to create another governance framework.

The point is to make one distinction easier:

What do we know — and what are we only saying?

You can get the free Claim Scope Review Checklist here:

https://worldreader6.gumroad.com/l/mkebln

If you work with coding agents or AI-assisted development, I’m especially interested in one question:

When your AI says “done,” what do you currently use to decide whether that claim is actually justified?

The first was a version label. I'd finished a fix on a small file; the earlier review had touched everything it noticed. Preparing to share the file, a different eye caught a footer line still on the old number. That eye had checked one more thing — a place the earlier review had not been positioned to see. It wasn't only about who was declaring; it was also about which observation was actually available to establish whether the fix held.

The second was one online post. A programmatic check said the post was up. My own logged-in view said the platform's filter had removed it. Someone else's browser, from a fresh session, said the same. The post itself didn't change while we watched. The observer did. The answer I got depended on where I was standing when I asked.

The third was a small hand-over between two systems I'd built for myself. One of them had added a rule: don't hand this over yet, the evidence isn't enough. The problem was that "enough" was the other system's authority to decide. The first system had quietly begun arbitrating a question that wasn't its to answer. It was still doing useful work; it just wasn't in the position it thought it was.

The three don't feel identical. One is about an additional observation that hadn't happened. One is about the same object showing different faces depending on surface. One is about who is entitled to decide. But something rhymes. In each case, a claim was made — a fix is complete, a post is up, a hand-over is ready. In each case, whether the claim actually held depended on something more than the declaration: an observation, a surface, an authority. That other thing wasn't the same across the three. But its role was similar. It was what the claim's standing hung on for the purpose at issue.

There's a small notation habit that helps me notice this a little earlier. When I write a fact down, I try to tag it: declared by whom, observed by whom, inferred by whom. It doesn't solve the problem. It doesn't guarantee I've named the recognition position that will actually matter later. What it does — sometimes — is make the pause self-announce at write time rather than at hand-over time. When I write "the fix is complete" without any tag, I'm collapsing declarer, observer, and authority into one line, and treating the collapse as a settled thing. If I have to type "declared complete by me" when I only had one eye on it, the sentence starts asking its own follow-up — observed by whom, admitted by whom — and the answer might be "not yet." Which is often what I needed to know. What I don't know is whether this actually reduces the gap or just relocates it. The tag says "declared by me" — but who observes it, and by whose authority is it admitted for the purpose at issue? Those slots become the next thing to fill, or the next thing to leave honestly open. Whether that's progress or a relocation of the same shape one layer up, I don't yet know. I'm going to keep writing the tags for a while and see what the next few weeks show.