Inside a builders risk submission: what InsightXtract extracts — and why it matters

Builders risk is a course-of-construction cover, and that makes it unusual. You are not insuring a stable, existing business — you are insuring a project that starts at ground level, rises in value every month, and disappears the day it is complete. The exposure is the building being built, valued at completion; the term is the construction schedule; and the hazard is everything that can go wrong on an active job site before the structure is finished and handed over. Get the project value, the split between hard and soft costs, the construction type, and the term right, and you have priced the risk. Miss one and you have mispriced it.

The submission that carries all of this is short — typically a broker’s email with the ask and a builders risk application form — but the data is dense and connected. InsightXtract runs an agentic, multi-document pipeline that classifies each file, extracts to a per-document schema, consolidates the two sources into one unified account record by source priority, and validates it against your reference data — so the underwriter opens a single, coded, cited record instead of a form and an email thread.

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

The idea that governs everything: value at completion is the exposure

Before the fields, the single most important concept. In builders risk, the exposure is the total value of the project at completion — not what stands on the site today. A tower that is a hole in the ground on the effective date will be a $60M structure by the completion date, and the policy has to cover the peak value it will reach. That is why the total project value, and the way it splits into hard costs (materials and labor that become the building) and soft costs (design, permits, financing, lost income), sits at the centre of every builders risk quote. Two projects with the same total value but very different soft-cost loads are very different risks.

The rest of the record exists to qualify that exposure: who the insured is, what the project is and how it’s built, how long it will be under construction, and what the coverage terms are. In the tables below, the Captured column flags how each field is held:

• Current — a value captured once for this project / term.
• Point-in-time — a static identity or classification fact.
• Per-row — a table: one building / project per row in the project schedule.

A · Insured and identity

Who the account is — the contract party, its legal structure, and how it’s classified for rating and appetite. Sources: application form, broker email.

Parameter	Captured	Why it matters
Named insured · DBA · FEIN	Point-in-time	The contract party and unique account key — drives clearance, conflicts, and de-dupe.
Address · risk state	Point-in-time	Mailing/physical location and the primary rating jurisdiction — standardized against the state-code reference table.
NAICS code · SIC code · entity type	Point-in-time	Class-based rating, appetite/knockout, and legal form — NAICS validated against reference data.
Business description · years in business	Point-in-time	Nature of operations and contractor track record — the stability signal behind the code.

B · Firmographics & exposure base

The size of the operation behind the project — the financial and workforce base that qualifies the insured. Source: application form.

Parameter	Captured	Why it matters
Estimated revenue	Current	Annual sales — the scale of the contracting operation, formatted as currency.
Total payroll	Current	Workforce exposure base and a proxy for the volume of work in progress.
Employee count	Current	Workforce size — operational scale relative to the project taken on.

C · Project profile — the exposure itself

This is the heart of the builders risk record. Where the project is, what it is, how it’s built, and — above all — what it’s worth and how that value is composed. Source: application form.

Parameter	Captured	Why it matters
Project name · project address	Current	Identifies the specific job site — the physical location of the exposure and its catastrophe geography.
Project type	Current	New build vs. renovation vs. addition — renovations over an existing structure carry very different hazards.
Total project value	Current	The value at completion — the core exposure the policy limit must reach, formatted as currency.
Hard costs	Current	Materials and labor that become the building — the physical-damage exposure that rises as the job progresses.
Soft costs	Current	Design, permits, financing, and lost income — consequential exposure a delay or loss triggers, priced separately.
Construction type	Point-in-time	Frame vs. masonry vs. fire-resistive — the single biggest driver of fire and wind vulnerability.
Number of stories	Point-in-time	Height and complexity — a signal of construction difficulty, wind exposure, and value concentration.

D · Term & construction schedule

Builders risk is a term-of-construction cover, so the schedule is part of the exposure. A longer job means more months of exposure and more chance the value peaks before it’s handed over. Sources: application form, broker email.

Parameter	Captured	Why it matters
Project start date · project completion date	Current	The construction window — when exposure begins and when it should end, normalized to ISO dates.
Coverage term (months)	Current	The policy period being rated — and whether it actually spans the full build with margin.
Project duration (months)	Current	Expected build length — longer schedules raise cumulative exposure and overrun risk.
Effective date	Current	Inception of cover and binding deadline — normalized to an ISO date.

E · Coverage, limits & program structure

The ask itself and the terms that shape it — the product, the requested limit, the retention, and any wrap-up program governing the site. Sources: broker email, application form.

Parameter	Captured	Why it matters
Product · requested limit	Current	The coverage form and capacity being requested — the core of the ask.
Deductible	Current	Retained loss — the insured’s share of each event and a direct rate lever, formatted as currency.
Existing structure value	Current	Value of any structure already standing on a renovation/addition — exposure beyond the new work.
Wrap-up type	Point-in-time	OCIP/CCIP or none — who carries the program and how liability is consolidated across the site.
Premium	Current	The quoted or target premium — the price-to-beat and rate baseline, formatted as currency.

F · Broker & submission

Who’s placing the account and how to route it — the distribution chain and correspondence path. Source: broker email.

Parameter	Captured	Why it matters
Broker name · broker email	Point-in-time	Distribution routing, binding authority, and the correspondence address for the quote.

G · The project schedule — one row per project

Many builders risk policies cover more than one building or phase under a single account. InsightXtract reads the schedule as a table — one row per project — so each building’s value and timeline is captured individually rather than collapsed into a total. Source: application form.

Column	Captured	Why it matters
Project name	Per-row	Identifies each building or phase under the policy for scheduling and reporting.
Address	Per-row	The specific site of each scheduled project — per-location catastrophe and aggregation exposure.
Value	Per-row	Completion value of each project — the per-building exposure, formatted as currency, that rolls up to the total.
Start date · completion date	Per-row	Each project’s construction window — overlapping schedules concentrate exposure in time, normalized to ISO dates.

From two documents to one connected record

Pulling these fields out of a form and an email is only half the job. The value is in consolidation: the insured named on the application, the broker on the email, the project value and construction detail on the form, and the requested limit in the ask all describe one account. InsightXtract merges them into a single record by a declared source-of-truth priority — the application form wins on project details like address, type, dates, construction, and deductible, while the broker email carries the broker identity, product, effective date, and requested limit — and links the result into an entity graph with the insured at the centre, connected to broker, project, coverage, and the project schedule.

Why it matters to the business

Comprehensive, structured, validated extraction of a builders risk submission isn’t a data-entry nicety — it changes the economics and quality of the book:

• Project value and soft costs = the exposure. Capturing total project value alongside the hard/soft-cost split, by default, means the layer is rated on the value it will actually reach at completion — and the consequential soft-cost load is priced, not missed.
• Term is risk. The construction window and coverage term drive how long the exposure is live. Extracting start, completion, and term months makes overrun and gap risk visible before binding, not after a claim.
• Construction type moves the price. Frame vs. masonry vs. fire-resistive, plus stories and existing-structure value, are exactly the vulnerability signals that decide the rate — captured every time, coded the same way.
• Faster quotes, fewer surprises. An underwriter opening a consolidated, cited record instead of a form plus an email thread triages and prices in minutes — and the per-project schedule surfaces multi-building aggregation instead of hiding it in a total.
• Consistency and auditability. The same fields, standardized and validated the same way, with provenance to the source document — the difference between a repeatable book and one that depends on which underwriter opened the file.

The Builders Risk agent extracts all of this today — insured identity and firmographics; the full project profile with value, hard/soft-cost split, construction type, and stories; the construction term; coverage, deductible, existing-structure value, wrap-up, and premium; the broker and submission; and the per-project schedule — consolidated into one coded record with every value standardized, validated, and cited to its source document. And because it’s all configuration — fields and tables in the agent’s output contract, not code — the schema keeps pace with what your underwriters ask for.