AI judgment and deterministic steps

A probabilistic AI step can handle inputs whose language, layout, or meaning varies. Useful examples include:

• classifying a free-form request;
• extracting fields from inconsistent documents;
• matching differently worded descriptions;
• summarizing a long thread;
• drafting text from supplied facts;
• identifying cases that may need specialist attention.

The same input can produce slightly different wording or scores across runs. That variability may be acceptable when the output is a proposal and downstream checks contain it.

A deterministic step follows explicit logic. Given the same validated input and software version, it should produce the same result. Examples include:

• comparing an amount with a policy threshold;
• calculating totals and dates;
• looking up an account by ID;
• checking whether a value belongs to an allowlist;
• selecting an approver from an organization chart;
• enforcing permissions;
• writing an approved record;
• sending a message to an exact address.

Using AI for an exact rule makes behavior harder to test without adding useful capability. Do not ask a model, “Is $1,250 above our $1,000 review threshold?” Compare numbers in code.

A common reliable structure is a judgment sandwich:

1. deterministic code gathers and normalizes inputs;
2. AI performs one bounded interpretation task;
3. deterministic code validates the result and controls what can happen next.

For receipt processing, code can verify file type and scan status. AI can extract merchant, date, category, currency, subtotal, tax, and total into a schema. Code then verifies that numeric fields add up, currency is supported, date is plausible, required evidence exists, and thresholds are followed. A person approves exceptions. Only an expense system with appropriate credentials issues reimbursement.

The model does not need reimbursement permission. Its useful role ends when it produces a structured proposal.

An AI step should have a contract as clear as any service boundary. Specify:

• allowed inputs and their provenance;
• allowed output fields and values;
• behavior when evidence is missing;
• whether citations or source spans are required;
• maximum input and output size;
• privacy restrictions;
• timeout and retry policy;
• evaluation examples;
• fallback behavior.

Prefer structured output to prose when another step consumes the result. For ticket routing, return a category from an enum, a reason code, and evidence spans. Reject unknown fields. Treat schema compliance as necessary but not sufficient: valid JSON can still contain a wrong category.

Give the model an explicit uncertainty route such as needs_review. Forcing a choice among ordinary categories turns ambiguity into false certainty.

Validation has layers.

Syntax validation checks that output parses and matches types.
Domain validation checks permitted values, ranges, relationships, and required fields.
Evidence validation checks that claims are supported by available sources.
Policy validation checks hard business rules.
Authorization validation checks that the current actor may request the action.

Suppose AI extracts a refund amount of 500.00. A number type passes syntax validation. Domain logic must also check that it is nonnegative, does not exceed the captured payment, matches the currency, and falls within the requester’s authority. If the amount came from a customer’s message rather than the transaction record, evidence provenance should prevent it from becoming authoritative.

Generating a proposal and executing it are separate operations. This separation creates a control point.

Bad boundary: “Read the message and update the account appropriately.”
Better boundary: “From the message, propose one of these change types and cite the supporting text.” Then code loads the account, validates the proposal, checks authorization, requests review if needed, and applies the approved change.

The separation also improves testing. You can replay historical inputs through the AI step without changing real records. You can test execution with fixed proposals without paying for model calls. During an incident, you can pause side effects while continuing to collect draft outputs for diagnosis.

For every workflow step, ask:

1. Is the correct operation completely specified?
2. Must identical inputs produce identical outputs?
3. Does the step enforce money, access, privacy, safety, or policy limits?
4. Does it cause an external side effect?

If any answer is yes, deterministic logic should usually own the step. AI may provide information to that logic, but it should not replace the rule.

Then ask:

1. Does the input vary in language or format?
2. Is interpretation or semantic matching required?
3. Can the result be checked, reviewed, or safely rejected?

If these are yes, a bounded AI step may be useful.

Setting temperature to zero does not turn a model into a rules engine. Providers may change infrastructure, model versions can change behavior, and ambiguous language still lacks a single mechanically correct interpretation. Lower variability can help evaluation, but it does not create guarantees.

Likewise, wrapping generated text in a schema does not make the content true. Reliability comes from architecture: authoritative data, narrow permissions, validations, human review where needed, and observable execution.