At Epic Games, we had a design system that, by most measures, was working. Consistent components, well-maintained tokens, documented patterns, and a team that cared deeply about quality. We were bought into the idea that context needed to travel with components and that meaning had to flow through the system for it to work at scale.

What we kept coming back to was a question no one could fully answer: where does intent actually live?

Not where it ends up in code or Figma, but where it begins. Where the intent behind a component gets articulated clearly enough that anyone, a new designer, a developer on a different team, an AI tool trying to use the system, could understand not just what the component is, but why it works the way it does.

We never fully solved it before I left. But the question stayed with me, and it reframed how I looked at everything we'd already built.

Looking at EDS docs differently, what I saw wasn't a collection of reference pages. It was a knowledge system the team had built over years of consistent authoring — consistent sections, explicit rules, clear usage guidance, relationships implied if not always stated. The structure was already doing the work of a primary artifact without being recognized as one. It had been designed to support the Figma file, the component library, and the token set.

But what if the doc isn't support material at all? What if it's where a component's meaning is fully defined — what Figma renders, what code implements, what AI queries when it needs to understand the system? What if knowledge is the primary artifact, and everything else is an implementation of it?

That realization is the foundation of this methodology. Knowledge is the primary artifact of a design system, and the doc is where that knowledge lives in its most complete, most structured form. Which means documentation isn't the last step. It's where intent originates, and where it needs to be structured well enough to serve every audience that depends on it.

The practice that follows from that philosophy is single-source. A well-structured component doc can serve designers, developers, and AI from the same artifact. One source, multiple audiences, different entry points. Designers scan for when to use a component. Developers read for API and implementation details. AI queries for relationships, constraints, and the reasoning behind rules. The structure accommodates all three without compromising any of them.

I tested this against Epic Design System docs — a mature, production system with consistent documentation across 50+ components. Ten components across four categories: navigation, form inputs, feedback, and complex patterns. The question was simple: how much of a complete knowledge model could be extracted from the existing docs without changing anything?

The results were consistent across all ten. Identity, usage rules, and API properties extracted cleanly, producing accurate, queryable fields for 80% of what AI needs, without a single change to how they were written. The remaining 20% was the same structural gap every time. Behavior rules were partially extracted — the rules were present, but the reasoning behind them wasn't always attached. Component relationships and token dependencies didn't extract because they were never part of the authoring template.

This isn't a documentation quality problem. The docs were good. The structure was consistent. The gap was specific and predictable, which means it's solvable without a rebuild, new tooling, or changes to how the docs read for human audiences.

Treating the doc as the primary artifact changes what the primary deliverable is for design system teams. The component library is still important. The token system is still important. But neither of them is the origin of the system's knowledge — the doc is. The team that invests in documentation as infrastructure rather than support material ends up with a system that scales without scaling the people required to explain it. New team members onboard faster. AI tools produce more reliable output. Decisions get made more consistently. The system becomes more resilient to turnover because the knowledge doesn't leave when people do.

This also answers the question that context-based design systems has been circling: where does intent originate, and what form does it need to take? Context-based design systems describes how context cascades through a system once it exists. Treating the doc as the primary artifact describes where that context originates — and what the doc needs to contain for it to travel reliably.

And the principle extends beyond design systems. Support operations, product documentation, onboarding systems, compliance, and governance — every knowledge-intensive domain faces the same structural problem. The knowledge exists. It's just not structured in a way that serves all the audiences that depend on it. The design system is the proof of concept. The principle scales.

What makes this methodology implementable — not just coherent — is that it requires something AI can't provide. AI can query a knowledge model once it exists. It can extract structure from well-authored docs and implement from a spec. But it can't decide what knowledge matters. It can't sit in a design review and recognize the moment a non-obvious constraint is being established. It can't facilitate the conversation between a designer and a developer where a component's meaning gets fully defined. It can't govern a knowledge system over time — knowing when a drifted component needs updating versus deprecating, when a decision is worth revisiting versus holding, when a new component proposal reveals a genuine gap versus an overlap with something that already exists.

That judgment comes from being inside the work. From knowing the system well enough to know what it's trying to be. From having been in enough of those rooms to recognize the difference between a rule that's self-explanatory and one that will quietly break things if nobody captures the why.