Turning INCONCLUSIVE Harness Verdicts into Contract‑Coverage Tests

Green tests hide a missing contract

Your CI pipeline reports 100 % passing. The artifact builds, the test suite runs, and the badge stays green. Yet the component never touches the data it is supposed to process. The underlying reason is that the harness exercised only the paths covered by the existing input contract. Anything outside that contract never runs, and the harness returns INCONCLUSIVE. The failure mode is treating that verdict as a generic failure and discarding it. The result is a false sense of safety.

INCONCLUSIVE is a clue, not a defect

An INCONCLUSIVE verdict means the harness could not satisfy the input contract required to execute the artifact. It does not imply a bug in the code. It signals that the contract description is incomplete or that the test data set does not reach the code path. In the SHPBL model‑independent ecosystem, the harness records four outcomes; only CERTIFIED and PROVISIONAL attest to correctness. INCONCLUSIVE sits on the ladder precisely to highlight missing contract coverage. Ignoring it leaves a blind spot between “it compiles” and “it is correct”.

Extending the harness from the verdict

The practical way to act on an INCONCLUSIVE result is to treat the verdict as a contract‑coverage ticket. Follow these steps:

1. Capture the harness log for the INCONCLUSIVE run. The log contains the input shape the harness attempted to provide and the point where it stopped.
2. Identify the missing fields or the unexpected type that caused the halt. In many cases the log will show “expected property ‘id’ missing” or “type mismatch on ‘payload.timestamp’”.
3. Write a minimal input fixture that satisfies the missing requirement. The fixture should be as small as possible – only the fields needed to reach the next execution point.
4. Add the fixture to the harness’s test matrix. The harness treats each fixture as a separate contract entry, so the new fixture expands the coverage without altering existing tests.
5. Re‑run the harness. If the verdict changes to PROVISIONAL or CERTIFIED, the contract gap is closed. If it remains INCONCLUSIVE, repeat the process with the next missing element.

A concrete example helps. Suppose a data‑transform component expects an object with {userId:string, payload:{value:number}}. The existing harness supplies only {userId:"abc"}. The run stops with an INCONCLUSIVE verdict, logging “payload is undefined”. Create a fixture:

{
  "userId": "abc",
  "payload": { "value": 0 }
}

Add it to the harness configuration and re‑run. The harness now proceeds past the previous stop point, and the verdict upgrades. The new fixture also becomes part of the regression suite, preventing the same contract gap from resurfacing.

From insight to Monday’s action

The pillar post “/blog/the-four-verdicts-between-green-tests-and-correct-code” explains why naming the rung matters. Apply that lesson today: treat every INCONCLUSIVE verdict as a contract‑coverage task, not a failure. On Monday, open the latest harness report, locate the first INCONCLUSIVE entry, and create a single input fixture that satisfies the missing contract element. Commit the fixture to the harness configuration and push the change. Within the next CI cycle you will see the verdict improve, and you will have added a concrete test that proves the artifact does something useful.

By turning INCONCLUSIVE signals into targeted harness extensions, you raise confidence without flooding the pipeline with false alarms. The ladder between compilation and correctness becomes clearer, and your test suite begins to measure behaviour rather than just build success.