Govern: decide once, at the right level

Governance lives as records in your repository

Loom keeps governance as files in a loom/ folder in your own repository: owners, rules, exceptions, proposals, patterns, deprecations, layer versions and rituals. Loom reads them, checks work against them and writes to them only through changes your team reviews. If you stop using Loom, the records stay with you. Working

This is what those records look like for Loom Base, our own open-source system:

On our copy of Story Atelier, adding these records (an owner per component, templates, a proposal schema, changesets, decision records, a deprecation timeline and a two-layer model) moved Governance from 49 to 100. Working That work was done on our copy and scored with Loom's own open rubric, and the founder has not yet accepted the records.

In our reading of 14 public design systems in October 2026, none published its governance as machine-readable records. They describe governance in prose. Loom makes it data that people, tools and agents can all read.

Every rule has an owner and a reason

A rule is a versioned record: an owner, a rationale, a severity, a scope and how it is checked. Changing a rule follows the same flow as code: propose, review, accept, release.

Decisions are records too, with their reason. A real one from Loom Base:

packages/base/decisions/0003-component-tokens-required.md
Status       Decided by the owner, 25 Oct 2026
Decision     Component tokens are required.
Why          Agents need precise, machine-readable mappings per component.
Consequence  Base generates the component tier from each contract's tokens
             block (about 1,300 tokens). Components read only their own
             component tokens; each aliases a semantic token.

By default, raw colours, raw spacing and rebuilt components are warnings. The owner of an area can promote a rule to an error for that area. Accessibility rules are always errors: no record and no setting can turn them into warnings. Working

Exceptions that end on their own

Sometimes a team must break a rule. An exception records the rule, the scope, the reason, who asked, who granted it and an expiry date, at most 90 days later. While it is active, the finding is shown as information. When it expires, the finding comes back on its own and the exception is flagged for renewal or closure. Only the accessibility owner can grant an exception to an accessibility rule. Working

# loom/exceptions/checkout-banner.yaml (sample record, in the format Loom checks)
rule: no-raw-colour
scope: Checkout banner
reason: Campaign artwork, ends with the campaign
requested_by: Growth team
granted_by: Foundations owner
expires: 2026-11-08   # at most 90 days after it was granted

Patterns are written so they can be checked

A pattern is a record: the problem it solves, the components it uses, rules on what to do and what to avoid, content guidance, accessibility notes and a working example. Agents build from it, and Loom checks a composition against it. A regional or product layer can extend a pattern within its lock level, for example adding phone sign-in to the core sign-in pattern. Working

A component is promoted only when three conditions are met

A component built for one product lives in that product's layer. It moves to a shared layer when three things are true: it meets the definition of ready, an owner is named at the new layer, and design, engineering and accessibility have signed off. Loom shows each condition as met or missing, with its evidence. Working

Every request waits in one queue, with a due date

Every item waiting for a decision shows its due date and the working days left. The default service level is three working days; your organisation sets its own. Working days skip your organisation's holidays. When an owner is away, or a service level is about to be missed, the item goes to the owner's named delegate. Working

Health is measured, and "not measured" is said plainly

The system owner's first view shows four groups: adoption (how much of the interface comes from the system), drift (differences between code, Figma and contracts), flow (proposal lead time, service levels met, open exceptions) and quality (accessibility, readiness and test coverage). Anything Loom cannot measure says "not measured". It is never estimated. Working

Breaking changes are decided by evidence

Loom compares two versions of a contract and decides the version change. Removed or renamed properties, changed defaults and removed states or keyboard behaviour are major. Additions are minor. A visual change above 0.5% of a key screen also counts as breaking. Working

What does not work yet: release automation, changelogs and scheduled major releases. Concept

Large organisations run a system of systems

Larger organisations run layers: a global brand, regions, digital brands and products. Each layer has its own owner and its own version, and declares which versions of its parent it works with. Loom checks every layer against its parent and shows which layers a parent release would leave behind. Working

Every rule says how far it can bend at lower layers:

• Locked: no lower layer may change it. For example, accessibility minimums and consent notices.
• Extendable: lower layers may add, but not change what exists.
• Overridable: lower layers may replace it, with a recorded reason.
• Default: a starting point that lower layers are expected to tune.

What does not work yet: resolving tokens per brand layer with the source of each value shown.

Deprecation is announced, dated and migrated

A deprecated item is announced with a replacement and a removal date. The audit reports every remaining use until it reaches zero. Partial What does not work yet: Loom opening migration pull requests in consumer products.

When design and code disagree, an owner decides

Neither wins by default. Your repository and Figma show what exists. Loom flags the difference from the accepted contract, and an owner decides: accept the change or revert it. The Figma drift report works today on a synthetic library; the accept-or-revert flow is a concept. Concept

The control area shows the whole system in one place

The system page shows the whole system in one place: health, the five tiers, who governs what, rules, exceptions, the review queue, versions, usage, deprecations and patterns. Partial What does not work yet: the inbox actions and parts of the dashboard run on labelled sample data.

In the management space, people with the right role change severities, grant exceptions, assign owners and set service levels and autonomy. Every edit becomes a draft. An accepted draft becomes a pull request that the owner merges. Loom never merges. Partial What does not work yet: it has been tested against simulated git hosts, not a client repository, and roles are declared, not yet verified by sign-in.

Rituals, such as a weekly triage, are part of your organisation's own setup. Loom drafts each agenda from the queue and the health measures, and prepares a calendar invite and a Slack or Teams message. Partial What does not work yet: posting to a real Slack or Teams workspace. Notifications in Slack and Teams are planned. Concept

Governance is not paperwork around the real work. It is how a team decides once and stops deciding the same thing again.

Questions

Is this heavy for a small team? No. A team of three or fewer gets no standing meetings by default. Every change follows the same four steps.

Do contributors need evidence before they propose? No. Any team can propose. Loom attaches its own evidence, such as local rebuilds found by the audit; evidence is never required.

Who approves exceptions? The area owner by default. A rule can name its own approver. Accessibility exceptions always need the accessibility owner.

Can Loom lock us in? No. Governance lives in your repository as plain files.