Outcome sets and explicit unknown states

The shape of a decision and the set of answers it may return are one design act. Get the set wrong and no amount of implementation quality recovers it, because the system cannot return an answer that is not on the list.

Pick the shape first

Shape	Returns	Use when
Classification	One value from a closed set	A downstream action differs per value
Score	A number on a stated scale	Values need comparing against a threshold
Ranking	An ordered list	Capacity is the constraint and everything gets worked eventually
Recommendation	A suggested action plus reasoning	A person will decide and needs the option, not the verdict

The most common mistake is producing a score when the business needs a classification. A score defers the decision: somebody still has to pick a threshold, and because the threshold lives in a report filter rather than on the card, it gets changed by whoever is looking at the report that week.

The second most common is ranking when nothing is capacity-constrained. Ranking implies everything gets worked eventually. If the bottom of the list never gets touched, you have a classification with extra steps and no stated cutoff.

Two outcomes is usually one too few

A binary decision forces every record into one of two buckets, and the interesting records are the ones that belong in neither.

For inbound qualification, the categories that matter are usually three: a real buyer, a real person who is not a buyer, and not a real person at all. Collapsing the middle one produces a specific and invisible failure. A binary filter deletes somebody with genuine interest. A binary router hands them to a seller who wastes an hour. The first costs you a customer and nobody ever finds out.

Ask directly: is there a category here that is neither yes nor no, and what happens to it today? The answer is usually "it depends who touched it".

Closed and mutually exclusive

Closed means the set is complete and nothing falls into an unchosen default. Mutually exclusive means no record could reasonably be two of them at once.

The practical test is to take twenty real records and place each one. The records people argue about are the ones that expose an overlap.

And a rule worth applying at the end: two outcomes that lead to identical handling are one outcome wearing two labels. If nothing downstream distinguishes them, merge them or give one of them a different consequence.

Unknown, review, and error are three answers

Almost every decision system collapses these, usually into whatever the storage default is.

State	Means	Fix belongs to
Unknown	The decision ran correctly and cannot reach an answer from the evidence available	Data capture
Review	The evidence is present, and either the rules do not resolve it or the consequence is too large to act on automatically	Rules, or the risk tier
Error	The decision did not complete	Operations

Merging unknown into a negative outcome is how an outage becomes a population of disqualified records. Merging review into unknown means a rules gap gets reported as a data gap forever, and somebody spends a quarter improving enrichment that was never the problem.

Every outcome needs a consequence and an escape hatch

Two rules complete the set.

Every outcome gets an action, and only some interrupt a person. Nothing is silently swallowed. But only the outcome that earns attention gets attention, or the alerting becomes noise and the important one arrives in a stream nobody reads.

Unknown needs a timeout. A record that sits undecided because the decision never returned is stranded. Give the undecided state a clock and a default outcome, and mark the record as having been defaulted rather than decided, so the two are countable separately later.

Test the set against real records

Pull twenty records the decision has already seen and place each one by hand. Three things surface immediately. A record that fits two outcomes means the set is not mutually exclusive. A record that fits none means it is not exhaustive. And a pile sitting in unknown means the evidence requirements are wrong rather than the outcome set, which is a different repair in a different place.

Then count how many of the twenty landed in the outcome that interrupts a person. If it is most of them, the set is describing work rather than deciding anything.

Related: Decision Card template for where the outcome set sits, Evidence requirements and confidence for what each outcome needs to be allowed, and Unknown versus zero versus bad data for the reporting consequence. The interactive walkthrough is Make the Decision Without Faking Certainty.