From Provisional to Certified: Incremental Harness Strategies

Why provisional verdicts linger

A code change lands with a PROVISIONAL verdict from the certification harness. The harness ran the artifact, but it could not prove correctness. The most common cause is a missing test that exercises a branch the artifact relies on. Teams treat the provisional label as a failure and stall, or they ignore it and ship anyway. Both choices waste time. The real problem is a gap between “the code compiles” and “the code is correct”. Naming that gap as provisional is honest, but it does not tell you how to close it.

A staged harness pattern

The certification harness already distinguishes four outcomes. Use that granularity as a roadmap. Start from a provisional verdict, then add a single focused test that targets the uncovered behaviour. Rerun the harness. If the verdict becomes CERTIFIED, the gap is closed. If it stays provisional, the test did not hit the missing path; add another test that explores a different input shape. Continue until the harness reports certified or you reach a point where the missing behaviour is not part of the artifact’s contract.

The pattern has three steps:

1. Identify the missing input – the harness report tells you which contract clause was not exercised.
2. Write a minimal test – craft a test case that supplies exactly that input. Keep it small; the goal is to prove the single behaviour, not to build a full suite.
3. Validate the verdict – run the harness again. If the verdict upgrades, you have a certified artifact. If not, repeat with a new input.

Because each iteration adds only one test, the suite grows incrementally. You avoid the temptation to write a large regression batch that is hard to maintain. The incremental approach also makes code verification transparent: every test corresponds to a concrete harness verdict.

Worked example: adding a boundary test

A library function parseRange(str) converts strings like "5-10" into a numeric interval. The current test set checks normal ranges and empty strings. After a recent refactor, the harness returns PROVISIONAL for a repository that uses the library.

The harness log shows:

PROVISIONAL: parseRange not exercised for input "10-5"

The missing behaviour is handling reversed bounds. The contract states that a reversed range should be normalised to the low‑high order.

Step 1 – Identify the missing input The log pinpoints "10-5" as the untested case.

Step 2 – Write a minimal test

import { parseRange } from 'my-lib';
test('reversed range is normalised', () => {
  expect(parseRange('10-5')).toEqual([5, 10]);
});

The test is a single assertion that mirrors the contract clause.

Step 3 – Validate the verdict Run the certification harness again. The harness now reports CERTIFIED. The provisional verdict was lifted by a single, targeted test.

If the harness had stayed provisional, the next log entry would have indicated a different missing input, such as "5-" (missing upper bound). The same loop would apply.

Putting the pattern into practice

On Monday, open the latest provisional harness report for your repository. Locate the first “not exercised” line. Write a test that supplies exactly that input. Run the harness via the live run page [/harness] and observe the new verdict. If it upgrades, merge the test and tag the artifact as certified. If not, repeat with the next uncovered input.

By treating the certification harness as an incremental test generator, you turn a vague “needs more testing” into a concrete, repeatable workflow. The ladder of verdicts becomes a ladder you climb one rung at a time, without over‑engineering the suite.

For a broader view of the four verdicts and why they matter, see the pillar post [/blog/the-four-verdicts-between-green-tests-and-correct-code]. It explains the semantics that make this staged approach reliable.