Claims triage that explains its own decisions
A triage model with a logged override path, a documented model card, and a monthly review session with the claims team that owns it.
- Handling time
- -31%
- Overrides logged
- 100%
- Claims scored daily
- 12k
- Model cards
- 3
The situation
Claims triage was manual and inconsistent. Two adjusters could route the same claim differently, and neither decision was recorded in a way that could be reviewed later.
Constraints
This is a regulated decision affecting individuals, so it was treated as high risk from the first design session. Every automated decision needed a logged reason and a human able to overturn it.
What we did
A triage model scoring 12,000 claims a day, with three model cards covering the components and a documented override path used by the claims team.
The override is not an escape hatch bolted on at the end. It is the primary interface: the model proposes a route, the adjuster confirms or changes it, and the reason feeds the next evaluation cycle.
Governance in practice
When the regulator asked how a decision was reached, the answer took an afternoon rather than a project, because the documentation had been written during the build rather than reconstructed afterwards.
Results
| Measure | Before | After |
|---|---|---|
| Average handling time | 14 days | 9.7 days |
| Claims routed automatically | 0% | 62% |
| Decisions with a logged reason | Partial | 100% |
| Time to answer a regulator | Weeks | Same day |
What we left behind
- A project in the client's own repository, with tests and CI
- Documented definitions with named owners
- Runbooks for every scheduled job, written for a non-engineer
- Two weeks of training for the team taking it over
Other engagements you might want to read
Tell us which number you cannot trust
Send one paragraph about the report that always starts an argument. A data lead, not a salesperson, replies within one business day.



