Cause of loss: the coded field, and why the caller's story is not it
In short
A cause of loss code is a value drawn from a fixed, carrier-owned vocabulary and stored on the claim record. The caller's account of what happened is evidence for choosing that value, not the value itself. Keep them in one field and you get reporting that cannot be aggregated and routing nobody can reconstruct.
Key takeaways
- The narrative is evidence and the code is a key. They belong in different columns with different edit rules.
- A code list is yours, not universal. Confirm values against your own data dictionary before mapping anything to them.
- A stubborn minority of descriptions cannot be coded at notice, because the deciding fact is not in the caller's head.
- Uncoded is a legitimate stored value. Guessed is not, because a guess is indistinguishable from a fact downstream.
- Every automated code assignment needs the sentence that produced it stored beside the value.
A cause of loss code is a controlled value on a claim record — one entry from a fixed list your organisation maintains, saying what kind of event this was. The caller's description is something else: an unstructured account, in their own words, which is evidence for choosing a code. Both belong on the file, in separate fields, with different rules on who may change them.
The distinction sounds pedantic until somebody asks how many escape-of-water losses you had last quarter and 3 teams produce 3 answers. It is the commonest data defect in claims intake, FNOL and triage, and it is created at first touch, not in the warehouse. BuildspaceLabs builds claims software and is not a carrier, broker or adjuster; nothing here is coverage advice.
One field is testimony, the other is an index
- The narrative is append-only testimony. It records what was said, including detail that later turns out to matter. A correction belongs beside it, not over it.
- The code is an index. It exists so claims can be counted, compared, routed and reported. It changes as facts arrive, and each change needs an author and a reason.
- The two disagree often, and that is fine. A roof that leaked in the storm is compatible with 2 or 3 codes, and the disagreement says what to investigate.
One rule follows: never derive a report from free text. If a figure goes to a regulator, an actuary or a reinsurer, it comes from the coded field, deliberately populated.
Turning what the caller said into a value from the list
Mapping is straightforward for most notices and impossible for a stubborn minority. The design question is what happens to the minority.
| What the caller says | Codeable at notice? | Why |
|---|---|---|
| Someone reversed into my car in the supermarket car park | Yes | Collision with a third-party vehicle; the description settles the event type |
| There was a fire in the kitchen after the fryer overheated | Yes | Fire, whatever the ignition source proves to be on inspection |
| Water came through the ceiling after Friday's storm | No | Storm ingress and a failed pipe look identical from below; the deciding fact does not exist yet |
| The laptop is gone from the meeting room | No | Theft, mysterious disappearance and loss are separated by evidence of entry |
| The engine seized on the motorway | Not yet | Mechanical breakdown may not be a covered peril; coding it pre-empts a coverage question |
| The tenant flooded the flat below with a running tap | Yes | Escape of water with a named responsible party; liability is separate |
The negative rows share a pattern: the missing input is not in the caller's head. A 4th follow-up question does not extract a fact the reporter does not have; it produces an irritated caller and a confident wrong answer.
Uncoded is a legitimate value; guessed is not
- Give the code field an explicit pending state, distinct from null. Null means nobody looked; pending means somebody looked and the fact was unavailable.
- Store the evidence with the value: which sentence, which speaker, which channel produced this code, and whether a person or a rule assigned it.
- Route on the pending state rather than on a guess. A file whose cause is genuinely unknown wants a human first.
- Re-code on new evidence and keep the history. First code and settled code differing is normal; being unable to see it is the fault.
- Reconcile monthly. Any code above roughly 15% of volume is usually an other bucket absorbing what the list cannot express.
What each field is permitted to drive downstream
The code may drive queue selection, vendor category, document packs and statistical reporting. With the loss date it decides which reporting period a claim lands in, which is why the three dates a claim record needs and the cause code are usually wrong together. It is also part of the duplicate match key in when one loss opens two claim numbers: the same event reported twice arrives with the same code and date.
The narrative may drive nothing automatically. It informs a person, supports a later coverage position, and is the text a model reads to propose a code — but the proposal reaches the code field only with the sentence that justified it attached. Enriching a cause from an outside source, a weather feed for instance, is a separate governance question: when an outside data feed becomes a rating variable.
Neither field may imply a coverage outcome. A code describes an event, not a decision about the policy, and any score built on it inherits that limit — the boundary in claim severity as a routing input.
The two-field split is a small piece of schema work with a long tail of value, and the kind of scope we take on in MVP and product builds within the insurance and claims practice — usually alongside reconciling the list that AMS360, Applied Epic, the carrier portal and the warehouse each hold a different version of.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is a cause of loss code in insurance?
It is a value from a fixed list, stored on the claim record, describing the kind of event that caused the loss. It exists so claims can be counted, routed and reported consistently. It is deliberately coarse: it says escape of water, not the tenant left a tap running upstairs, which is the narrative field's job.
Is a peril code the same as a cause of loss code?
They are often used interchangeably and are not always the same field. Peril usually names the insured event in the policy wording, while cause of loss is the operational classification your claims system stores. Where a carrier keeps both, mapping between them belongs in a documented lookup rather than in someone's head.
Can a model assign the cause of loss code automatically from the description?
For the clear cases, yes, provided the assignment is stored with the evidence that produced it. The design decision that matters is the ambiguous cases: the system must be allowed to return pending rather than a best guess, because a guessed code is indistinguishable from a confirmed one downstream and gets counted in reports as though a person chose it.
- claims data
- cause of loss
- controlled vocabulary
- claims intake
Read next
- First notice of loss: the fields that turn a call into a workable fileA first notice of loss is not a claim file. It becomes one when it carries enough structure to be routed, clocked and reserved without a call back to the reporter.definition
- Date of loss, date reported, date received: three fields that are not the same fieldOne date decides coverage, one decides whether notice was late, and one starts your service clocks. Collapsing any two of them breaks something you will not notice for months.definition
- Claim severity score: a routing input, not a reserve and not a decisionA severity score exists to decide which queue a new claim joins and how fast. Everything a licensed person is accountable for stays outside its remit.definition
- The damage photos come back too dark, too close, or missing the one angle the adjuster needsSplit your photo rejections by capture path and device class before redesigning anything. In-app camera and gallery upload fail for entirely different reasons and need different fixes.diagnostic
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