About

Background

I started in mechanical engineering. An interview turned me toward data instead, and that detour became business school, then a few startups, then a decade building the infrastructure underneath other people’s decisions. The work I have spent the most time on is the unglamorous half of the discipline: pipelines that have to be right, migrations that cannot lose a row, and systems where “it usually works” is not an acceptable state.

That has mostly meant regulated data. I have led a hospital revenue-cycle modernization — refactoring more than a hundred fact and dimension tables and the reporting models over them, sourced from Epic Clarity and Caboodle — so healthcare data structures are familiar ground rather than a vertical I picked. Before that: data quality and reconciliation on syndicated credit facilities at a major US bank, where the daily job was proving that two systems agreed and finding out why when they did not; statewide transportation pipelines feeding a state’s public mobility reporting, delivered 30% faster than the ETL they replaced; analytics for an energy utility’s portfolio of digital products; IoT and SaaS telemetry at a consumer-electronics manufacturer; and ISO-9000 audit work early on, which is where I learned that a control nobody can evidence is not a control.

Most recently I migrated a player-cohort analytics platform onto a Databricks medallion architecture and built the config-driven framework that proved every migrated table matched its source — 678 million rows, 114 automated checks on every run. The migration was not really the deliverable. The evidence that it was correct was.

Today I work as a lead consultant in data engineering, running engagement teams of three to six engineers who build lakehouse platforms on Databricks — streaming ingestion through Delta Live Tables, governance in Unity Catalog, deployment through version-controlled Asset Bundles. The assignment underneath is the same in every industry: get the platform to the point where a published number can be traced back to its source, then make that traceability automatic instead of heroic.

That background is why this consultancy looks the way it does. Marketing software is generally built to move fast and apologize later. When the buyer is a regulated practice, the apology is expensive and sometimes reportable — so the interesting engineering problem is not how to send more, it is how to make the constraints structural instead of aspirational. Audit, reconciliation, and provable correctness are the recurring theme of my career, and they are what this product sells.

What I am building now

The current thread is AI-native data engineering — platforms designed for agents to work inside, and using agents to accelerate the engineering itself. In practice that means a ninety-odd-skill Databricks engineering catalog served live to AI coding agents over Model Context Protocol, with a usage-telemetry loop that decides what gets written next, and agentic systems that automate the translation and validation a migration otherwise repeats by hand.

The referral engine this firm sells is that same work pointed at a commercial problem.

Why referral infrastructure

Private practices grow on referrals and almost none of them run a referral program. Not from lack of interest — because doing it properly means knowing who the referring clinicians are, being confident the outreach is permissible, and measuring whether any of it worked. Each of those is a real problem, and the combination is enough that most practices do nothing.

Doing nothing is a decision with a cost, and it is usually invisible.

Built in public

The work is developed in the open, and the artifacts are the record.

The delivery platform, the client-tenant pattern, and the decisions behind both live in version control with their rejected alternatives written down. When a choice was hard to reverse, the reasoning is committed next to it. When something is unverified, it is labelled unverified rather than quietly rounded up.

The same discipline governs this site. Every claim on it is registered in a proof inventory with its status and its evidence, and the build refuses to publish a number that has not been signed off. Claims are upgraded by amending that inventory first and the page second, never the other way round — which is the same rule the program applies to a client’s own claims.

Here is what that discipline looks like when it catches something. The rule that decides whether a clinician is addressed as “Dr.” is tested against a corpus of 9,756 real clinician records pulled from the public registry, not against hand-written examples. Testing it that way is how we found that a naive version — checking whether a credential string contains “MD” — reads MDiv as a medical degree. It would have addressed 24 chaplains as doctors and withheld the title from 522 people who had earned it. The fix is that the system abstains when it is not certain rather than guessing, and the corpus is now a permanent test.

That is a small thing. It is also exactly the kind of small thing that arrives on a clinician’s desk with your practice’s name on it, and it is the sort of detail I would want shown to me before I trusted anyone with my own.

What I am looking for

Practices with a referral-led growth model and a low tolerance for hand-waving. If you have asked a vendor how something worked and not gotten a straight answer, we will probably get along.

The engineering work behind all of this — case studies, the full stack, the certifications and who issued them — is at jonathanhazeley.com. You can also find me on LinkedIn if you would rather check the background before booking anything.

Outside the work I box, dance salsa, bachata and merengue, and build furniture in a shop I document about as carefully as I document a lakehouse. The through-line, if there is one, is a preference for practices with an honest feedback loop: the round, the dance floor, and a joint that either closes or does not.