An AI claims adjudicator, a blind cross-check, and a human at every gate

The first model call writes worked reasoning in plain text: causation per item, category, lifespan, depreciation, the repair-or-replace test, exclusions and the final status. A second call transcribes that reasoning into a schema-constrained record with fixed enums (twenty item categories, and closed sets of bases, confidences and statuses) and is told not to re-adjudicate. The thinking and the structured copy are stored separately, so the structured output cannot round a figure differently from the reasoning it came from.

Before the model, each claim is checked for a duplicate invoice by hashing vendor, invoice number and amount, and against a rate band (advisory, and flagged only on the high side) and prior approved claims at the same property over 183 days are fetched, with a guard so a blank property key never matches everything. After it, a deterministic layer works in integer cents: contents plus dwelling must equal the total, line items must equal the total, allocation buckets must equal the total within a cent, a per-reservation cap applies, and no money may attach to an item the model has low confidence caused. A claim that fails the maths is zeroed and set to an error state with no automatic retry; one that trips a cap or a confidence rule is forced to escalate, with the proposed figures kept separately so a person sees what the model wanted.

Once a decision has passed the maths, a larger Claude model reads the same claim payload from scratch, without the first answer. Only then are the two compared on judgment fields alone: status, and per item the category, age, basis and causation confidence. Money amounts are deliberately not compared, because the first layer's arithmetic covers them and a rounding difference is not a disagreement. A mismatch holds the claim and blocks payment at the ledger gate.

Each fragile step has its own handler. The first failure leaves the claim to be retried on the next poll; the second becomes a hold, because an unverified decision must never look verified. A run counter incremented on pickup caps first-pass attempts at two, so a crash cannot loop. Every notifier (the team feed, the review card, the approval announcer and the billing and receipt steps below) ticks a stamp on the record after it sends and excludes stamped records from its own watch, so nothing posts twice.

Once the approver decides, four more scenarios carry the claim forward. A billing notice emails the full record (requested, authorised ceiling and charged amounts, how it was paid, who is owed what) and posts a one-line pointer in the finance channel; it warns that an approval is a ceiling, not a payment, until a receipt exists. When the company itself buys the replacement, a receipt request goes to the regional manager in their market's channel, with a fallback channel for anything unmapped. The owner's letter then passes two gates: the draft is posted for the approver and the operations lead to approve in the thread, marked DRAFT NOT SENT, and a final gate asks the approver alone for the green light, only once a readiness formula in Airtable says everything else is in place.

The approver's email originally carried one-click approve and deny links. A mail scanner followed them and decided claims on its own, so the links were removed and replaced with a link to a queue where a person sets the status. The announcer also holds back an approval until the payout recipient is settled, and the owner-letter gate warns loudly if it is not, so no message about money can be ambiguous about who is owed what.