Converting Seamline: we audited our own design system first

A design system can be well documented and still be hard to govern, hard to change and hard for an agent to trust. Seamline is a service design tool I built for UX teams, so that research, journeys and blueprints stay connected instead of living in separate files. It is in private beta. Its design system, Story Atelier, is the first system converted with Loom.

I need to be clear from the start. I built Seamline and I founded Loom, so this is not an independent customer story. It is the system we know best, tested by the standard we will apply to every client. If the audit was going to be gentle with anyone, it would have been gentle with us. It was not.

Seamline's design system scored 59 out of 100, a C. We would rather show that than an easy A.

A good system can still score a C

Story Atelier is not a neglected system. It has 69 typed tokens in a valid DTCG file, 72 catalogued components, and nine patterns and nine page templates with followable rules. Every component has a machine-readable contract, and the average contract fills all ten fields of the template. Microcopy rules are machine-readable and checked automatically. Every entry carries a lifecycle label, and the changelog records dates and commits.

Many teams would be proud of that. But Loom scores structure, governance and use, not the presence of documents. On the eight areas of our public rubric, Story Atelier scored 63 for foundations and tokens, 56 for components, 100 for patterns and pages, 58 for usage, 49 for governance, 24 for brand, illustration, microcopy and localisation, 43 for tools and sync and 77 for AI readiness. The overall score was 59.

The gap was not in what the system says. It was in what the system can enforce.

Tokens that look layered are not always layered

The most important finding was in the tokens. Story Atelier labels its tokens in three tiers: 21 primitive, 36 semantic and 12 component tokens. That is the architecture the DTCG format and most mature systems recommend. Yet none of the 48 semantic and component tokens refers to a token in the tier below. Every one holds a literal value.

The labels promise a structure that the file does not contain. The audit also found three role tokens that repeat another token's colour as a literal. The primary colour and the focus colour are both written as the same hex value, and so is a violet role and a plum accent.

Imagine that the brand team adjusts the primary colour to improve contrast on a new surface. Someone updates the primary token. The focus ring keeps the old value, because it was never an alias. Nothing breaks, so nobody notices. A few releases later, focus states no longer match the action colour, and a reviewer has to find out why by hand.

The same structure blocks themes. The system supports a light mode only. Dark mode was explicitly decided against, which is an honest record, and high contrast is not mentioned. Without aliases, adding either mode would mean touching components rather than remapping roles.

A tier label is a promise. The architecture only exists when the references resolve.

Documentation is not quality assurance

The second group of findings was about proof. None of the 72 components had a test or a story of its own in the code we audited, and none of the 30 interactive components had a keyboard or focus test. Six component records cite test files that were not part of the inputs. The accessibility guidance is written down carefully, but nothing in the inputs checks it.

The same pattern appeared in tools. Check commands are documented, but there is no CI configuration that runs them. There is no Storybook or other workshop, and nothing links the Figma library to the code. No component declares which platforms it supports, so there is no React Native counterpart and no recorded decision not to have one.

None of this means the components are broken. It means a team, or an agent, has to take their quality on trust. A complete contract with no automated checks is good documentation. It is not yet a definition of ready.

Governance written in prose cannot route a review

Seamline has a governance page, and it covers the right topics. Owners are described by area and role. There is a contribution route, a written semver policy and a deprecation policy that names a replacement and a removal condition.

The problem is that prose cannot be acted on. There is no owner field per component, so a review cannot be sent to the right person and a broken rule cannot notify anyone. Decision records are referenced but were not in the inputs, so no rule can be traced to the decision behind it. Deprecation has no timeline, so a consumer cannot plan a migration. There is no layer model, which matters as soon as a second brand or product needs to override something.

What the audit could not see

An honest audit says what it did not measure. The only consumer code we scanned was Story Atelier's own documentation site: 26 files and 3,592 lines. In that code, 455 of 492 component uses came from the system, about 92%. The audit also found three local re-implementations of system components, 12 interface elements in use with no contract or rule, 23 raw HTML elements where the system ships a component and 63 raw pixel values.

But adoption by a system's own site proves that the components render. It does not prove that product teams use them. Real adoption, drift and bypass can only be measured in product code, and that scan is still to come.

What the conversion produced

The conversion generated 91 artefacts. It derived 1,186 items from evidence in the system and left 219 explicitly for a human decision. Loom does not guess an owner, a purpose or a policy. It writes the question down.

The output includes a typed DTCG token set in which the semantic layer aliases the primitives, with two proposals to confirm. It includes 81 component contract files, where every field is marked as derived from evidence or as missing. The 192 open fields are mostly owners, which only the team can assign. There is a governance model with owners, semver, a contribution flow, deprecation and lifecycle, four guideline scaffolds for brand, illustration, microcopy and localisation, and agent instructions with 251 machine-readable rules.

Loom's MCP server now serves the system to agents. In a recorded session, a scripted agent asked for a destructive action with a confirmation. The server returned ConfirmDialog and Button with their exact imports. The agent's first draft used a component from another library, guessed a prop name, used two primary buttons and hard-coded a colour and a margin. The composition check returned four errors and one warning, each with the fix. After the agent applied those fixes, the same check returned no errors and no warnings.

In Figma, on a Professional plan, Loom pushed the tokens as variables, built native component sets and reference pages, and read the file back. When we changed one typography value on purpose, the next readback reported the difference, and the restored value passed. The Figma work is partial: of 764 declared component scenarios, 153 passed, 3 failed and the rest are not yet bound or need review. Code Connect was not established.

What we have not proven yet

The generated system has not been merged into Seamline's repository. That means there is no "after" score yet, and no visual comparison that proves the look is unchanged. Those are the next steps, and they will arrive as reviewable pull requests with before and after screenshots, like any client conversion.

We also learned something about our own standard. A system can be thoughtful, careful and well written, and still leave its quality to memory and goodwill. That is not a failure of the people who built it. It is what happens when one person maintains a system alongside a product.

Audit your own system against the standard you would apply to anyone else. Then make every rule something a person or an agent can check.

If you lead a design system, start with the free health check on this site, which scores your system on the same eight areas. If you want to see the full audit of your own code and Figma, book a conversation with us.

Continue the conversation

These sources go deeper into the topics behind this case study.

Design Tokens Format Module 2025.10 by the W3C Design Tokens Community Group

The specification behind the token file, including aliases between tokens.

Web Content Accessibility Guidelines 2.2 by the W3C

The standard behind the contrast, keyboard and focus checks in the audit.

How agents use a design system by Xavier Sorribas

What an agent needs from a system before it can build on it, and what it should never decide alone.

Governance for small teams by Xavier Sorribas

A lightweight model for owners, contribution, semver and deprecation when the system team is one or two people.

Fix the system, then keep it healthy by Xavier Sorribas

Why design systems need someone to operate them, not only to document them.