The claim diary: a scheduling primitive, not a to-do list
In short
A claim diary is the set of dated obligations attached to a claim file: each entry names a due date, a reason, an owner, an escalation target and the condition that satisfies it. That last field separates a diary from a reminder list. An entry the system cannot evaluate closes only when somebody asserts it is done.
Key takeaways
- A diary entry is a dated obligation bound to a file: date, reason code, owner, escalation target, satisfaction condition.
- If the system cannot evaluate the satisfaction condition, the entry is a reminder and closes on assertion alone.
- Limitation and statutory-clock entries must never roll forward without a second person seeing the move.
- Count entries closed with no file change. That ratio is the health measure only a diary makes available.
A claim diary is the set of dated obligations bound to a claim file. 1 entry is 1 obligation: a due date, a reason code, an owner, an escalation target if the date passes, and a condition that says when it has been met. Adjusters talk about being on diary for a file; the useful reading is that the file carries scheduled work, as a record rather than a memory.
One distinction decides whether any of it functions. An entry whose satisfaction condition the system can evaluate closes itself when the work happens; an entry without one closes when somebody says so. They look identical on screen. Only the second produces the file everyone agrees was on diary and nobody touched for 7 months.
The fields an entry needs before it can close itself
| Field | What it carries and why it is load-bearing |
|---|---|
| File and coverage part | Binds the obligation to 1 claim and, on multi-coverage losses, to the part it belongs to |
| Due date and origin | The date, and whether a rule, a statute, a court date or judgement produced it |
| Reason code | Why it exists, from a closed list. Free text here is why diaries cannot be reported on |
| Owner | A person or queue, reassigned with the file rather than left pointing at a leaver |
| Escalation target | Who sees it if the date passes untouched, and after how long |
| Satisfaction condition | The observable that closes it: document received, payment issued, field changed |
| Set-by | Rule id for a generated entry, user id for a hand-set one |
Reason code is the field most often left open. A free-text diary cannot answer how many files wait on a third party, the most useful question a claims manager can ask of a caseload. A closed list of 15 to 30 codes covers most books and makes the diary reportable.
Conditions a system can check, and conditions that need a person
| Entry reason | Satisfaction condition | Machine-checkable |
|---|---|---|
| Awaiting police or fire report | Document of that type attached to the file | Yes |
| Awaiting signed proof of loss | Signed document received and logged | Yes |
| Estimate review due | Review record against the current estimate version | Yes |
| Reserve review due | A reserve entry after the trigger, or a logged no-change | Yes, if no-change is recordable |
| Contact the insured | Contact logged with an outcome, not merely attempted | Partly |
| Assess liability position | A written position on the file | No — a person decides |
The reserve row repays attention. An entry closeable only by a reserve movement pressures adjusters into moving numbers they believe are right, so no-change must be recordable as an outcome. That is the mechanism behind reserves set once and never moved: the trigger existed, and closing it honestly was harder than closing it quietly.
Generated entries and hand-set entries age differently
- A generated entry belongs to a rule. It carries the rule id and is not hand-editable: if it is wrong, the rule changes, or every file that rule touches gets the same wrong entry.
- A hand-set entry belongs to a person and a judgement. It can move, but the move is an event with a reason, not a silent date edit.
- The first entries come from the notice, so they inherit whatever it lacked — the fields argued for in what a loss notice must carry to become a file.
- Where a jurisdiction sets acknowledgement or response timeframes, those dates are not the adjuster's to move. Confirm the wording in the relevant insurance code rather than hard-coding a remembered number.
The entries a roll-forward must not be able to touch
Most entries can legitimately move: the report has not arrived, look again in 10 days. 2 kinds cannot. A limitation or prescription date is a hard external boundary, and rolling past it destroys a right rather than deferring work — which is why the preconditions in what makes a file referable to subrogation sit on a clock. Statutory response dates behave the same way.
A diary schedules the decision, it never makes it
The diary is a scheduling layer, and the line has to be explicit because automation drifts across it. An entry may prompt a reserve review; it may not propose a figure. It may flag that recovery screening is due; it may not close an opportunity as unviable. It may require a coverage position; it may not draft one accepted by default when nobody responds.
A reminder tells someone to do something. A diary entry states an obligation, names its owner, and knows whether it was met.
The measure this unlocks is entries closed with no corresponding change on the file — the closest direct read on whether a diary works, and what turns an untouched-file assertion into a countable one, the category question in what claims leakage counts and what it cannot. The wider caseload picture sits across the claims handling and recovery topic. Building the generator, escalation and audit trail is scope we take under AI agents and automation for insurers and MGAs, with the constraints in AI agents in production.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is the difference between a claim diary and a task list?
A diary entry is bound to a file and carries a satisfaction condition; a task is bound to a person and carries a completion tick. The difference shows when someone leaves or a file is reassigned: diary entries move with the file and keep their obligations, while a task list walks out of the door with its owner.
How often should a claim be on diary?
Frequency is the wrong control — set entries by obligation, not by interval. A file waiting on a third-party report needs an entry timed to when that report could realistically arrive, not a 14-day touch producing a note that says still waiting. Where a book needs a floor, express it as a maximum period without a file-changing event.
Can a system create and close diary entries without an adjuster?
It can create them from rules and close them on observable evidence, such as a document arriving or a payment issuing. What it should not do is close an entry whose condition is a judgement — a liability position, a coverage decision, a contested estimate. Split reason codes into machine-satisfiable and person-satisfiable at design time; retrofitting that line means auditing every entry already closed.
- claims handling
- adjuster workflow
- diary management
- workflow design
The work behind this page
Builds from our portfolio that this page draws on.
AP Copilot
An AI accounts-payable copilot that reads invoices, matches them to POs, and routes clean approvals
FintechAskVault
An AI internal knowledge-search platform that answers employee questions from your own docs — grounded in citations, with knowledge gaps surfaced and deflection tracked.
Productivity AIRead next
- The oldest and newest files move; the ones in the middle of a caseload stopNew files move because a clock is running and old files move because someone escalated them. The band in between has no forcing function at all, and that is where inventory quietly accumulates.diagnostic
- Reserves get set in the first week and never move until the file closesA reserve that has not moved in nine months is not a stable claim. It is an unasked question, and the repair is a set of file-event triggers rather than a better first estimate.diagnostic
- Subrogation referral: the facts a file needs before recovery is possibleRecovery teams argue about which files deserve attention. The argument disappears once referability is written as 4 conditions, each pointing at a field.definition
- Claims leakage: what the term actually counts, and what it quietly cannotLeakage is a subtraction where 1 of the 2 numbers came from a reviewer imagining a file that never happened. The standard is part of the answer.definition
- Fraud indicators fire on a third of the book and nobody reads them any moreInvestigators ignoring alerts is the symptom. The finding underneath is almost always that nobody can say what any single indicator's firing rate buys in accepted referrals.diagnostic
- Cause of loss: the coded field, and why the caller's story is not itThe loss narrative and the coded cause of loss are two fields with two jobs. Conflating them gives reporting nobody trusts and routing nobody can explain.definition
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation