The Shape of the Domain
Insurance claims for utility-scale energy assets have a very particular shape, and the platform had to model it faithfully rather than approximately.
Every claim belongs to one of 300+ special-purpose legal entities, each holding its own assets and policies. Every claim carries two parallel financial tracks: Material Damage (the physical assets) and Loss of Profit (the generation revenue lost during downtime). Each track accumulates its own estimates, broker assessment, surveyor assessment, and payments — and settlement depends on both tracks being complete.
And the process itself is strictly linear: thirteen stages from intimation to paid, with no skipping, and controlled withdrawal available until the final payment lands.
Data Model: Objects, Not Tables Bolted On
The platform models the domain in DocQ Object Management: claims, entities, policies, and the per-track financial records are structured objects with real relationships. A claim references its entity; its two financial tracks reference the claim; every assessment and payment row references its track.
This is the part that spreadsheets could never hold: referential structure. A Loss-of-Profit assessment can't exist detached from its claim, and a claim can't reference an entity that doesn't exist. The data model enforces what the workbook could only hope for.
Lifecycle: Thirteen Gates
The claim lifecycle is implemented as a strict stage machine. Each of the thirteen stages defines mandatory fields that must be present before the claim can advance — an unassessed financial track or a missing surveyor report simply blocks the gate. Transitions are recorded with who, what, and when.
Two properties were non-negotiable in the design:
- Linearity — stages advance in order, so a claim's stage is an honest statement of its progress.
- Withdrawal — a claim can be withdrawn at any stage before payment, leaving its full history intact.
The gating turns process discipline from a management aspiration into a system property. Nobody has to remember what stage seven requires; stage seven refuses to proceed without it.
AI Document Intake
Claim documents arrive unstructured: surveyor reports, broker assessments, payment advices, correspondence. The intake path classifies each incoming document automatically, then runs DocQ's zero-training extraction to pull structured fields — assessed amounts, deductibles, dates, policy references — directly into the claim's records.
The extracted values don't float free. Each lands on the correct financial track of the correct claim with its source document attached, so every number on the claim is one click from the evidence behind it.
The Portal: Roles from Teams
The insurance, finance, and site teams work through a dedicated claims workspace served from the DocQ instance itself — same origin, same session, no separate identity to manage. Authorization derives from DocQ teams: a user's team membership maps to a role, and the role scopes exactly what they can see and do. Site users see their sites' claims; the insurance team sees the portfolio; finance sees what finance needs.
There's no second user directory and no synchronization problem — access control lives where the users already live.
Audit as a By-product
Because everything — stage transitions, field changes, document arrivals, extractions, decisions — happens on platform objects and workflows, the audit trail assembles itself. The complete provenance of any claim, from first intimation to final payment, is a query rather than a reconstruction.
That's the quiet architectural lesson of the build: when the process runs inside the system of record, compliance stops being a separate activity. The platform doesn't document the process. The platform is the process.
