Keep the parser, add insurance truth

Compatibility

PolDex can operate underneath an existing parser. Customers send parsed markdown, text, JSON, tables, or parser events into FastScript for insurance-specific schema enforcement, evidence grounding, conflicts, and exports.

This is a compatibility architecture and API rail. It does not disclose or market PolDex internal reader choices.

Status	Integration proof case
Audience	Teams already using Hyperscience, Docugami, Reducto, Unstructured, LlamaParse, cloud OCR, or internal parsers
Schema or surface	`parser_output`

All Case Studies Compatibility ->

Before / After

The job PolDex takes off the workflow.

The product boundary is narrow: turn messy insurance evidence or parser output into reliable, schema-controlled data that another system can use.

Before

Manual or generic extraction

A team may already have parser approvals, privacy reviews, or workflow investment in another document system.
Parsed text alone still lacks insurance truth states, schema enforcement, conflict handling, abstention, and benchmark posture.
Switching parsers can slow enterprise adoption even when the real missing piece is insurance adjudication.

After

PolDex output

The raw PDF can remain inside the customer parser or compliance boundary.
PolDex receives parsed output and runs FastScript as the insurance truth layer.
Parsed-output mode uses a lighter credit policy than full raw-document extraction.

Workflow

How the proof path runs.

Parse upstream

The customer uses their existing parser or OCR system to produce markdown, text, JSON, tables, or an event payload.

Import parsed output

The customer calls POST /v1/connectors/parser-output/import or a partner-specific import rail.

Adjudicate with FastScript

PolDex enforces schema scope, evidence rules, normalization, conflicts, unresolved fields, and exports.

Deliver to systems

Structured insurance truth moves to the API response, signed artifacts, webhooks, agents, or review cockpit.

Output

What downstream systems can use.

These are the fields or artifacts this case study is meant to make legible to databases, workflows, operators, and AI agents.

Structured output

Data contract

parser_output_import_id
selected_schema
credit_policy
credits_captured
facts
evidence
conflicts
unresolved_items
artifacts
webhook_event

Proof

Evidence contract

Customer-provided parser provenance
Parsed text or table excerpts used for labels
FastScript evidence and abstention state
No need for PolDex to see raw PDFs in parser-output mode

Try It