Most extraction tools hand you a confidence number and leave you to interpret it. But a reviewer staring at 0.87 on a policy effective date and 0.87 on a loss ratio has no way to tell them apart — even though one may have been copied verbatim from the declarations page and the other divided out of two other numbers. The number is a scalar; the decision the reviewer has to make is categorical. InsightXtract closes that gap by attaching a standard confidence category to every field, alongside the numeric score, so the output is triage-ready the moment it lands.
The principle is simple: an agent should tell you not only how sure it is about a value, but how it got the value. Those are different things, and the second one is what determines whether a human needs to look. A field that was read straight off the page is trustworthy in a way that a field inferred from a chain of reasoning is not — even when a raw score happens to land them in the same neighborhood.
The four categories
The taxonomy is a fixed, four-value enum. It is the same across every agent on the platform — excess casualty, D&O, loss runs, freeform — so a category means the same thing no matter which agent produced the record.
| Category | Typical score | What it means |
|---|---|---|
| exact | ~1.0 | The value was read verbatim from the document — a labeled field on the ACORD, a number on the declarations page, a cell in the loss run. There is a literal source span behind it. |
| implied | ~0.85 | The value was stated indirectly or drawn from adjacent context — not on its own labeled line, but unambiguous from the surrounding text or layout. |
| inferred | ~0.6 | The value was derived or computed from other values — a loss ratio calculated from incurred and premium, a total summed across rows, a class code reasoned from an operations description. |
| uncertain | ~0.3 | The source was ambiguous, conflicting, or low-quality — two documents disagreed, the scan was poor, or the value could plausibly have been one of several. A flag to look before you trust. |
Notice what the categories are ordered by: not the model’s enthusiasm, but the provenance of the value. Verbatim beats reasoned; reasoned beats guessed. That ordering is what makes the category actionable in a way a raw score is not — two fields can share a score of 0.85 while one is exact at the low end and the other is implied at the high end, and the reviewer wants to know which is which.
The key asymmetry: who assigns the label, who checks it
The most important design decision in the taxonomy is who is allowed to set the category. It splits cleanly:
- The model emits the category. Only the model knows how it obtained each value — whether it copied a labeled field, read it from context, or computed it. That knowledge exists nowhere else in the pipeline, so the model is the source of truth for the label. It emits the category per field, together with the evidence span it relied on.
- The deterministic post-processor validates the label — and can only downgrade it. After extraction, a code pass checks each field against reality: does the value actually parse as the declared type? Was a required field returned empty? Does the numeric score support the claimed category? The post-processor can lower a category when the evidence doesn’t hold up. It can never raise one.
This is deliberate and it is the opposite of how formatting works. For formatting — dates, currency, percentages, booleans — the deterministic post-processor is the source of truth and the prompt is best-effort, because the canonical shape of a date is a mechanical fact that code should own. Confidence is the mirror image: the prompt (the model) is the source of truth, because the way a value was obtained is something only the model witnessed, and code merely audits it.
Why downgrade-only
Code can catch a model that is over-confident — it can prove a value doesn’t parse, or that a required field is missing, and cap the category accordingly. But code cannot prove a value was read more carefully than the model claimed; it has no independent line of sight into provenance. Allowing an upgrade would mean inventing confidence the post-processor never actually established. So the reconciliation is strictly one-directional: validate, and downgrade when warranted.
A concrete downgrade
Suppose the model returns a policy effective date labeled exact, but the numeric score attached to it is 0.82 — below the band the platform associates with exact. The reconciliation step sees the mismatch between the claimed category and the supporting score and downgrades the field to implied. The model’s optimism is corrected by evidence, without ever fabricating confidence in the other direction.
And a field that came back null — not found in the document — gets no confidence at all. There is nothing to be confident about. It carries no category and no score; it is simply absent, which is itself the honest signal. (A required field that comes back empty is capped at uncertain so it surfaces for review rather than sliding through silently.)
How the label travels through the pipeline
The flow below is the same for every agent. The model produces both a category and a score per field; the deterministic pass validates them together and reconciles downward only; the final category is what routing keys off.
emits category + score
+ evidence span] --> B[Validate
type parses? required?
score supports label?] B --> C{Label holds up?} C -- yes --> D[Keep category] C -- no, evidence weaker --> E[Downgrade only
e.g. exact @ 0.82 to implied] D --> F[Final confidence
category per field] E --> F F --> G{Route by category} G -- exact --> H[Auto-accept] G -- implied / inferred / uncertain --> I[Human review]
The model owns the label; code validates and can only lower it; the final category drives routing.
What it looks like in the output
Each field is a small object carrying its value, its numeric confidence, and its confidence category (the same wrapper also holds page and evidence provenance). Here is a trimmed slice of an extracted record:
{
"named_insured": {
"value": "Ridgeline Freight Systems LLC",
"confidence": 0.99,
"confidence_category": "exact"
},
"policy_effective_date": {
"value": "2025-01-01",
"confidence": 0.82,
"confidence_category": "implied"
},
"loss_ratio_2024": {
"value": 0.63,
"confidence": 0.60,
"confidence_category": "inferred"
},
"iso_gl_class_code": {
"value": "50091",
"confidence": 0.31,
"confidence_category": "uncertain"
},
"umbrella_aggregate_erosion": {
"value": null,
"confidence_category": null
}
}Named insured read verbatim (exact); effective date started as exact but was reconciled to implied at 0.82; loss ratio computed from incurred and premium (inferred); a class code the source left ambiguous (uncertain); and a field not found in the packet, carrying no confidence at all.
How reviewers use it: the category is a triage signal
The point of the taxonomy is not decoration — it is to route work. Because the category is standard and provenance-ordered, a review queue can be built on it directly, without anyone eyeballing scores field by field. A typical routing policy:
| Category | Default action | Reviewer’s question |
|---|---|---|
| exact | Auto-accept | Nothing — it was read verbatim. Sample for QA, don’t gate on it. |
| implied | Spot-check | Was the context read the way I’d read it? Usually yes. |
| inferred | Route to review | Is the derivation sound and are the inputs right? |
| uncertain | Always review | Which reading is correct — and which source do I trust? |
The effect is that a reviewer’s attention lands exactly where it is worth spending. On a 50-field submission record, the great majority of fields are exact and clear straight through; the handful that are inferred or uncertain are the ones that pull a human in. The reviewer opens the record already knowing which four fields to look at instead of re-reading all fifty. That is the difference between a category and a bare number: the number needs a threshold and a judgment call every time; the category already made the call.
Configurable bands, one standard taxonomy
Two things are true at once, and keeping them separate is what makes the system both consistent and tunable:
- The taxonomy is standard and fixed. The four categories — exact, implied, inferred, uncertain — are the same across every agent. A category label means the same thing whether it came off the excess casualty agent or the D&O agent, which is what lets you build review policy and portfolio reporting on top of it.
- The bands are configurable at the platform level. The numeric thresholds that map a score to a category — where exact ends and implied begins — are admin-tunable in one place. A team that wants to be stricter can raise the bar for exact so more borderline fields fall to implied and get a second look, without touching any agent’s configuration.
So the vocabulary is shared and the sensitivity is a dial. You never redefine what the categories mean; you only adjust where the boundaries between them sit, globally, and every agent inherits the change.
Why it matters
Confidence that you can only read as a number is confidence you can’t operationalize. A category turns a scalar into a decision:
- Review goes where the risk is. Auto-accepting exact and routing inferred and uncertain to a person means human time is spent on the values a machine genuinely shouldn’t decide alone — the derived and the ambiguous — not on the ones read straight off the page.
- The label is honest by construction. Because only the model can raise a category and code can only lower it, the confidence you see is never inflated by a post-hoc process. It reflects how the value was actually obtained, checked against whether the value holds up.
- Absence is explicit. A not-found field is
nullwith no confidence — never a fabricated low score, never a blank guess. You can tell “we didn’t find it” from “we found it and we’re unsure,” and those call for different actions. - It is consistent across the book. Because the taxonomy is standard, the same triage rules and the same quality metrics apply to every agent. You can report the share of exact fields across a whole portfolio and watch it as a data-quality signal, not one document at a time.
Every field InsightXtract returns carries this today: a value, a numeric confidence, and a standard confidence category, with the category emitted by the model that knows how the value was obtained and validated — downgrade-only — by a deterministic pass that checks whether it holds up. The categories are the same across every agent; only the band thresholds are a platform-level dial. The result is output you can route on the moment it arrives, instead of a number you still have to interpret.
Related reading →
See what a fully consolidated record looks like: inside an excess casualty submission — what InsightXtract extracts and why it matters.