Test, Don’t Verify#

(Why Confidence Is Not Evidence)

In Part I, we looked at SQLite and its unglamorous insistence on surviving reality.

Not design intent. Not proofs. Reality.

This time, we need to talk about the quiet failure mode that precedes most outages:

Stopping when we feel confident.

Verification Is Necessary and Incomplete#

Verification is not the villain here.

Strong typing, formal reasoning, models, proofs, these things matter. They eliminate entire categories of errors before the code ever runs. They narrow the space of possible failure. They make systems easier to reason about.

That’s real value.

But verification has a hard limit that no amount of cleverness can escape:

You can only verify what you thought to specify.

Reality is not obliged to respect your imagination.

What Verification Actually Gives You#

Verification answers questions like:

  • “Does this meet the specification?”
  • “Is this invariant preserved?”
  • “Is this state transition valid?”

Those are important questions.

They are also inward-facing.

Verification tells you whether the system behaves correctly within the boundaries you defined.

It does not tell you whether those boundaries were sufficient.

What Testing Does That Verification Cannot#

Testing asks worse questions:

  • “What happens when memory runs out here?”
  • “What if the disk lies now?”
  • “What if the input is legal, malformed, hostile, and unexpected all at once?”
  • “What fails after the 400-millionth operation?”

Testing is not about confirmation. It is about confrontation.

Where verification expresses understanding, testing discovers disagreement.

The Missing Sentence Most Teams Never Say#

Most engineering cultures quietly assume this:

If we verified it, we understand it.

SQLite assumes the opposite:

*If we haven’t watched it fail, we don’t understand it.

That single difference explains why SQLite runs in airplanes while more “modern” systems collapse under routine stress.

Types, Proofs, and Models Are Guardrails — Not Seatbelts#

Strong verification tools are structural advantages:

  • They reduce error density
  • They make testing more effective
  • They shrink the space of chaos

But they do not:

  • Simulate I/O failure
  • Model corrupted state
  • Expose timing bugs
  • Survive resource exhaustion
  • Predict adversarial inputs
  • Account for operational reality

They shape intent. They do not prove survival.

SQLite uses verification where it helps. It simply refuses to stop there.

The Real Failure Mode Isn’t Choosing Wrong — It’s Stopping Early#

The problem is not verification versus testing.

The problem is treating verification as closure.

Verification produces:

  • Artifacts
  • Checkmarks
  • Approvals
  • Confidence

Testing produces:

  • Failures
  • Evidence
  • Rework
  • Discomfort

One of these fits neatly into project plans. The other refuses to finish politely.

Most systems fail because they stopped at the point where things looked correct.

Why This Is Uncomfortable (And Always Will Be)#

Deep testing does something verification carefully avoids:

It removes plausible deniability.

You can no longer say:

  • “No one could have predicted this”
  • “This was an edge case”
  • “The system behaved unexpectedly”

If your tests already showed the failure, the responsibility is unambiguous.

SQLite accepts that responsibility. Most organizations quietly structure their processes to avoid it.

The Corrected Thesis#

So let’s say this cleanly, without theatrics:

Verification defines what must not happen. Testing reveals what will.

Both matter. Neither is sufficient alone. Stopping after belief is the mistake.

The Half-Fast DevOps Rule (Refined)#

Here is the rule most teams resist:

If your system has never failed under test, you don’t know how it behaves. You only know how it hopes to.

Verification builds confidence. Testing builds resilience.

SQLite didn’t choose between them.

It refused to confuse belief with evidence—and refused to stop when things felt done.

Half-Fast DevOps isn’t anti-verification. It’s anti-complacency.