The demo is not the delivery.

A demo is a very persuasive liar.

It shows the path someone prepared, with the data they expected, in the environment they remembered to configure. Then everyone says “looks good” and a small piece of unearned confidence gets promoted to production.

The problem is not the demo. The problem is asking it to prove something it never tested.

Five claims hiding inside “done”

Software delivery gets easier to reason about when the evidence stays attached to the claim:

1. The change works. A focused check exercises the behavior that changed, including a meaningful failure case.
2. The application still works. The broader checks pass on the actual candidate, not an earlier revision.
3. The result is acceptable. Someone reviews the behavior, copy and experience against what was requested.
4. The change is deployed. The intended version reaches the intended environment.
5. The live behavior works. A production check confirms the important journey after deployment.

These are related. They are not interchangeable.

A merged pull request proves that source entered a branch. It does not prove that the build succeeded, the domain points to it, or the configuration is correct. Those are separate observations. Apparently software refuses to run on optimism.

Test the claim, not the screenshot

Consider a marketing site with draft articles. The Writing page looks excellent. The draft is absent from the list. Ship it?

Not yet. The article might still have a generated URL. It might be sitting in the sitemap. It might appear in a homepage teaser. Hiding a link is not the same thing as excluding content from a build.

A useful check asks whether the draft is present in any public output:

import assert from 'node:assert/strict';
import { existsSync, readFileSync } from 'node:fs';

assert.equal(existsSync('dist/writing/internal-draft/index.html'), false);
assert.equal(
  readFileSync('dist/sitemap.xml', 'utf8').includes('internal-draft'),
  false,
);

This example is deliberately small. A real check should cover every surface that consumes the publication state. The point is to test the property being claimed: unpublished content does not become public.

The screenshot is still valuable. It tells you whether the reading experience is good. It just cannot answer the other question.

Give agents a receipt, not a victory speech

The same distinction matters when an agent does the work. “Implemented and tested” is a summary. Useful evidence is more specific:

• Which revision was tested?
• Which command or journey passed?
• What was deliberately left unverified?
• What needs a person’s decision?

A concise handoff can be enough:

Candidate built. Draft exclusion and core links checked. Local preview is ready. Article approval and production deployment remain outstanding.

That is less exciting than “all done.” It is also considerably less expensive to misunderstand.

Keep the checks proportional

This is not an argument for turning a three-page website into a space programme. A static site needs different evidence from a payment system. Use the smallest checks that can catch the failures you actually care about.

The distinction between implementation, review and deployment can fit in a short checklist. What matters is that crossing out one line does not magically cross out the others.

The demo earns attention. The evidence earns “done.”