Claim bundles arrive already sorted.Claims data stays in your network.
FNOL bundles and underwriting submissions, split, read and routed on your own servers. Your team checks what it isn't sure of. You own the code.
No claim page leaves your network.
Every field keeps its source page.
Open-weight models on your hardware, no outside AI service, and no copy on our side. The audit record is written as the work happens.
- 01
Bundles arrive
FNOL bundles, submissions and broker email, from the mailboxes, portals and SFTP drops they already land in.
- 02
Split, classified, read
Each page is labeled, the bundle is split into documents, and fields are read per document type, so a conflicting estimate stays separate.
- 03
Adjuster review
A doubtful field goes to a person beside its source page. The categories you name, such as total loss or bodily injury, always do.
- 04
Routed to your claims system
Approved fields land in the claims and policy systems you already run, through an interface they already accept.
Every routed field records its source page, its confidence, the model version, and who approved it.
The same system, already running.
At an insurer and at a lender.
Both run inside the client's own network on open-weight models, and both reached production thirteen weeks after kickoff.
Claim bundles a month
Split, classified and extracted for a European P&C insurer, with 63% of documents routed untouched. Underwriting intake followed on the same stack.
Read the case73%Of loan fields post on their own
At 98%+ precision for a US commercial lender, each with a per-field audit trail examiners can replay. No data leaves its network.
Read the caseThirty minutes. You leave knowing whether the work is worth automating.
Three queues your team sorts by hand.
It does the sorting, they make the calls.
None of it decides coverage or liability. It takes the sorting and the keying, and a person signs off on anything unclear.
FNOL and claim bundles
A form, phone photos, an estimate, a police report and a medical bill in one PDF, split into documents and read type by type. Adjusters get fields, not a pile.
Underwriting submissions
Applications, loss runs, schedules of values and broker correspondence, read into one submission record before the underwriter opens the file.
Estimates and invoices
Repair estimates, supplements and invoices, read line by line. When two documents disagree on a material amount, the claim goes to an adjuster.
The questions your review will ask.
Five answers your team can test itself.
Where claims data goes, how medical records are held, what it decides, how audits replay it, and what it touches in your stack.
Nowhere outside your network. It runs on your hardware or private cloud, calls no outside AI service, and we keep no copy of anything it reads.
Fields are tagged personal or medical in the schema, injury documents go to a separately controlled queue, and derived files follow the claim's retention clock.
No. It informs those calls and never makes them. Total loss, bodily injury, fraud indicators and litigation can be set to always reach a person, whatever the confidence.
Yes. Every page, label, field, confidence, threshold in force and reviewer action is stored, so any routed value can be rebuilt months later.
One process, agreed before we start, written into your claims system through an interface it already accepts. Code, models and documentation are yours on delivery.
Start with one intake queue.
Or with two weeks of looking.
Fixed scope, fixed price, and the code is yours at the end. We stay until your team runs it, so you are never tied to us.
Automate one queue
Claims or submission intake, measured in handling time per bundle and documents routed untouched. We stay until your team runs it day to day.
A two-week review
We go through your claims and underwriting intake and tell you which queues are worth automating, and which are not.
“Bring the intake queue your adjusters complain about most. On the first call we go through what lands in it and say whether it is worth automating.”