Fitting Into an Existing Claims Workflow

TL;DR — We separate unstructured document ingestion from our mathematical prediction models to limit latency and prevent hallucinations. The resulting forecasts are pushed via API directly into the existing claims system, eliminating context switching.

The fastest way to kill a new piece of claims software is to ask an adjuster to log into it. Claims professionals live in their core systems. They are evaluated on cycle times and resolution metrics, not their willingness to adopt third-party applications. If a tool requires manual data entry or dragging a 3,000-page PDF into a separate browser window, it fails immediately. Building Canotera meant accepting this reality. We are a forecasting platform for insurance claims and litigation. Our job is to deliver calibrated settlement ranges and reserve deltas on day one. To do that, the system must operate entirely in the background, treating the existing claims workflow as the master environment.

Insurance core systems are transactional databases. They excel at recording policy limits, tracking payments, and enforcing compliance. They are not built to read unstructured medical files or run complex geometric machine-learning models against historical litigation data. Bridging this gap requires a pipeline that respects the boundaries of the system of record while offloading the heavy computational lifting. We designed our architecture around a strict separation of concerns. The core system manages the state of the claim. Canotera manages the analytical workload. Core systems are rigid by design. Changing a schema or adding a new database table in a legacy deployment takes months of IT steering committee meetings. By communicating via a flexible REST API, we decouple the analytical engine from the slow release cycles of the system of record.

The Ingestion Pipeline

The process begins with ingestion. We integrate directly with the carrier's document management system or data lake via secure API or encrypted SFTP. When a new document arrives, a webhook triggers our ingestion service. This is where the heavy lifting starts. We run optical character recognition and parse the raw text. Generative AI reads this unstructured mass. We use large language models strictly for reading and structuring, never for prediction. The AI identifies the parties, categorizes the injuries, flags specific legal theories, and maps the timeline of events.

Processing thousands of pages of unstructured text introduces significant latency. Real-time inference on a massive medical file is mathematically and financially impractical. We handle this through asynchronous processing. When an adjuster opens a newly assigned file, our pipeline has already run. If new correspondence is added to an existing claim weeks later, we process the delta. Re-reading the entire historical file every time a new motion is filed wastes compute resources and delays the output. We update the structured schema with the new facts and pass it to the forecasting engine. This requires strict state management. We hash incoming files and compare them against the existing document repository for that specific claim. If a law firm sends the same 500-page medical file three times, our ingestion layer recognizes the duplicate hashes and drops the redundant payload before it hits the expensive OCR and language model layers.

Structuring the Forecast

Extracting facts is only the prerequisite. The actual prediction happens in a completely separate layer. We pass the structured schema to our mathematical and geometric machine-learning models. These models are trained on large volumes of resolved cases with known outcomes. They map the geometry of the new claim against historical precedents. Because the Gen AI is kept out of the prediction layer, we eliminate the risk of hallucinated settlement values. The output is strictly tied to historical data.

The resulting forecast is highly specific. We calculate a calibrated settlement range rather than a single point guess. We quantify the probability of the file escalating to severe litigation. We identify comparable resolved cases and calculate a specific reserve delta versus the current reserve set by the adjuster. These metrics give claims managers the data they need to allocate defense spend and set realistic reserves immediately. Facing social inflation and third-party litigation funding, early detection of nuclear verdict potential is the only defense carriers have. Reserve volatility destroys balance sheets. Setting the right number early changes the trajectory of the file.

Presenting this data requires exact traceability. Claims professionals negotiate based on hard evidence. If a model suggests a high settlement range based on a specific spinal injury and a history of aggressive plaintiff counsel, the adjuster needs to see the proof. We map every driver behind the forecast directly to the source documents. The API returns the specific page and paragraph where the injury was mentioned or the legal threat was made. The adjuster clicks the citation and sees the raw text. Black box models fail in insurance because they demand blind trust. Traceability by design forces the system to show its work. If the math model increases the escalation probability due to a specific co-morbidity, the interface highlights the exact physician's note. This allows the adjuster to verify the finding and use it in a negotiation.

Security and System Integration

Claims files contain highly sensitive personally identifiable information and protected health information. Security cannot be an afterthought patched on before deployment. Our infrastructure isolates data at the tenant level. The mathematical models trained on resolved cases operate independently of the ingestion pipeline handling active, sensitive files. We encrypt data in transit and at rest, maintaining strict access controls tied to the carrier's identity provider. If an adjuster lacks permission to view a specific class of files in the core system, they cannot query that data through our API.

The final step is pushing the forecast back into the workflow. We deliver the outputs via API directly into the core system interface. The settlement range, escalation flags, and comparable cases appear as native fields or embedded components exactly where the adjuster already works. This requires careful payload design. Our API responses are structured to match the data types expected by the carrier's system, minimizing the middleware translation required by their IT teams. We provide the analytical depth of a dedicated platform without the friction of context switching. Software adoption fails when engineers ignore the daily reality of the end user. We built this platform to do the reading, run the math, and deliver the answer exactly where it is needed.

A forecast is useless if it lives in a dashboard nobody opens.