When a claim event does not fit

“Why was nothing ceded on this claim?” is the question a ceded team asks most often, and in most carriers it has no quick answer. The claims system sent something; the reinsurance module did something, or nothing; the log, if there is one, says processed. Finding out means a ticket to the integration team, who find out a week later that a field was blank in a release that went out on a Thursday. Meanwhile the bordereau for the month is struck without the claim, and the recoverable is not billed.

InsightCede is built so that every transaction leaves a record of what happened to it, including nothing, with the reason in words. This post follows the events that do not fit: what the intake does with them, what the agents prepare, and what a person still decides.

The contract at the door

InsightUW and InsightCW do not decide anything about reinsurance; they report what happened. What they may send is published as two versioned contracts. The underwriting contract carries one event per policy transaction — bound, endorsed, audited, cancelled, reinstated — with the premium as the delta that transaction added and the policy inception date that decides which risks-attaching treaty responds. The claims contract carries reserve movements, payments, voids, recoveries, closes, reopens, large-loss notices and catastrophe roll-ups, each with the claim’s cumulative position — incurred, paid, recovered, reserved — never a delta, plus the loss date and the policy inception. The claims system tests its own emissions against the same file Cede publishes, so a release that drops a required field fails its tests before it ships.

Events arrive at one signed webhook. The intake is idempotent on the event id: an id it has seen is acknowledged and nothing is ceded twice, which is what makes a sender’s retries safe. Every event then ends in one of four outcomes, each with a note:

Outcome	What happened	What follows
Ceded	The engine found the contracts that respond and wrote the cessions	The cession decision agent explains it; a clean cession is noted, not queued
Noted	A notice with no cession of its own — a large-loss notice, a catastrophe roll-up, a facultative certificate	The notice agents act on it where they apply
Nothing ceded	No contract responded: not covered, outside the period, below the attachment, or a date the basis needs was missing	The cession decision agent explains it and waits for a person; the contract mismatch agent proposes the handling
Error	Refused: an event type the intake does not know, or the engine failed	The desk is notified and the event shows under Errors on Inbound; replay is available

Three agents after every commit

When the engine has committed an event, the intake hands its id to the agents, in their own session, so nothing they do can fail or slow the intake. One orchestration runs per event:

Cession decision agent (L2). Lists every contract considered, in inuring order, and says which responded and why each other did not — the line is not covered, the event is outside the period, the basis needed a date the event lacked, the loss did not reach the attachment, an excess layer is paid by layer premium rather than per policy. A clean cession is explained and noted on the event. Anything uncovered or not ceded waits for a person.
Anomaly explainer (L1). Looks for what the engine wrote that looks wrong: two cessions to the same contract on one event, a cession to a treaty with no panel or a panel short of 100%, an uncovered remainder, or a repeat of an earlier cession on the claim with the same amount to the same layer — a resend the netting did not catch. It proposes a contra cession, a programme fix, or nothing.
Contract mismatch agent (L1). For an event with nothing ceded or refused: an unknown type needs a mapping; a basis that needed a date the event did not carry needs a resend; no contract in force needs a manual decision — retain it, scope a treaty, or bind a facultative certificate.

sequenceDiagram
    participant CW as InsightCW
    participant I as Intake and engine
    participant G as Intake agents
    participant P as Ceded analyst
    CW->>I: claim event, signed
    alt known type
        I->>I: cede, or record why not, then commit
        I->>G: event id, after the commit
        G->>P: explanation, anomaly, handling
        P->>CW: ask for what was missing, if anything
    else unknown type
        I-->>CW: refused, not to be retried
        I->>P: notification, Errors on Inbound
    end
    CW->>I: next event, a new id

Every known event reaches the agents after its commit. A refused event never commits, so it reaches the desk as a notification and an error row instead. Either way the fix usually lives in the sender.

Use case details

	Events that do not fit
Trigger	On event: after every committed inbound event; a refused event raises a notification instead
Actor(s)	Ceded analyst; the UW or CW integration owner who fixes the sender; an administrator for replay
Agent	`cession_decision_agent`, `anomaly_explainer_agent`, `contract_mismatch_agent`
Grounded in	`cede_inbound_event` (payload, outcome note, status), the cessions written for the event and the claim, the candidate contracts and why each was skipped, the panel, the intake’s event vocabulary
Prepares	The explanation of each event; a proposed correction for an anomaly; the handling for an event with nothing ceded
Checkpoint & default level	`cession_review` L2; `anomaly_review` L1; `mismatch_review` L1
What a person decides	Whether the outcome is right, what the sender must change, whether a line is meant to be retained, and whether a correction is written
What is recorded	The event with its kept payload and outcome note, one run per agent per event, each decision and its answer, the exchange log per flow, and any replay

The Inbound page: Reported, Ceded, Nothing ceded and Errors tiles; the events with transaction, claim or policy, source, outcome, cessions, amount ceded and the reason in words; and the cession agent’s rail — **Read the Why column.** Every row says what happened in a sentence, including the rows where nothing did. Selecting one opens the decision behind it, the cessions written, and Replay.

The demo ledger’s inbound

The demo ledger has 50 inbound events: 30 ceded, 20 with nothing ceded, none refused. Most of the twenty are correct outcomes — six small reserve movements below any attachment, ten policies no contract in force covered, one property policy where the only contracts are excess layers paid by layer premium, one liability payment that found no contract for its dates. Two are not. Two auto claims arrived as reserve movements without a policy inception date, and the note says exactly why nothing was ceded: each year of the casualty quota share is risks-attaching, so it needs the policy inception date, which the transaction did not carry. That is a field the claims contract requires. It is a sender problem, and the note names it; the contract mismatch agent’s handling for it is a resend.

A worked example

Priya Raman, ceded analyst, the morning after a CW release

Calder Mutual’s claims system shipped an update overnight. By 09:00 fourteen auto reserve movements, $1,900,000 of gross incurred between them, have arrived with nothing ceded. The auto line sits on a 25% risks-attaching quota share.

09:00
Fourteen waiting explanations
Each event’s cession decision says the quota share was skipped because it needs the policy inception date, which the transaction did not carry. Each waits for a person at L2. Each contract mismatch decision proposes a resend.
09:10
Priya opens one trace
The data trace for one event lines up the exchange logged from CW, payload included: policy_inception is absent. The release dropped it from reserve movements.
09:30
The sender is fixed
CW’s integration owner restores the field and sends a corrected reserve movement for each claim under a new event id. Re-sending the old ids would only be acknowledged as already processed.
10:15
The positions cede
Each corrected event carries the claim’s cumulative position, so the engine cedes the whole of it: $475,000, 25% of $1,900,000. The cession decisions on the new events are clean and noted; nobody is asked anything.
10:20
Closing the morning
Priya answers the twenty-eight original decisions — fourteen explanations, fourteen proposed resends — accepted, with a note naming the release. The exchange log for the CW flow shows the failure window.

Illustrative composite. The figures are internally consistent and every step is one the product supports today.

A refused event goes differently. Suppose the same release had introduced a new type, say claim.salvage_received. The intake refuses it, answers the sender that it should not retry, notifies the desk, and lists it under Errors. Replay will not help: replay re-runs the payload the ledger kept, so an unknown type is refused again. The fix is a mapping in the sender — salvage is a recovery — and the event resent as claim.recovery_received under a new id.

What replay is for

Replay exists for one case: an event that was refused because something on Cede’s side was wrong at the time — most often an engine failure that has since been fixed. An administrator replays it from the event on Inbound or from the flow on the integrations hub; the intake deletes the error row, ingests the kept payload as if it had just arrived, and logs the outcome against the sender’s flow. Only refused events replay. An event that ceded, or ceded nothing, is final on its id.

The integrations hub: the flows InsightUW to Cede, InsightCW to Cede, Cede to InsightPulse and the data API, each with its health — **One row per flow.** Each opens its contract, its recent failures with replay, and the exchange log.

What it does not do

Refused events do not reach the agents on their own. The hook runs after a commit, and a refused event never commits. It reaches the desk as a notification (through the signed webhook) and an error row; the contract mismatch agent can be run on it by hand.
An event id is spent once it is seen. Resending a corrected event under the same id is acknowledged as already processed and changes nothing, including for a refused event. A correction needs a new id — or, for a claim, the claim’s next movement, which carries the full position.
Replay cannot change a payload, and it cannot re-run nothing-ceded events. If the programme is fixed after an event ceded nothing, that event stays as it was; the claim catches up on its next event, a policy on a resend with a new id.
The intake does not enforce the whole contract. It requires an event id and a known type. A missing inception or loss date is caught by the sender’s contract tests, or surfaces as nothing ceded with the reason — as in the demo.
Corrections are proposals. The anomaly explainer may propose a contra cession; there is no screen in this build that writes one by hand, so a correction goes through the sender or the engine.

Why nothing ceded is a record, not a silence

A transaction that cedes nothing is the one most likely to be wrong and least likely to be noticed. Keeping it, with the reason in a sentence and an agent’s explanation beside it, turns “why was nothing ceded?” from a ticket into a click.

If your integration with the claims system is a nightly file and a log that says processed, talk to us about pointing a test feed at a demo ledger and reading what the intake says back.

← All posts Request a demo