Inside a Technology & Misc E&O submission: what InsightXtract extracts — and why it matters

Technology & Miscellaneous E&O is a class where the exposure is the work, not the building or the fleet. A software firm, an IT consultancy, a staffing agency and a marketing shop can all arrive under the same line of business, yet each carries a completely different failure mode — a bad deployment, a missed deliverable, a placement gone wrong, a claim of misleading advice. The submission that decides the price is usually just two files: the broker’s email and a completed application. The information that matters — the services profile, the revenue-by-service mix, the claims-made trigger and retroactive date, and the prior claims — is spread across them and rarely stated in one place.

Most intake tools read one document at a time and hand back a flat list of fields. InsightXtract instead runs an agentic, multi-document pipeline: it classifies each file by its role (submission email vs. application), extracts to a per-document schema, consolidates everything into one unified account record by declared source priority, and validates it against reference data and rules — so the underwriter opens a single, coded, cited record instead of a pair of attachments.

Two documents, one connected record — classify, extract, consolidate, link, validate.

The idea that governs everything: the service mix is the risk

Before the fields, the single most important concept. In Tech & Misc E&O, the class code tells you almost nothing — the service mix tells you everything. Two accounts can both file as “technology services” and be worlds apart: one earns 90% of its revenue building custom software for hospitals, the other resells hardware to small retailers. Same line, radically different professional-liability exposure. That is why the application’s services description and the services schedule — revenue percentage by service and by client type — sit at the heart of the record.

The second governing idea is the claims-made trigger. Unlike occurrence-based casualty, E&O responds to when a claim is made, gated by a retroactive date. Miss the retro date or misread the claims-made flag and the coverage analysis is wrong from the start. InsightXtract captures both explicitly. In the tables below, the Captured column flags how each field is held:

• Point-in-time — a single static fact about the insured or the ask.
• Current term — a value that describes this policy period.
• Per-row — a table: one service line or one claim per row.

A · Insured & identity

Who the account is — the contract party, legal structure, location, and operations classification. Source: 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	Point-in-time	Domicile and venue — the state is standardized against a reference table for clean routing and rating.
entity_type · years_in_business	Point-in-time	Legal structure and stability credit — a two-year startup is a different risk than a twenty-year firm.
business_description · naics_code · website	Point-in-time	Class-based appetite and knockout — the NAICS code is validated against the reference lookup, and the website is a live check on what the firm actually does.

B · Broker & submission

Who is placing the account and what kind of transaction it is — the distribution chain and correspondence. Source: broker email.

Field	Captured	Why it matters
broker_name · broker_company · broker_email	Point-in-time	Distribution routing, binding authority, and the correspondence thread — captured from the email, not the application.
submission_type	Current term	New business vs. renewal vs. quote — sets the workflow and the rate-change baseline.

C · Services profile & revenue

The core of an E&O risk — what the insured actually does and how big the operation is. Source: application.

Field	Captured	Why it matters
services_description	Point-in-time	The narrative of the professional work — the single richest signal of what can go wrong and how badly.
annual_revenue	Current term	The primary exposure base for E&O rating — formatted as currency and the denominator behind the service-mix percentages.

D · Coverage & limits

The exact shape of the professional-liability cover being requested — trigger, limits, retention, and term. This is where the claims-made mechanics live. Source: application.

Field	Captured	Why it matters
claims_made · retroactive_date	Current term	The trigger and its gate — a claims-made policy only responds back to the retroactive date, so this pair defines the tail of prior-acts exposure the carrier assumes.
requested_limit · each_occurrence_limit · aggregate_limit	Current term	The capacity being offered — the each-claim ceiling and the annual aggregate. Each is formatted as currency for clean comparison.
deductible · retention	Current term	The insured’s share of each loss — drives net exposure and signals the firm’s risk appetite and ability to self-fund.
primary_or_excess	Current term	Layer position — whether this cover sits first-dollar or above an underlying tower, which changes the pricing basis entirely.
premium	Current term	The price on the table — the target or expiring premium against which the quote is measured.
effective_date · expiration_date	Current term	The policy period and binding deadline — both standardized to a canonical date format.

E · The services schedule — one row per service line

This is the table that separates two firms with identical revenue and the same class code. InsightXtract reads the revenue breakdown as a table — one row per service — so the underwriter sees the concentration, not just the total. Source: application.

Column	Captured	Why it matters
service	Per-row	The specific offering — custom development, consulting, hosting, resale, staffing — each with its own failure mode and severity.
revenue_percent	Per-row	The share of revenue from that service — the concentration signal. Formatted to one decimal so the mix is exact, not rounded.
client_type	Per-row	Who buys it — enterprise, healthcare, government, small business. The same service to a hospital is a heavier E&O exposure than to a retail shop.

F · Claims history — one row per prior claim

The single biggest pricing input after the service mix. InsightXtract reads each prior claim as a row — identity, date, nature, status, and the money — so the underwriter sees frequency, severity, and open development at a glance. Source: application.

Column	Captured	Why it matters
claim_number · date_of_loss	Per-row	Each claim’s identity and timing — the date, standardized, places the loss relative to the retroactive date and the current term.
description	Per-row	The nature of the alleged error — the qualitative signal of whether losses cluster around one service line or one client type.
status	Per-row	Open vs. closed — open claims carry development risk still on the books.
paid · reserve · incurred	Per-row	The money — what has been paid, what is still reserved, and total incurred. All formatted as currency so the loss rollups are exact and comparable.

From two documents to one connected record

Pulling these fields out of a broker email and an application is only half the job. The value is in consolidation: the insured on the application, the broker on the email, the services on the schedule, and the losses in the claims history all describe one account. InsightXtract merges them into a single record by a declared source-of-truth priority — the application is authoritative for the insured, coverage and services; the email is authoritative for the broker and submission type — and links the result into an entity graph with the insured at the centre, connected to broker, submission, coverage, the services schedule, and the claims history.

Reference data and validation, not just capture

Extraction that isn’t checked is just faster data entry. As the record is assembled, InsightXtract standardizes and validates it against your reference data: the insured_state is normalized against a US-state lookup and flagged if it doesn’t resolve; the naics_code is validated against the NAICS reference table with the same warning behavior; every currency field — limits, deductible, retention, premium, revenue, and the paid/reserve/incurred on each claim — is formatted consistently; every date is coerced to a canonical format; and insured_name is enforced as required, so a submission that arrives without a named insured is caught rather than quietly passed downstream.

Why it matters to the business

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

• Service mix as a risk signal. Capturing revenue-by-service and by client type — not just a single revenue number — lets you rate to the concentration, which is where E&O money is won or lost. A firm 90% concentrated in one high-severity service is a different risk than one evenly spread.
• Claims-made done right. Extracting the claims_made flag and retroactive_date by default means the coverage trigger and prior-acts tail are on the underwriter’s screen from the first look — not discovered at claim time.
• Revenue exposure in context. With annual_revenue as the exposure base and the service schedule as its breakdown, the rate is built on how the money is actually earned, not a headline figure.
• Fewer missed exposures. An open claim developing upward, a loss clustered on the biggest service line, a retro date that doesn’t reach the oldest claim — the fields that cause surprises are extracted every time, so they reach the underwriter instead of the claim file.
• Consistency and auditability. The same fields, standardized the same way, every time — state and NAICS validated against reference data, with provenance to the source document. That is the difference between a repeatable book and one that depends on who opened the file.

The Technology & Misc E&O agent extracts all of this today — the insured and identity; the broker and submission; the services profile and revenue; the full claims-made coverage and limits; the services schedule broken down by revenue and client type; and the per-claim claims history — consolidated into one coded record of 28 fields and two linked tables, every value cited to its source document and checked against your reference data. 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.