- contact@insightxtract.com
How the pieces fit — a governance-first hierarchy, an agentic reasoning loop, multi-format intake, a type-driven data contract, and an integration surface — all running inside your cloud, on your model.
Submission intake is where specialty P&C carriers lose the most time and gain the least leverage from automation — because every submission is a bundle of mixed formats carrying overlapping facts. This paper describes a reference architecture for solving it with agents rather than templates: a governance-first configuration hierarchy, an agent that reasons over each document independently and consolidates by source priority, a type-driven data contract, connectors and an API gateway for integration, and human-in-the-loop review that feeds tuning. Its defining constraint is the data boundary: everything runs in the customer's own cloud, on the customer's own model. This is a description of the design, not a benchmark report.
The hard part of submission intake is not reading one document — it is producing one trustworthy record from many.
A submission arrives as an email with attachments: a broker application, an ACORD form, an exposure workbook, sometimes a loss run. The formats differ, the facts overlap, and occasionally they contradict. A template-driven pipeline breaks the moment a broker reformats a spreadsheet. The architecture described here takes a different stance: it treats every part of a submission as a first-class document, extracts each one independently through a reasoning agent, and consolidates the results into a single downstream-ready record with provenance and confidence attached. Just as important for enterprise evaluators, it runs entirely within your environment — your cloud account, your choice of model — so no submission data leaves the boundary you already govern.
Three principles shape every component. They are the questions an evaluator should ask of any intake platform, and the answers this architecture commits to.
Configuration is not scattered across documents — it is organized as a hierarchy: Organization → Business Unit → Document class. A Business Unit is a project. When the engine needs a setting — a glossary, an output rule, a model choice — it resolves it most-specific-wins: the document class overrides the Business Unit, which overrides the Organization. Every configuration object is versioned with draft and publish states, so a change is authored, reviewed, and released deliberately rather than taking effect the instant someone edits it. Governance is the foundation, not an afterthought bolted on for audit.
The platform is designed to be deployed into the customer's own cloud and to call the customer's own model. There is no vendor-hosted inference tier that submission data must traverse. For a security reviewer, the data-flow diagram stays inside a single account: object store, metadata database, vector index, and model endpoint are all resources you own and monitor.
Extraction is performed by an agent that reasons about a document — forming a plan, checking its own output, and correcting itself — rather than matching fixed field coordinates. Templates are brittle against the format drift that is normal in broker-sourced documents; a reasoning loop degrades gracefully and can explain what it did. This is the design decision that makes the rest of the architecture worth building.
End to end, a submission flows through seven stages. Ingest normalizes whatever arrived into first-class documents; classification assigns each a role; per-document extraction runs the reasoning loop against the matching document-class spec; consolidation merges by source priority; the data contract shapes the unified record; routing decides what a human sees; and the result is returned by API or written back to a system of record.
flowchart TD
A["Ingest / Connectors
email · folders · API · uploads"] --> B["Classify
role per document"]
B --> C["Per-document Extract
perceive → plan → extract → validate → reflect"]
C --> D["Consolidate
merge by source priority + conflict reasoning"]
D --> E["Data Contract
type-driven output + glossary / lookup standardization"]
E --> F["Route / HITL
confidence routing → auto-accept or review queue"]
F --> G["API response / Write-back
SharePoint · S3 · policy admin"]
F -.->|corrections| C
Two properties of this diagram matter. First, the loop from Route / HITL back to Extract is the continuous-improvement path: reviewer corrections become tuning signal. Second, no stage reaches outside the customer's environment — the only external call is to the model endpoint the customer configured, which itself can be in-account (e.g. Bedrock, Vertex, or Azure OpenAI).
The hierarchy is the control plane. An Organization sets defaults for the whole tenant. Each Business Unit — a project, typically one line of business or one team — refines them. Each Document class (application, ACORD form, exposure workbook, loss run) carries the most specific configuration of all: its field schema, its bound glossaries and lookups, its extraction and validation rules.
Resolution is most-specific-wins. When the engine extracts an exposure workbook for the Excess Casualty unit, it composes configuration from the document class first, then fills gaps from the Business Unit, then from the Organization. This keeps common policy in one place while allowing any level to override without copying settings downward.
Every configuration object is versioned with a draft/publish lifecycle. A builder edits a draft, reviews the diff, and publishes; a published version is what production runs. Rolling back is selecting a prior version, not reconstructing lost state. Access to all of this is governed by role-based access control:
| Role | Can do |
|---|---|
| Admin | Full control: tenant settings, users, roles, connectors, deployment configuration. |
| Builder | Author and publish document classes, schemas, glossaries, rules, and master configuration. |
| Operator | Run and monitor intake — upload bundles, trigger runs, watch pipeline status. |
| Reviewer | Work the review queue: accept, correct, and comment on flagged fields. |
| Viewer | Read-only access to results and dashboards; no changes. |
Permission enforcement is applied at the service layer, so a role's limits hold regardless of which surface — UI, API, or connector — initiated the request.
At the center is an agent running a five-step reasoning loop, per document:
Crucially, each document in a submission is classified to a role and extracted independently through its own document-class spec. The application is not contaminated by the ACORD form; the exposure workbook is read as a workbook, not as loose text. Only after every document has its own clean result does a consolidation step merge them.
Consolidation is not a naive union. It merges by source priority — for any given field, the architecture knows which document type is the authoritative source — and applies conflict reasoning when sources disagree. Where the broker email says one thing and the ACORD form another, priority decides, and the decision is recorded with its provenance. This is why the unified record can be trusted: it is a deliberate merge, not a last-writer-wins accident.
Why independence then merge? Extracting everything in one pass forces the model to reconcile contradictions while it is still reading — the worst time to do it. Independent extraction keeps each document's evidence pristine, and moves reconciliation into an explicit, auditable step where source priority is a rule, not a guess.
Every part of a submission becomes a first-class document, and each format takes the path that preserves the most signal:
| Format | How it's handled |
|---|---|
| Email (.eml / .msg) | Exploded into body + attachments; each part becomes its own document and is classified and extracted separately. |
| Word / office | Converted to PDF, then read with vision — same layout fidelity and citations as a native PDF. |
| Excel | Read by a deterministic layout analyzer that distinguishes metadata blocks from tables and maps header names — no model guessing cell positions. |
| PDF / scans | Vision extraction over rendered pages, with bounding-box citations tying each value to where it appears. |
Treating every part as first-class is what lets governance, extraction, and consolidation apply uniformly — an attachment gets the same document-class spec, the same review, and the same provenance as a directly uploaded file.
The architecture exposes two integration modes so it fits both batch and real-time systems.
Submissions can arrive through watched folders whose layout follows a template — for example year / insured / submission-id. The connector picks up new bundles, runs them, and can write run metadata and results back to the originating system: SharePoint, S3, or a policy administration system. The round-trip means the platform slots into an existing document workflow without asking the business to change where it puts files.
Applications can POST a document bundle and receive a structured record with provenance and confidence. The gateway is secured by API key or OAuth, supports idempotency keys so a retried submission is not processed twice, and offers webhooks for asynchronous completion on larger bundles.
Both modes return the same shape — the type-driven data contract — so a downstream system integrates once regardless of how the submission arrived. See The data contract for how a global, type-driven output specification plus glossary and lookup standardization yields one record shape across every line of business.
Confidence is a first-class output, and it drives routing. High-confidence fields auto-accept; uncertain fields go to a review queue where a reviewer confirms or corrects them. The unit of review is the field, not the document — a reviewer spends attention only where the agent was unsure, not re-keying values it got right.
Corrections are not discarded after a run. They are captured and feed agent tuning over time, so the fields and document types that most often need review are exactly the ones the system improves at. The feedback loop in the pipeline diagram is this mechanism: review is both a quality gate today and the training signal for tomorrow. For how correctness is measured against known ground truth, see Measuring extraction accuracy.
The deployment model is the architecture's strongest commitment to enterprise evaluators: it runs entirely in the customer's environment.
For a security reviewer, the consequence is a clean architecture review: the trust boundary is the customer's account, the datastores are theirs, and the model endpoint is theirs to choose and monitor. Nothing about intake requires data to leave. See the deployment documentation for reference topologies and the concrete managed services on each cloud.
The claim this architecture makes. Not that agents are magic — but that submission intake becomes governable when configuration is a versioned hierarchy, extraction is a reasoning loop with provenance, consolidation is an explicit priority decision, and the whole thing runs inside a boundary you already control. That is an architecture you can evaluate on its own terms.
We'll walk your architecture, security, and platform teams through a reference deployment in your cloud, on your model — and run it against a sample of your real submissions.
Talk to us → Next: Measuring accuracy →InsightXtract — agentic document extraction for specialty P&C. This paper describes a reference architecture and the design decisions behind it; it does not report benchmark figures. For measured accuracy results, see the accuracy whitepaper.