AI claims processing with a check per step

An LLM will process a claim. It will read the loss notice, pull the policy, apply the coverage terms, do the arithmetic, and write a decision letter that reads like an adjuster wrote it. It will also, some fraction of the time, apply the wrong deductible, miss an exclusion, value a total loss off the wrong schedule, or deny something it should have paid - and the letter will read exactly as confident either way. What you have when that happens is a transcript. A claim denied in error is not a transcript problem. It is a regulator problem, a bad-faith problem, and a person waiting on money.

Pebble builds claims processing as a verified environment: the adjudication process mapped into numbered steps, each step with its own verification check, run by an AI model inside that structure. The model does the work. The checks decide whether the work counts.

How does a verified environment process a claim?

It walks numbered steps, and each step must pass its check before the run moves on. Here is a plausible step map for first-party claims adjudication, with the check type at each step.

Step 1: Intake the loss notice and assemble the file. The run captures the first notice of loss from whatever channel it arrived on and pulls the policy, the endorsements, the prior claim history, and any attached documents or photos. Check: computed. Code confirms the policy number resolves to a policy that was in force on the loss date, that the required documents are present, and that every referenced attachment actually landed. No model grades this. Either the policy was in force or it was not.

Step 2: Extract the claim record. The model reads the notice and supporting documents and produces structured fields: date and time of loss, cause of loss, location, parties, damaged items, claimed amounts. Check: classified. A small model, trained for this one job and scored against held-out examples before it is trusted, flags illegible and ambiguous fields - a loss date that could be read two ways, a cause description that maps to two different peril codes. A field that fails the classifier does not flow silently into the coverage decision. It fails the step.

Step 3: Confirm coverage. The extracted facts are tested against the policy terms: is the peril covered, is the loss date inside the term, which deductible applies, which limit and sublimit apply, does an exclusion or an endorsement change the answer. Checks: computed and judged, split deliberately. Everything codified in the policy schedule is computed - dates, limits, deductibles, waiting periods, arithmetic. Where the decision turns on reading policy language against a fact pattern, the check is judged: your adjusters annotate pass and fail examples of correct coverage reasoning, Pebble trains a judge on them, and reports judge-human agreement on held-out cases. Where agreement is too low, an adjuster stays in the check rather than being replaced by an optimistic percentage.

Step 4: Value the claim and set the reserve. The run applies the valuation basis the policy specifies, depreciation schedules, agreed repair or replacement pricing, and any applicable fee schedule, then sets the reserve. Check: computed, the gold standard. Do the line items sum to the claimed total. Does the net payable equal the covered loss minus the deductible, capped at the limit. Is the reserve inside the band your policy requires for that severity. This is arithmetic against a schedule, verified by code, not by a model grading its own math.

Step 5: Screen for fraud and referral. The model scores the claim against your referral criteria and flags what belongs with the investigations unit. Check: classified, trained on your historical referral outcomes and scored against held-out examples, so the referral rate and the miss rate are numbers you can read rather than assurances. A claim that trips a referral rule stops here.

Step 6: Authorize the decision and issue the letter. Clean claims route for payment inside the authority limits. Denials, partial denials, and anything above authority route to a named human. The customer-facing letter states the basis and the appeal path. Checks: computed for routing and authority, code confirms the payment amount is inside the authority of whoever approved it and that the claim landed in the queue your matrix says it should. The letter itself is judged against operator-annotated examples of an acceptable explanation. Regulator-facing correspondence keeps a human in the check permanently, and the environment is built to keep them there rather than pretend otherwise.

What happens when a step fails?

The run stops at the failed step, gets fixed, and resumes at that step, not from scratch. If the classifier at step 2 flags an ambiguous loss date, the run halts there. A person reads the notice, the date is corrected, and the run resumes at step 2. Coverage, valuation, and the letter never operated on the wrong date, because the wrong date never got past its check.

Compare that to the unverified version, where a wrong deductible surfaces two months later in a complaint and someone reconstructs what happened from a chat log. In a verified environment, when something goes wrong you get a step number. "Claim 88214 failed at step 3, exclusion check" is a sentence a claims manager can act on in a minute. The conditions that make a check trustworthy enough to sign off on are set out in approved checks.

What does compliance actually get?

A run record per claim: every step, every check result, every human intervention, in order. When a regulator, a reinsurer, or a plaintiff's attorney asks how a specific claim was decided, the answer is the record rather than a reconstruction. Reliability stops being a claim and becomes a percentage read off run history - this many claims, this many clean runs, failures concentrated at these steps.

That distinction is about to matter more. The EU AI Act's high-risk list names risk assessment and pricing for life and health insurance at Annex III, point 5(c) and creditworthiness evaluation at point 5(b). Claims handling is not itself named there. But an insurer running claims on AI sits next door to that perimeter, and the questions a supervisor asks are the same either way: what did the system decide, on what basis, and who could have caught it. A logged chain of model reasoning does not answer those questions. A graded run record does, and the difference is explained in verified agent audit trail.

What do you own afterward?

A dataset of your adjudicated claims, and eventually an open-source model post-trained on it that belongs to you. Every completed run is a worked example of your claims process done correctly, with verified checkpoints at each step. Once the history is deep enough, that dataset post-trains a model you own, running your adjudication at a fraction of frontier API cost per claim, that no one can reprice or deprecate out from under you. When a stronger open base ships, the same run records train its replacement.

The path runs in three stages. First the environment runs on a frontier model against real claims. Then it proves itself: a full audit trail, reliability read off run history rather than a vendor's deck, postmortems that start from a step number. Then you own it.

How does an engagement start?

With a scoping call, and if an environment is the wrong tool for your claims operation, Pebble says so on the call. From there: about a week of discovery inside your systems under your access model - Pebble keeps the step map and none of your data - ending in a written proposal with a fixed price per work package. Then the build, exercised against real claims before it is called done. Then it runs, on your infrastructure or Pebble's, with a retainer.

Claims is one process. The same structure applies to invoice reconciliation in finance and to customer onboarding in compliance.

Ready to see your claims process as a step map? Book a scoping call: [email protected].