From Prompt to Proof, Part 2
The Work Is Not Done Because AI Says It Is
When an AI system says the work is done, I treat that as a status report. It is not the conclusion.
Done can mean the system generated a file. A command finished. A draft exists. Another application accepted a request. The agent reached the end of its available steps.
Those are useful status updates. They do not tell me whether the outcome I intended is true.
That distinction matters because AI can make unfinished work look finished. The response is polished. The checklist is green. The explanation sounds certain. Speed and confidence can close the conversation before anyone inspects the evidence.
I separate two questions:
- What did the system produce?
- What proves the assignment was completed correctly?
The first question is about output. The second is about acceptance.
For consequential work, I care much more about the second.
A merge that did not finish the work
The content package behind this series gave me a clean example.
A pull request was merged. If I had asked only whether the pull request was merged, the answer would have been yes.
The intended outcome was to place the package on the repository's current main branch.
That was not what happened.
The package landed on an obsolete feature branch. The merge status was accurate. The desired integration was false.
The repair required more than another confident completion message. The package had to be replayed onto current main without overwriting 216 intervening commits. The corrected pull request then exposed two failing security checks. Both failures were false positives, but that did not make them safe to ignore. Each needed a narrow repair and a clean rerun.
The repository prerequisite became complete only after:
- the correct base branch was verified;
- the 18-file package was preserved;
- intervening main-branch work remained intact;
- the two security false positives were repaired;
- the repair merged;
- both CI workflows completed successfully.
That specific case reached M3: the correction was completed with human review and terminal CI evidence.
The broader Prompt-to-Proof doctrine is still M1. I have not formally adopted or measured it as a company-wide policy.
That distinction is part of the standard.
Define completion before the work begins
Most false completion starts with a vague assignment.
We ask AI to research an issue, fix a problem, update a record, prepare a decision, or build a tool. We describe what we want produced, but we do not describe what a responsible person must inspect before accepting the work.
That leaves the system to infer what done means.
The better question is simple:
I will accept this work as complete only when...
Finish that sentence before the assignment begins.
For research, the answer may require every consequential claim to be supported by a current primary source, with conflicts or uncertainty identified.
For software, it may require the requested change to appear in the correct diff, the relevant tests to pass, and the deployed state to be confirmed separately.
For an operating workflow, it may require the authoritative record to show the correct status, material totals to reconcile, and every unresolved item to have an owner or escalation path.
The criteria should match the risk. A low-stakes outline may need a quick review. Work touching money, private information, employment, legal rights, client communication, housing, or a live system requires stronger evidence and clearer human authority.
The goal is not bureaucracy. It is to stop using the same casual definition of completion for work with different consequences.
Output and evidence are different
Output is what the system creates or reports.
Evidence is what allows a person to decide whether the intended result is real.
A citation supports a factual claim only when the source is current, authoritative, and actually supports that claim.
A test log supports defined software behavior only when the relevant tests ran and the result can be inspected.
A diff shows what changed in code. It does not prove deployment.
A deployment record shows that a version reached an environment. It does not prove that the business result improved.
A reconciled total can support a financial result. A generated summary cannot replace the underlying record.
This is where leaders can get into trouble. We receive a clean explanation and treat it as proof of the thing being explained.
The explanation may be useful. It may be correct. It still needs evidence proportionate to the decision.
A draft message is not a sent message. A prepared CRM update is not an updated record. A proposed approval is not an approval. A merged pull request is not necessarily the requested integration.
The work has to reach the place where the outcome actually lives.
Confirm the source of truth
Every consequential workflow needs an authoritative place to check the result.
That may be the source repository, deployed environment, CRM, accounting system, property-management platform, approval record, or another system that legitimately owns the state.
AI can summarize across those systems. It can compare them and surface inconsistencies. Its summary does not become the source of truth because it is easier to read.
Before I accept completion, I want to know:
- Which system owns the final state?
- Was that system checked after the action?
- Does its current record match the requested outcome?
- If two sources disagree, which one governs?
- Who owns the conflict?
The wrong-branch merge would have passed a shallow check. GitHub showed a merged pull request. Only the governing branch readback exposed that the intended state was still missing.
The action ran and the result is true are different claims.
Give exceptions somewhere to go
Reliable work does not depend on everything going according to plan.
It defines what happens when the system cannot proceed safely or cannot prove the result.
The exception path should cover predictable conditions:
- The authoritative system cannot be reached.
- Required evidence is missing or conflicting.
- The system lacks permission for the next action.
- Human approval is required.
- Validation fails.
- The request crosses a privacy, security, legal, financial, housing, employment, or other human-only boundary.
- The available information is too ambiguous to act responsibly.
In those conditions, blocked is a better answer than false completion.
A useful exception report states what happened, what remains unresolved, what evidence exists, who needs to decide, and what would return the work to the normal path.
Silence is not an exception process. Neither is retrying indefinitely.
A system earns more trust when it can stop clearly, preserve what it knows, and hand the decision to the right person.
A human still owns closure
AI can perform work, collect evidence, and recommend a disposition. It cannot absorb accountability for the business outcome.
Someone still owns acceptance.
That does not mean the CEO reviews every detail. It means the assignment has a named human owner with enough authority and context to accept the evidence, reject the work, or escalate the exception.
A nontechnical leader does not need to inspect every line of code or every tool call to govern the work responsibly. The leader does need to define the result, boundaries, evidence, authoritative source, and person who can close the loop.
Delegation does not end ownership. It makes ownership explicit.
The Prompt-to-Proof closure test
Before accepting consequential AI work, I want five questions answered:
- What were the acceptance criteria?
- What inspectable evidence supports completion?
- What does the source of truth show?
- What exceptions remain?
- Who accepted the result?
If any answer is missing, the honest status may be drafted, built, tested, waiting for approval, blocked, deployed but not verified, or abandoned.
Those are useful states. They tell the next person what is true and what still has to happen.
Done is useful only when everyone knows what it means.
The opportunity with AI is larger than faster output. We can redesign delegation around clearer context, stronger boundaries, visible exceptions, and evidence a responsible person can accept.
That is the standard I am working toward.
Get the Prompt-to-Proof Delegation Contract
Define the goal, sources, authority, prohibited actions, evidence, escalation conditions, and human owner before consequential work begins.
Primary CTA destination: /from-prompt-to-proof/delegation-contract/
