Pull the third-party and internal data an underwriting file needs, reconcile what the sources disagree about, and show every field's origin — the underwriter decides, on evidence that can be cited.
Take the submission as it arrives — named insured, entity, address, vehicle or property, and the broker's description.
02
Order the reports and internal records the guideline calls for: loss history, prior policies, inspections, exposure data.
Reason
03
Resolve every record to the entity, address, VIN or location the submission names, and hold back the ones that do not.
04
Normalise units, dates, classifications and addresses, so a figure from one source can be compared with another at all.
05
Set the sources side by side, keep the disagreements visible, and stamp each field with its source and its as-of date.
Decide
06
Where the records match, the sources agree and every field is cited, the file reaches the underwriter complete.
07
Conflicts, stale records and weak matches are named in the file and put in front of an underwriter as open items.
Out
08
Hand over one file — each field with the source it came from, its date, and any source that reads differently.
09
Retain the sources ordered, the versions read, the matches made and the fields the underwriter later corrected.
→Product statement
The agent gathers, reconciles and shows its sources. The risk decision is the underwriter's — and nothing adverse to an applicant may rest on a source the file cannot cite.
Example workflow
One submission, end to end
AgentHuman
1Submission receivedA new or renewal submission with the named insured, entity, location and the broker's own description
2Sources orderedThe third-party reports, bureau and property or vehicle data, and internal loss, policy and inspection history the guideline calls for
3Records matched to the riskEach record resolved to the entity, address, VIN or location the submission actually names — or held back
4Fields reconciledUnits, dates and classifications aligned; where sources disagree, both readings are kept with their dates
No human action required
Stages 1 to 4 run without a person in the loop — ordering, matching and reconciliation are finished before an underwriter opens the file. Nothing has been assessed.
5DecisionSplits on whether the file is matched, current and free of unresolved conflict
Matched, current, no conflict
Reaches the underwriter as a complete file.
Conflict, gap or weak match
Reaches the underwriter with the open items named.
Underwriter or underwriting technician
Sees the disagreement, the sources behind it and their dates, and decides which record stands — or orders the source again.
Accept · Correct · Order again
Resolved — handed back▼
6File handed to underwritingRecorded with each field's source and as-of date, and the open items named rather than closed
7Outcome evaluatedMatch precision, source currency, conflicts surfaced, provenance completeness and underwriter rework, by cohort
Source corrections
Every field an underwriter changes is counted against the source that supplied it.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Rating, pricing or quoting the risk.
Declining, non-renewing or refusing to quote.
Deciding which of two conflicting sources is right.
Adding a data source or a variable to underwriting.
Automation boundaryAgent acts unaided
✓Order the sources the underwriting guideline calls for.
✓Resolve records to the entity, address or VIN named.
✓Normalise units, dates and classifications, and cite every field.
✓Name each conflict, stale record and weak match as an open item.
Write actions run only inside the approval boundaries agreed during implementation. Rating, pricing and any decision adverse to an applicant are not among them, on any tier, in any configuration.
Dropping a record the applicant disputes.
Ordering reports outside the permitted purpose.
Writing the reason given in an adverse notice.
Changing match thresholds, source priority or approval rules.
Example output
One submission file, annotated
Every field the agent puts in the file is attached to the source and the date it came from.
Underwriting file output · single submissionIllustrative example
Submission
Risk
Sources read
Conflicts open
Confidence
Risk decision
Commercial property renewal
One named location
Nine, all dated
Two, both shown
93%
None — underwriter's
As receivedThe submission as the broker sent it, and the sources the underwriting guideline calls for on that class.
Sources citedPrior-carrier loss runsProperty survey, datedPublic construction record
Why two are openTwo sources give a different roof age. Neither is picked, and neither is dropped.
ActionAcceptCorrectOrder again
What the score decidesHow much of the file the underwriter checks back at source. Never a reason on a notice.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every submissionFrom the broker, portal or renewal queue
03Provenance
Keep the sources apart, and dated
Every field carries the source it came from and the date that source was current, so a later question about the file has an answer in the file.
01Approved path
Cut the ordering and re-keying
Reports are ordered, records matched and fields normalised before an underwriter opens the submission, so the file starts assembled rather than empty.
02Human review
Show conflicts as conflicts
Where two sources disagree, both readings stay in the file with their dates and go to an underwriter — never settled silently by rule, recency or source rank.
04Build an evidence trail
Retain the sources ordered, the versions read, the matches made, the conflicts shown and the underwriter's own decision — on both paths.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
The thin files belong to the same applicants every time
A cohort whose file is reliably thinner is not a data problem alone — it is how a disparity reaches an underwriting decision without anyone choosing it. Nestack reports performance by slice, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Recently moved applicants
4.9%
3.6×
Review
Common and shared surnames
3.3%
2.4×
Review
Rural and unaddressed locations
2.5%
1.9×
Watch
Repeat renewals, unchanged risk
1.1%
0.8×
Normal
Bar: wrong-or-missing-field lift vs. repeat-renewal baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
Corrections travel back to the source that sent them
When an underwriter changes a field, the question is which source supplied it and whether the file admitted the doubt. That belongs in the evaluation.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
One cohort's matches get looser, or its files come back thinner than the rest.
02Diagnose
Which source, which match rule, which reconciliation step, which handover.
03Improve
Underwriting approves the source, rule or format change, and the version is pinned.
04Verify
The change is re-asked of held-back submissions and of every corrected field.
05Learn
The corrected field joins the regression set, and the error goes back to the vendor.
Learn → DetectThe return edge. Every cycle re-reads coverage by cohort — a file that is reliably thinner for one group of applicants stops the release.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, source and matching work, provenance and testing, evaluation, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Workflow discovery and automation-boundary definition.
02Source inventory and permitted purpose.
03Policy-admin and vendor API assessment.
04Entity and address resolution rules.
05Unit, date and classification alignment.
06Conflict surfacing and source-priority rules.
07Provenance capture to notice standard.
08Proxy and disparity testing.
09Underwriter review workflow and file-format sign-off.
10Match, currency and coverage evaluation.
11Vendor oversight and error feedback.
12Observability, deployment and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne line, one source setProductionProduction underwriting integrationAdvancedMulti-line / multi-jurisdiction
Introduced at Pilot
Source ordering and ingestion✓✓✓
Entity and address matching✓✓✓
Field-level provenance✓✓✓
Conflict surfacing✓✓✓
Baseline evaluation✓✓✓
Introduced at Production
Normalisation across sources—✓✓
Provenance to adverse-notice standard—✓✓
Cohort-coverage and disparity slices—✓✓
Observability and audit trail—✓✓
Introduced at Advanced
Third-party vendor oversight and audit rights——✓
Multi-line and enterprise controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on the lines and territories in scope, the data sources and vendor contracts in play, policy-admin and workbench integrations, submission volume, provenance requirements and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01The lines, classes and territories in scope→Workflow discovery and automation-boundary definitionWeek 1
02Your underwriting guideline and the sources it calls for→Source inventory, permitted purpose and ordering rulesWeek 1
03Access to policy admin, the workbench and vendor APIs→Policy-admin, workbench and vendor API integrationWeek 2
04Vendor contracts, audit rights and data-use terms→Vendor oversight, audit rights and the error-feedback routeWeek 2
05Your written rule on what an adverse notice must cite→Provenance capture to adverse-notice standardWeek 3
06Real submissions, including files matched to the wrong risk→Evaluation suite, regression cases and failure-mode testingWeek 4
07Named underwriters and an underwriting technician→Review workflow, file format and correction trackingWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Phases are drawn over the weeks they actually occupy. No file reaches an underwriter before week 5, and every correction they make is counted.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Lines in scope, the guideline's sources and permitted purposeW2Policy-admin, workbench and vendor API integrationW3Entity matching, normalisation and conflict surfacingW4Provenance capture, evaluation suite and cohort-coverage slicesW5First live files, underwriter corrections and targeted fixesW6Production validation, vendor error feedback and handover
Reading the bandUnderwriter corrections in week 5 are counted on live submissions, not a retrospective sample. Each bar covers its own weeks only.
At the end of W6Underwriters are working from assembled files, and every field in them can name the source and the date it came from.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Insurance AI agent
Assemble the file before you decide the risk.
Show us the sources your guideline calls for, where they sit, and what an adverse notice has to be able to cite. We'll assemble one submission the way an underwriter would want it, and agree what the file may never decide.
