Inside an architects & engineers submission: what InsightXtract extracts — and why it matters

Architects & engineers professional liability is a design-risk line, not a property or fleet line — and that changes what matters at intake. There are no vehicles or statements of value to schedule. What decides the price is the nature of the work: what disciplines the firm practices, how many licensed professionals it employs, how much it bills, what kinds of projects it designs, and what has gone wrong before. A structural firm doing hospitals and parking garages is a very different exposure from a residential interior-architecture practice doing the same annual billings — and the claims-made trigger, with its retroactive date, means the firm’s entire prior-acts tail rides on a single date field.

Most intake tools read the application, hand back a flat list of fields, and drop the tables on the floor. That is not how an A&E account is underwritten. InsightXtract runs an agentic, multi-document pipeline that classifies each file, extracts to a per-document schema, consolidates the broker email and the application into one unified account record, standardizes codes against reference data and glossaries, and validates the result against your rules — so the underwriter opens a single, coded, cited record instead of a PDF and an email thread.

One submission, two documents, one connected record — classify, extract, consolidate, standardize, validate.

The idea that governs everything: the work is the risk

Before the fields, the single most important concept. In A&E, the annual billings number tells you almost nothing on its own — the project mix is the risk. Two firms can bill the same $8M a year and carry wildly different loss potential depending on whether that revenue comes from single-family residential, commercial office fit-outs, hospitals, bridges, or geotechnical work. That is why InsightXtract does not just capture the billings figure; it captures the project-types table — each project type with its percentage of billings — and standardizes the project type against a glossary so “hospital,” “healthcare,” and “medical facility” all resolve to one canonical class.

In the tables below, the Captured column flags how each field is stored:

• Point-in-time — a single static fact about the firm or the account.
• Current term — a value for the coverage being requested this term.
• Per-row — a table: one project type, or one claim, per row.
• Standardized — normalized against reference data or a glossary so it’s comparable across the book.

A · Insured firm & identity

Who the firm is — legal identity, address, classification, and tenure. This is the account key everything else hangs off. Source: A&E application.

Field	Captured	Why it matters
insured_name · dba_name · fein	Point-in-time	The contract party and unique account key — drives clearance, conflicts, and de-dupe.
insured_address · insured_city · insured_state · insured_zip	Standardized	Location and venue; insured_state is normalized to a US state code so venue rolls up cleanly.
business_description · naics_code	Standardized	Class-based appetite and knockout; naics_code is validated against the NAICS reference table.
entity_type · years_in_business · website	Point-in-time	Legal structure and stability credit — a longer-tenured firm is a different risk than a new practice.

B · Broker & submission

Who is placing the account and what they’re asking for — the distribution chain and the transaction type. Source: broker email.

Field	Captured	Why it matters
broker_name · broker_company · broker_email	Point-in-time	Distribution routing, binding authority, and correspondence — who to go back to for missing items.
submission_type	Current term	New vs. renewal — sets the workflow and whether there’s a rate-change baseline to beat.

These four fields come from the submission_email role, not the application. That split matters: the broker email is the source of truth for the distribution chain and the ask, while the application is the source of truth for the firm and the risk. InsightXtract keeps each field bound to its declared source so provenance is never guessed.

C · Firm profile — the exposure base

This is the heart of A&E exposure. What the firm does, how many licensed professionals stand behind the work, and how much it bills. Source: A&E application.

Field	Captured	Why it matters
disciplines	Point-in-time	Architecture, structural, civil, MEP, geotechnical — the practice areas that define the hazard grade of the work.
number_of_licensed_professionals	Point-in-time	The professional headcount standing behind the designs — a primary rating base and a signal of firm scale.
annual_billings	Standardized	The revenue exposure base, formatted as currency — but read alongside the project mix, never alone.

D · Coverage & limits — the claims-made ask

The exact shape of the professional liability cover being requested — limits, retention, and the claims-made mechanics that define the tail. Source: A&E application.

Field	Captured	Why it matters
retroactive_date	Current term	The single most important date in claims-made cover — it defines the prior-acts tail the policy will answer for.
each_occurrence_limit · aggregate_limit	Current term	The per-claim and annual capacity — the core of the ask, formatted as currency.
requested_limit	Current term	The limit the broker is asking to place — checked against each-claim and aggregate for consistency.
deductible · retention	Current term	The firm’s own risk retention — affects net exposure, price, and the firm’s incentive to manage claims.
premium · primary_or_excess	Current term	The price and the layer position — primary vs. excess changes how the limit is exposed.
effective_date · expiration_date	Standardized	The policy term, normalized to ISO dates — drives binding deadlines and concurrency with the retro date.

E · The project-mix table — one row per project type

The table that turns a billings figure into a risk profile. InsightXtract reads the firm’s work breakdown as a table — one row per project type — and standardizes the type. Source: A&E application, table project_types.

Column	Captured	Why it matters
project_type	Per-row Standardized	The kind of work — standardized via the ae_project_types glossary so “hospital,” “healthcare,” and “medical facility” resolve to one class, making project mix comparable across the whole book.
billings_percent	Per-row	The share of revenue in that project type — the weight that turns a discipline into a dollar-weighted exposure.

This is where standardization earns its keep. Without the glossary, project mix is free text — unqueryable and impossible to aggregate. With it, every A&E submission speaks the same vocabulary, so an underwriter can ask “how much of this firm’s book is high-hazard structural work?” and get an answer, and a portfolio manager can see project-type concentration across every account at once.

F · The claims-history table — one row per prior claim

The single biggest pricing input on any liability line. InsightXtract reads each prior claim as a row, with the financials that show cost and development. Source: A&E application, table claims_history.

Column	Captured	Why it matters
claim_number · date_of_loss	Per-row	Each claim’s identity and timing — date_of_loss is normalized to an ISO date so frequency-over-time is computable.
description · status	Per-row	The nature of the error and whether the claim is open or closed — open claims carry future development.
paid · reserve · incurred	Per-row	Cost to date, money still held against the claim, and total incurred — the shape of the loss, formatted as currency.

Reading claims as structured rows — not a blob of text — is what lets the rest of the system reason about them: total incurred across the history, the ratio of open to closed, the largest single loss, and whether reserves are developing. A firm with three small closed claims is a different risk from one with a single large open reserve, even if the headline count is similar.

From two documents to one connected record

Pulling these fields out of the email and the application is only half the job. The value is in consolidation: the firm named on the application, the broker on the email, the coverage ask, the project mix, and the claims all describe one account. InsightXtract merges them into a single record by the source-of-truth priority declared in the contract — the application is authoritative for firm and risk fields, the email for the broker and submission type — then standardizes codes (state, NAICS) against reference tables and project types against the glossary, and validates the result. The insured_name is required; insured_state and naics_code raise warnings if they don’t match reference data.

Why it matters to the business

Comprehensive, structured, standardized extraction isn’t a data-entry nicety — it changes the economics and quality of the A&E book:

• Project mix is priced, not guessed. Capturing the project_types table with standardized types — instead of a single billings number — lets you rate to the actual hazard of the work, which is where A&E money is won or lost.
• The claims-made tail is protected. Extracting retroactive_date, effective_date, and expiration_date as first-class, ISO-normalized fields means the prior-acts exposure and any date inconsistency surface at intake — not at claim time.
• Billings exposure is read in context. annual_billings and number_of_licensed_professionals together give a real sense of scale and revenue-per-professional, a far better exposure signal than billings alone.
• Loss history is computable. Reading the claims_history table as rows — with paid, reserve, and incurred — lets the system roll up total incurred, open exposure, and severity instead of leaving them in prose.
• Consistency and auditability. The same fields, coded the same way, every time — with provenance, confidence, and validation on every value. That is the difference between a repeatable book and one that depends on which underwriter opened the file.

The Architects & Engineers agent extracts all of this today — the firm identity and profile, the broker and submission, the full claims-made coverage and limits, the standardized project-mix table, and the claims-history table — consolidated into one coded record from the broker email and the application, every value cited to its source, codes normalized against reference data and the ae_project_types glossary, and each field carrying provenance, confidence, and validation. And because it’s all configuration — fields and tables in the agent’s output contract, not code — the schema keeps pace with what A&E underwriters ask for.