When an underwriter keys a total insured value into a rating engine, that number acquires consequences. It flows into the premium, into the treaty cession, into the bordereau you send your reinsurer, into the file a regulator may one day pull. If it is wrong — or right but unexplained — the question that follows is always the same: where did this come from, and who stands behind it? A modern extraction platform has to answer that instantly, for every field, or it is not fit for regulated insurance work.
Auditability in P&C is not a nice-to-have that you bolt on for exam season. It is load-bearing. Market-conduct and financial exams routinely sample individual files and ask you to substantiate the data. Errors-and-omissions exposure hinges on being able to show a reasonable, documented process. Premium and coverage disputes are won or lost on provenance. And reinsurance bordereaux are only as trustworthy as the extraction feeding them — a systematically mis-read limit can distort an entire cession. InsightXtract treats every one of these as a first-class requirement and captures the audit trail as the data is produced, not after.
The audit trail behind a single field
Consider one field on one excess-casualty account: the total premium. The broker’s cover email said $148,000; the ACORD stated $152,500. Which number ended up in the record, and can you prove why? In InsightXtract the answer is a continuous chain, captured step by step from raw document to published record.
sequenceDiagram
participant D as Raw document
participant E as Extraction agent
participant R as Reviewer
participant A as Approver
participant P as Published record
D->>E: ACORD page 3 + broker email
E->>E: Read total_premium candidates
email $148,000 / ACORD $152,500
E->>R: Value $152,500 (conf 0.86)
+ page/bbox provenance
Note over E,R: rule prefers ACORD annual
over email target premium
R->>R: Verify against ACORD citation
R->>A: Confirm $152,500 (no change)
A->>P: Approve & publish
agent v14, contract v3
Note over P: record reproducible:
source + who + when + why
Every hop in that sequence is retained. The record does not just say total_premium = $152,500; it says the value came from the ACORD annual-premium line on page 3, that a deterministic rule chose it over the email’s target figure, that the extraction confidence was 0.86, that a named reviewer verified it against the citation and made no change, and that a named approver published it under a specific agent version and output contract. If that premium is ever disputed, the entire story is one click away.

Provenance and citations: back to the exact spot on the page
Provenance in InsightXtract is not a vague “extracted from this document” note. Each field carries a citation down to the page and bounding box — the precise rectangle on the ACORD or loss run where the value was read. A reviewer clicking total_premium is taken straight to the highlighted region on page 3 of the ACORD; a reviewer clicking a paid-loss figure lands on the exact cell of the loss-run table it came from.
This is what makes verification fast and disputes short. Instead of re-reading a forty-page submission to check one number, the reviewer confirms it against the highlighted source in seconds. And because the citation is stored with the record, an auditor months later sees the same rectangle on the same page — the evidence does not degrade or drift.

Corrections: old, new, reason, who, and when
When a reviewer does change a value, the correction is a permanent, structured record rather than a silent overwrite. Suppose on a different account the agent read the deductible as $25,000 but the reviewer, checking the citation, sees it should be $250,000. The platform stores the old value, the new value, a reason, the reviewer’s identity, and a timestamp. The original machine-extracted value is never erased — you can always see both what the AI produced and what a human decided, side by side.

Separation of duties: correcting data is not configuring the agent
Auditability collapses if the same person can both correct a record and quietly change the rules that produced it. InsightXtract enforces separation of duties through role-based access control. A Reviewer can fix the value on a document, but a Reviewer cannot silently alter the agent configuration, publish a new agent version, or promote a change to production — those are distinct permissions held by distinct roles.
| Capability | Admin | Builder | Operator | Reviewer | Viewer |
|---|---|---|---|---|---|
| View records & audit trail | ✓ | ✓ | ✓ | ✓ | ✓ |
| Run / re-run extraction | ✓ | ✓ | ✓ | — | — |
| Correct field values | ✓ | — | — | ✓ | — |
| Edit agent config (prompts, rules, glossaries) | ✓ | ✓ | — | — | — |
| Approve & publish agent version | ✓ | — | — | — | — |
| Manage users & roles | ✓ | — | — | — | — |
flowchart LR
subgraph Roles
AD["Admin"]
BU["Builder"]
OP["Operator"]
RV["Reviewer"]
VW["Viewer"]
end
subgraph Permissions
P1["Correct field values"]
P2["Edit agent config"]
P3["Publish agent version"]
P4["Run extraction"]
P5["View + audit"]
end
RV --> P1
RV --> P5
BU --> P2
BU --> P4
OP --> P4
OP --> P5
AD --> P1
AD --> P2
AD --> P3
VW --> P5
The separation is the safeguard. Because the reviewer who corrects a deductible cannot also rewrite the extraction prompt, an auditor can trust that a data correction is exactly that — a data correction — and not a disguised change to how every future document will be read. Configuration changes travel their own governed, approval-gated path.
Versioning: reproduce any historical extraction
Every published record is stamped with the agent version and the output contract that produced it. That pairing is what makes historical extractions reproducible. If a treaty audit in 2027 questions how a 2026 statement of values was read, you can identify the exact agent version that was live at the time, the rules and glossaries it carried, and the output schema the record conformed to — and re-run the original document against that same version to reproduce the result byte for byte.
This is the difference between an audit you can answer and one you have to negotiate. “The system read it this way because version 14 was active, here is version 14, here is its configuration, and here is the same output when we re-run it” is a defensible answer. “We think it was configured roughly like this at the time” is not.

What “by design” really means
The audit trail is not generated on request from logs after the fact. Provenance, confidence, corrections, approvals, and versions are captured as the data is produced and stored with the record. There is nothing to reconstruct because nothing was ever left implicit.
Why this matters to the business
- Defensible records. Every value carries its source, its citation, its human decisions, and the version that produced it — substantiation is built in, not assembled under deadline.
- Faster audits and exams. Sampling a file no longer means a scramble; the full chain for any field is available on demand, which shortens exam cycles and reduces the internal cost of responding.
- Lower E&O risk. A documented, role-separated, reproducible process is itself evidence of reasonable care — and per-field provenance shrinks the surface for disputes over “who got the number wrong.”
- Trustworthy downstream data. Bordereaux, treaty cessions, and rating all inherit clean, traceable inputs — so an error anywhere upstream can be located and explained, not just discovered.
Related: how the agent gets better →
Auditability and improvement are two halves of the same discipline. The companion post shows how those same corrections drive self-improving extraction — reviewer-approved, validated, and versioned, so the same mistakes stop recurring.