Building for coherence, not compliance
Lessons from Baldurs Gate 3 on contracts, governance, and judgment at the edges
I’ve wanted to play Dungeons and Dragons for years. I just never wanted the table, the improvising in front of people, the social exposure, or the feeling of performing. So the game stayed on my to-do list, somewhere between intention and excuse.
Baldur’s Gate 3 removed the table. No group, no performance, no one watching. Just a character sheet and a rules engine sophisticated enough to make the world feel genuinely alive. I’ve been playing most evenings since the weekend, and fairly quickly I stopped thinking about my character and started thinking about the engine running the world. Not the story – the rules underneath it.
In tabletop D&D, that’s the Dungeon Master. Think of the DM as the person running the rules and the world – part referee, part simulator – responding in real time to whatever the players attempt. A good DM isn’t an author who writes the story in advance and delivers it to the table. They’re an interpreter. Someone who understands the rules well enough to respond faithfully to whatever a player tries, including things the rulebook never explicitly anticipated. The story emerges from that collision between player intent and system logic. That’s the frame Larian seemed to be working from: the studio as Dungeon Master, adapting the rules with a few house choices to make the world work.
That framing matters more than it might seem. Larian didn’t implement D&D 5th Edition faithfully. They changed the bonus action rules, rebuilt the movement system from their own engine, and reworked the magic item economy to the point of being almost unrecognisable from the tabletop version. Strictly speaking, it isn’t a faithful port. But it feels more coherent with the intent of D&D than many things claiming strict adherence, because Larian understood what the rules were trying to produce and built consistently toward that.
There’s a meaningful difference between following a rulebook and understanding what the rulebook is for.
I’ve spent years arguing that design systems are infrastructure rather than catalogues, that the most useful frame for a component library is contracts rather than approved screenshots. Playing BG3 sharpened that argument in a way I hadn’t anticipated – a DM who’s only memorised documented outcomes is useless the moment a player does something unexpected. What makes a DM valuable isn’t recall, it’s judgement grounded in a genuine understanding of what the rules are trying to produce. Most design systems never make that reasoning legible. They can answer questions they’ve already answered. They can’t help you reason when something new appears.
The Player’s Handbook encodes intent rather than prescribing specific outcomes. Action economy, spell slots, class abilities with clearly defined constraints, each one is a contract describing how the world works rather than how a particular situation resolves. A DM fluent in that logic can handle anything a player attempts, because every response can be grounded in the same underlying framework.
Design systems built with that same discipline look different from the catalogues most teams maintain. Tokens aren’t just variables; they encode decisions about what a colour means, where it applies, and why it was chosen. A component isn’t just a documented pattern; it’s a contract describing what it accepts, what states it supports, and what problem it solves.
In practice, this is the difference between a button API that exposes intent and one that exposes styling. tone="critical" and importance="primary" tells a team what the action is. color="red" and variant="solid" tells them what it looks like. Both ship pixels. Only one ships reasoning, and only one preserves accessibility and theming guarantees without asking everyone to remember them.
That’s when you find out what kind of system you actually have. An edge case, a new product surface, an interaction pattern that doesn’t map to anything in the library. A DM facing that situation has a choice: shut it down because it isn’t in the documentation, or make a call grounded in what the rules are meant to produce. A DM who consistently chooses the former kills the game incrementally, because players stop attempting anything the book hasn’t pre-approved and the world shrinks to the edges of what’s already been catalogued. A design system that governs the same way does the same thing to the teams relying on it.
I wrote about this in the context of AI agents, which can’t infer intent from visual similarity the way a human designer can. The same constraint applies to a developer who joined the team mid-project, or a designer trying to understand why two similar-looking components aren’t interchangeable. Documented outputs don’t carry the reasoning that produced them. They carry the result, not the logic.
Teams that treat a design system as a rulebook to follow produce brittle, over-fitted work. They implement the documented solution even when context has shifted enough that it no longer fits, because deviation feels like a violation rather than interpretation. Teams that understand what the system is trying to achieve can adapt without breaking what it’s for. Compliance was never the point. Coherence was, and those aren’t the same thing.
What protects against that brittleness isn’t more documentation. It’s governance with a clear enough basis for judgement that novel situations can be resolved consistently, a shared understanding of intent legible enough that a team can ask whether something feels coherent with what the system is trying to do and actually arrive at a useful answer. That’s the difference between a system teams trust and one they treat as optional.
I’m still early in the game. From what I’m told, it gets considerably more complex from here. I’ll keep playing, and I’ll keep thinking less about where to move my party than about what it means to build a system coherent enough to handle situations its authors never imagined.
A good DM doesn’t need a rule for everything. They need to understand the rules well enough that everything they do feels like it could have been one.
Thanks for reading! Subscribe for free to receive new posts directly in your inbox.
This article is also available on Medium, where I share more posts like this. If you’re active there, feel free to follow me for updates.
I’d love to stay connected – join the conversation on X and Bluesky, or connect with me on LinkedIn to talk design systems, digital products, and everything in between. If you found this useful, sharing it with your team or network would mean a lot.