Claims Automation · Reference blueprint

Automate the claim. Gate the payout.

A reference blueprint for property & casualty claims — intake, fraud triage, and payout approval as governed actions on the Cortex runtime. Payouts at or above $5,000 route to a human before a dollar moves, every triage decision is explained, and the whole outcome is sealed in the Trust Ledger. This blueprint specifies the ontology, policies, actions, and agents; the signed, installable pack is on the roadmap.

payout ≥ $5,000 → human approval (409 without it) · representative targets · reference blueprint (not yet a signed artifact)

insurance-claims · Reference blueprint
Insurance Claims Automationinsurance-claimsBlueprint
ontologyTypes3
policies5
actions4
agents3
reference blueprint · not yet a signed artifact
reference blueprint ▸ ontology · policies · actions · agents
What this pack governs

One governed blueprint — the whole solution, specified.

The Claims blueprint governs the path from a filed claim to a paid (or denied) outcome. It specifies the claims ontology (claim, policyholder, payout), the policies that cap autonomous payouts and force fraud holds, the Action Fabric actions that approve or deny a payout, and three curated agents — so claims automation is defined as one governed solution with the money-moving step always under human control.

Representative targets

The targets the pack is tuned to.

Illustrative targets for this use-case, configurable per deployment — the gates that enforce them are specified in the blueprint.

~70%
Straight-through rate
Representative target — low-risk claims auto-cleared under cap.
100%
Triage explanation
Every triage decision carries an explanation and evidence.
≥ $5,000
Payout approval
Hard threshold — payouts at/above route to human approval.
What's inside

Four governed sections, one blueprint.

A blueprint specifies the four governed sections a Solution Pack bundles. When it ships as a signed pack, the same envelope — canonicalize → sha256 contentHash → HMAC signature — is what makes it portable and provable.

ontologyTypes×3
  • Claim — claimNo, lossType, amount, status, fraudScore
  • Policyholder — name, policyNo, ssn (PII, restricted)
  • Payout — amount (restricted), method, approvalState
policies×5
  • Payout ≥ $5,000 → require human approval
  • fraudScore over threshold → hold for investigation
  • ssn is restricted — read denied outside intake
  • Deny requires a cited reason code (no silent denials)
actions×4
  • approvePayout — riskTier: high, approval-gated ≥ $5k
  • denyClaim — riskTier: medium, cited reason required
  • requestDocuments — riskTier: low, auto-executed
  • flagFraud — riskTier: medium, opens an investigation
agents×3
  • Claims Intake — structures the FNOL into the ontology
  • Fraud Triage — scores risk, cites the signals it used
  • Payout Approver — proposes payout, routes ≥ $5k to human
What it does

Governed agents, mapped to real Cortex controls.

Every capability in this pack is enforced by a runtime control you can audit — identity, policy, action approvals, and a sealed Trust Ledger. The pack configures them; the platform enforces them.

The $5,000 line is a hard gate
  • approvePayout is a high-risk Action Fabric action: at or above $5,000 the agent can only propose — a human approves before the money moves. Below the cap, low-risk claims clear straight through.
Fraud triage that shows its work
  • The Fraud Triage agent scores each claim and cites the signals it used. No black-box denial: every hold and flag carries an explanation a reviewer (or regulator) can read.
Denials need a reason code
  • denyClaim won't execute without a cited reason — policy forces every adverse decision to name the rule it rests on, so the claimant and the examiner both get an answer.
A receipt on every outcome
  • Approve, deny, or compensate — each executed action mints a signed receipt into the hash-chained Trust Ledger, so a disputed payout has a verifiable record behind it.
Policyholder PII stays locked
  • ssn and payout amount are restricted properties: read-denied outside the agents that need them, keeping sensitive claimant data out of prompts that shouldn't see it.
Watch the fleet, pause on demand
  • Every claims agent reports into the Control Tower with live state — pause a misbehaving agent, disable a tool, or arm the kill switch across the whole fleet.
$5,000Payout approval threshold (human-gated)
100%Triage decisions with an explanation
3Governed agents in the pack
10-hopProvenance on every payout decision
How it ships

A blueprint today — a signed, installable pack on the roadmap.

This blueprint fully specifies the ontology, policies, Action Fabric actions, and agents. When it ships as a Solution Pack it inherits the same packaging every Cortex pack uses: canonicalize → sha256 contentHash → HMAC signature, then a verify-first importPreview → importApply that checks hashOk + signatureOk before a single row is written — into your own tenant only.

  • Ontology, policies, and Action Fabric actions specified and ready to package
  • On publish: verifyPack checks hashOk + signatureOk before import
  • Runs on the same governed runtime as the shipping Tax pack — same gates, same ledger
  • Want it sooner? Bring your workflow and we'll prioritize the build.
packs · verify + import
Refund under capapprovePayout $240 → auto-executed200 OK
Payout at thresholdapprovePayout $5,000 → proposed, awaits human409 hold
Fraud holdfraudScore over threshold → investigationheld
Uncited denialdenyClaim without a reason codeblocked
importApply verifies first ▸ 409 if invalid · upserts into your tenant only
From blueprint to shipping pack

How this blueprint becomes an installable pack.

The design is done; packaging is what remains. A blueprint carries the same four governed sections a shipping pack does — it just isn't sealed and signed yet.

  1. 01

    Specified today

    The ontology, policies, Action Fabric actions, and agents above are the real design — the same shape the runtime enforces for every shipping pack.

  2. 02

    Packaged & signed

    When it ships, the contents canonicalize → sha256 contentHash → HMAC signature and land in the registry on a stable or beta channel — exactly like the Tax pack.

  3. 03

    Verify & install

    importApply re-checks hashOk and signatureOk, then idempotently upserts into your own tenant. Until then, we can stand the workflow up for you from this blueprint.

Governance included

The controls your auditors already cite — built in.

The ontology permissions, fail-closed policies, approval gates, and sealed Trust Ledger map directly to the frameworks this use-case reports against. Aligned with — never claiming a certification you don't hold.

NAIC Model Acts · claims handlingGDPR · claimant dataSOC 2 · auditISO 42001 · AI recordsEU AI Act · logging

Ship claims automation that keeps the payout under control.

Bring your claims workflow and we'll stand up the governed pack from this blueprint — automating the claim while every dollar over $5,000 still stops for a human.