Imagine you hire the best cook in the world.
Day one, they tie on an apron and open the pantry. Unlabeled jars. Three open bags of flour, three different brands, not a date on any of them. A sauce someone made for a dish that never happened. Two versions of the same dressing, and nobody knows which one is right. And a recipe book full of cross-outs, with torn-out pages and margin notes that contradict each other.
You ask for dinner.
It's going to take three times as long. They're going to use something past its date without knowing it. And when the dish comes out wrong, someone in the dining room will say the cook wasn't that good after all.
I ended the last installment by saying that most AIs don't get a pantry. They get a junk closet. This one is about the opposite: what a kitchen in order looks like. Because whether your AI gets it right or wrong almost never comes down to the cook. It comes down to the kitchen you hand it.
Kitchens already knew how to do this
Every restaurant that works solved this problem long ago. Not with technology, but with three habits that seem obvious until they're missing: nothing goes into the pantry without someone checking it, nothing gets thrown out without leaving a trace, and there's a recipe book everyone shares, even though each kitchen has its own menu.
The data world arrived at the same three habits on its own, thirty years ago, and gave them technical names. For a long time I wrote about them under another name, living documentation: rules checked against reality every single day, instead of a PDF gathering dust on a wiki.
Until recently, whoever consumed that documentation was a person. An analyst, a dashboard, a report for the regulator. Today, more and more, it's an AI. And when the diner changes, the kitchen doesn't. The name does.
We call it Governed Corpus.
Living documentation + AI consumer = Governed Corpus
It's not a new idea. It's an old idea, taken somewhere nobody had taken it yet.
Here are the three habits, and with each one, what I actually did when I rebuilt the system I talked about last time.
First pillar: nothing gets in without going through the door
In a serious kitchen, deliveries don't go straight into the pantry. The supplier shows up, and someone checks the packing slip before anything gets put away. Is this what we ordered? Is it in good shape? Does it have a date? If something doesn't add up, it doesn't get mixed in with the rest. It's set aside, logged, and someone decides what to do with it. The cook never grabs anything from a box that hasn't been checked yet.
With the documents an AI reads, that almost never happens. Someone writes something, drops it in the folder, and from that moment on it's the truth as far as the model is concerned. Nobody has checked where it came from, whether it replaces something else, or whether it contradicts what was already there.
The data world has a name for this: Executable Data Contracts. Explicit rules something has to meet before it can be used. In Governed Corpus it's the first pillar: validation at the door, not an audit on the way out.
When I rebuilt the system, writing a document stopped being enough to make it exist. Everything new arrives first as a draft, in a holding area no agent looks at. An agent analyzes it and proposes where it goes and what it depends on. That proposal becomes a plan. And there everything stops until a person says yes or no.
If the answer is no, the agent doesn't push back or look for a workaround: it goes back and analyzes from scratch. It's happened to me, and it's the best proof that the door isn't just for show. The inspector sends boxes back, too.
Second pillar: nothing gets thrown out without leaving a trace
If a customer gets sick after dinner, the first thing any health inspector asks is what exactly they were served. Which recipe, which version, which batch of each ingredient. A well-run restaurant can answer that. One that corrects its recipes right on top of the old ones, erasing what was there, can't.
That's why in good kitchens, recipes don't get rewritten: they get versioned. When the chef changes the dressing, the new recipe goes down with its date, and the old one stays crossed out but readable. And every plate that goes out can be traced back to the ingredients in it.
In the data world this is called the insert-only pattern, and it's the foundation of any data warehouse that hopes to have a history. In Governed Corpus it's the second pillar: memory. What almost nobody gets the first time is that it doesn't mean “never change.” It means “never overwrite.” The chef can change the recipe as many times as they like, as long as they don't tear out the old page.
When I rebuilt the system, I stopped editing rules in place. Every change creates a new version, with its date, and the previous one stops being served, but it's still there. Even the identifiers of old documents stay reserved, so nobody confuses the identity of the concept with the version of the content. And every time an agent does a job, it leaves a written record of which documents it read and which version they were in.
That's the plate's traceability. And it's the answer to the question I left open last time: where did the AI get this from? With memory, it's a query. Without it, it's an investigation.
Third pillar: a shared recipe book, a local menu
Think of a chain with hundreds of restaurants. There are things no location can change: what a margherita is, what goes on it, what it's called. If every restaurant had its own idea of what a margherita is, the brand would mean nothing. But each location picks its own menu, its daily specials and what it offers its neighborhood, without asking headquarters for permission.
The two get along without a fight because they live on different levels. The shared recipe book is small and non-negotiable. The menu belongs to each location.
In the data world, Data Mesh christened this Federated Governance. In Governed Corpus it's the third pillar: governance on two levels.
The shared level is the one you notice most when it's missing. It's the one that decides which concepts exist and what they mean, and it separates a concept's identity (which is stable) from the content said about it (which changes over time). That separation, which sits at the heart of the Data Vault methodology, is what lets you change how something is prepared without changing what it is.
When I rebuilt the system, I didn't write a single line until I had that shared recipe book: a short catalog, with a handful of concepts, each with its name and a one-sentence definition. From there, each document says exactly one thing and hangs off one of those concepts. If a document starts talking about two, it gets split. If something doesn't fit any concept, nobody forces it: everything stops and we decide whether a new one is needed. And other parts of the system have their own menu, their own local catalog, on one condition only: don't copy or contradict the shared one.
What I didn't expect
There's one effect of all this I wasn't looking for, and that now strikes me as one of the most valuable.
In the fridge, a jar that holds one thing, with its label and its date, can be checked: has it gone bad or not? A container of leftovers from five different meals can't. It's always half fine.
Documents work exactly the same way. When each one says a single thing about a single concept, a question that used to be impossible becomes possible: is it still true? You can go back to it and check whether what it says still applies to the concept it hangs off, or whether the concept has changed and the document has been left behind.
Without my looking for it, the structure creates a quality layer. Not a control someone bolts on top, but a check that's only possible because everything is in its own jar. The document doesn't quietly go stale, because you can ask it.
The test
There's a simple way to know whether your kitchen is in order. The same one the health inspector would use:
What did your AI know on day X? Can you prove it with a query, or does it take a project?
If it takes a project, what you have is documents with an index. Not a governed corpus.
What's next
A pantry in order lets the best cook shine. But a restaurant that depends on its best cook doesn't scale. As soon as it grows, the new hire, the pastry cook and the server also need to know what's theirs to do, what they have on hand and who they pass the plate to. Real kitchens solved that more than a century ago, and we'll get there.
Something more basic comes first. I've described the shared recipe book as if building it were easy. It isn't. Deciding what counts as an ingredient with its own identity and what's just a way of preparing it is, by far, the hardest part of all this. And everything else hinges on that decision.
That's what the next installment is about, with a concrete example.
At your company, which of the three habits is missing most: the inspector at the door, the versioned recipe book, or the split between what belongs to everyone and what belongs to each location?