verification-before-completion

Verification Before Completion

Overview

Claiming work is complete without verification is dishonesty, not efficiency.

Core principle: Evidence before claims, always.

Internal belief that something worked is not evidence. The deck feels clear to you; the memo reads well to you; the process change looks adopted to you — none of that is external evidence that the stakeholder got an answer, the reader understood, or the team changed behavior. Go look.

Violating the letter of this rule is violating the spirit of this rule.

The Iron Law

NO COMPLETION CLAIMS WITHOUT FRESH EXTERNAL EVIDENCE

If you haven't confirmed it against the real world in this exchange, you cannot claim it is done.

The Gate Function

BEFORE claiming any status or expressing satisfaction:

1. IDENTIFY: What observation would prove this claim?
2. GATHER: Go get that observation (ask the person, read the doc,
           check the metric, look at the reply, watch the meeting).
3. READ: Full evidence, not a snippet. What does it actually say?
4. VERIFY: Does the evidence confirm the claim?
   - If NO: State the actual status with evidence.
   - If YES: State the claim WITH the evidence.
5. ONLY THEN: Make the claim.

Skip any step = lying, not verifying.

Common Failures

Claim	Requires	Not Sufficient
Deck answers the stakeholder's question	Stakeholder confirms in their own words	"It addresses the brief"
Memo was understood	Reader restates the key decision	"It's well written"
Process change landed with the team	Observed behavior in the next cycle	Announcement sent
Metric moved	Fresh pull of the metric	"The change should lift it"
Candidate accepted the offer	Signed offer in hand	Verbal "I'm excited"
Email addresses the reader's objection	The actual objection from the reader	The objection you imagined
Requirements met	Line-by-line checklist against the brief	General sense of done
Decision is approved	Approver said yes, in writing if that's the norm	Silence after you sent it

Red Flags — STOP

• Using "should", "probably", "seems to"
• Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
• About to send, publish, or announce without checking the thing exists and says what you think
• Trusting a secondhand report ("someone said it went well") as evidence
• Relying on partial verification (one reply from one person ≠ the whole audience aligned)
• Thinking "just this once"
• Tired and wanting work over
• ANY wording implying success without having gathered evidence

Rationalization Prevention

Excuse	Reality
"Should work now"	Go verify it
"I'm confident"	Confidence is not evidence
"Just this once"	No exceptions
"It reads well to me"	You wrote it; of course it does. Ask the reader.
"Someone told me it was fine"	Verify with the actual person of record
"I'm tired"	Exhaustion is not an excuse
"Partial check is enough"	Partial proves nothing about the whole
"Different words so the rule doesn't apply"	Spirit over letter

Key Patterns

Did the deliverable answer the real question?

OK:  Share draft with stakeholder → they restate what they now know →
     it matches the question they originally asked → "Answered."
NOT: "The deck covers the topic." / "It reads well."

Did the reader actually understand?

OK:  Ask the reader to restate the decision/ask in their own words →
     it matches → "Understood."
NOT: "The memo is clear." (to you)

Did the process change land with the team?

OK:  Observe the next cycle → the new behavior shows up → "Adopted."
NOT: "I sent the announcement and nobody objected."

Did the metric move?

OK:  Pull the metric after the change has had time to take effect →
     compare to baseline → "Moved from X to Y."
NOT: "The change should lift it."

Is the hire accepted?

OK:  Signed offer in writing → "Accepted."
NOT: "They sounded excited on the call."

Does the email address the actual objection?

OK:  Name the objection the reader actually raised → point to the
     line in the draft that answers it → "Addressed."
NOT: "I covered the concerns I imagined they'd have."

Requirements:

OK:  Re-read the brief → checklist each requirement → verify each
     against the deliverable → report gaps or completion.
NOT: "Feels comprehensive."

Delegation:

OK:  Person reports they did the thing → you check the artifact
     (the sent email, the updated doc, the calendar hold, the
     spreadsheet row) → "Confirmed."
NOT: Trust the report without looking.

Why This Matters

• Trust is the only currency. Once a partner hears "it's done" and finds it isn't, every future claim is discounted.
• False completion claims send the work to the next phase uncooked. Someone downstream then discovers the gap, and the rework costs more than the original verification would have.
• "I don't believe you" is a terminal state. Avoid it by never spending credibility on unverified claims.

When To Apply

ALWAYS before:

• ANY variation of success/completion claims
• ANY expression of satisfaction
• ANY positive statement about work state
• Sending, publishing, announcing, scheduling
• Moving to the next task
• Reporting status upward
• Handing work off

Rule applies to:

• Exact phrases
• Paraphrases and synonyms
• Implications of success
• ANY communication suggesting completion or correctness

Relationship To Other Skills

Referenced by systematic-problem-solving — once you believe you have the fix, verification-before-completion is what turns that belief into a claim.

The Bottom Line

No shortcuts for verification.

Gather the evidence. Read it. THEN claim the result.

This is non-negotiable.