$cat your-moat-is-your-data-model.md

Your Moat Is Your Data Model, Not Your Model

July 26, 202615 min readby MDflowview as .md

An emerald wireframe knowledge graph on a raised plateau encircled by a glowing moat ring, with translucent interchangeable module blocks dissolving into particles above it, on a dark terminal grid

Every few weeks a new frontier model lands and some part of an AI product stops being special. The demo that felt like a moat in March is a default capability in July, available to your competitors on the same afternoon it ships to you.

So what is actually defensible? Mike Phipps of the Gates Foundation gave the sharpest answer we have heard in a while at AI Engineer, presenting an enterprise platform that had just rolled out to roughly 4,000 people: your moat is your data model. Not the model. Not the chat window. The structured understanding of how your own organisation actually works.

TL;DR — Frontier models improve every quarter and everyone gets them at once, so nothing you build on top of a model is durable by itself. What is durable is the data model: the entities in your organisation, how they connect, which sources are authoritative, and the tacit knowledge of how questions have always been answered. Build that, expose it to agents over an open protocol instead of building yet another chat app, and use evals to find the holes in it. The prose half of that model — meanings, conventions, decisions — belongs in plain markdown you own, which is what MDflow is for. Start free.

What "your moat is your data model" means

It means the defensible layer of an AI system is the structured, curated understanding of your own domain — and everything above it is a commodity you rent. Phipps framed the decision as a set of questions any team should ask before building: how much of your deployed stack do you actually want to own, given monitoring, upkeep and the dependencies other teams will build on it? How much appetite do your users have for yet another access point? And what is your product differentiation against the SaaS assistants they already have open?

Answer those honestly and the list of things worth owning gets short. The model is rented. The chat UI competes with Claude and ChatGPT and loses most days. The framework will have a breaking major before your next planning cycle.

What is left is the part his team called the moat: the tacit knowledge required to run AI successfully against their own operations. In the Gates Foundation's case that is 25 years of grantmaking structure — the figures cited in the talk include over 2,000 grants in a single year, more than 100 countries, funding across dozens of internal strategies, and over $7 billion in annual disbursement. None of that is hard for a model to talk about. All of it is hard for a model to reason over correctly, because the meaning lives in people's heads and in four separate systems of record that were never designed to be joined.

Their platform — the Strategic Intelligence Platform, or SIP — is described in one line: structuring operational data for agentic retrieval. Systems of record land in a lakehouse, a curation layer processes them, and the output is a cross-system semantic graph that agents traverse at query time. The graph is the product. The chat is a delivery channel.

The tacit knowledge problem

The expensive part of a data model is not the schema — it is the knowledge that was never written down. Phipps was blunt about the method: repeated engagement with data owners, because you cannot model what you do not understand. What does this field actually mean? How do these two datasets join? What are the known systematic limitations? Which records carry security trimming? What are the reporting conventions?

That last one produced the most quotable line in the talk, and it is worth sitting with:

It's not enough just to answer a question a certain way. You have to answer it the way that it's been answered in the past.

This is where most internal AI projects quietly fail. A technically correct answer that contradicts the number a team has published for five years is not a win — it is a trust incident. The convention is the requirement, and it exists nowhere in your database.

The talk splits the curation work into three buckets, which travel well to any organisation:

Preparation — filtering, deduplication, document ordering, and resolving inconsistencies between documents up front rather than at query time.
Extraction — structured field extraction, semantic chunking of unstructured documents, converting figures into retrievable text, tagging that forms connections, and metadata generated in the pipeline that becomes properties in the model.
Governance — masking PII, classifying sensitive data, and enforcing per-user entitlements. His framing here is exact: AI does not create new data, it makes previously accessible data much more accessible, so your risk surface grows even when your permissions have not changed.

Model the organisation, not just the records

A useful data model contains the hierarchies people actually think in, and most of them are absent from source systems. SIP models several at once: a funding hierarchy from internal funding teams through portfolios to investments, where several teams may fund one investment; a management hierarchy where direct and indirect ownership are different edges, with rolled-up relationships precomputed; and a people hierarchy — owners, directors, meeting attendees, reporting lines — that traditionally sits alone in an HR system while being essential context for every other question.

Then the unstructured half attaches to the structured half: annual strategy reviews produce meetings, meetings have documents, documents have sections, and those sections connect back to the same entities the structured data describes. That is what lets an agent move from a document to the investment it discusses to the team that manages it without a human doing the join.

There is a second-order benefit worth naming, because it is the one teams do not anticipate. Phipps points out that building the model exposes what you did not know about your own organisation — the gaps in understanding, the dataset nobody had included, the field two teams define differently. The modelling exercise pays for itself before a single agent query runs.

Serve users where they already are

The most strategic decision in the talk is a subtraction: they decided the interface was not defensible, so they did not build one. Users are already in Claude or ChatGPT. Rather than compete for that attention, SIP is exposed through MCP — Neo4j's open-source MCP servers, forked and modified with schema updates and state passed back to their own system — so the graph shows up inside the assistant people already have open.

This is the same conclusion a lot of teams are arriving at from different directions, and it generalises: own the substrate, rent the surface. The complement they are building is constrained workflow experiences for tasks where free-form chat is the wrong shape, served through the same knowledge layer. One platform, several front doors, none of them load-bearing.

If you have been reading our posts on thin agents on a smarter substrate or systems of context, this is that architecture arriving from the enterprise-data side rather than the agent side. Everyone is converging on the same shape: keep the agent thin, make the layer beneath it rich, expose it over an open protocol.

Evals are how you debug a data model

Treat eval failures as bug reports against your data model, not your prompt. This is the part of the talk most teams under-use. SIP's eval questions are written with data owners so they encode real reporting standards, and are separated into complexity tiers.

The mechanism is the clever bit. Structured data changes constantly, so a frozen expected answer would be wrong within a week. Instead they store the graph query alongside each eval question, execute it against the live graph at eval time, and compare the agent's answer to that. The expected answer regenerates itself.

An LLM-as-judge scores the results, tracking not just pass@1 but stability — ask the same question several times and do you get the same answer? A system that is right two times in three is not two-thirds useful; it is untrustworthy, and stability measures exactly that. Failures then feed back into schema descriptions and domain rules, closing the loop.

And the residual failure mode, once the system is strong, is instructive: the misses are mostly ambiguity. The answer is not wrong, it is not what the user meant. That is a modelling gap too — it just gets fixed with a clearer definition rather than a new edge.

Why this matters for developers and AI agents

For developers, it reorders the roadmap. The instinct is to spend the quarter on the agent — routing, tools, prompt scaffolding, a nicer UI. The moat argument says spend it on the layer beneath: write down the definitions, resolve the conflicting sources, encode the conventions, capture the governance rules. That work has no demo, and it is the only part of the stack a model release cannot devalue. It also raises the ceiling of every future model rather than only the current one.

For AI agents, it is the difference between guessing and knowing. An agent with retrieval can find text that resembles your question; an agent with a data model can discover the structure at query time and reason across it — which team funds this, which document decided it, which figure is the reported one. Semantic similarity cannot tell you which of four copies is authoritative. A curated model can, and it says so in language the agent can read.

Which applications benefit most

Enterprise operations and portfolio management — grants, budgets, programmes and investments spread across systems that were never designed to be joined.
Internal copilots over BI and reporting — where the failure mode is metric ambiguity and convention mismatch, not SQL syntax.
Consultancies and agencies — the methodology, the client conventions and the definitions are the product; the model that renders them is not.
Regulated and audited domains — where "answer it the way it has always been answered" is a compliance requirement rather than a preference.
Engineering organisations — specs, ADRs, API contracts, runbooks and the tribal rules about which service owns what.
Research and knowledge-heavy teams — where the connections between documents, people and results carry more value than any single document.

How MDflow fits

MDflow is a home for the prose half of your data model — the meanings, conventions and decisions that agents need in order to interpret anything else correctly. Being direct about the seam: MDflow is not a lakehouse and not a graph database. If you need to join four systems of record and traverse relationships at query time, that is Neo4j's job, or your warehouse's. But a large part of the tacit knowledge Phipps describes is not tabular at all — it is "this is what this field means, this is the number we report, this is why the 2024 method differs" — and most teams have never written it down anywhere, which is precisely why extracting it takes months of interviews.

What already lines up today

Folder descriptions are a written semantic layer. Every folder carries a description stating what its documents are for, and mdflow_get_context ranks those descriptions above folder names and document titles — retrieval without a vector database, where the ranking signal is a sentence you wrote and can edit. Workspaces scope that layer per client, programme or product line.

Markdown-native, so the model is inspectable. Documents are plain markdown with YAML frontmatter, and every shared document has a raw .md twin any tool or model can fetch — this post included, at /blog/your-moat-is-your-data-model.md. A definition you cannot read, diff and correct is not a data model; it is a black box.

Served where your users already are. A hosted remote MCP server — Claude and the ChatGPT app connect with an OAuth sign-in and no pasted token, while Cursor, Codex and Claude Code use a Personal Access Token — plus an HTTP API with an OpenAPI spec, a VS Code extension, an n8n node and a web clipper. Same substrate, several front doors, exactly the pattern SIP chose.

Agents write back, and the writes are attributable. An agent that resolves an ambiguity mid-run can record the definition in the workspace instead of losing it. Version history keeps a line-by-line diff and non-destructive restore on every write path, and the Document Log names the actor — automated · <token name> for API and MCP writes — so a curation loop leaves an audit trail rather than silent edits.

Governance on the knowledge itself. Email shares with viewer or commenter roles, read-only public links, collections, comments, and per-document client-side encryption for material that should never be readable by anything but you. Entitlements on the meaning layer matter for the same reason Phipps flags governance in the curation pipeline: making knowledge reachable by agents makes it reachable, full stop.

Where we are headed

Direction, not a dated commitment: descriptions that can express relationships between folders, not just what each one contains; serving a whole collection to an agent as one cross-linked bundle so a definition, its decision log and its exceptions arrive together; richer typed frontmatter so a document can carry owner, status and freshness as signals an agent weighs; and scoped tokens so an agent's reach into the layer matches its job.

The bottom line

Models will keep getting better, and every improvement will arrive for you and your competitors on the same day. The only part of the stack that compounds in your favour is the one that encodes what you know and nobody else does.

Write down what your fields mean and how your questions have always been answered. Model the hierarchies your organisation actually runs on. Put governance in the pipeline rather than after the incident. Expose the result over an open protocol and let people keep the assistant they already like. Then use evals to find the holes, and fix the model rather than the prompt.

The chat window is rented. The model is rented. The data model is yours.

Start free · Connect an AI agent · Read the API docs

Frequently asked questions

What does "your moat is your data model" mean?

It means the defensible part of an AI system is not the model, the chat interface or the framework, but the structured understanding of how your own organisation works — which entities exist, how they connect, which numbers are authoritative, and how a question has always been answered. Models improve every quarter and are available to your competitors on the same day. Your data model is the part nobody else can buy, and it keeps its value when the model underneath changes.

Why is tacit knowledge the hardest part of an AI platform to build?

Because it is not written down anywhere. Field meanings, join conditions, reporting conventions, known data limitations and the safeguards around sensitive records usually live with a handful of data owners rather than in any schema. Mike Phipps of the Gates Foundation described the work as repeated engagement with those owners to extract it, and made the sharp point that it is not enough to answer a question correctly — you have to answer it the way it has always been answered, or people will not trust the system.

Should we build our own chat UI for an internal AI platform?

Usually not. The chat interface is the least defensible layer: users already have Claude and ChatGPT open, and a competing internal chat app has to win that comparison every day. The Gates Foundation's Strategic Intelligence Platform serves its knowledge graph through MCP into the assistants people already use, and keeps ownership of the layer underneath. Build the substrate, expose it over an open protocol, and meet users where they are.

How do evals help improve a data model?

Evals expose gaps in it. When an agent answers a question in a way that does not match a team's reporting standard, the fault is usually a missing definition, an ambiguous field or an unmodelled relationship rather than a bad model. The Gates Foundation team writes eval questions with the data owners themselves, stores the graph query alongside each question, runs it against the live data at eval time so the expected answer never goes stale, and feeds failures back into schema descriptions and domain rules.

Do you need a knowledge graph to have a data model moat?

No. A graph is the right tool when you need to join several systems of record and traverse relationships at query time. But most of the defensible knowledge is prose: what this folder is for, which number is authoritative, how this metric has always been reported, what the exceptions are. That half can live as plain markdown that both people and agents read, and it is the half most teams have never written down at all.