ZION BOGGAN
← WRITING  ·  DESIGN NOTE

Make the bad outcome unrepresentable.

A pipeline becomes safer when a silent drop or a guessed remap is not merely discouraged. It is absent from the vocabulary of the program.

DesignVerificationPipelines

By Zion Boggan ·

An unsafe outcome is absent from the safe decision typeINPUTknown or unknownexact or ambiguousNAMED OUTCOMESKeep with evidenceQueue for reviewThe silent drop has no name
A safe state machine gives uncertainty somewhere visible to go.
Vertical safe decision type for a phone screenINPUTknown or unknownexact or ambiguousNAMED OUTCOMESkeep with evidencequeue for reviewsilent drop has no name
Uncertainty has a visible destination. Erasure does not.

A missing decision is not a decision

Many systems end up with a convenient escape hatch: if an input cannot be classified, drop it; if a source does not line up, remap it to the nearest known value; if an external service times out, continue and clean up later. These choices feel practical because they keep the pipeline moving. They also convert uncertainty into invisible damage.

The safer shape is explicit. Every item receives a decision record. It can be kept with evidence, or it can enter a short human queue with the reason it needs review. There is no silent drop state. There is no automatic remap state. A bug cannot quietly choose those outcomes because the program has no names for them.

The design test: list the outcomes that would be dangerous if they happened without a person noticing. Then remove those outcomes from the type, schema, or state machine.

What this looks like in practice

Before and after comparison of a weak pipeline and a safer pipelineBEFOREunknown → dropnear match → remaptimeout → successAFTERunknown → evidence queuenear match → human decisiontimeout → visible failure→
The safer pipeline preserves uncertainty instead of laundering it into success.
Vertical weak and safer pipeline comparisonBEFOREunknown → dropnear match → remaptimeout → successAFTERunknown → evidence queuenear match → human decisiontimeout → visible failure
The safer pipeline preserves uncertainty instead of hiding it.
Weak shapeSafer shape
Unknown item disappears.Unknown item is retained with evidence and routed to review.
Near match is substituted silently.Exact match is required, or the item is visibly unresolved.
Timeout is treated as success.Timeout is a first-class failure with retry and receipt.
Dashboard says complete.Completion requires the artifact, behavior check, and observation.

This is not a demand for perfect automation. It is a demand that the system preserve the uncertainty it cannot resolve. A person can clear a visible queue. A person cannot recover an item the system erased.

Test the absence

Most tests ask whether the happy path works. Add tests for the paths that must not exist:

  • Feed an unknown identifier and assert that the run stops or queues it with a reason.
  • Feed two plausible matches and assert that neither is selected automatically.
  • Remove the artifact destination and assert that the result is not marked complete.
  • Repeat the run and assert that the receipt prevents a second side effect.

The test is not complete when the error is logged. It is complete when the system leaves behind enough evidence for another person to understand what happened and what remains safe to do.

For a small team, this can be as simple as a queue file with four fields: input, reason, evidence location, and next decision owner. The implementation can grow later. The important first step is that no unresolved item can vanish between one command and the next.

Retire a design when evidence says to

There is a second version of the same discipline: do not protect a pipeline merely because it has consumed time. State the claim, choose the smallest blind comparison that could disprove it, and let the measured result decide.

In one production workflow, a 12-sample blind comparison chose a replacement framing in all 12 cases. The measured render cost was lower too. That result retired the old shape. The work invested in its scoring logic was still useful, but it was no longer a reason to keep the wrong pipeline alive.

If the result cannot change the design, the comparison is theatre. If an unsafe outcome can still happen without a named record, the safety boundary is theatre too.

A useful default

When the system does not know, preserve the input, preserve the evidence, and preserve the decision that remains to be made. Make the safe outcome easy to represent. Make the unsafe shortcut impossible to represent.