// Core system integration
Cloud Data Access gives you a replica, not a model.
Guidewire on the cloud, a mid-tier policy system on some lines, and fifteen years of premium history, policy records and claim files on a stack nobody wants to touch. The AI problem is rarely the new system. It is that the data your models need lives somewhere else, and the answer has to land back in PolicyCenter.
Dearborn Labs is an AI-native software development firm built specifically for insurance. There is no Dearborn Labs product in this — you hire the engineers, and the integration code sits in your repository from the first commit.
// The situation
The complexity is always underestimated in the same place.
Gartner finds CIOs consistently underestimate integration complexity in modernization programs, particularly where financial transactions are involved — payments in particular stay buried in legacy workflows behind custom integrations, so legacy increasingly dictates architecture rather than supporting it.
Gartner, via Duck Creek · February 2026 · vendor research.
So the surface assessment happens before the scope, not during the build. We name which surfaces are sanctioned, which need a vendor partnership before they are an engineering problem, and which are not safe to build on at all — and we verify general-availability status against the vendor’s own documentation rather than against a slide, because several of these surfaces have moved in and out of early access in the last two years.
// The stack you actually run
The surfaces, named, with their limits.
Nearly every carrier above roughly $500M of direct written premium runs a hybrid.
A modern policy system for new and renewal business on some lines, and a retained stack holding runoff books, older lines and, critically, the historical claims and premium data your models need for training. Reading from a Cloud Data Access replica in S3 is straightforward, because the data is already leaving the system on its own. What lands is a replica of the operational schema: wide, deeply normalized, effective-dated, and built for transactions rather than for analysis. You have the data. You do not have a model.
Writing a decision back is a different problem and it is the one that separates a demo from a deployment. It needs entity-model depth, a versioned API contract, and your change-control calendar. Those are the three things a proof-of-concept never has, which is exactly why the proof-of-concept always works.
// The build
Four builds, and what each one is measured on.
A semantic layer over Cloud Data Access
The operational replica turned into an analytics model that respects your transaction and version semantics — policy term, endorsement sequence, audit, cancellation, reinstatement — with tests that fail when a premium total stops reconciling to what finance recognizes. This is the actual first project on most Guidewire Cloud engagements, budgeted or not.
Surface: Cloud Data Access into your S3, plus Application Events for lifecycle, into a model in your repository.
Write-back into the system of record
A decision that survives the next endorsement, appears in the audit trail, and does not break the effective-dated model. Built on Cloud API, Application Events and Integration Gateway, inside your release calendar, with rollback defined before go-live rather than discovered at one.
Surface: Cloud API, versioned, with the change-control calendar as a hard constraint on the schedule.
Getting at the data on the retained stack
Fifteen years of claims and premium data on AS/400, DB2 or COBOL runoff, extracted with its field semantics documented rather than guessed, and joined to the modern system on a key that holds. It is not glamorous and it is not fast, and any proposal that skips it is either scoped on the new system only or it is wrong.
Surface: batch extract from the retained stack into the same model as the modern system, with a reconciliation report per period.
Effective-dated transaction semantics as a first-class concern
Commercial policies are amended constantly — endorsements, audits, mid-term cancellations, reinstatements. Anything touching premium or exposure has to understand version semantics or it produces a confident number nobody in finance recognizes. We model the semantics before the use case, and every derived figure states the as-of basis it was computed on.
Surface: the transaction and version tables, expressed as tested logic in your repository rather than as a convention someone remembers.
What we measure
Write success rate by transaction type, never as an average — new business, endorsement, cancellation and reinstatement fail differently, and an average hides the one that matters. Endorsement survival, meaning the share of written decisions still correct after the next policy change; this is the number nobody measures and the reason write-back projects get quietly abandoned. Audit-trail completeness, meaning every written decision traceable to its input, its version and the human who could have overridden it. Rollback rate, and by whom. Reconciliation variance between the semantic layer and the finance close, as a dollar figure and a trend. Definitions first, in week one.
// We ran one of these
A decision written into the system of record has to survive the next endorsement. Anything that does not is a decision the business quietly stops trusting.
The operating record →// What's hard about this
Two limits, and what we do about each.
Release-train coupling: the vendor upgrades on their cadence, not yours.
Anything built against a non-sanctioned surface — direct database reads, custom Gosu plugins, the old event-messaging pattern, screen scraping — breaks on the vendor’s schedule. The break is rarely at a convenient moment, and the cost of it lands on your team rather than on whoever built it.
So the build goes on Application Events, Integration Gateway and Cloud API, or the thing you want is declared as not safe to build yet, in the proposal, with the reason. Where a build needs the vendor’s partner program to get access at all, that is a business-development timeline before it is an engineering timeline and it is named as such before you fund it. Fallback approaches exist; when one is the only path, it is labeled fragile in writing and you decide.
Effective dating will make a naive extract wrong, silently.
A model that reads the replica without understanding transaction and version semantics will produce a premium or exposure figure that looks authoritative and reconciles to nothing. Nobody catches it in the pilot, because the pilot is not being reconciled to a close.
The refutation is to make reconciliation a build artifact rather than an assurance. The semantic layer ships with tests that compare its totals to the finance close for the same period, per line and per term, and the tests run on every change. Where a figure cannot be reconciled, the model reports it as unreconciled instead of publishing it, and that gap is a finding in week one rather than a surprise in month six.
// What ships with it
The governance file, scoped to a system of record.
Data lineage from the source system, table and field to every value a model consumes, because lineage on an integration build is the part an examiner can actually test. A model inventory entry with a risk tier for anything that writes a decision. Audit-trail completeness as a reported metric. Role-based access and audit logging on everything built. Drift thresholds with remediation triggers, and a named human decision-maker specification for every write path. Roughly half the states have adopted the NAIC AI Model Bulletin, and a decision written into the system of record is the decision they are asking about.
NAIC and state bulletins · current at September 2026.
What the governance file contains →Bring us one integration you have already tried.
We will tell you which surfaces are sanctioned, which need a partnership, and which are not safe to build.