why deterministic code should make the final call, not the model

it's a monday morning. a new ai system promises to handle client intake for your regulated practice. the vendor pitch sounds great: speed, accuracy, cost savings. but you're not a technologist. you're a managing partner. and you have a nagging question. if this thing makes a bad call on a real client matter, who explains what happened, and how.

that question is the whole problem with most ai intake tools. it is also the answer. the model should never make the final call. a deterministic function, code that does the same thing every time given the same input, should make the decision. the model reads. it does not decide.

the model reads, it does not decide

language models are probabilistic. ask the same question twice and you can get two different answers, worded differently, weighted differently, sometimes contradicting each other. that is not a flaw to be patched out with a better prompt. it is how the technology works. it predicts likely text. it does not apply a rule and stop.

for a lot of tasks that is fine. summarizing a call, pulling a phone number out of a paragraph, guessing at whether an intake sounds urgent. the model is genuinely good at that kind of reading. it is bad at being the last word on something that has to hold up later: was this potential client's matter routed to the right attorney, was a conflict properly flagged, was an intake rejected for a reason that can be stated plainly to a bar examiner or a judge.

decisions in regulated work need to be the same every time the inputs are the same. models are not built to guarantee that. so the fix is not to make the model more careful. it's to stop asking it to decide anything final.

when auditability matters more than a guess

the real objection to letting a model decide isn't accuracy, it's opacity. if a model outputs "route to senior partner," you cannot ask it why in any way that produces a stable, repeatable answer. ask again and it might explain itself differently. that is a black box, and a black box is not something you can defend in a bar complaint, a malpractice claim, or a routine audit of your own intake process.

what a firm actually needs is a chain of logic a human can walk through line by line. this case was flagged urgent because the caller used the word "deadline" and the extracted date was inside seven days. this matter was routed to attorney x because the practice area field matched a rule set two years ago and hasn't changed. that sentence is boring. boring is the point. boring can be shown to a managing partner, a regulator, or opposing counsel without anyone flinching.

that kind of sentence only exists if a deterministic function, not a model, produced the decision. the rule has to live in code someone wrote and can read back, not in weights nobody can inspect.

how the work splits: extract and route, then decide

in practice this looks like two separate jobs done by two separate things. the model reads an intake call or a submitted form and extracts structured fields: practice area, jurisdiction, stated urgency, whether the caller mentioned an existing attorney relationship, whether a statute of limitations date is close. that is extraction. it is what the model is good at.

those fields then get handed to a plain function. if practice_area equals personal_injury and jurisdiction is in the approved list, route to intake queue A. if urgency_flag is true and days_to_deadline is less than ten, escalate immediately and notify a named person, not a queue. if a conflict keyword matches an existing client name, stop the process and route to a human for manual review. none of that is generated. it is written, versioned, and testable the same way any other business logic is.

the model never touches the decision step. it hands off structured data and its job ends there. if you want to know why a given case was routed a given way, you read the function, not the model's explanation of itself.

the infrastructure lives in your accounts, not ours

a system like this only means anything if the firm can actually inspect and keep it. that is why the infrastructure runs inside the client's own cloud accounts, not a vendor's shared environment. the rules, the logs, the routing history: all of it sits where the firm's own IT and compliance people can already reach it, under whatever access controls the firm already runs.

the practical effect shows up on the day a firm wants to leave. it becomes a handover, not a hostage negotiation. there's no proprietary black box to negotiate for, because there isn't one. the deterministic functions are readable code. the logs are the firm's logs. what changes is who maintains it going forward.

when the model fails, the work goes to a human

models go down. rate limits get hit. sometimes the extraction comes back with a confidence too low to trust, or the model returns something malformed that doesn't map to a field the rules engine expects. the failure mode matters as much as the happy path.

the answer here is not to guess and hope, and it is not to silently drop the intake. when the model is unavailable or its output doesn't meet the bar the rules require, the case routes straight to a person. no decision gets manufactured to fill the gap. the work waits for a human rather than getting a confident-sounding answer built on nothing. that is a deliberately unglamorous design choice, and it is the one that keeps a firm from ever having to explain why the system invented a routing decision out of a timeout.

none of this is a claim about what your obligations are under your state's rules on advertising, unauthorized practice, or record-keeping. those vary, and a vendor telling you what's compliant should make you nervous rather than reassured. what a firm can control is whether the system it adopts is built so a human can check its work, end to end, on any given case.

if you're evaluating a system like this, or trying to figure out where an existing one is quietly letting a model decide things it shouldn't, a workflow audit is a two-week, fixed-scope look at exactly that. it costs $2,500 and the fee is credited toward a build if you move forward. details are at /workflow-audit.