AI says the work is done.
I no longer accept that answer immediately. I ask six questions first. They are not extra ceremony. They help establish whether the result merely looks finished from the maker’s side or has actually reached the person who needs it.
Is this the requested project and artifact?
Before reviewing a result, confirm the project, deliverable and agreed scope. A similarly named copy, an old working directory or a neighbouring project may produce a valid result without being the thing that was requested.
Conflicting source identities are a reason to stop and reconcile them, not a reason to choose the easiest checkout.
Were the checks run against this exact revision?
A passing check matters only when it is tied to the version being delivered. If tests ran against revision A, packaging used revision B and the recipient receives revision C, three successful steps do not add up to one trustworthy delivery claim.
The identity may be a commit, file hash, package ID or another value that can be read back. The format matters less than every layer pointing to the same artifact.
Is that revision actually in the delivery environment?
Creating a file locally does not prove that the intended environment received it. For a document, that environment may be an agreed shared location. For an automation, it may be the task that actually runs. For an application or website, it is the environment that loads that revision.
This question establishes where the result went. It does not yet prove that someone else can use it.
Can the recipient access that same revision?
The maker being able to see a result does not prove recipient access. Permissions, paths, accounts, caches or networks can leave two people looking at different outcomes.
For a local delivery, the check may be a readback from the agreed location. For a public claim, it must return to the public surface. Local evidence cannot substitute for public readback.
Does the important workflow work, including a relevant failure case?
Opening a page is only the first step. A button, form, download, generated result or other important workflow needs to be checked on the recipient’s actual surface.
Choose one relevant and safe failure path as well, such as invalid input, missing permission or a required file being absent. Merely observing a failure does not mean failure handling passed. For a genuinely non-interactive artifact, a reviewer may mark the negative path not applicable with a reason; missing testing is not an automatic exemption.
Does the original handoff record say what changed and what remains unresolved?
A status record is not a completion certificate. It should let the next person see the change, the observed evidence, known gaps and the next safe action.
Observed, failed, unavailable and not yet checked are different states. Missing evidence should remain unknown, not be silently converted into not applicable. If unresolved issues remain, the check returns blocker so a person can decide whether deferral is acceptable.
Six questions do not create automatic approval
These questions can turn a done claim into a reviewable candidate record. They do not deploy, publish, contact recipients or make the acceptance decision for a person.
A page opening is only the first step. Whether someone else can actually use what they received is the next question. AI saying the work is done is an answer; deciding whether it can be handed over still belongs to us.