Your Moat Is Your Data Model — Mike Phipps, Gates Foundation

Yes. My talk today is about the title "Your Data Models, Your Moat." We have an enterprise-wide platform that we had just rolled out here this past month, and so I'll go into details on this. I'll give you some, hopefully some practical lessons here on why we made decisions we made for this, how you could picture your processes within a similar type of framework.

So first, just a quick introduction. So this gets into the title here, the talk, and the framing of what I hope you take from this. But with AI moving very fast at the frontier, what's defensible? You can move, you can build things very quickly with Claude code, but once you push things to production, there's constraints.

You find how much of your deployed stack do you want to actually own? There's monitoring, there's upkeep, there's people building dependencies off your stack that you have to be prepared to handle. How much appetite do users have for decentralized access?

This gets into I'll show you what we built, but what's the access point for users? Is it another chat app? Is it Claude? Is it ChatGPT? Is it something else? What's your product differentiation from those different SaaS products?

And so our team then, with this context in mind, thought through here, what's our skill set here? What's our competitive advantage in this environment? And this is what I really hope that you take from this talk and picture yourself in this.

But our moat here was our understanding of our internal processes, the tacit knowledge that you need to run successful AI. And this is true, I think, no matter how good AI gets, how good models get, new releases that different companies put out when Mythos comes out or when there's a new app from Claude.

I'm not worried because the part that we've built is the defensible part that's durable. So these are the I'll tell you what this means here in more detail, but these are the processes, tacit knowledge that we've modeled into what we call the Strategic Intelligence Platform, or SIP.

And it rolled out here this past month in production for enterprise use across the Gates Foundation, so about 4,000 people.

So first, I know this is an engineering talk, but the scope of this talk gets into data modeling, internal operations processes. And so I want to give very quick background here over what the Gates Foundation does, because this is what we're modeling.

So as you're probably familiar, the Gates Foundation has a very wide scope and it's very ambitious work that we've been doing for the past 25-plus years. And there's all kinds of broad initiatives that we're doing, whether it's for child mortality, whether it's for nutrition, agriculture, education.

And these are kind of broadly the different buckets that these different initiatives fit into: creating market incentives, spurring innovation, collaboration between public and private sectors. And then the fourth one here kind of gets into the lens that we're building here: high-quality data, trying to drive data-driven insights from the actual investments, the grants that we've put out.

And over 25 years, there's a ton of structure, there's a ton of data that's developed. And trying to extract those insights at scale is difficult, and that's what we're trying to solve.

So this slide here is a snapshot of some of the different work that went out in 2023 within the foundation. This gives you an idea. I just put this here to show some of the structured, the structure that we have that we're working across.

So you have over 2,000 grants in one year. Many of these are 5 million-plus, many 100-plus countries that are targeted with these grants, alumni. So there's 4,000 different employees of the foundation, many different strategies within the foundation, the US, within the US, across almost all the states, grantees, the total annual disbursement over $7 billion.

And so this gives you some idea of structure that we're working with. And this one just finally here, when I show the data model, this will make more sense, but we have different divisions. That funding goes out through different divisions.

And so this breaks down some of those divisions so you can see different priorities, and it'll make more sense in a second here. But global development, global health, gender equality, USP are just a sample of the different divisions.

OK, so the fun stuff here now, I hope. The Strategic Intelligence Platform. So

in a nutshell here, structuring operational data for agentic retrieval. So we're building a knowledge graph with the idea of the agent consumer.

And here is an end-to-end look of what this looks like. So we have different systems of record, structured, unstructured. These have been siloed traditionally. So part of our team here, the work has been to create what's essentially a data lakehouse, putting everything under one roof.

This is our internal enterprise-wide data. It's also different programmatic data that are

outputs of different investments. Once it's there, it's easy for us to consume. So we have a data curation layer that does different processing to it. And then finally, SIP here at the end with agentic chat, agentic workflow as the UX, how users are consuming our platform.

And so it's a cross-system semantic graph layer that agents can reason across. OK, so some of this I'll try to speed through here just for the sake of time, but this one is critical. When you're dealing with systems of record with lots of complexity, engagement is critical.

This is something that we've found here repeatedly. We have to engage data owners to understand this tacit knowledge we're trying to model. What's the full meaning of different fields, the structure of the data set? How do we join things together?

How do we understand limitations, systematics of the data, safeguards, security trimmings, reporting conventions? 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. And so this comes back to the moat here.

This is the procedural understanding, tacit knowledge that AI needs, and it's the part that we own, that's ours.

And that's what we're modeling here. OK, so going back here just very quickly for this one. This is a snapshot here of different data curation considerations that go into this pipeline. So you have, for different data sets, whether it's structured, unstructured, there's different pre-processing, filtering, deduplication.

There's an order to different documents. There can be inconsistencies across documents. Those need to be handled up front. There's extraction, so structured field extraction, semantic chunking for unstructured documents. If you have figures, you need to convert this into text in some way so you can do retrieval across this.

Various forms of tagging that these can form connections in your graph. Structured metadata that you create during this pipeline and that becomes different properties in your graph. And then the third bucket here, governance. And this is an important one that I think AI makes more acute.

Things that were accessible previously, they're much more accessible now with AI. And so you have to consider this. Your risk sphere is larger. So things like PII need to be masked. You need to reconsider different sensitive data, classifying this, making sure that there's theright entitlements for each user who's accessing your system.

OK, so that's the overview here. The data model itself now, this is the part I'll walk through here. There's a nice animation here, but hopefully the takeaway is you can picture your own organization's story within what I show here.

I'll get somewhat technical, but it's only to hopefully give you an idea of how we solved our problem, and then you can hopefully model this to yours as well. Graph is a very flexible, practical representation of a physical model.

OK, so I'll zoom through a few of these here, but just the entry point here. We have over 80 different strategy teams. These teams have annual reviews that happen. This is how the budgeting for each year is derived.

And then so we model this here, the graph. The meetings are where unstructured documents enter into this system from, but then they have a structured connection to your other systems of record. What I show here is a conceptual data model, so it's flat.

So you're not seeing instantiation of the actual graph. There's many different nodes. Cardinality is at one-to-one, one-to-n. So the actual graph, it's even more complicated. But for the data model itself, let me show you the first different so we have multiple hierarchies that exist within what we've modeled.

There's different types of hierarchies that you can have. In this case, this is a hopefully you can see all this very well, but it's an additive DAG. So there's all five levels here of this hierarchy from the top to the bottom matter.

So you have to consider everything together. And so then there's different roll-up patterns that you can do to work across this sort of pattern. In our case, we have an in-path shortcut here that connects to the funding path.

Funds to bow is where we have the budget for each of these different funding teams that's stored.

So we have funding. The internal funding teams have portfolios. These portfolios then go towards different investments. Multiple funding teams fund an individual investment. So it's an end-to-end relationship there. The investments are the thing that are our product. It's our business.

But internally, we have funds that then prioritize different types of investments, and that's what's shown here. And so you can take this down to the transaction level, or you can have different annual-based aggregations that you map here as well.

And then from investment, there's a lot of interesting things you can do. You can map to all the different organizations, and you can have different types of organizations. And there's actually a lot here that is still kind of green space that we want to fill in.

We have all these different observables that people have produced in the investments that we want to model here. So published reports, products, all this stuff is structured and connects to the entire organizational picture.

So I mentioned that there's different hierarchies. This is the second type of hierarchy. At this hierarchy, each level matters in and of itself. And so it's not a DAG necessarily. And so you can actually do things like pre-computing

some of these different shortcuts. So the hierarchy goes from the top to the bottom, contains, connects it. This is showing the investment management side of the organization. And there's concepts of direct team management. So one team at team level two manages the investment.

But then there's also a concept of indirect management. So the children below team level two still should be attributed to the team level two. And so there's different things, different games you can play with these sort of roll-ups to precompute.

I don't know if you can see this, but roll-up managers env is a derived edge that we create after we create the contains and manages env edge.

So I've shown two different lenses for one investment. There's the funding lens, the management lens. And you can model both of these here then within the graph.

A third hierarchy here is people. You have organizations, you have org charts, and you have people who are owners. You have people who are attendees in meetings. You have people who are directors. There's all kinds of different roles they have.

You can model these here. You can have

who they report to, what their team structure is. And these all are structured data that connects across systems. Traditionally, they existed in just an HR source system, but they're relevant for the context of the full story.

And then that leads to this connectedness. So we have different source systems that were siloed. To understand the entire picture for the agent to understand correctly across the structure, you need to find these common

entities that you stitch together. And so that's what's shown here. These are different source systems, but they're related entities that exist there. And now the agent can traverse here and understand this pretty complicated organizational structure.

One last part here that I haven't shown yet is the document part. And this is still there's a lot more we can do to this part. We've just been ingesting one different document source so far. But this is where you combine unstructured and structured.

And this gets into part of the magic here that you can model with Neo4j. But we have meetings that have documents. Documents then have different semantic sections that you can, or chunks that you can model here. You can put full-text indexes across these to aid in the different search and retrieval approaches for the agent.

There could also just be a pure graph retrieval that the agent does. And then all these things then connect back to your main organizational structure.

So then as a whole, this is what the data model looks like. So I've been zooming in here now. You can see the full interconnectedness of this four different systems, one graph, one semantic layer that's exposed through an MCP then to the agents.

What do you do by.

And so this is the so if you think of the agent's perspective, this is the structure that it can dynamically discover and reason across at query time. And for the developer, it's also a very cool thing because it exposes what you don't know about the thing you're modeling.

Very soon you find out that there's a gap in your understanding, or there's some data set that you're not fully including. And so this process in and of itself is very valuable.

OK, let me give you a sense here of what we do with this now. So this is the I showed you the platform, the graph, but then how does this relate to AI? So we've connected this through MCP.

And I discussed earlier what's durable, what's defensible. To us, what was not defensible was the chat interface, was the UI. And even in some cases, the general chat cases, the agent interaction. And so users themselves are in Claude already or ChatGPT.

And so we serve the platform where they are. And so it's served here now through MCP. Here's an example, just kind of an innocuous question here. But Neo4j has some off-the-shelf MCP servers here. We've actually modified these quite a bit here.

We forked it, and then there's various updates to the schema, things to pass state back to our system, the conversation IDs, the message numbers, stuff like this we've modified in these MCP tools. But so that's a general chat experience.

That's one entry point. The other part that we're buildingright now too that's very exciting is more constrained workflow experiences. And so these can also be offered through things like Cowork or Claude chat. And you can do things like you can have your you can have MCP apps be the standard entryway that users access different UIs that are ported into your chat experience.

And then you can have different sandbox-based agents that then run the workflow. And so these are active things that we're working on. It helps to constrain the experience compared to chat. But at the same time, it pulls from that same knowledge graph-based backend platform.

OK, I've got a couple of minutes. I'll kind of speed through this. But the way evals then relate to data modeling is that as you're doing evals, you find gaps. You find ambiguities in your data model. You find ways in which users are asking questions that are ambiguous, or

it's not returning things that conform with the reporting standards. So what we've done here then is we've worked with data owners. We've built targeted eval questions that match their reporting standards. We've separated these into different complexity tiers. One challenge is that the structured data is constantly changing.

So we have to have the graph query itself that we create for each of these different questions. And then at runtime for the evals, we pull from the live graph, and then we compare that to what the agent is delivering for that question.

And so that's what's shown here then. And there's a feedback loop that you can do for this. So as you're running an eval pipeline, an eval structure pipeline, you have an LLM as a judge. We've modeled things like pass at one stability.

So if you ask the same question multiple times, you get the same answer back. You can use LLM as a judge to measure this. And then there's a feedback loop here that you can update then your data model.

You can update your domain rules, your schema descriptions

to help fill those gaps that you find. And then after you do this, this is just some eval reporting here that we show the pass at one and the stability for our system. So we've gotten this very strong.

The questions that we end up do missing, it tends to be things that are ambiguous in some way. And so it's not wrong. It's just that it's things that

might beright, but not what the user intended. So that's kind of the constant struggle that we're working around. 30 seconds here. What's ahead for SIP? So we're continuing to fill out our existing data from systems of record, so things that fit into our current data model.

We want to expand the primary graph to additional enterprise-wide data sets. There's a lot of demand for a federated graph experience. So we have a main enterprise system, but we have specific teams that have their own data that they want to link to this.

And so we're working on how to do this, different agentic experiences, like I mentioned as well. And that's it. So please, if you want to ask questions, if there's things that you want to talk about, I'll be out back.

Or you can add me on LinkedIn here and keep the conversation going. Thank you.