Domain Foundation

You’ve watched it happen. The person who’d been there long enough to remember why a pattern got killed or which edge case sank a feature — they retire, or they get laid off, and what they knew goes with them. None of it was written down anywhere you can reach.

That’s the problem Domain Foundation is about. Most of what an experienced team knows lives in people’s heads. Now and then someone leaves a doc behind, or trains the person taking their chair, but it’s rare and it goes stale fast. So the knowledge leaves when they do.

I think the fix is to put that knowledge somewhere it can be reached, owned by the people who hold it, and let the model compose from all of it when someone needs an answer. That’s the whole idea. The rest is detail.

The technical details change fast. What survives the churn is the shape of the knowledge and who owns it. Moonbird was that shape applied to Oracle Health; Domain Foundation is the shape itself.

Whoever holds it owns it

The knowledge has natural owners, and that turns out to matter more than anything technical. The design system team owns the universal principles. Strategists and clients own the industry reasoning. The people who author a component own usage rules. Researchers own what they know about the users. Four layers is what worked where I came from; another place might want five, or three. The point is that nobody becomes the bottleneck, because the people who produce the knowledge are the ones who own where it lives.

This is just the design group’s corner of it. Customer feedback, regulatory correspondence, the decisions made in hallways and never written down — all of that lives in other systems and has to find its own way in.

What goes away

When the knowledge is reachable, a lot of the daily friction goes away. A designer starts with a prompt and gets back something already aligned to the org’s rules instead of starting from scratch and retrofitting compliance later — a workflow that already respects the deployment context, the component library, and the accessibility constraints for the roles who’ll actually use it.

A PM can sketch a workflow over the weekend and run it past the model to see if it survives. The model checks it against the encoded rules and brings it to a state worth debating. By the time a designer sees it, the question isn’t “does this match the system” — it’s “does this belong, and if so, where does it go from here?”

And the one nobody asks for until they’ve lost it: you stop having to be the team’s memory. A team argues about a pattern choice they’re sure they’ve made before. Instead of walking over to the person who’s been there eight years, they ask the model, and it surfaces the last time this came up — what was proposed, what shipped, what got rejected, why. The reasoning stops leaving every time someone does.

The strategist caught it

My component design team killed a feature for privacy reasons. A design strategist caught a real edge case — the kind of specific, rare scenario that sits outside anything AI could recognize. The full story is its own case study; the part that matters here is what the AI couldn’t do. It had the clinical literature. It had the workflow. What it couldn’t do was reason about the actual room the feature would land in — the specific human context a strategist sees because they’ve sat with it.

Domain Foundation exists so that why — the strategist’s read on the room — can be captured in a form a model can use, so the judgment doesn’t walk out the door when the strategist does.

It’s also the difference between a team whose work is hard to copy and one whose work isn’t. If your expertise only lives in people’s heads, a PM with a good prompt can already reproduce most of what you ship.

The FigJam board

I made a FigJam board over winter break. Four layer nodes, all connecting down into a database icon at the bottom. It was the first time the project had a shape I could see whole.

You can’t shape-find in this work at the pace the field moves. Late 2025 and early 2026 ran at a speed that burned through any thought I tried to have inside it — every day another model release, another paper, another architecture pattern that partially did what we were trying to build. The Moonbird research was in peak momentum. None of it left room to back up and look at the big picture.

Winter break was the first week since the research started when I wasn’t moving at that pace. What the board made clear wasn’t a technique — it was the separation. The knowledge in layers, owned by the people who hold it, sitting in a store any tool could reach.

Hard to demo

The methodology is hard to demo. Half the value is in what an organization chooses to put in the knowledge base, and the choosing is the expertise. The structure is just the container.

The people I find myself talking to now are the ones who’ve already arrived at the same realization: default models produce default output.