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.

Use AI as an independent second scorer

There is a useful role for AI between “make the decision” and “do nothing.” Let it produce a second, advisory assessment that a person can interrogate.

The pattern works for lead qualification, account health, opportunity risk, and sales methodologies such as MEDDICC:

1. The business defines the components and what each value means.
2. A person or deterministic model owns the operational score.
3. AI evaluates the evidence it can access and returns its own component scores.
4. Every AI suggestion includes confidence, rationale, evidence, and what is missing.
5. The two assessments remain separate and their delta is measured.
6. A human resolves meaningful disagreement without erasing either side.

Run the AI evaluation even when the human score is missing. Leadership can still see what the available evidence suggests, while the absent owner assessment remains obvious. When the human score exists, do not show the model only the total and ask it to rationalize the answer. Ask for a component-level evaluation grounded in the underlying evidence so the comparison reveals something.

In a MEDDICC implementation, for example, a company might define 0 as no supporting evidence, 1 as possible or light evidence, and 2 as confirmed with receipts. Those labels are not universal. The score rubric belongs in the business context and can vary by company, product, segment, or methodology.

The rep's assessment remains authoritative. Reps have conversations that were not recorded, receive customer messages that never reached the CRM, and carry context an integration cannot see. Give them a small, dedicated context field so they can supply that evidence for the next evaluation. Treat the note as high-trust human evidence, with author and time, rather than as an instruction that automatically forces the AI to agree.

If the AI and rep disagree, the model has not won. It has created a better management question. A leader can ask why the rep considers somebody an economic buyer when the captured evidence shows influence but not purchase authority. The answer may expose a weak score, uncaptured evidence, a context-rule gap, or a broken input pipeline.

That last case is why disagreement must be reported. In one implementation, persistent score deltas revealed that an experiment intended to save context was sending truncated transcripts to the evaluator. The model could even describe the evidence it lacked—but only because the output contract required it to justify every component instead of returning a number alone.

Ask for the minimum on both sides

The design question is not how many fields can be created. It is:

• What is the minimum the accountable person must supply to own the assessment.
• What is the minimum the AI must return to be accurate without becoming a black box?

The person usually needs component scores and one place for context the systems did not capture. The AI usually needs an advisory component score, component confidence, the deciding evidence, missing evidence, and a short reason. Much of the machine metadata can stay out of the rep interface while remaining available to RevOps and leadership for evaluation.

Confidence does not create authority. A high-confidence disagreement means the captured evidence strongly supports the AI's challenge. It still routes to human judgment rather than silently changing a human-owned score.

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.