Blog
How PolDex turns insurance documents into proof-backed infrastructure.
Essays on FastScript, schema hardening, evidence, abstention, benchmark gates, agents, credits, security, and the path from commercial P&C into the full insurance document universe.
Start with the control layer.
The first three essays explain the core idea: readers collect candidates, but FastScript decides which insurance facts are safe to return.
Why insurance extraction needs a truth layer
Insurance documents do not just need OCR. They need a system that decides which facts are safe to return, which facts conflict, and which fields should stay unresolved.
7 min readReliabilityEvidence before confidence
A confidence score without evidence is not enough. PolDex treats cited source text, page context, and truth state as part of the output contract.
6 min readEngineInside FastScript
FastScript is the control layer inside PolDex: models read, but schema contracts, evidence rules, abstention, and benchmark gates decide the customer-facing result.
8 min readTwenty-four detailed notes for developers, investors, and agents.
Every article keeps the public story honest: no fake customers, no fake revenue, no fake SOC, and no global accuracy claims beyond named benchmark corpora.
Schema hardening is the product
The insurance universe is broad, but PolDex only promotes a schema after real public documents, source labels, evidence, and benchmark scores prove it.
COIs, policies, and endorsements disagree
Insurance packets often contain multiple versions of the same fact. A reliable extractor must preserve conflict instead of flattening disagreement into one confident value.
Abstention is a feature
In insurance extraction, a missing value is often safer than a wrong value. FastScript is designed to abstain when evidence is weak.
Benchmarking insurance extraction
Insurance extraction benchmarks need document pass rate, required-field score, exact-label score, and evidence score. One aggregate number is not enough.
Agent-ready insurance extraction
Agents need more than an API endpoint. They need schema discovery, cost estimation, explicit confirmation, status polling, evidence, and downloadable artifacts.
Credit estimates and safe spend
PolDex uses prepaid credits and estimates before extraction so developers and agents can control cost before a document is processed.
Webhooks and artifacts are part of extraction
The output is not only JSON in a response. Production extraction needs jobs, webhooks, signed results, CSV, XLSX, ZIP, and manifest workflows.
Processor without workflow lock-in
The PolDex processor gives operators a narrow way to run files, URLs, and pasted text without turning PolDex into a dashboard suite.
The provider-neutral reader layer
OCR, VLMs, layout parsers, and document-reading APIs can all be readers. FastScript decides what becomes insurance truth.
OpenAPI, MCP, CLI, and LLM discovery
PolDex is built for developers and agents that need to discover schemas, estimate cost, run extraction, and retrieve artifacts without guesswork.
Security, retention, and document handling
Insurance documents can contain sensitive business and personal data. PolDex keeps retention, deletion, audit, and procurement posture visible.
Commercial GL and the first proof gate
Commercial General Liability was the first proof-gated schema because it concentrates the core insurance extraction problems: limits, entities, endorsements, and evidence.
Commercial Auto, Workers Comp, and Property
The next commercial lines expanded FastScript beyond liability into vehicle schedules, workers comp identifiers, and property coverage evidence.
Umbrella, Professional Lines, Cyber, D&O, EPLI, and Crime
The later commercial schemas deepen PolDex into follow-form limits, claims-made posture, retentions, continuity dates, cyber limits, management liability, EPLI, and crime coverage.
From documents to insurance workflows
PolDex does not replace broker, carrier, claims, or compliance software. It gives those systems the extraction rail they need when documents arrive.
The Insurance Intake API
The intake API turns submissions, ACORD forms, broker packets, and attachments into normalized underwriting-ready data without becoming an underwriting suite.
The COI Compliance API
COI compliance needs evidence, requirements, limits, endorsements, dates, and conflict states. A generic certificate reader is not enough.
Claims, FNOL, and loss packets
Claims documents need a careful extraction posture because facts, invoices, estimates, medical bills, reports, and settlement material can disagree.
Benefits, health, and reinsurance documents
Benefits, health, and reinsurance expand PolDex beyond commercial P&C, but the same proof rules apply: real documents, evidence, labels, and benchmarks.
Why PolDex is not a workflow suite
Workflow suites try to own the screen. PolDex stays at the infrastructure boundary and lets existing systems keep the workflow.
The road to the full insurance universe
The full PolDex ambition is 56 schema contracts across commercial, consumer, claims, benefits, reinsurance, ACORD, and document primitives, hardened one at a time.