Insight that guides.
Fractional data architecture for insurance carriers, MGAs, and insurtechs — building platforms that are governed from day one, not retrofitted after the first audit finding.
The failure pattern
They fail because nobody owned the definition of a policy. Because the lakehouse got built before anyone decided what the raw layer was allowed to contain. Because a business sponsor stood up a parallel extract in a spreadsheet, and it quietly became the number everyone quotes in the board deck.
By the time these surface, they're expensive. The platform works. The pipelines run. And no two reports agree.
The fix isn't more tooling. It's someone senior enough to own both the design and the delivery of it — and stubborn enough to make the governance decisions before the first table is written.
What I do
Lakehouse design, canonical modeling, and source-system integration for insurance data. Medallion architectures on Azure Databricks with Unity Catalog governance, and canonical mapping to ACORD so every source maps once — never source to source.
Access models, role definitions, RACI, service principal registries, and data standards — written so a new engineer can follow them in month one and an auditor can follow them in year three.
Governed semantic layers, reconciliation tooling, and LLM-assisted mapping — introduced where the data underneath can actually carry them. Most AI disappointment is a data governance problem wearing a different hat.
Gate frameworks, deliverable registers, vendor management, and steering-ready reporting. I stay accountable for a design once it meets a schedule and an implementation partner — including telling you when the vendor's estimate is fiction.
Engagements
Every engagement is structured to leave you with artifacts your team owns — not a dependency on me.
Ongoing · Retainer
I hold the target-state design, review what's being built against it, and make the calls that would otherwise sit unmade for weeks.
Good fit when you have an implementation partner building something and no independent technical voice on your side of the table.
Defined scope · Fixed fee
The layer most programs skip: the access model, the standards, and the decision record.
Good fit when you're about to provision a platform — or you already have one and can't answer who has access to what.
Time-boxed · 3–6 weeks
Where an in-flight program actually stands, what's structurally at risk, and what to do in the next ninety days.
Good fit when the status reports are green and your instincts say otherwise.
10–15 hours monthly
A standing block of hours for the questions that don't justify a project: design reviews, vendor evaluations, second opinions, interview support for data hires.
Good fit when you have a capable team and want senior backup on the decisions that are hard to reverse.
Approach
Here's what I actually believe, so you can decide whether we'd work well together.
Access models, naming conventions, and layer contracts cost days if you decide them before you build, and months if you decide them after. The programs that go badly are almost never the ones that spent two weeks on governance up front.
The landing layer is a faithful record of what the source system said, at the time it said it. Every correction and business rule happens downstream where it can be seen, tested, and explained. The moment you fix data on the way in, you've lost your ability to answer why a number looks the way it does.
Each source maps to the canonical model exactly once. Never source to source. This sounds like modeling pedantry until you add your fourth system and find the alternative is a combinatorial mess nobody can maintain.
Documented lineage drifts. Lineage captured from transformations that actually execute doesn't.
Business-friendly structures belong at the consumption layer. Flattening early feels efficient and quietly destroys your ability to represent one-to-many relationships — which, in insurance, is most of the interesting ones.
A decision that only exists in someone's head isn't a decision. It's a liability with a start date.
About
I design the data architecture that regulated businesses run on — canonical models, governed lakehouses, and the standards that keep them coherent once dozens of people are building against them. Currently that work is a multi-year modernization for a property and casualty carrier, where I own the target-state architecture and the program delivering it.
I got here by way of two decades in industries where getting the number wrong has consequences. As a VP of data at a top-20 U.S. bank, I was accountable for a large organization and the governance model that kept it aligned. Before that, years in asset management working the problems that don't make it into conference talks: reconciling systems that disagree, standing up governance that survives an examiner, and getting business and technology to agree what a term means before building anything on top of it.
That history matters for one reason. A security master and a policy master fail in the same ways. Position keeping and exposure reporting break on the same question — which record is authoritative, and as of when. Having solved that in more than one regulated domain means I recognize the pattern early, while it's still cheap to fix.
I don't hand over a design and walk away. On my current engagement I define the canonical model, and I'm also the one who tells steering the truth about the schedule. Most people do one or the other. Clients tell me the combination is the thing they can't find elsewhere.
The best architecture document is the one your team can still follow after you've left.
Contact
The most useful first conversation is usually thirty minutes about where you are and what's not working. No deck required.
Send along whatever you already have — an architecture diagram, a vendor SOW, a status report — and I'll come with specific questions instead of generic ones.