From Demo to Deployment: Onboarding a Carrier

TL;DR — To deploy forecasting models effectively, carriers must separate document structuring from mathematical prediction, use asynchronous webhooks to manage compute load, and integrate calibrated settlement ranges directly into the adjuster's core system.

A sales demo runs on pristine, curated data. The vendor uploads a perfectly formatted PDF and the system instantly returns a clean result. Real claims environments run on legacy mainframes, corrupted files, and handwritten medical notes scanned upside down. Transitioning an insurance carrier from a pilot to full production deployment exposes the gap between software that looks good and software that actually works. The first technical hurdle is always ingestion. Carriers possess massive volumes of data, but it is trapped in unstructured formats. A single complex bodily injury claim often contains thousands of pages of pleadings, medical records, police reports, and correspondence. Getting this data out of a core claims system and into our pipeline requires a pragmatic approach to API design. We provide endpoints that accept raw payloads directly from the carrier's document management system. We handle the heavy lifting of deduplication, text extraction, and initial parsing before the data ever touches a model.

Processing these massive payloads requires strict architectural boundaries. We separate the act of reading from the act of predicting. Generative AI is highly effective at language comprehension. We use it exclusively to read and structure the case file. The pipeline extracts timelines, identifies plaintiff counsel, notes specific injuries, and parses venue details. It builds a structured, deterministic representation of the claim. It does not guess the outcome. Mixing large language models with numerical forecasting introduces hallucinations and destroys auditability. We avoid this fundamental error by design.

Connecting Unstructured Text to Mathematical Models

Once the GenAI pipeline structures the raw documents, the data flows into our prediction engine. This is a separate system built on mathematical and geometric machine-learning models. These models operate in high-dimensional spaces, mapping the structured facts of the new claim against historical patterns of resolution. They are trained strictly on large numbers of resolved cases with known outcomes. This separation of concerns ensures that the forecasting mechanism remains grounded in actual settlement data. It prevents the volatility inherent in generating text from contaminating the mathematical rigor required for financial forecasting.

The output of this geometric engine is deliberately calibrated. Point estimates fail in litigation because litigation is inherently uncertain. We generate a settlement range and an escalation probability. We also surface comparable resolved cases and calculate a specific reserve delta against the carrier's current reserve. The engineering challenge is making these numbers completely traceable. Traceability is hardcoded into our data model from the moment of ingestion. Every driver behind a settlement range is linked back to the exact page and paragraph in the source documents. If the model flags a high escalation probability due to a specific comorbidity or a history of aggressive tactics by the plaintiff's firm, the user interface surfaces the exact medical record or pleading. This requires maintaining a rigorous index of document pointers throughout the entire processing pipeline. We do not expect claims professionals to trust a black box. We expect them to verify the evidence.

Securing the Pipeline and Integrating the Workflow

Handling thousands of medical records and legal pleadings triggers strict security requirements. Carrier onboarding involves deep infosec scrutiny. We architected Canotera around absolute tenant isolation. Data from one carrier is never exposed to another, and model weights are not shared across boundaries. All data in transit and at rest is encrypted. We maintain comprehensive audit logs for every API call, ensuring that compliance teams can track exactly who accessed what and when. Security in claims data is not a compliance checkbox. It is the baseline requirement for operating in the space.

Latency and system load are practical constraints during deployment. Reading a 5,000-page file requires significant compute overhead. If we processed this synchronously, we would tie up connections and eventually time out the carrier's core system. Instead, we use an asynchronous webhook architecture. The carrier pushes the documents to our ingestion endpoint and immediately receives a standard accepted response. Our system queues the job, scales the necessary compute resources to process the text, runs the prediction models, and fires a structured JSON payload back to the carrier's system when the analysis is complete. This keeps the carrier's infrastructure fast and responsive.

Once deployed, the engineering job shifts to monitoring. Claims environments are not static. Plaintiff tactics evolve, and judicial environments shift. We monitor the incoming data streams for distribution shifts and track the performance of the geometric models against newly resolved claims. If the characteristics of incoming claims deviate significantly from the training baseline, our observability stack flags it. This continuous monitoring ensures the platform remains accurate as industry forces like nuclear verdicts, social inflation, and third-party litigation funding reshape the risk landscape.

The final step of onboarding is placing the insights where the decisions happen. A separate dashboard is useless if the adjuster never logs into it. We integrate our calibrated outputs directly into the carrier's existing system of record. The settlement range, the escalation probability, and the specific drivers populate directly within their daily interface. This enables claims teams to set realistic reserves on day one, allocate their defense spend efficiently, and negotiate using data rather than gut instinct. Software only matters when it survives contact with the workflow.