Models are readers
Foundation models are strong at reading text, tables, pages, and clauses. PolDex uses that strength, but it does not make raw model output the product. A reader can produce candidates. FastScript decides whether those candidates become insurance facts.
This separation keeps PolDex provider-neutral. A document can be read by OCR, a vision model, a layout parser, or a future document reader. The customer-facing contract stays stable because FastScript owns the schema, evidence, validation, and packaging layer.
The control stack
FastScript fingerprints documents, applies schema contracts, normalizes candidates, records evidence, preserves conflicts, adjudicates authority, and packages the result into API, processor, webhook, artifact, MCP, and CLI outputs.
That stack is deliberately stricter than prompt-to-JSON. A schema defines fields, evidence expectations, normalization rules, missing-value handling, export mapping, and benchmark requirements. The schema is not just a TypeScript type. It is the behavior contract for the product.
Why it compounds
Every real document, label, correction, failed extraction, source span, rule update, and benchmark result improves the control layer. The moat is not one secret prompt. It is the growing operating memory of how insurance documents behave.
That is also why PolDex hardens schemas one by one. A schema does not become callable because it exists in a registry. It becomes callable when it clears a named proof gate and can be defended with source-verifiable evidence.