Claims, renewals and documents, with an audit trail you can hand to the regulator.
OCNORA was first run in production for insurance platforms. FNOL triage, document extraction and approvals are workflows here, not custom code.
Three workflows teams build here first.
- 01
First notice of loss: extract the claim from the form or the email, validate it, triage by severity, notify the adjuster.
- 02
Policy documents and IDs read into structured fields, with a human check on anything below a confidence threshold.
- 03
Renewal and endorsement workflows with the approvals your underwriting rules require, recorded step by step.
What runs, step by step.
A first notice of loss: documents kept and read, fields extracted and validated, doubtful or severe claims sent to an adjuster, then the claim opened and the claimant told.
- 01Claim submitted
- 02Keep the documents
- 03Read the documents
- 04Extract claim fields
- 05Validate against schema
- 06Severity and confidence
- 07Adjuster review
- 08Open claim
- 09Notify the claimant
Every step is a node type in the catalog. Diagram only: no data, no live run.
Before you start
- An intake form or mailbox that posts each new claim to a webhook.
- A Google Cloud Document AI processor (or AWS Textract) with a credential, and a bucket for the originals.
- A JSON schema for a valid claim, and the severity and confidence thresholds from your rules.
- An API on your claims system that opens a claim, and adjusters to route reviews to.
What you get
Every claim arrives as validated structured fields; the doubtful and the severe reach an adjuster before a claim is opened, and each step, payload and approval is in the run’s audit log.
Limitations
- The thresholds in the template are a starting point. Set them to your own underwriting rules before going live.
- The Textract node detects text. Form and table analysis goes through the HTTP node with an AWS credential.
- Crypto-shred covers personal data OCNORA stores. Copies written to your claims system or bucket follow those systems’ retention.
- Self-hosting means you run the Kubernetes cluster it lives on.
First notice of loss: extract, validate, triage
A claim notification arrives by webhook; AI extracts the loss details, the payload is validated, an adjuster triages it and the claim is opened in Iris.
See each step's output, and approve the risky ones.
Illustrated with a support workflow; the run view and the approval request look the same for every workflow.
Built for this, not adapted to it.
An FNOL triage template
Extract, validate against a schema, ask a human when the data is doubtful, branch by severity, notify. Import it and change the thresholds.
Document extraction as a node
AI extraction with a JSON schema, then a validation node. Bad extractions fail a step, not a claim.
Approvals as first-class steps
Human prompt nodes with timeouts and reminders. Approval is part of the run, so the record of who approved what is part of the run too.
An audit log on every run
Every run, step, payload and mutation is recorded with who and when. Run lineage is a view, not an investigation.
PII crypto-shred
Personal data is encrypted with per-record keys. Deleting the key deletes the data everywhere it was written, including in run history.
Run it where the data must stay
Self-host on your Kubernetes with Helm values for AWS, Azure or GCP, under an offline licence. Nothing leaves your boundary.
Start from one of these.
Each one imports into a workspace; swap the connections and run it.
- First notice of loss: extract, validate, triageA claim notification arrives by webhook; AI extracts the loss details, the payload is validated, an adjuster triages it and the claim is opened in Iris.
- Document extraction to APIReceive a PDF (base64) by webhook, parse it, extract structured fields with a JSON schema, reshape them and POST the record to your API.
- Extract with human clarification on low confidenceExtract structured data from text; when the model is unsure it pauses and asks a person to pick from candidates, then the record is posted.
Apps this kind of workflow usually touches.
Each one has its own page with operations, triggers and auth.
Anthropic
Google Document AI
AWS Textract
Amazon S3
SendGrid
PostgreSQLRead before the first live run.
- How to test a workflow before it touches anything realStatic validation, a dry run against real config with side effects held back, then a first live run on one record. A practical order for shipping automations safely.
- How to keep an AI agent’s spending close to the number you setA retry loop, a huge tool result or a growing prompt can turn one agent into a runaway bill. Here’s how per-tenant budgets and a circuit breaker limit it.
- How much a dry run actually proves before you trust it liveA dry run executes your workflow with side effects suppressed and shows each step’s output shape. That shows the path resolves, not that the result is right.
See a workflow run on your own use case.
Book a technical demo. Bring an n8n file or pick a template, and we build it with you on the canvas while Workflow Health checks it before it ever runs.