# Mapping the systems your AI feature has to touch

_One healthtech CTO could not point his AI at a single database, because there was no single database. There was a scattered constellation of sources, and the map was the product._

AI features touch more systems than anyone lists at the start. An anonymized healthtech CTO on reconciling scattered sources with no single source of truth, plus how Density Labs maps the surface in the AI Readiness Assessment.

# Mapping the systems your AI feature has to touch

Ask a team which systems their AI feature will touch and you usually get a short, confident list. Ship it, and the real list turns out to be longer, messier, and full of sources nobody mentioned because nobody thought of them as systems. The gap between the list you drew and the systems you actually touched is where the deployment gets stuck.

The reason is structural. In most enterprises the data an AI feature needs is siloed across systems that were never designed to talk to each other. There is no tidy warehouse waiting. There is a scatter of sources, each with its own owner, format, and refresh cadence, and your feature has to reconcile all of them. Mapping that scatter is not prep work. It is the work.

## When there is no single source of truth

The CTO of a healthtech startup working on pharmacy pricing described this with unusual clarity, because his product cannot exist without it. When someone asks what a drug will cost, there is, as he put it, "not like a repository." The answer is spread across the insurance company, the pharmacy benefit manager, and the pharmacy itself, plus the drug price, the deductible, and the member's status, each living in a different place.

His AI's real job is not a clever answer. It is reconciling those scattered, non-integrated sources into one. And the map keeps moving: "pharmacy drug prices go up and down. Formularies change monthly." A deductible can flip which price applies. A whole parallel cash-pay ecosystem sits alongside the insurance one and has to be modeled too. He also had to ingest plan documents that arrive as a PDF, work historically done by "a human being reading it and typing it and putting in numbers," and the feeds do not even carry every condition, so the system has to infer what is missing.

None of that is a model problem. It is a mapping problem. Before a single recommendation is possible, someone had to enumerate every system the feature touches, understand how each one lies or omits or shifts, and design the reconciliation. Skip the map and the model produces confident answers from an incomplete picture, which in his domain means a wrong price and a broken trust.

## The systems you forget are the ones that break you

The dangerous systems are the ones that do not look like systems. The PDF someone emails monthly. The spreadsheet that holds an exception the database does not. The downstream tool that consumes your output and quietly assumes a format. The feed that omits a field you needed. Each is a system your AI feature touches, and each one you fail to map is a place production diverges from the demo.

A real map names all of them, including the ugly manual ones, and marks how each behaves over time. That map is boring to make and it is the single best predictor of whether a pilot survives contact with production.

## How we approach it at Density Labs

In the AI Readiness Assessment ($2,500), building the map is the first deliverable, not a footnote. We trace every system the feature reads from and writes to, including the informal ones like the monthly PDF and the exception spreadsheet, and we mark which sources shift, omit, or contradict each other. You leave with the real surface area of the feature, not the optimistic short list.

The model can only be as complete as the map underneath it. Draw the whole map first, ugly systems included, and the pilot has a chance.