A few months ago the IT group at a health system asked why we couldn't leave their data in their warehouse and run against it. They'd spent years consolidating into that warehouse and building governance around it, and they wanted us to read from their tables and skip the ingestion entirely.

It's a fair question, and it took me a week to answer properly, mostly because the honest answer has two halves that sound like they contradict each other.

The first half: we want you to have a warehouse

We're not trying to replace it, and a customer who already has a good one makes our integration easier.

Without a warehouse we integrate against source systems directly — the EHR, the billing system, the ERP, timekeeping, whatever else carries data we need. Each one is its own refresh schedule, its own owner to negotiate with, its own trip through security review. There is also the very real risk that an external system’s unexpected query patterns will make a critical business system less performant. A warehouse collapses most of that into one governed extract point, out of the critical daily work path, and the entity resolution your data engineers already did is work we don't have to redo or guess at. When your employees look at data in Translucent, it matches what you provide them in your internal reports, dashboards, and tools. If you have one, we'd rather read from it.

The second half: it can be our source, but not the store we run on

The distinction that took me longest to state is between where data comes from and where the application executes. The first is flexible. The second isn't, and not because of a connector we haven't written. Many of the capabilities our agents have are only possible because of the tight, principled integration between them and our bespoke data layer.

There's no shared schema to point at

We don't ship a single canonical data model across customers, deliberately. Every customer arrives with a different EHR, a different billing system, different internal software systems, different processes, and a different set of enabled modules; tables that share a name across two customers routinely don't share columns. So "provision a P&L workspace" isn't a specification. It means nothing until it's mapped onto that customer's actual data, and that mapping is different every time. Our data layer needs to dynamically represent our customers’ data in the manner they want to see it, encoded with their business rules, so that our agents can really see data the way financial analysts see it. The format is different for every health system’s business, and our agents and data layer adapt to those differences automatically.

The mapping gets built from the data as it lands

Rather than asking you to model your data into our shape, we build a graph over what arrives. Structure, lineage, and relationships are made self-describing, and columns are classified deterministically as data lands — a column is filterable because of how it relates to the rest of the graph, not because someone configured it.

The closest familiar thing is a semantic layer. The difference is authorship: a semantic layer asks one team, usually data engineering, to hand-maintain the plumbing and the business definitions together. We split them. The plumbing is derived; the definitions stay with your finance team.

So there's no modeling project. That only works because the indexing is part of storage.

Agents search the shape, not the rows

Here's the part I find most interesting. Someone in finance asks how colonoscopies have been performing financially. Nobody has a table called “colonoscopy” — it's a procedure code on a claim line, a description in a code table, text in a note.

Hand a person an entity diagram of a few hundred tables and they'd start at whatever entity has the most connections and walk outward. That instinct is roughly right, and it's what the agent does: it searches the shape of the graph to find where to enter, then traverses from there. Claim, to procedure code, to rate table, pulling only the fields the answer needs.

That isn't embedding search over your rows, which is what people tend to assume, and it isn't a knowledge graph. The index is over structure, combined with healthcare finance contextual hints.

You can trace any number back to where it came from

A second graph sits above the first: workspaces, scenarios, the encoded definitions of your business. It references the data graph, and the two can be joined.

That join answers what a number actually means here — not its label, but which subquery produced it, which table that came from, which source system fed the table, and which business rules and transformations were applied along the way. When a health system tells us what mission-based P&L means to them, we codify that definition and can still show the arithmetic underneath it.

The traceability exists because both graphs live in the same place. Split them across infrastructure boundaries and it stops being a join.

Which is why the store isn't a deployment choice

None of that is a service acting on a store. They're things the store does. Databricks and Snowflake are good at what they're built for; neither exposes these primitives to a third party, so there's no connector that closes the gap.

This isn't a claim about anyone's data platform. It's a coupling problem — the runtime and the storage layer were designed together and don't come apart cleanly. 

"Then why not point an LLM at our warehouse ourselves?"

I'd probably ask that too. The model isn't the hard part; making an arbitrary customer's data navigable is, and it's where much of our engineering has gone. A general-purpose model pointed at a few hundred tables with no overarching structure will produce answers, and some of them will be right, but you'll never be sure which ones without large archaeological efforts to reproduce the finding. That's the failure mode I'd worry about most in healthcare finance.

Structure is only part of it. The numbers are only right if the rules underneath them are, and most of those rules aren't yours to write. How remittances reconcile back to claims, how a DRG gets attributed, how wRVUs are counted — those definitions belong to the healthcare industry, they're unforgiving, and getting one subtly wrong doesn't surface as an error message. It surfaces in a board pack.

Our data layer solves a fundamentally different problem than a data warehouse. Data warehouses are designed to allow any query to succeed with little concern for latency. Our data store is designed to allow joins over contextually valid data relationships, filter over any dimension we can auto-index, and provide context-relevant descriptions and data lineage inline, while being fast enough to serve online UIs and agents. The architecture of a data warehouse fundamentally does not fit that purpose.

What this looks like in practice

We read from your warehouse (or your source systems if you prefer). Data lands on our infrastructure, gets indexed, and the application runs there. Your warehouse and source systems stay the governed source of record for your organization. Our systems are optimized for agentic interactions, and the labelling, indexing, and resulting multi-dimensional graph structure is what makes those agents really work.

Of course, working in the intersection of healthcare and finance means we need to be exceptionally careful with our customers’ data. Cross-tenant isolation, agentic safety, data residency, and data retention requirements are built using deterministic controls, not agentic guardrails. Data access authorization is a first-class component of our data layer, baked into every dynamically generated entity in the graph. The graphs we create are not only unique per customer, they can be further redacted per user, on the fly, based on their specific permissions, job function, and role.

There's one other option, and it's real: we'll build a bespoke version on your infrastructure and quote it. It will cost you what it cost us to build, which is not a number anyone has wanted to hear. It's a bit like asking a cloud provider to run a region on your own hardware — they will, if you're a large enough bank.

If the requirement comes from something specific, a residency rule, a PHI policy, an egress constraint, tell us which one. Most of those have answers that aren't architectural, and we’ve probably done it before. The data layer and agentic integration architecture is the one part we can't negotiate; it’s where trustable agentic work is sourced.

‍