Choose the Required Evidence

The outcome set is settled. The first version of the rule behind it reads: route to a seller if the company is large enough.

A request arrives from a company whose record has no revenue figure, no headcount, and an industry of “Other.” The rule cannot run. So the implementation does the helpful thing and fills the gap: it works out from the company name and domain that this is probably a large manufacturer, and routes the request.

It was right. That is the problem. It was right the same way a coin lands heads, and the record now says “routed to seller” with nothing on it to indicate that the decisive fact was a guess. The next forty times it does this, some of them will be wrong, and all forty will look identical in the report.

Evidence has a source, an authority, and a freshness

Define What Your CRM Data Means built this vocabulary for fields. It transfers directly, and it is worth not reinventing: every piece of evidence a decision uses has a source (how the value arrived), an authority (whether it is allowed to support this particular decision), and a freshness (how current it is, and whether that is current enough for this decision).

Sort every piece of evidence into three groups. Required evidence must be present, or the decision cannot return a normal outcome. This is a short list. Being strict here is what makes Chapter 6's unknown state meaningful rather than decorative. Supporting evidence changes the answer when present but does not block it when absent. Prohibited evidence is the group most cards leave out, and it is worth writing down explicitly: things the decision must not use, even though they are available and even though they might correlate with the right answer. A person's name. A personal email domain, on its own, as a proxy for whether they are a serious buyer. Anything you would be uncomfortable reading aloud in the post-mortem for a decision that went wrong.

An estimate must announce itself

The missing-revenue case is not solved by refusing to estimate. Refusing would throw away a usable answer most of the time. It is solved by a rule about how estimates are recorded:

Where a required value is absent, the decision may estimate it from stated evidence. It must record that the value was estimated, what it was estimated from, and it must not write the estimate into the field as though it were observed.

Two things follow from that, and both matter more than they look. The first is that the report stays honest. “Routed to seller, company size estimated from industry and domain” and “routed to seller, revenue on file” are different rows, and when the routing turns out to be wrong you can tell immediately which population it came from.

The second is that the field stays clean. An estimated value written into the revenue field is indistinguishable from an observed one a week later, and it will be used by the next three systems that read that field. This is the same failure Keep Your CRM Data Trustworthy covers when an enrichment provider silently overwrites a value: the damage is not the wrong number, it is that nothing downstream can tell it is wrong.

Carry this into your business

Take a decision your team automates and ask what happens when a required field is empty. If the answer is that it never is, check. If the answer is that the system fills it in, find out where that value goes, because it is probably in the field by now.