The ceded function at most mid-sized carriers lives in four places. A treaty register in a workbook, maintained by the head of reinsurance. Bordereaux that arrive and leave by email. A recoverables tracker the ceded accountant rebuilds each month from claim payments. And a reinsurance module bolted onto the policy or claims system, which computes something nobody fully trusts and everybody reconciles to.
Leaving that estate is less about the software than about the first honest look at the numbers. The plan below is built around that look, and around one rule: nothing the old estate does stops until the new ledger has reproduced it or explained why it should not.
First, what has and has not been run
| Status | Where | |
|---|---|---|
| The ledger on Postgres, moved off its first MySQL home row for row | Run | The dev ledger, 20 October 2026 |
| The defect fixes on a carrier's own data, by contra | Run | The demo carrier's ledger |
| The engine's rules against the demo carrier's claims | Run | Tests on a local Postgres |
| Agents running live, with the model, on the ledger | Run | The demo: 50 runs, 46 with a model call |
| A message to a reinsurer | Never | Every release outside production is a dry run |
| Any agent above L2, or any promotion | Never | The demo has no answers recorded yet |
| Any carrier's production programme | Never | No customer runs it yet |
| A Schedule F filing | Never | The agent drafts parts for review only |
Everything below that is described as having happened happened on the demo carrier — a demo US property-casualty writer whose programme was loaded from its own reinsurance schema. Everything else is the plan.
What moving in actually involves
1. The programme, from the book of record
The treaty structure — reinsurers, treaties by underwriting year, layers, the panel with signed lines — is loaded by a script from the carrier's book of record, so Cede describes the same programme the carrier already describes. On the demo that source was a ten-table reinsurance schema. Two things are deliberately not copied.
- Erosion and reinstatements used. They are consequences of the cession ledger, and the source had stored them independently until they drifted into an impossible state: a layer recorded as 3 reinstatements used out of 1 available, and erosion $2.1M beyond anything it could pay. In Cede they are derived, which makes that unrepresentable.
- Unscoped lines. Every source treaty had no lines of business recorded, which would make a casualty quota share respond to a property cat loss. The lines were scoped on load.
2. The history, as events
Past transactions are replayed through the same intake the workbenches use, in batches. Intake is idempotent on the event id, so a replay can be stopped and restarted without double-ceding. The engine cedes each one under today's rules, which means the new figures will not always match the spreadsheet. That is the purpose of the exercise: each difference is either a defect in the old estate or a rule to agree.
3. The defects, fixed by contra
The demo carrier's data went through this. A fix-up script, dry-run by default, reported every change before writing any, and wrote them in one transaction. What it found is a fair preview of what any carrier's data will show.
| Finding in the demo carrier's data | How it was fixed |
|---|---|
| Four treaty years with no panel, so nothing ceded to them could be billed | A panel proposed at the cat programme's signed lines, flagged with its source for a person to replace with the real placement |
| A 2026 cat treaty duplicating another: same layer, same lines, same inuring order | Retired with a reason, so one 2026 loss is ceded once |
| A policy bound twice, by a manual event and by underwriting's backfill | The manual bind's cession reversed by a contra premium cession, not deleted |
| Treaty years past expiry still marked active | Moved to run-off: they still respond to losses inside their term |
| Two probe events in the inbound ledger | Retired |
| Figures the earlier engine got wrong | Restated by contra: a 13,125 cession made twice; reinstatement premium from 501,932.21 to 724,929.26; a 56,100 charge for a reinstatement that did not exist; a residual cent |
Nothing was edited and nothing was deleted. Every correction is a row that says what it corrects.
4. Moving the database itself, if there is one
The ledger's own first move is the template for any copy. The copy script runs as a dry run
by default and prints the counts, the plan and the position on both sides; with the apply
flag it refuses to write into tables that already hold rows; ids, guids, timestamps and money
are kept exactly, money as Decimal, never as a float; and a re-run after a complete
copy is a no-op. The test of the move is that the position reads the same on both sides.
Thirteen weeks
gantt
dateFormat YYYY-MM-DD
axisFormat %b %d
todayMarker off
section Load
Programme and panel loaded :p1, 2027-01-04, 14d
section Replay
Replay a year (slips here) :crit, p2, 2027-01-18, 28d
section Run both
Queue answered, sends dry run :p3, 2027-02-15, 28d
section Switch
Live sends, tracker retired :p4, 2027-03-15, 21d
| Phase | What it produces | The tell that it is stalling |
|---|---|---|
| Load (weeks 1–2) | The programme in Cede; the gaps report run; every gap either fixed at the source or recorded as a decision | A gap that nobody will own |
| Replay (weeks 3–6) | A year of events ceded; a list of differences against the workbook, each explained | “Close enough” in a status update |
| Run both (weeks 7–10) | The queue answered daily; feedback accumulating; the old tracker kept as the check | Decisions expiring unanswered |
| Switch (weeks 11–13) | Sends live in production; the recoverables tracker retired; bordereaux struck in Cede | Someone still emailing a statement from the workbook |

The two weeks of overrun were all in the replay, and they were the right weeks to spend. The loss-date error alone had been moving cat recoveries between treaty years for as long as the workbook had existed.
Measuring it
Cede publishes its own numbers for the agents, and the ledger's numbers do the rest. The useful ones are few.
| Measure | Definition | Demo today |
|---|---|---|
| Agreement | Accepts over accepts, changes and rejects, last 30 days | — (no answers yet) |
| Accepted as prepared | Decisions accepted unchanged, or acted on at L3+ and not pulled back, over all prepared | 0 of 36 |
| Wait for a person | Median hours from prepared to answered | — |
| Unbilled | Recoverable raised but never asked for | 5 small quota-share items |
| Overdue | Outstanding past its due date, by days late | Every cat recoverable, 13 days |
| Position against the old estate | The difference between Cede's position and the workbook's, explained to the cent | Not applicable: no old estate |

The honest version of the business case
The benefit you can prove in ninety days is not autonomy. It is a ledger that reproduces your programme, a list of the defects your workbooks were hiding, and a desk that answers prepared decisions instead of assembling them. Letting agents act alone comes later, if the answers earn it, and the plan should not count on it.
What it does not do
- There is no spreadsheet importer. A workbook programme has to become a structured extract first, or be proposed from the slip's text by the placement intake agent and then loaded. Nothing reads an .xlsx.
- Reinsurers' files are not ingested. Their statements and remittances arrive as files; the reconciliation agent matches lines it is given, through the API, and there is no screen for that yet.
- The programme is not edited in Cede. There is no screen to enter or change a treaty or a panel line; corrections are made at the source and reloaded.
- It has not been done at a carrier. The thirteen weeks are a plan built from what the demo carrier's data needed. The first production run will find something this post does not mention.