Discipline
/verify"Done" is a claim. Prove it.
Completion needs a referent
Done is a claim about a specific boundary
An AI agent can edit the expected function and explain why the change should work without executing it. The reasoning may be useful, but it is not evidence that the code compiles, the behaviour changed or a user can reach the result. "Done" is a claim, and every claim needs a clear boundary.
"The file parses," "the bug is fixed," "the service is deployed" and "customers can complete the task" are different claims. A green command can support one while saying little about the others. Verification begins by naming what is being asserted, then choosing evidence that can actually challenge it.
Match evidence to the completion claim
A confident sentence is not proof. The required evidence grows with the scope of done.
Claim
- The focused bug is fixed Needs the original failing case and adjacent boundary.
- The feature is complete Needs integration and realistic user-path evidence.
- The release is safe Needs production controls, monitoring and owned residual risk.
scope the proof
Evidence
- Focused test Shows the observed failure now behaves correctly.
- Wider suite and diff Checks adjacent behaviour and unintended change.
- Live boundary check Confirms the deployed system, permissions and data path.
Name what remains unverified instead of stretching narrow evidence into a broad claim.
Match evidence to the claim
Climb only as high as the claim requires
Use an evidence ladder. A syntax or type claim needs the parser, compiler or type checker. A behaviour claim needs a focused test that would fail without the change. An integration claim needs the real boundary, or the closest controlled substitute, such as a test database or provider sandbox. A deployment claim needs the intended version on the live environment plus a health or browser check. A business claim needs observed user or operating evidence, not merely working software.
Relevance matters more than the colour of the output. A green unit test cannot verify DNS, credentials or a production database. A successful HTTP response cannot prove the page is usable. A screenshot cannot prove the underlying record was saved. Evidence should be current, tied to the version and environment under discussion, and strong enough that a wrong claim had a reasonable chance of failing.
A worked evidence chain
From code change to a real captured enquiry
Suppose the claim is: "The website enquiry form now captures a valid message and prevents an empty one." First reproduce the empty-message bug, then write a focused test for rejection and a valid-message test for the saved record. That connects the fix to the original failure, the discipline behind finding the bug first and writing a behavioural test before the change. Run both tests and the build. This supports the code-level claim.
Next exercise the integration against the approved test datastore and notification provider. Confirm one record is created and one notification is issued. Deploy the identified revision, open the live form in a browser, submit a labelled test enquiry and verify the live record and notification. Then submit an empty message and confirm the form rejects it without creating a record or sending a notification. Now both halves of “deployed and reachable” have evidence at the user boundary.
The ladder stops there for the technical claim. It does not prove the form will generate qualified enquiries, improve conversion or justify its cost. Those are business claims. They require an agreed observation window and measures such as valid enquiries received, completion rate and follow-up outcome. Working software is necessary evidence for that question, not the answer.
This is one purpose of a verification harness: record the claim, run the relevant check, preserve the result and prevent a workflow from silently promoting code evidence into deployment or business evidence.
The honest uncertainty branch
Report the boundary you could not cross
Sometimes the ladder cannot be completed. Production credentials may be unavailable, a third-party sandbox may be down or the business observation window may not have elapsed. The correct branch is not failure theatre or a confident completion statement. Report three things: the strongest claim the current evidence supports, the boundary that remains unverified and the exact next check with its owner.
For the enquiry example: "Focused tests and the build pass on revision abc123. I could not deploy because production access is unavailable. The release owner must deploy that revision, submit a labelled live enquiry and confirm the record and notification before calling it live." If the live check is intermittent, say that too and investigate rather than selecting the one green run.
Evidence has limits even when every check passes. Tests can encode the wrong requirement, monitoring can miss rare failures and a business metric can move for unrelated reasons. The professional habit is calibrated language: verified here, unverified there, uncertain beyond this point. Completion is still a claim. Good work makes the claim small enough to test and the remaining uncertainty visible enough to own.