The declarations page: the shortest document saying what was bought
In short
A declarations page is the carrier-issued summary of one policy: who is insured, for what period, under which coverage parts, at what limits and deductibles, with which forms attached and for how much premium. It is an index rather than the contract, and its fields fall into 3 groups whose extraction difficulty is predictable.
Key takeaways
- The dec page names what was bought; the coverage form says what those words mean.
- Split the target fields 3 ways — standard, semi-standard, carrier-specific — and route each differently.
- The forms schedule is the most valuable block on the page and the one most often dropped.
- A dec page is issued at a moment; endorsements change the policy without it being reissued.
- Store which dec version was in force on a given date, or you cannot answer what was covered.
A declarations page is the carrier's summary of a single policy: the named insured, the policy period, the coverage parts bought, their limits and deductibles, the forms and endorsements attached, and the premium. It is normally 1 to 4 pages at the front of a policy, and it is the only part of the document specific to this insured rather than boilerplate.
Treat it as an index. The dec page tells you a general liability part exists with a stated aggregate; the coverage form behind it defines what that aggregate applies to, and the endorsements listed change both. An extraction returning dec page fields has captured what was bought, not what is covered.
The target record, field by field
These are the 10 fields worth extracting, each labelled for how standardised it is. Unlike an ACORD application, a dec page has no agreed field order, so that label decides whether a field can be auto-accepted, needs a confidence threshold, or needs a per-carrier template.
| Field | What it holds | How standard |
|---|---|---|
| Named insured | The legal entity or entities the policy covers | Semi-standard — often several entities, and the block position moves |
| Mailing address | Where correspondence goes | Standard, but it is not the risk location and must not be reused as one |
| Policy number | The carrier's identifier for this policy and term | Carrier-specific — format, length and term suffixes are carrier choices |
| Policy period | Effective and expiry dates, usually with a time and a place | Standard in meaning, unstable in format |
| Coverage parts | Which parts are in force, each with its own limit structure | Carrier-specific — the hardest block on the page |
| Limits | Occurrence, aggregate, per-location and sublimits | Carrier-specific — labels and nesting differ, and sublimits often hide in footnotes |
| Deductible or retention | The amount and, critically, the basis it applies on | Carrier-specific and semantically loaded |
| Forms schedule | Every form and endorsement attached, with its edition marker | Semi-standard — reliable identifiers, unreliable layout |
| Premium | Total, often split by coverage part, plus taxes and fees | Semi-standard — the split is carrier-defined |
| Rating exposure | Payroll, sales, area, vehicle or unit counts used to rate | Carrier-specific, often pushed onto a separate schedule |
2 of those 10 rows carry more risk than their size suggests. A deductible must never be flattened into a single number, because a retention behaves differently in a claim — the record shape that keeps them apart is in retention and deductible are not one field. And a form captured without its edition marker is not evidence of coverage, the argument in form numbers and edition dates.
The split that predicts your error rate before you build anything
- Standard fields mean the same thing and look the same everywhere. Dates and addresses sit here. Auto-accept above a single high threshold — teams commonly start near 0.95 and tune from the review queue.
- Semi-standard fields mean the same thing in unstable shapes. Named insured blocks, premium splits and forms schedules sit here. They need field-level confidence and a review queue, and hold most of the available accuracy gains.
- Carrier-specific fields have no reliable shape. Limit structures, deductible bases and rating exposures sit here. They need a template keyed on the issuing carrier, plus an unknown-carrier path that routes to a person rather than guessing.
So a dec page pipeline is not 1 model. It is a classifier that identifies the carrier and form family, a general extractor for the first 2 groups, and a registry of templates for the third — after which the fields still have to land in AMS360, Applied Epic or EZLynx under their names, not yours. Building that registry, and the tooling to add a carrier without a deploy, is ordinary product build work.
Where the page stops being authoritative
A dec page is true as at the moment it was issued. Endorsements change the policy afterwards and most carriers do not reissue the page, so the PDF in the file can be accurate about the policy as bought and wrong about the policy as it stands. Keep 3 dates — issued, effective, superseded — plus a version number, and record which version was in force on a given date. Otherwise what was covered on the date of loss has no answer your system can produce.
That version history is also the evidence when a servicing dispute arrives and nobody can prove what was asked for, the situation in when the client swears they asked for the change.
The declarations page is the table of contents for a contract nobody reads. Extract it as an index, never as an answer.
One boundary is worth stating plainly. Commercial property dec pages routinely reference a schedule of locations rather than listing them, and that schedule is a different document with different failure modes, covered in the statement of values as a schedule you can parse. This page sits in the forms: extraction and classification, part of our insurance and claims software practice.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is a declarations page on an insurance policy?
It is the carrier-issued summary of one specific policy — named insured, policy period, coverage parts, limits, deductibles, attached forms and premium — usually 1 to 4 pages at the front of the policy. Everything else in the policy is standard wording; the dec page is the part specific to this insured and this term.
What is the difference between a declarations page and a policy form?
The dec page says what was bought and the form says what those words mean. A dec page may state a general liability part with a per-occurrence limit; the coverage form behind it defines the insuring agreement, exclusions and conditions that decide whether a loss falls inside that limit. Endorsements then amend the form, and the dec page lists them without restating what they do.
Which dec page fields are hardest to extract reliably?
The limit structure, the deductible basis and the rating exposure. All 3 are laid out however the carrier chooses, with labels, nesting and footnoted sublimits that vary between carriers and sometimes between lines at one carrier. Dates and addresses are close to solved by comparison. Plan for a per-carrier template over the unstable third.
- declarations page
- document extraction
- policy data
- insurance forms
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 AIScanQueue
An AI radiology worklist that flags suspected critical findings on incoming CT, MR and X-ray studies and orders every read by acuity and SLA — so the sickest patient is read first, not FIFO.
Healthcare AIRead next
- The loss run: what it is, and why its valuation date changes the answerA loss run is a snapshot of files that are still moving. Without the valuation date beside them, the numbers on it cannot be compared to anything, including a later copy of themselves.definition
- Statement of values: a spreadsheet pretending to be a policy documentAn SOV is a table whose columns were agreed between a broker and a carrier, not standardised by anyone. Settle the grain and the valuation basis first.definition
- 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
- 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
- Claimants start the online loss report and phone in anywayChannel fallback is measurable. A step-level drop table segmented by device and reporter, joined to inbound calls within the following hour, names the step that sends people to the phone.diagnostic
- 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
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