Claimpilot Chat
Claimpilot Chat is an AI assistant that lives inside a claims-handling system and talks to the claim on screen. These pages are for the developers who build, run, extend and integrate it.
What it is
The pilot recreates two ClaimPilot claim screens: the UK product's MatterHome and the US product's Claim page, switchable with a flag. Beside them sits an assistant that answers questions about the claim, runs specialist tasks on it, and can be spoken to as well as typed to.
The assistant is grounded in one thing: the claim record. It carries a short brief in its instructions and reads everything else through tools: the policy wording, the diary, the documents, the payments, the financial position. Every answer can show which lookups produced it.
On top of free-form questions it offers 19 capabilities in five groups:
| Group | Capabilities |
|---|---|
| Understand | Summarise claim, Summarise documents, Timeline, Data insights |
| Decide | Validate policy, Reserve estimation, Next actions, Settlement guidance, Litigation risk, Recovery opportunities |
| Protect | Fraud check, Vulnerable customer check, Complaints guidance, QA review |
| Produce | Draft a document, Call assist, Field visit briefing, Handover brief |
| Help | What can you do? |
Each capability is a playbook prompt plus, where it helps, a small deterministic tool that does the arithmetic a model should not: checking whether the policy was in force, listing every deadline, cross-checking payments for duplicates, scanning the diary for vulnerability signals.
The same code, two ways
As a demo. A single Cloudflare Worker serves the React front end, the API and the voice relay. Several hundred synthetic claims, generated against the Davies claims-processing taxonomy with deliberate "gotchas" planted in them, sit in Cloudflare D1 or Neon Postgres.
As a tag in someone else's system. <claimpilot-assistant> is a custom element. A host page hands it the claim it is already displaying, and gets back the same assistant in a shadow root, with no store, no router and no claim of its own to fetch.
What makes it work
- One contract. The Claim document (
packages/shared/src/claim.ts) is the agreement between the generator, the stores, the screens, the tools and every host. Eight fields are required; everything else has an honest empty default. - One seam per moving part. A capability is one object in one file. Prompt text lives only in the prompt catalogue. The model sits behind the
AiProviderport, the claims store behind theClaimRepositoryport. - Safety first, structurally. The safety prompt is assembled before any claim data. Tools are read-only and run server-side against the one claim in the request. Anything inside the record is data, never instruction.
- Offline tests. A scripted model stands in for Gemini, so the whole pipeline is tested without a key, a database or a network.
How these docs are organised
Every claim in the pilot, and every example in these pages, is synthetic. Before the assistant handles real claims, read Security and data protection and Known limits.