Return a Consistent Result

The decision returns an answer, and the shape of what comes back depends on what happened on the way to it.

Routed records get an outcome and a reason. Not-a-prospect records get an outcome and nothing else, because the reason felt obvious. Unknown records get a null. Records that errored get a string that starts with “Error:” in the same field the outcome normally occupies.

Every consumer downstream now needs to know all four shapes. The alerting workflow checks for the string. The report groups on a field that is sometimes an outcome and sometimes an error message. When somebody adds a fifth case, three consumers break and one silently starts miscounting.

One shape, always

The output contract is the interface between this guide and everything that comes after it, and it has one rule: every run returns the same shape, whatever happened.

Every result carries the outcome, always one of the values the Decision Card defined; a short human-readable reason; the deciding rule that actually determined the answer; the evidence used; anything estimated rather than observed, with what it was inferred from; required inputs that were missing; any conflicts found and which value was used; confidence on a stated scale; and run metadata. An error is not an outcome. It is a separate status on the envelope, so a system failure can never be counted as a business answer.

Why every field earns its place

Two of these look like overhead and are the reason the contract exists.

Deciding rule is what makes a wrong answer diagnosable. Without it you know the system said “not a prospect” and you are reverse-engineering why. With it you know which rule fired, and you know within a minute whether the rule is wrong or the reading was.

Evidence estimated is what stops an inference hardening into a fact. Define the Decision established that an estimate must announce itself. This is the field it announces itself in, and it is what lets a report separate “routed on observed revenue” from “routed on inferred scale” when somebody asks why routing quality dropped.

The next guide consumes all of this. An explanation a user can inspect, an unknown a user can understand, and an override that preserves history are all built from the fields above. A decision that returns only an answer cannot be explained afterward, no matter how good the explanation interface is, because the information was never captured.

Versioning

One field prevents a specific, miserable afternoon: record which version of the design produced each result. The rules will change. When they do, every historical result was produced by rules that no longer exist, and without a version stamp you cannot tell whether last quarter's answers came from the old logic or the new. Every question about whether a change helped becomes unanswerable.

Carry this into your business

Look at what one of your automated decisions writes to the record. If it writes only the answer, you can never audit it, and you will find that out on the day somebody asks why it started behaving differently.