Design System Architect
Governing the Onion: Design System Intelligence Layers
AI tools come and go. The layers underneath them are what need governing. I wrote the strategy that named the principle, and proved it at three scales: knowledge, operations, assets.
What I delivered
- Authored the Fluent Intelligence Strategy: named the principle (govern the layer, not the tool) and mapped the fragmented LLM-documentation landscape no single team owned.
- Defined the 3 governed layers and proved each: knowledge (one base fed by 6 teams, 4 endpoints, Flubert as first proof), operational (LydAI as a callable skill), and asset (the markdown/YAML split plus component-map and drift-detect).
What it enables
- The layer outlasts the tool: Flubert was superseded, but the governed layers it sat on are still the right architecture, and every new tool that plugs in inherits them.
- Surfaces get better for free: get the layer right and Flubert, the Teams chatbot, VS Code extensions, and the doc site all draw from one trusted source instead of fragmenting.
The problem
When AI tooling arrived at Microsoft, it didn’t arrive in one place. It arrived everywhere at once: in Figma, in VS Code, in chat, on the Fluent documentation site, in research tools, in component workflows. Each team built what they needed. Each team trained their own models on their own materials.
The fragmentation showed up at every layer of the intelligence stack. Documentation lived in silos. Instructions and personas duplicated across agents, drifting in subtle ways. The assets the models read and wrote against had no shared validation, so generated UI was Fluent-shaped on the surface and not-quite-Fluent underneath. Users flooded Teams channels with questions even with all the documentation in place, because none of it was findable or trustworthy at scale.
This wasn’t a tool problem. It was a governance problem at multiple layers.
Govern the onion, not the tools
Why an onion? Well, system intelligence is comprised of three nested layers, each requiring its own specifics and nuance. The power move: govern each layer with different tactics but the same logic.
The intelligence layer architecture. Three nested layers, each with its own governance discipline.
Get the layer right and every tool that plugs into it gets better. Get it wrong and you’re just building more confident ways to deliver inconsistent information.
I wrote the Fluent Intelligence Strategy as the early articulation of this principle while working on an AI assistant named Flubert.
The strategy doc. The cover beat that seeded the layer architecture.
Three goals of the strategy:
| Goal | Layer | In practice |
|---|---|---|
| Elevate user knowledge | Knowledge | Make it easy to find the right answer without hunting across six different doc sites |
| Make driving coherence simpler | Operational | Reduce the overhead of staying aligned across a fragmented ecosystem |
| Streamline manual, time-intensive tasks | Asset | Get AI doing the repetitive work so the team could focus on the hard stuff |
The knowledge layer: Powered by Fluent Intelligence
The strategy doc’s first commitment was a trustworthy source of truth for design system knowledge. This meant corralling more than centralizing. A single knowledge store fed by content from Fluent 2, MAI, Teams, VSCode, Xbox, and extension teams. Flubert, Teams chatbot, VS Code extensions, and the Fluent doc site all became front-end endpoints drawing from the same source.
One brain, many surfaces, and a trusted brand.
The architecture formalized four commitments at this layer:
- Single source of truth. A unified knowledge base covering design guidance, code guidance, content standards, implementation docs, and best practices.
- Trust as a design property. A branding framework so users could recognize Fluent Intelligence-powered tools and know what that meant about quality.
The “Powered by Fluent Intelligence” sticker in production. Recognition tells the user this surface draws from the trusted knowledge layer.
- Built to be extended. Markdown templates, metadata standards, and a contribution review process, so teams could add knowledge without fragmenting the base.
- Three-phase implementation. Foundations (codify tribal knowledge), integration with tools and APIs, then continuous improvement through evals and feedback.
"Lydia played a crucial role in defining the strategy and vision for Flubert, unifying its complex feature set into a cohesive vision and roadmap. She has demonstrated broad, high-level strategic thinking by mapping out the overlapping LLM documentation projects across different teams at Microsoft and showcasing how Flubert would sit within this complex ecosystem."
— Tony Chan, Senior UX Engineer
I shaped Flubert’s strategy and scope as the first endpoint that would prove the layer in production. The interesting design decision wasn’t its feature surface, but what happened when Flubert couldn’t answer. Rather than failing silently, it surfaced the gap back to the Fluent team. (Bidirectionality, anyone?) Every unanswered question signaled where the knowledge base needed work.
The governance pattern at this layer: surfaces query the layer, the layer learns from what gets asked.
The operational layer: There’s peace in procedure
The next commitment was governing how models reason on top of knowledge. Instructions, personas, and agent behaviors were proliferating across teams, each one well-intentioned, all of them slightly different. The same fragmentation that hit the docs hit the prompts.
LydAI is the proof point at this layer. The instructions started as one agent’s system prompt built on top of the Fluent Style Sheet. They multiplied into a callable skill that other agents reach into. The instructions live once. Every agent that calls them inherits the discipline.
The governance pattern at this layer: the layer defines once, surfaces reuse rather than reinvent.
The asset layer: System truths, audited
The deepest commitment is governing the deterministic values that humans and models alike must not improvise on. Tokens, schemas, components, the actual constraint set that defines what Fluent is. If the assets drift from their source of truth, every layer above is compromised.
Two structural choices carry the governance at this layer. The markdown/YAML split makes the layer legible: semantic intent lives in SKILL.md, deterministic values live in tokens.yaml, and the line between them is what humans and models alike are bound by. Drift detection makes the layer enforceable: a component map indexes every component’s surfaces, and an audit skill catches when a surface diverges from its spec. The architecture and the audit mechanism are both deep-dived in Fluent, Fluently.
The governance pattern at this layer: the layer is the contract, surfaces are audited against it. Lifecycle becomes testable, not just declared.
The layer outlasts the tool
A tool’s lifespan is shorter than the layer it depends on. Flubert was superseded. LydAI’s instructions outlast the agents that call them. Drift detection’s contract outlasts whatever surface gets audited. The strategy that said centralize the knowledge, govern the layer, make it trustworthy and extensible is still the right answer.
Tools are temporary. The layers are infrastructure.
Tools are temporary. The layers are infrastructure.