No raw LLM truth
PolDex does not ask a model to produce final customer-facing insurance truth. Models can read text, tables, pages, and clauses. FastScript decides what survives into the output contract.
FastScript
Insurance Reliability Engine
LLMs made documents readable. FastScript makes insurance documents reliable.
PolDex is the first dedicated insurance truth layer, turning raw documents or parser output into 99%+ benchmarked, evidence-backed, schema-controlled insurance data.
FastScript is the engine inside PolDex. It does not prompt an LLM and expose the answer as the product. It turns model reads into schema-controlled, evidence-backed, benchmark-gated insurance data.
The point is accuracy, not completion theater. FastScript goes through the document, preserves evidence, exposes conflicts, abstains when the proof is weak, and returns stable output through API, processor, exports, webhooks, MCP, CLI, and agent-ready endpoints.
FastScript also lets PolDex sit underneath existing parser stacks. Customers can parse with Hyperscience, Docugami, Reducto, Unstructured, LlamaParse, cloud OCR, or internal tools, then send parsed output to PolDex for insurance adjudication.
The moat compounds because every schema, evidence span, correction, conflict rule, benchmark case, and real insurance document makes the engine wiser and harder to replace.
Operating Principle
PolDex is not betting the company on raw model output.
Foundation models are useful readers. They are not the system of record. FastScript is the controlled extraction layer that decides what becomes insurance truth.
That boundary is parser-neutral: parse with whoever you trust, adjudicate with PolDex.
Evidence before confidence
A value is only useful when the system can point to why it exists: page, section, source text, form role, extraction state, confidence, and whether the evidence was strong enough.
Accuracy over completion
FastScript is designed to abstain, flag conflicts, and mark unresolved fields instead of filling every field with a plausible answer. In insurance, a wrong value is worse than a missing value.
Insurance documents deserve care
Policies, COIs, endorsements, schedules, claims packets, and requirements documents are not generic PDFs. FastScript reads them as insurance artifacts with authority, overrides, conflicts, and audit risk.
Schema scope is a contract
A commercial GL run should not leak personal auto, homeowners, life, or unrelated line output. FastScript shapes the final JSON, CSV, and XLSX around the requested schema only.
Control Stack
Models read. FastScript controls.
Insurance extraction cannot stop at text. Policy data needs source authority, field contracts, normalization, missing-value handling, conflict handling, and audit-ready evidence.
Document fingerprinting
Identify document family, insurance line, source type, carrier/form signals, page structure, table density, schedule behavior, and whether the document is supported, unsupported, or partially supported.
Schema contracts
Each schema defines the fields PolDex will return, their expected evidence, normalization rules, truth states, missing-value handling, export mapping, and benchmark requirements.
Output shaping
Candidate facts are filtered back to the requested schema before packaging so unrelated line evidence, unsupported facts, and noisy abstentions do not pollute customer output.
Evidence normalization
Candidate reads are converted into cited facts with source text, page references, form context, provenance, confidence, and evidence quality so downstream systems can audit the result.
Conflict graph
Insurance packets disagree. Declarations, endorsements, COIs, schedules, and requirements can state different versions of a fact. FastScript preserves those disagreements instead of flattening them away.
Adjudication rules
Line-specific rules decide when a value is accepted, when an endorsement overrides a base policy, when a value is unresolved, and when weak evidence must be rejected.
Provider abstraction
Foundation models are replaceable readers inside PolDex. FastScript is the customer-facing behavior: stable schemas, validation, evidence, exports, and release gates regardless of model routing.
Benchmark gate
All 56 schema families cleared the 100+ document release gate. New major extraction changes keep passing required-field scoring, evidence checks, and regression tests before they touch the public accuracy surface.
Operational rails
Credits, estimates, holds, retries, signed artifacts, webhooks, connector events, processor downloads, API responses, and agent calls all wrap the same FastScript-controlled result.
Output Contract
Every returned value needs a reason to exist.
FastScript is built around a simple rule: do not just return the answer. Return the answer, the evidence, the state of certainty, and the shape downstream systems can trust.
| Output part | Why it matters |
|---|---|
| Field value | The normalized value PolDex is willing to return to a user, API client, processor export, or agent. |
| Evidence | The page, snippet, form context, table row, clause, or source signal that supports the field. |
| Truth state | present, absent, unresolved, conflicting, inferred, unsupported, low confidence, or review required. |
| Conflict state | Whether a certificate, policy, endorsement, schedule, or packet item disagrees with another source. |
| Confidence | A controlled signal derived from evidence strength and rule outcome, not just a raw model probability. |
| Export mapping | The stable JSON field path and the derived CSV, XLSX, ZIP, webhook, connector, MCP, and CLI artifact shape. |
Execution Path
The document moves through an adjudication engine, not a prompt.
Customer-facing behavior is controlled by FastScript. The reader layer can improve over time without changing the API, processor, CLI, MCP, or export contracts.
01
Classify
Detect document family, schema fit, source role, insurance line, carrier/form hints, packet structure, and support state.
02
Read
Use model readers to collect candidates from text, tables, spans, clauses, schedules, endorsements, and page-level context.
03
Ground
Attach evidence to each candidate: page, text, form region, table row, source authority, and extraction provenance.
04
Normalize
Convert candidates into canonical insurance fields, money/date/entity formats, enum states, and stable JSON paths.
05
Adjudicate
Accept, reject, abstain, or preserve conflict based on schema rules, evidence quality, authority hierarchy, and benchmark behavior.
06
Package
Return API JSON and derive processor exports, webhooks, signed files, connector payloads, MCP responses, and CLI output from the same truth source.
Compounding Moat
The head start is the evidence memory.
Competitors can copy visible pages, claim extraction, and call similar models. They cannot instantly copy the accumulated insurance memory that comes from documents, labels, corrections, and release history.
| Owned asset | How it compounds |
|---|---|
| Private corpus memory | Every real document family teaches FastScript how insurance data appears, disappears, contradicts itself, and moves between forms, schedules, endorsements, and packets. |
| Gold labels | Expected values, evidence spans, page references, and known misses become release material. That makes each schema harder to copy than a prompt. |
| Schema memory | FastScript remembers field behavior by insurance line and document family: where limits hide, how names vary, when dates conflict, and what evidence is sufficient. |
| Correction loop | Processor corrections, failed extractions, benchmark misses, support cases, and customer overrides become new tests, rules, labels, and extraction states. |
| Authority rules | Policy versus endorsement, COI versus policy, declaration versus schedule, current term versus prior term, and table versus clause logic compound over time. |
| Release history | A benchmarked history of what changed, what improved, what regressed, and which fields are safe to claim publicly becomes an operational moat. |
Defensibility
Why this gets harder to copy every month.
The defensibility is not secrecy around one trick. It is the combination of corpus, labels, evidence, schema memory, authority rules, and correction loops around a vertical where mistakes are expensive.
Competitors can copy the claim
They can say evidence-backed extraction. They can add a schema. They can call the same models. That does not give them the document memory, gold labels, correction history, and insurance authority rules.
Competitors cannot copy the learning loop instantly
The loop compounds: document, extraction, evidence, correction, gold label, rule update, benchmark, release gate. The longer PolDex runs, the more expensive it becomes to recreate the behavior.
Competitors cannot win with a model switch
If a better model appears, PolDex can route it as a reader. FastScript remains the control layer. The moat is the insurance reliability system around the model, not the model vendor.
Competitors cannot fake trust forever
Insurance buyers care about wrong limits, wrong dates, wrong insureds, missing endorsements, and unsupported claims. FastScript is built to show evidence, abstain, and expose uncertainty before bad data enters a workflow.
Learning Loop
Every difficult document should make the engine wiser.
From output to evidence memory
A processor correction, failed extraction, benchmark miss, customer override, support report, or disputed field should become a labeled case that strengthens FastScript rather than disappearing inside support chat.
From evidence memory to rules
Repeated field behavior becomes schema memory: which page is authoritative, which schedule overrides which policy field, when a COI is insufficient, and when a claim packet contains duplicate facts.
From rules to benchmark gates
The benchmark program turns that memory into release protection: new behavior must pass field scoring, evidence scoring, abstention checks, and regression tests before it joins the public 99%+ accuracy surface.
Maturity
Real today, compounding into the moat.
FastScript is already the control layer behind PolDex surfaces. The enduring moat is the benchmark-trained insurance memory that grows as PolDex sees more real documents.
Today
Live control layer
Schema-bound output, evidence posture, conflict states, processor/API/playground/live proof integration, exports, webhooks, agent-facing discovery, and 56 release-ready schemas passing the 100+ document release gate.
Near term
Benchmark-trained reliability
More real documents, gold labels, page-level evidence, field scoring, correction loops, and regression gates deepen the 99%+ release surface.
Long term
Insurance memory engine
A growing library of insurance document behavior, authority rules, carrier/form fingerprints, jurisdiction variants, and release-tested schema intelligence.
Boundary
What FastScript is not.
Not a prompt wrapper
The final product is not a long prompt asking an LLM to extract JSON. The final product is a controlled engine that decides what evidence-backed facts become customer-facing output.
Not evidence theater
Unknown fields do not get borrowed citations, and guardrail pass/fail is computed from required fields, evidence, conflicts, and unresolved critical fields.
Not generic OCR
OCR can tell you what text appeared. FastScript is built to decide what insurance fact that text supports, whether it conflicts, and whether it is safe to return.
Not workflow lock-in
PolDex does not force customers into our workflow. FastScript powers API, processor, webhooks, MCP, CLI, exports, and existing systems.
99%+ accuracy release
56 release-ready schema contracts across 7 insurance families have 100+ source-verified real-public documents and passing release-gate scores. The 99%+ accuracy claim is active across the full schema universe; customer, revenue, SOC, and marketplace claims remain separate and only appear when independently true.
FastScript is the compounding part of PolDex.
Every schema, benchmark, customer document family, correction, conflict rule, and evidence pattern strengthens the control layer behind the public API.