An insurance submission is never one document, and the data you need is never in one shape. A broker email, an ACORD application, an exposure workbook, and a stack of ACORD forms each hold a piece of the same account — and your downstream systems want a single, clean, predictable record. The gap between “what the tool extracted” and “the schema my PAS expects” is where teams quietly spend months building and maintaining glue code.

InsightXtract closes that gap with an output contract. Instead of accepting whatever the extractor produces and transforming it yourself, you define the target record up front — and the agentic engine extracts each source document, then assembles, standardizes, validates, and provenance-tags the result to your contract. The contract is the spec the whole run is measured against.

What an output contract declares

A contract has four parts, all declarative:

PartWhat it defines
Document rolesWhich document plays which part — and which are required. (email, application, exposure workbook, ACORD forms…)
Output schemaThe target fields and tables: type, required, the source priority across documents, and any lookup/standardization to apply.
Post-processingHow raw values become clean ones — standardize, format, derive, validate.
Output formatThe shape and guarantees: include provenance, include validation, strict conformance.
# master_config — the output contract for an Excess Casualty submission
document_roles:
  - { role: submission_email, document_class: excess_casualty_submission_email, required: true }
  - { role: application_form, document_class: excess_casualty_application, required: true }
  - { role: exposure_workbook, document_class: excess_casualty_exposure_workbook, required: true }
  - { role: acord_forms, document_class: excess_casualty_acord, required: false, max_count: 5 }

output_schema:
  fields:
    - name: insured_name
      type: string  required: true
      sources:  # priority: which document wins
        - { role: acord_forms, priority: 1 }
        - { role: application_form, priority: 2 }
    - name: insured_state  lookup: us_state_codes  # auto-standardize
    - name: naics_code    lookup: naics_codes
  tables:
    - name: exposure_schedule  source_role: exposure_workbook

output_format:
  include_provenance: true  # every field → its source doc & page
  include_validation: true  # attach the validation outcomes
  include_class_fields: true # keep extra per-doc fields too
  strict: true         # conform to the schema, or flag

Notice what the contract carries: the source priority that drives conflict resolution when documents disagree, the lookups that standardize codes, the authoritative source_role for each table, and the output guarantees — provenance, validation, and strict conformance. The record isn’t a byproduct; it’s the specification.

How the run honors the contract

flowchart LR D1[Email] --> X[extract each doc
to its class spec] D2[Application] --> X D3[Exposure workbook] --> X D4[ACORD forms] --> X X --> A[assemble to contract
source priority per field] A --> S[standardize & validate
lookups · rules] S --> O["one governed record
+ provenance + validation"]

Each document is extracted independently against its own class spec, then the engine assembles the unified record field by field — taking each value from the highest-priority source that has it, standardizing codes through the declared lookups, and running the validation rules. The output is exactly the shape you declared, with every value tagged to the document and page it came from.

InsightXtract agent overview — an Excess Casualty agent that turns four document types into 38 coded output fields, six glossaries, and dozens of rules, all defined by its output contract
The contract, made real: one agent turns four document types into a single governed record of coded fields and tables.

Why declaring the record changes everything

  • No downstream ETL. The output already matches the schema your PAS, warehouse, or API expects — there’s no reshape-and-rename layer to build and maintain.
  • Change is a config edit, not a code change. Add a field to the contract and the next run fills it — from the sources you name — with no engineering ticket.
  • Consistency you can measure. Because every run targets the same declared schema, results are directly comparable — which is what makes evaluation and regression testing meaningful.
  • Guarantees, not hopes. strict conformance means a value that can’t be shaped to the contract is flagged, not silently dropped or mistyped. Provenance and validation ride along by default.

One extraction, many consumers

Because the canonical record is governed and provenance-tagged, the same run can feed an underwriter’s workbench, a straight-through API response, and a BI warehouse — without re-extracting. The contract decouples how the documents are read from how the record is delivered, so a new consumer is a new mapping, not a new extraction project.

Where it sits in the engine

The output contract is the frame around everything else in this series: the reasoning loop extracts each document, conflict resolution picks the winning value by the contract’s source priority, and post-processing cleans it to the contract’s rules. You define the destination; the agent finds the safest route there.