Claims triage

Claims arrive as prose and get handled by whoever opens the inbox

Somebody reads the email, works out what kind of claim it is, digs out the order, checks the numbers against the record, and decides whether to pay it, dispute it or ask a question. It is the same steps every time, on inputs that never look the same twice.

That combination — a fixed process over unstructured input — is exactly where language models earn their place. It is also exactly where they cause the most damage when the failure modes have not been thought about, because a claim is money and a dispute is a letter to a real customer.

Five stages, and a hard line down the middle

The model reads and extracts. Everything after that — every comparison, threshold and routing decision — is ordinary deterministic code.

No arithmetic, no threshold and no routing call is left to the language model, and confidence gates are deterministic rather than model reported. A model asked to compare two numbers will occasionally be wrong, will not tell you, and the error lands in a decision about somebody's money.

A missing invoice number, read as proof of guilt

A verification check returned false because an invoice number was missing from the claim. The router read false as proven invalid and auto-drafted a dispute letter.

A claim we could not check was being treated as one we had disproven. A real customer would have received a dispute generated from data we never had, written in a confident tone, with our name on it.

The fix

• Unknown became its own state, distinct from a failed check.
• A verifiability gate went first in the routing order, ahead of every outcome rule, so anything unverifiable reaches a person before any other logic runs.
• Confidence gates were made deterministic rather than model reported.

Six defects went into the log in total, every one found by running the thing rather than by reading it. This was the one that mattered, and it is the rule I have carried into everything since. In the AI Value Register it reappears three times: an intake agent that records unknown rather than guessing, a calculation that refuses to run on an unknown input, and a register column left blank instead of zero.

Thirty scenarios, written before the build

The test set was authored first, deliberately. Write the cases after you have seen what the system does and you will unconsciously label to match its behaviour: the score comes out excellent and measures nothing at all. This is the most common way evaluation gets faked, usually without anyone intending to fake it.

The set includes the awkward cases on purpose — claims missing the fields the check depends on, claims that read like one type and are another, and messages that are not claims at all. The adversarial cases are the ones worth writing; the clean ones tell you nothing you did not already know.

Orchestration

n8n, two-phase workflow

Model

Google Gemini, classification and structured extraction

Decision layer

Deterministic routing, verifiability gate, no model-reported confidence

Data

Synthetic claims and reference records, thirty case scenario set

Assurance

Written defect log, six entries with cause, fix and how it was found

Human in the loop

Mandatory for anything unverifiable and for every outbound letter

Next: AI Value Register →