If you handed the life-science data problem to an engineer who'd never worked in biology — just someone who builds systems — they'd ask one question first: what depends on what?
That question, asked in the right order, gives you the whole stack. And it exposes why most life-science data efforts fail: they're built upside down. The team starts with the impressive top layer — the AI demo — and never builds the three layers it silently depends on. The demo works in the meeting and falls apart in production.
Here's the stack, bottom to top, the way the dependencies actually run.
Underneath the AI: more layers than the demo admits
Above the visible AI layer sit several foundational layers that the demo quietly depends on and rarely shows. Broadly, before a system can answer well it has to reliably get the data (and keep it fresh), make it consistent (formats and vocabularies that otherwise never agree), and — the part almost everyone underestimates — know which records are the same real-world thing. Only on top of that does retrieval, dashboards, or natural-language Q&A actually behave.
The scale alone tells you why none of this is a quick join: PubMed holds 40M+ citations [1], ClinicalTrials.gov 590K+ studies [2], and the USPTO 12M+ patents [3] — none sharing identifiers, each in its own format. Getting even a single source into usable, consistent shape took a median of 358 days in one peer-reviewed network, with vocabulary mapping the most time-intensive step. [4] The identity problem — knowing two differently-named records are one molecule, device, or product — is the hardest of these, because it needs global consistency (whether A and B match can depend on the whole dataset) rather than row-by-row guessing. It's also why a bigger language model doesn't rescue it: models reason locally. We've covered that failure mode across clinical data, pharma BD, and medical devices.
Only once that groundwork exists does the AI layer make sense — retrieval, dashboards, agents, and natural-language queries, all only as good as the resolved, consistent data beneath them. Skip the foundation and the failure becomes visible here: Gartner predicts organizations will abandon 60% of AI projects through 2026 for lack of AI-ready data. [5] Those projects didn't fail at the AI layer. They failed at the foundation and only noticed at the top.
Why the order is the whole point
The foundation is worthless to skip: an AI layer on unresolved, inconsistent data hallucinates and contradicts itself. The reason MIT found roughly 95% of enterprise generative-AI pilots producing no measurable P&L impact [6] is, more often than not, an inverted investment: all of it at the top, none at the foundation.
The good news for a technical leader is that the unglamorous foundational work is largely the same from one company to the next — it doesn't have to be reinvented per org, which is exactly what makes the embedded-engineering model work for teams that can't staff a full platform org. Build the foundation first, or buy/embed it from someone who already has — but don't ship the AI demo on top of nothing.
If you mapped your own stack today, which layer is actually missing — and is your AI sitting on top of the gap?