Typed decisions in the mid-market: six processes that fit

An incoming invoice is held against the purchase order, the contract, the vendor record and the delivery evidence. The questions are independent of one another: does the line match the order, is the price within the agreed range, is the vendor known, does delivery evidence exist. Each question gets its own probability, and only the code combines them into an approval.

That is the difference from a single model call asking "check this invoice". Four separate judgments can be traced and tuned individually. One combined judgment cannot.

An expense receipt is first checked for readability, then classified, then held against the travel policy. Meal receipts are where most automations break, because the rule is rarely unambiguous and the amount alone is not enough.

As a question set it works well: is the receipt readable, which category, does the amount exceed the limit for that category, is a required detail missing. Anything below the confidence threshold goes to a person, together with which of the four questions was uncertain.

First assessment of a claim usually has a checklist already. Today it is either worked through by hand or squeezed into a form. As a set of independent yes/no questions on the same case, every individual probability survives instead of collapsing into a traffic light.

The operational gain is not automating the decision, it is the ordering. Cases where every question is clear pass first. Cases with one uncertain answer land at the front of the human queue instead of the back.

Holding a document against a requirements catalogue is a batch of independent questions on one state. Contract clauses against a list of requirements, an audit report against a standard, documentation against a checklist. The model answers each requirement separately and the report is assembled in code.

The boundary matters: the output is a pre-sort, not an assessment. Anyone who needs a reason needs a person or a generative model, and why those are not the same thing is in A number without a reason.

A security alert is joined with the context it came from and then checked on three things: was the action authorised, is there a benign explanation, how strong is the evidence. The third question matters most, because it decides whether anyone gets woken up at all.

The same pattern carries review of completed agent runs, for companies that let AI agents touch their own systems. Permission breach, task completion, anomaly, each as its own question.

The most effective pattern for document pipelines is a cascade. A small, cheap model extracts the fields. A typed decision layer checks each value individually against the source text. Only what fails goes to a larger model or to a person.

That moves the quality question from "how well does the model extract" to "how reliably do we catch a wrong value". The second question is measurable; the first never was. Which failure shapes are typical in document pipelines is covered in Where an AI feature goes wrong.