Every decision is a record

Ceded reinsurance is audited from the outside in. The external auditor samples recoverables and asks for the bill. The reinsurer's claims team asks when they were told. The regulator asks for Schedule F and then for the support behind a line. In each case the question is not only “what is the number” but “who decided, on what, and when”.

Once agents prepare part of that work, the question gets a new branch: which parts did a machine prepare, at what level of authority, and which did a person approve? InsightCede answers it by refusing to let an agent do anything that is not written down.

Three records for every piece of work

Every time an agent runs, whatever happens, a run row is written: who it ran as, at what level and what limited it, the prompt it read, the model, tokens, cost, latency, the trace id and the outcome. If it found something for a person, it writes a decision row: the subject, the money, the evidence, the proposal and the explanation. And when a person answers, the answer is written back to the decision and recorded as feedback against the agent and action, which is what the autonomy roll-up reads.

erDiagram
    AGENT_RUN ||--o| AGENT_DECISION : prepares
    AGENT_DECISION ||--o| HELD_MESSAGE : "holds a send"
    AGENT_DECISION ||--o| PULLBACK_WINDOW : "opens at L3"
    AGENT_DECISION ||--o| FEEDBACK : "answered as"
    FEEDBACK }o--|| AGENT_STATS : "rolled up into"
    AGENT_RUN {
        string agent_code
        string autonomy_level
        string limited_by
        string prompt_version
        string model
        float cost_usd
        string trace_id
    }
    AGENT_DECISION {
        string title
        string evidence_json
        string proposal_json
        float amount
        string decision_status
        string decided_by
        string delta_json
    }

Every row the agent writes during the run is also stamped. The run happens inside an acting context: created_by and modified_by become agent:<code>, and the row's properties carry the full actor — the agent, its level, and, when a person's acceptance applied the proposal, who approved it and on whose behalf. The listener fires only while an agent identity is current, so a person's own request is never re-stamped. An in-process call the agent makes is made with a short-lived token carrying an act claim, minted by the identity package and never taken from a request.

What one run looks like

This is a real run record from the demo programme — a demo US property-casualty carrier, not a customer — read from the live API. It is the collections agent's chaser to Munich Reinsurance America for $15,730,529.

Admin · Agents · Agent

The decision row, and its states

A decision row is what a person reads and answers. Its evidence is a list of label, value and source — every figure with the ledger table it came from and a link into the ledger where there is one. Its proposal says what accepting does: a send with recipients and a draft, a strike, a programme fix with steps, a credit proposal, a Schedule F draft. Its amount is the money at stake and the queue's first sort key; its deadline depends on the step, from two days for erosion notices to fourteen for programme work.

A decision pulled back inside its window does not get a status of its own: the held message is cancelled, the decision reopens at L2, and the note says who pulled it back. A send that fails on release is parked the same way, back with a person, never retried blind.

Decision record

The dial is a record too

Changing what an agent may do is written down the same way. Setting a level or switching an agent off needs a manager or an administrator and a reason; the request is refused without one. The autonomy row keeps who set it, when and why, and an automatic demotion is written by the roll-up under its own name with the sentence that justified it — “People agreed with only 13 of 22 answers (59%) in 30 days” — so a level that moved without a person is distinguishable from one a person moved. Accepting a promotion records the recommendation it accepted. The ceiling is the one setting that is not on the page: it is the deployment's environment, changed by whoever changes the deployment.

One flow, end to end

A figure comes from a committed row or it is not in the record. A contact comes from the reinsurer master or the draft has no addressee.

What it does not do

• The prose is instructed, not checked figure by figure. Every agent's prompt says to use only the evidence and cite it, and the evidence and amount come from the ledger. But the platform's grounding guard — which throws away model text containing any number not in the facts — is not yet called by Cede's agents. In the demo, the counterparty agent's explanation states that Munich's excess over the 25% limit is “about $2,621,755”, a figure it calculated. It is right ($15,730,529.10 less $13,108,774.25), and nothing checked it.
• The demo has no traces and no released prompts. The Lense exporter is off unless an endpoint is set, so trace_id is empty, and InsightPrompts is not configured, so every run read the product's own prompt row (db-v1).
• The prompt text itself is not kept. Traces carry no prompt or response text unless capture is switched on. What the model saw is reconstructed from the evidence and the prompt version, not read back verbatim.
• Model and cost live on the run, not the decision. They join on the run guid. A report on decisions alone will not show what they cost.
• The dial's own history is short. An autonomy row records who set it, when and why, and keeps its last twenty changes in its properties; anything older is in the audit of the change, not on the row.

Talk to us about audit and controls →

← All posts   Request a demo