Architecture and data protection
How it fits together, what it costs to run, and how the data is protected
Components
The system is a small web application with a background worker. Each part has one job and a defined boundary, so the claims data source or mail system can change without rewriting the rest.
| Component | Job | Notes |
|---|---|---|
| Mail connector | Watch the shared mailboxes, fetch messages and attachments, read the folder tree, apply categories and flags, move messages, save drafts | Microsoft 365 through Microsoft Graph. Separate read-only and read-write connections; see below |
| Work queue | Hold each email's progress through the pipeline; retry on failure | An email is never lost if a step fails; it stays in the inbox |
| Document preparation | Clean email text, convert attachments, extract references | Rules only: text extraction and optical character recognition for scans. The original PDF is passed to Claude only if the email goes to the fact extractor. |
| Rule editor | Edit, dry run, test, publish and roll back rules | See the rule editor page. Dry runs use the read-only connection only. |
| Rules engine | Recognise known senders and templates, match claims by reference, and turn facts into category, folder, handler and review flag | Runs first and last for every email. Plain, versioned rules a supervisor can read. Given the same facts, always gives the same answer. |
| Fact extractor | Only for emails the rules engine could not settle: ask Claude to read the unstructured text and return facts in a fixed structure | The only component that talks to Claude. Returns facts, never decisions. |
| Claims data adapter | Answer "which claim is this?" and "tell me about claim X" | Mock data for the demonstration; SiteView export or interface later |
| Medical report reader | Claude extracts injury facts; rules classify, look up tariff amounts and run cross-checks | Real-time for new reports, batch for backlog |
| Web application | Review queue, decision view, corrections, dashboards, settings | Staff sign in with their Microsoft 365 accounts |
| Audit log | Record every decision, action and correction | Append-only; includes model, rules and prompt versions |
Technology
PHP 8.4 and MySQL, server-rendered pages that work without JavaScript, following Custodia's usual approach of minimal dependencies. Claude is called through Anthropic's Messages interface. Anthropic's guidance is to use their official PHP library rather than hand-written HTTP calls; that is one external dependency, installed with Composer, and we think it is justified here because it handles retries, streaming and error types correctly.
Microsoft 365 connection
Postbot connects to One Claim's Microsoft 365 through Microsoft Graph, Microsoft's supported programming interface for mail. Nothing is installed on staff computers and no mailbox passwords are held.
| Item | Proposal |
|---|---|
| Registration | An application registered in One Claim's (or the group's) Microsoft Entra ID, owned by their administrators, who grant consent and can revoke it at any time |
| Two connections | Read-only (mail read permission) for dry runs, shadow running and the accuracy test. Read-write (mail read and write) is only created when One Claim moves to assisted filing. Until then Postbot has no technical ability to change the mailbox. |
| Mailbox scope | Both connections restricted to the named shared mailboxes using Exchange Online's controls for application access, so they cannot read any other mailbox in the tenant |
| Credentials | Certificate-based, not a shared secret; stored on the server outside the web root; rotated yearly |
| New mail | Microsoft Graph change notifications tell Postbot when mail arrives; a check every few minutes catches anything a notification missed |
| Folders | The folder tree is read from each mailbox and kept in step, so the rule editor offers real folders and warns when one is renamed or removed |
| Actions (read-write only) | Move to folder, apply an Outlook category ("Category 1", "Category 2", email type), set a flag, save a draft reply in the shared mailbox's drafts. No send, forward or delete permission is used by the code, and sending is not built. |
| Staff corrections | Changes to the folder of an email Postbot filed are detected and recorded as corrections |
| Several mailboxes | Each mailbox is configured separately, with its own rule sets if needed |
| Limits | Microsoft limits the rate of requests per mailbox; the connector backs off and retries, and email waits in the inbox rather than being lost |
Which shared mailboxes are in scope, and who in One Claim or Specialist Risk Group IT can register the application and grant administrator consent?
Data model
The main records the system keeps. Facts and decisions are stored separately, which is what allows a rule change to be dry run over thousands of emails without calling Claude again.
| Record | Holds | Kept for |
|---|---|---|
| Mailbox | Connection, folder tree, which rule sets apply | Life of the system |
| Microsoft 365 identifiers, sender, received time, thread, cleaned text, extracted references | One Claim's retention period | |
| Attachment | File (encrypted), extracted text, page count | One Claim's retention period |
| Fact set | Facts for one email or report, each with confidence and evidence; the model and extraction instruction version that produced them | As email |
| Decision | Type, category, claim, folder, handler, review flag; the rule version and the rule that made each part; whether live or dry run | Audit period agreed with One Claim |
| Action | What was done in the mailbox and when (move, category, flag, draft) | Audit period |
| Correction | Who changed what, from and to | Audit period |
| Rule set version | All rules in a version, author, approver, notes, dry-run results, publish and retire dates | Permanently |
| Test case | Email reference, expected outcome, reason, who set it | Until retired |
| Dry run | Scope, rule version tested, results and differences | 12 months, suggested |
| Claim (cached) | Reference, parties, registrations, client, handler, status from SiteView | Refreshed; not a system of record |
| Medical report | Report, injuries with groups and prognosis, tariff lookup, flags, handler corrections | One Claim's retention period |
| Audit event | Every sign-in, setting change, publish, rollback and export | Audit period |
Use of Claude
Design rule: where a decision can be made deterministically, it always is. Inference is used only for tasks that cannot be done by a fixed rule, which in practice means reading unstructured text: free-written emails and letters, scanned documents, and medical reports. Claude's output is a set of facts with evidence. Every decision (category, folder, handler, claim match, tariff group, tariff amount, flags, counts) is made by code from those facts.
This keeps decisions consistent, testable and explainable, costs less, and means the system keeps working for the rule-decided share of email if the Claude service is unavailable.
- Model: we propose Claude Opus 5 as the starting point for both email triage and medical reports. Once there is a labelled test set of One Claim's real email, we will measure whether a cheaper model (Claude Sonnet 5 or Claude Haiku 4.5) gives the same Category 1 recall for triage. Switching is a cost decision for One Claim, made on measured results.
- Structured output: facts come back as data matching a fixed schema, each with a confidence and the passage it came from. The software validates the structure and checks facts against known data (for example, a reference Claude reports must exist in the text and in the claims data) before using them.
- Tools: kept to a minimum. Claim candidates found by rule are passed in with the request, so Claude does not need to search for them. It has one read-only search tool for the case where no candidate was found, and no tool that can act on email.
- Prompt caching: the extraction instructions and worked examples are the same for every email, so they are cached by Anthropic between requests, which reduces cost and response time.
- Citations: for medical reports, Claude cites the page and passage behind each extracted fact.
- Batch processing: backlogs of medical reports go through Anthropic's batch service, which costs half the normal rate and returns results within 24 hours.
What Claude sees and returns
For an email the rules could not settle, Claude is given the cleaned email text, the attachments, the references the rules already found, and any claim candidates already matched. It has one tool:
| Tool | Input | Returns |
|---|---|---|
search_claims | Names, places, dates or descriptions Claude has read in the text | Candidate claims. Offered only when the rules found no candidate. The match is still confirmed by rule. |
It returns facts only. An illustrative example with invented data:
{
"email_type": { "value": "credit_hire_notification", "confidence": 0.93,
"evidence": "\"we confirm our client has been provided with a replacement vehicle\"" },
"hire": { "ongoing": true, "start_date": "2026-09-18", "daily_rate": 68.50,
"evidence": "attachment p1: \"Hire commenced 18/09/2026 ... £68.50 per day\"" },
"deadline_text": null,
"injury_mentioned": { "value": false },
"complaint_or_dissatisfaction": { "value": false },
"vulnerability_indicators": [],
"parties": [ { "role": "credit_hire_company", "name": "Example Hire Ltd" },
{ "role": "third_party_driver", "name": "J. Example" } ],
"claim_identifiers_in_text": [ { "type": "registration", "value": "AB21 CDE" } ]
}The rules engine then decides: email type credit hire + hire ongoing gives Category 1; the registration matches claim OC-24-01873 in the claims data; the folder comes from the filing table for that client and type; the reply comes from the credit hire acknowledgement template. Each of those steps is logged with the rule that made it. The final schema will be agreed once One Claim's email types and folders are known.
Running costs
Claude is paid per use, by the amount of text read and written, measured in tokens (roughly four characters of English per token). Anthropic's published list prices at the time of writing, in US dollars per million tokens:
| Model | Input | Output | Role here |
|---|---|---|---|
| Claude Opus 5 | $5.00 | $25.00 | Proposed default |
| Claude Sonnet 5 | $2.00 | $10.00 | Candidate for triage, if accuracy holds |
| Claude Haiku 4.5 | $1.00 | $5.00 | Candidate for simple first-pass sorting |
Email: only emails the rules cannot settle go to Claude. An email that does might use around 6,000 input tokens and 600 output tokens: about 4.5 US cents on Claude Opus 5 before caching. At an assumed 300 emails per working day, if half need Claude, that is roughly $150 a month; if all did, roughly $300. The share decided by rules should rise over time as corrections become rules. Caching and short emails bring the cost down; long attachments push it up.
Medical reports: a 12-page report might use 30,000 input tokens and 4,000 output tokens: about 25 US cents on Claude Opus 5, or about 12 cents through the batch service. A backlog of 2,000 reports would be in the region of $250 to $500.
These figures depend entirely on One Claim's real volumes and document lengths (Q2, Q12). We will report actual cost per email from the accuracy test. Hosting and support are separate.
Data protection
Claim correspondence contains personal data about drivers, claimants and witnesses. Medical reports contain health data, which is special category data under UK data protection law. We suggest the following, for One Claim and Specialist Risk Group's data protection lead to review.
- Impact assessment: a data protection impact assessment before any real data is processed. We will provide a draft covering data flows, retention and risks.
- Roles: One Claim (or its insurer clients) as controller; Custodia as processor if we host it; Anthropic as a sub-processor. Contracts to reflect this.
- Anthropic account: for live use, the API key should belong to One Claim's own Anthropic organisation, under Anthropic's commercial terms, so One Claim holds the contract, the billing and the data relationship directly. The demonstration can run on a Custodia key using invented data only.
- Training: Anthropic's commercial terms state that data sent through the API is not used to train its models. One Claim should confirm this against the current terms as part of its review.
- Retention at Anthropic: Anthropic offers zero data retention arrangements for eligible organisations, subject to agreement. We recommend One Claim asks for this for medical report processing.
- Where processing happens: Anthropic's interface lets the caller choose where processing takes place from a set of regions. Claude is also available through Amazon Bedrock, Google Cloud Vertex AI and Microsoft Foundry, which may suit if Specialist Risk Group already has agreements and UK or European data commitments with one of these. We will confirm the options available at the time of build.
- Minimisation: only the email and attachments being triaged are sent, plus the claim summary Postbot looks up. We do not send whole claim files.
- Retention locally: Postbot keeps decisions and audit records; copies of email content and attachments are kept only as long as One Claim's retention policy allows, then deleted automatically.
Security
- The API key is held on the server, outside the web root, never in a browser. Separate keys for demonstration, test and live, each with a monthly spend limit set in Anthropic's console.
- Mailbox access uses an application registration restricted to the named shared mailboxes, not to the whole Microsoft 365 tenant, and is read-only until assisted filing is approved.
- Staff sign in with Microsoft 365 accounts. Roles: triage, handler, supervisor, administrator.
- All traffic encrypted; stored attachments encrypted at rest.
- Email content is treated as untrusted input. The model's output is checked against a schema and rules before any action.
Hosting
The demonstration runs on Custodia's server under this site. For live use there are two realistic choices, and the right one depends on Specialist Risk Group's IT policy:
Custodia hosted, in the UK
- Fastest to set up
- Custodia manages updates and monitoring
- Needs group approval as a supplier handling claim data
Within Specialist Risk Group's environment
- Data stays within group infrastructure
- Group IT controls access and backups
- Longer to set up; needs group IT time