--- title: "Governed Claims Adjudication | Cyoda" description: "Use Cyoda to govern AI-assisted claims adjudication through entity workflows, traceable state transitions, audit history, adjuster review, payment, appeal, and reversal paths." canonical: https://cyoda.com/use-cases/governed-claims-adjudication --- Use case ยท Governed claims adjudication # Governed Claims Adjudication Governance lifecycle for AI-assisted property and casualty claims AI is already drafting assessments, summarising records, and proposing adjudication decisions inside carriers. The hard part is moving any of it into production. Cyoda runs each claim through a governed entity workflow and records every state change as an immutable event, so teams can audit decisions, reconstruct what the system knew, and prove control over AI-assisted claims handling. The problem ## A claim decision needs an entity lifecycle, not a stitched-together approval trail An assessment agent can draft a coverage opinion quickly. The hard part is proving what evidence it saw, which authority limits applied, who confirmed the proposal, what payment issued, and how a later dispute or reversal was handled. If the FNOL extract lives in one place, the proposed decision in another, the adjuster confirmation in a third, and the payment record in a fourth, carriers end up reconstructing the control story after the event rather than governing it at write time. Cyoda models the claim itself as the governed entity. The workflow transitions act on that entity directly, so captured evidence, authority checks, agent proposals, adjuster decisions, payment results, and immutable history stay together. ### Where carriers get stuck * Proposed adjudication sits outside the claim system-of-record lifecycle. * Adjuster authority limits and SIU referrals are bolted on after the AI pilot. * Payment, denial, and reversal flows are split across queues, logs, and manual runbooks. * Audit on a contested claim requires stitching together prompts, tool traces, document snapshots, and adjuster notes from months or years earlier. How you can model it with Cyoda ## Claim entity workflow for governed adjudication Each claim is a Cyoda Claim entity. Its lifecycle can be modelled as an entity workflow: captured FNOL context, coverage and authority checks, agent-drafted assessment, adjuster review, adjudication, payment, failure handling, appeal, and reversal paths, all as transitions on the claim itself. Agents act through automatic transitions guarded by criteria. Adjusters act through manual transitions where human judgement or authority is required. Every proposal, confirmation, rejection, payment result, and reversal path becomes part of the claim's ordered history. ENTITY WORKFLOW Claim Governance lifecycle for AI-assisted claims adjudication Pan to explore the claim lifecycle and select a state or transition for details. ### Entity lifecycle detail Select a state or transition to inspect the entity lifecycle semantics. Claim entity workflow JSON This viewer is driven directly from the supplied Claim entity workflow file, including FNOL capture, coverage checks, assessment proposal, adjuster review, payment, appeal, failure, and reversal paths. What the entity contains This illustrative Claim example uses a more realistic adjudication model: policy terms, insured and claimant parties, loss-event context, vehicle data, coverage evaluation, reserves, and captured evidence all sit on the same governed entity record. Claim.json JSON entity ``` { "modelVersion": "claim/v3", "claimNumber": "CLM-2026-04-0073829", "lineOfBusiness": "personal_auto", "jurisdiction": "US-CA", "reportingChannel": "MOBILE_APP", "reportedAt": "2026-04-12T14:03:11Z", "lossDate": "2026-04-11T22:40:00Z", "policy": { "policyNumber": "POL-PA-3389441", "effectiveFrom": "2025-09-01", "effectiveTo": "2026-09-01", "carrierEntityCode": "ACME-PA-CA", "producerCode": "BRK-44012", "policyVersionAtLoss": 7, "endorsements": ["END-RENTAL-A", "END-OEM-PARTS"] }, "insured": { "partyId": "PRT-882140", "displayName": "[REDACTED]", "preferredLanguage": "en-US", "contactPreference": "SMS" }, "claimants": [ { "claimantId": "CLT-1", "partyId": "PRT-882140", "role": "INSURED_DRIVER", "represented": false }, { "claimantId": "CLT-2", "partyId": "PRT-991733", "role": "THIRD_PARTY", "represented": true, "counsel": { "firmName": "[REDACTED]", "firstNoticeOfRepresentationAt": "2026-04-13T16:22:00Z" } } ], "lossEvent": { "lossType": "COLLISION_TWO_VEHICLE", "faultIndicator": "INSURED_AT_FAULT_LIKELY", "narrativeFromFnol": "Insured rear-ended stationary vehicle at signalized intersection; low speed; airbags did not deploy.", "policeReportNumber": "SFPD-26-118944", "location": { "street": "16th & Folsom", "city": "San Francisco", "region": "CA", "country": "US", "geo": { "lat": 37.767, "lng": -122.417 } }, "weatherSnapshot": { "source": "NOAA-LCD", "fetchedAt": "2026-04-12T14:04:51Z", "conditions": "CLEAR", "visibilityMiles": 10, "precipitationInches": 0 } }, "vehicles": [ { "vehicleRef": "VEH-1", "role": "INSURED_VEHICLE", "vin": "1HGCV1F30LA*****", "year": 2020, "make": "Honda", "model": "Accord", "garagingZip": "94110", "estimatedRepairCost": 6420, "totalLossThresholdUsd": 14500, "totalLossSuspected": false }, { "vehicleRef": "VEH-2", "role": "THIRD_PARTY_VEHICLE", "vin": "5YJ3E1EA7K*****", "year": 2019, "make": "Tesla", "model": "Model 3", "thirdPartyDemandAmount": 11800 } ], "coverageAssessment": { "applicableCoverages": [ { "code": "COLL", "limitUsd": 50000, "deductibleUsd": 1000, "perOccurrence": true }, { "code": "BI", "limitUsd": 100000, "deductibleUsd": 0, "perPerson": true }, { "code": "PD", "limitUsd": 50000, "deductibleUsd": 0, "perOccurrence": true }, { "code": "RENT", "limitUsd": 1500, "deductibleUsd": 0, "perOccurrence": true } ], "exclusionsConsidered": ["EXC-RACING", "EXC-DUI"], "exclusionsTriggered": [] }, "financials": { "currency": "USD", "reserves": { "indemnity": { "collision": 6420, "bodilyInjury": 8000, "propertyDamage": 11800 }, "expense": { "appraisal": 350, "legal": 0 } }, "paymentsToDate": [], "subrogationPotential": "NONE", "salvagePotential": "NONE" } } ``` Illustrative example only. These examples show how a system could be modelled with Cyoda. They are not detailed business requirements or prebuilt Cyoda application templates. The outcome ## What changes when the claim lifecycle is native Proposed adjudication is held on the Claim entity, not passed around as workflow-local state. Captured evidence, authority checks, adjuster decisions, payment results, and exception paths stay on the same entity record. Low-value, high-confidence claims can move through criteria-driven automatic transitions without losing auditability. Adjuster review is part of the lifecycle when workflow criteria require it. Payment, denial, appeal, reversal, and exception states remain queryable in one entity history. The full claim record can be reconstructed as of a past point in time. Regulated production ## Why this matters once AI-assisted claims handling leaves the pilot ### Snapshot reconstruction When a denied claim becomes a complaint later, teams can reconstruct the claim state, captured evidence, agent rationale, adjuster confirmation, and payment outcome at the time the decision was proposed or issued. ### Governed adjudication authority An agent-drafted assessment does not equal a paid claim. Authority limits, SIU referrals, fraud-screening criteria, and adjuster confirmation stay in the write path. ### Appeal and reversal discipline Failed payments, contested denials, and post-payment disputes move through explicit states. Retry, escalation, appeal, and reversal are lifecycle behaviour, not log archaeology. ### Less custom control plumbing Carriers do not need to stitch a separate control layer around every promising claims-AI workflow. The control layer is the platform. If you are moving AI-assisted claims handling from prototype to governed production, we can help map the entity lifecycle, control points, and audit requirements. [Talk to us](/contact)[Read the architecture](/#how-it-works)