There’s a moment in every AI-in-production conversation where the pilot stalls: someone in risk or compliance asks how the system arrived at a number, and the honest answer is “the model said so.” For a regulated insurer, that’s not good enough — not for a market-conduct exam, a coverage dispute, or a reinsurer’s diligence. Explainability isn’t a nice-to-have that comes later; it’s the gate between a demo and a deployment.
InsightXtract clears that gate by design. The extraction engine is a reasoning loop with discrete steps — and every run records an ordered trace of those steps as it goes. The trace isn’t a log bolted on for compliance; it’s a byproduct of how the agent works, so it’s always there, for every document.
What the trace records
Each step the agent takes appends an entry: which node ran, what it did, what it touched, and the outcome — including retries. Read top to bottom, it’s the story of the extraction.
effective_date + the loss table; text for the identifiers. 18 fieldsloss_history, each with evidence. Model: claude-sonnet. doneeffective_date confidence 0.58. 2 issuesThe trace is streamed live as the run happens — so an operator sees the agent working through a document instead of staring at a spinner — and it’s persisted with the result, so the same story is available months later for an audit.
The questions a trace answers
| Question | The trace shows… |
|---|---|
| Why is this value what it is? | Which step extracted it, from which strategy, with what evidence and confidence. |
| Why was this field flagged? | The validation check that failed, and whether re-extraction could resolve it. |
| Did the agent correct itself? | The re-extract entries — what failed, what was retried, what changed. |
| Which model & how long? | Provider, model, and per-step timings — for cost and capacity planning. |
| What did it ignore? | Noise it discarded and structure it chose not to trust. |
{ "node": "re_extract", "t_offset_s": 6.0,
"reason": "validate failed: loss table did not foot",
"fields_targeted": ["loss_history", "effective_date"],
"retry": 1, "outcome": "reconciled" }
Why a glass box matters
- It clears the compliance gate. “How did it decide?” has a concrete, per-document answer — the difference between a pilot and production in a regulated line.
- It makes review faster. A reviewer looking at a flagged field sees why it’s flagged and what the agent already tried, instead of re-deriving it.
- It makes the system debuggable. When an extraction is wrong, the trace shows exactly which step went wrong — so you fix a rule or a skill, not guess at a prompt.
- It feeds capacity planning. Per-step timings and model usage across runs tell you where time and cost actually go.
Explainability you don’t have to reconstruct
Because the trace is emitted by the engine as it runs — not reconstructed after the fact — there’s no gap between what the agent did and what the record says it did. Paired with per-field provenance and citations, it’s the full chain: this value, from this source, reached this way.
Read next →
See the loop the trace records: how an extraction agent actually thinks, and how it all stays defensible end to end: auditability by design.