Your tests passed.
Your product still violated the spec.

A passing test suite answers an important question: does the implementation behave the way the tests expect? It does not necessarily answer the harder question: does the product still honor the intent that caused us to build it?

The most valuable failure on our dashboard

While reconstructing the verification record for the Ross Beurmann Consulting platform, we found two failed acceptance criteria in an older specification. At first glance, that sounds like ordinary regression debt. It was not.

SPEC-006 described the pre-launch contact experience. It deliberately offered a contact address and collected no visitor data. At the time, those criteria were correct. The implementation met them.

Later, SPEC-009 introduced a real lead-capture workflow. It intentionally collected and persisted contact submissions. The new feature worked as designed—but its instantiation made two formerly valid SPEC-006 criteria false.

We had several ways to make the dashboard green. We could delete the old criteria. We could rewrite SPEC-006 as though it had always anticipated lead capture. We could ignore the failure because the new feature was intentional.

Every one of those choices would destroy useful information.

The failure told us exactly when the product’s intent changed, which later decision changed it, and whether the discrepancy was a defect or an approved replacement. That is not test noise. That is product intelligence.

SDD needs an evidence contract

Spec-Driven Development gives AI-assisted work a much stronger foundation than conversational prompting. The specification creates reviewable intent. Acceptance criteria constrain interpretation. Implementation can be traced back to a reason.

But a specification alone does not guarantee that its acceptance criteria are provable, that yesterday’s evidence still applies today, or that a new specification has not invalidated older intent. If verification arrives after implementation, teams discover those problems at the most expensive point in the flow.

We call our response Verification-First Spec-Driven Delivery, or VF-SDD. We are not claiming to have invented verification-first engineering or Spec-Driven Development. VF-SDD is RBC’s specific operating method for connecting specification intent, evidence design, dependency change, release control, and visible rework.

What changes when verification comes first

Under VF-SDD, every acceptance criterion becomes an evidence row before implementation begins. It must say how proof will be produced, where that proof is valid, whether its failure blocks release, and what decision should follow if it does not pass.

The specification itself is revision-pinned to its verification manifest. Declared specification dependencies are pinned too. If either changes, the old evidence becomes stale. The system does not assume that a passing result from an earlier version still proves the current intent.

That creates two deliberately separate controls:

• The pre-deployment gate fails closed for stale evidence, malformed contracts, invalid dependency pins, and non-passed criteria designated as release-blocking.
• The rework queue retains partial, missing, blocked, and failed advisory evidence without pretending that every evidence gap is a production defect.

This distinction matters. A release gate that blocks on everything becomes bureaucracy and is eventually bypassed. A dashboard that blocks on nothing becomes decoration. VF-SDD makes the risk decision explicit at the criterion level.

Five honest rework decisions

A failed criterion should not automatically generate “fix the code.” The implementation may be wrong, the specification may be wrong, the evidence may be incomplete, or later intent may have legitimately replaced the earlier requirement.

1. Repair: the implementation drifted from valid intent.
2. Amend the spec: the written intent is incorrect or incomplete.
3. Supersede: approved successor intent replaced the earlier criterion.
4. Retire: the capability was intentionally removed without a successor.
5. Collect evidence: the behavior may be correct, but the proof is incomplete.

SPEC-006 required supersession, not a rollback of SPEC-009. Preserving the failed observation alongside the supersession decision gives future maintainers both the historical truth and the current product truth.

Why this matters more with AI

AI can produce implementation, tests, and documentation at extraordinary speed. It can also reproduce the same misunderstanding across all three artifacts. A coherent stack of spec, code, and tests may still be coherently wrong.

Verification-first design forces the team to decide what independent evidence would be convincing before the implementation starts shaping the answer. It also reduces a subtler risk: delivery moving so quickly that evidence becomes permanently attached to an earlier version of intent.

The goal is not more paperwork. The goal is a repository that can answer, at any moment:

• What did we intend?
• What proves it?
• Is that proof still current?
• What changed the intent?
• What must happen before release?
• What remains as deliberate rework?

The spec is the scoreboard. Evidence keeps score.

Our public delivery dashboard currently shows both a passing pre-deployment gate and an advisory rework queue. That is not a contradiction. It is the point.

The gate says the current release met the evidence obligations designated as blocking. The queue says we still owe evidence, disposition, or controlled follow-up elsewhere. The historical-intent event says a later specification intentionally changed what an earlier specification required.

That is a far more useful picture than “all tests passed.” It tells us whether the product, the evidence, and the decisions that shaped both are still aligned.

← Back to Thinking