Self verification

Skill 07: Self-Verification & Quality Control

Purpose: Prove your work actually does what it should, before you declare it done. Use when: You're about to call anything "done," "fixed," "working," or "complete." Every single time. Don't use when: Never skip it. If the work is truly trivial (a one-line typo fix), the verification is trivial too, but you still do it.

---

Why this matters

The single biggest quality gap between strong and weak work is this: strong work is verified; weak work is assumed. Weak models and junior engineers routinely announce "done" based on a feeling, the code looks right, it should work, the change seems complete. Then it doesn't run, or it solves the wrong thing, or it breaks something else. Declaring victory without checking is the most common and most damaging habit there is.

This skill is a discipline, not a technique. The hard part isn't knowing how to verify: it's actually doing it every time, especially when you're tired, confident, or under time pressure. Those are exactly the moments verification catches the most.

The core principle

"It should work" is a hypothesis, not a result. You are not done until you have observed it working against the criteria you set. The word "done" is a claim about reality. Back it with evidence you actually gathered, or don't make it.

---

The verification procedure

Before claiming completion, produce evidence for each of these:

1. It runs

Actually execute it. Not "read it and it looks correct": run it. The number of "obviously correct" changes that fail on first run is humbling and constant.

2. It meets the acceptance criteria

Pull up the success criteria from requirements-and-success-criteria. Walk each one. For each: did you observe it pass? Check the box only when you've seen it, not when you believe it.

3. The unhappy paths behave

Feed it the bad inputs: empty, missing, malformed, too large, wrong type, unauthorized. Confirm each produces the intended behavior (a clear error, not a crash or silent wrong answer). Untested error handling is usually broken error handling.

4. You didn't break anything else

Run the surrounding checks/tests. A change that fixes one thing and breaks two is negative progress. If there are no tests, manually exercise the things most likely to be affected.

5. It solves the actual request

Re-read the original request. Does your result address what was asked, not a nearby thing you found easier? This catches the subtle, expensive failure of confidently solving the wrong problem.

6. No debris left behind

Remove debugging prints, commented-out experiments, temporary files, and dead code introduced along the way. Leave the intended checks/tests; remove the scaffolding.

---

Report honestly

How you report results is part of quality control. The rules:

• If a check failed, say so: with the actual output. Don't bury it, don't round "3 of 5 pass" up to "working."
• If you skipped a step, say you skipped it. "I didn't test the 1M-row case" is valuable; a silent gap is a landmine.
• Distinguish "verified" from "should work." State plainly which claims you observed and which you're inferring. "Runs correctly on the sample (verified); should scale to production volume (not tested)" is an honest, useful report.
• Don't hedge a real success into mush, and don't inflate a partial one. Say exactly what is and isn't proven.

A truthful "it's 80% done and here's the failing 20%" is worth more than a false "it's done." The false "done" gets discovered downstream at ten times the cost.

---

The testing mindset

You don't need a test framework to test. Testing is just deliberately trying to make it fail before reality does.

Think adversarially about your own work

For each piece, ask: how could this be wrong? Then check that specific way. Good self-testers attack their own work harder than any user will.

Cover the classic danger inputs

For any input, run through this list and handle each:

Class	Examples
Empty / zero	empty string, empty list, 0, empty file, no rows
One	single element (off-by-one lives here)
Many / huge	very large input (performance, memory, overflow)
Boundary	first, last, min, max, exactly-at-the-limit
Malformed	wrong type, wrong format, corrupt, partial
Duplicate / repeated	same item twice, re-running the same operation
Missing	null, absent field, missing file, no permission
Hostile	injection, oversized, deliberately tricky input at trust boundaries

Pick the check that fails loudest if the logic breaks

When you leave a test behind, make it the smallest test that would actually break if the core logic were wrong: not a test that passes no matter what. A test that can't fail proves nothing.

---

Worked example

Situation: You wrote the --json export and are about to say "done."

Assumed-done (weak): "The function calls json.dumps, so it works. Done."

Verified-done (strong):

1. Runs: Executed report --json on the sample. ✅ produced output.
2. Criteria: Piped output into a JSON parser → parses, and the totals round-trip equal to the table version. ✅
3. Unhappy paths: Ran --json on an empty file → printed {} cleanly, no crash. ✅ Ran on a missing file → clear "file not found," exit code 1. ✅
4. No regressions: The plain table output still matches. ✅
5. Actual request: Asked for "export the report as JSON", yes, that's what it does. ✅
6. Debris: Removed the print(rows) I added while building. ✅

Report: "Verified: --json produces valid JSON matching the table totals on the sample; empty and missing-file cases handled. Not tested: extremely large exports (>100 MB)."

Now "done" is a fact with evidence, and the one untested case is disclosed.

---

Common failure modes

Failure	Fix
"Looks right," never run	Execute it. Every time.
Declaring done by feeling	Walk the acceptance criteria and observe each.
Only testing the happy path	Run the danger-input list.
Ignoring regressions	Run surrounding checks after any change.
Solving a nearby easier problem	Re-read the original request; confirm it's addressed.
Inflating partial results	Report exactly what's proven vs. inferred.
Hiding a failure	State failures with their actual output.
Tests that can't fail	Use the smallest check that breaks if logic breaks.

Red flags: stop, you are not done

• You're about to say "done" / "fixed" / "works" and haven't run it since the last change.
• You can't point to the evidence for a completion claim.
• You tested only that it works, never that it fails correctly.
• You're rounding a partial result up to "done."
• You changed something and didn't check what else it touches.
• You're relieved to be finished and want to skip the check: that relief is the risk.

Definition of done for this skill

• The work was actually executed, not just read.
• Every acceptance criterion was observed to pass.
• Danger inputs / unhappy paths were exercised.
• Surrounding checks confirm no regressions.
• The result addresses the original request.
• Debris removed; intended checks left in place.
• The report distinguishes verified facts from inferences and discloses any gaps.

See also

• requirements-and-success-criteria, where the acceptance criteria come from.
• systematic-debugging, what to do when verification fails.
• robustness-and-failure-modes, designing so fewer things fail in the first place.