Deterministic rules versus AI judgment

The interesting question is rarely whether a model would be accurate. It is which parts of a decision are checkable, which need judgment, and what happens at the seam.

The test for each condition

A condition belongs in deterministic code when it is checkable: the same inputs return the same answer every time, and a person reading the rule can predict the result without running it.

A condition needs interpretation when two competent people could look at the same evidence and disagree, and the disagreement is about meaning rather than about the value of a field.

Condition	Kind	Why
Company size above a stated threshold	Hard	A number and a comparison
Matched company is a known competitor	Hard	A list lookup
Person is suppressed from outbound	Hard	A recorded state
The request is for something this product actually does	Interpretive	Requires reading what they wrote
The stated need is a real business problem rather than a course assignment	Interpretive	Requires reading what they wrote
Seniority implied by an unusual job title	Interpretive, and often prohibited	See below

Rules first, judgment on top

The architecture that holds up puts deterministic rules underneath.

1. Rules build the candidate set. Eligibility, consent, ownership, and duplicates are all checkable, and none of them needs interpretation.
2. Hard disqualifiers run before anything expensive. A competitor match should not cost a model call.
3. Interpretation runs only on what survives, and only on the questions that actually need it.
4. A hard rule can veto an interpretive pass, and never the reverse. Matching every quantitative criterion does not survive a qualitative disqualifier, and a favourable interpretation does not overturn a competitor match.

The seam rule matters more than either half: the model never widens the candidate set. It adjudicates within a set the rules produced. A system where interpretation can add records is a system where a prompt change alters your population.

Order changes the answer

Rules are cheap to reorder and the order is a decision. Placing an inexpensive numeric check before a qualitative disqualifier means records failing the qualitative test never reach it, and the population you end up with is not the one you described.

State the evaluation order on the card, and state which rules stop evaluation when they fail.

One governing principle often beats the tiers

Worth knowing before adding a sixth threshold: a single well-chosen semantic rule about who the decision is for frequently sorts more of the junk than any quantitative criterion. "Is this a request from somebody the product is built to serve?" is a question a threshold cannot express and interpretation answers well.

That is the case for interpretation, and it is narrower than it first appears: it earns its place on the questions rules cannot state, not on the ones they state cheaply.

When not to use AI at all

Four cases, and they come up more than the literature suggests.

The rule is checkable. A threshold does not need a model. Adding one makes the result less predictable and no more correct.

The number has to be explainable in a meeting. A deterministic composite that leadership reads weekly is more useful than a more accurate one nobody can interrogate. When somebody asks why a number moved, "the model weighed it differently" ends the conversation badly.

Accountability matters more than accuracy. A component score entered by the person who owns the account is sometimes correct precisely because a named person owns it. Automating it saves time and removes the thing that made it trustworthy. Ask what the assessment is for before automating it: if the answer is "so the owner has a view", a model produces a different artifact with the same name.

There is no evidence a model could read. Interpretation needs something to interpret. Applied to a record with no notes, no message, and no activity, it produces a confident guess from the fields a rule already had.

Count the split before you build

List every condition the decision evaluates and mark each one rule or judgment using the test at the top of this page. Most teams doing this for the first time find the judgment column holds one or two items, not the eight they assumed, and that the rest were only ever waiting on somebody to write the threshold down.

That count is the build order. The rule conditions ship first and cost an afternoon. Whatever survives in the judgment column is the only part that needs a model, an evaluation set, and a reason to trust it.

Related: Decision Card template for where rules and their order are recorded, Evidence requirements and confidence, and Context precedence for precedence inside an AI context layer. The interactive walkthrough is Define the Decision Before You Automate It, which contains no AI on purpose.