System work is invisible until it breaks a plan
Nobody knows who decides. A team needs a new component or a change to an existing one. The request sits in a channel. Nobody knows who owns it or when there will be an answer.
Rework arrives late. A screen passes design review, then fails a design-system review or an accessibility check in the last week. The work is done twice.
Exceptions never end. A team was allowed to break a rule "for this release". A year later the exception is still there, and others copy it.
System changes break plans. A change to a shared component lands in the middle of a sprint and breaks a product team's work.
Status reports are opinions. You cannot see how healthy the system is, or whether it is getting better.
Loom makes the system's work visible and predictable
Every request has an owner and a due date
Every item waiting for a decision sits in one review queue with its due date and the working days left, or how long it is overdue. 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 the service level is about to be missed, the item goes to the owner's named delegate. Working
Requests start with one clear question
Every request starts with: does something already exist? Loom answers reuse, extend or new, with the evidence, before anyone builds. Needs that nothing meets are recorded and counted, so you can see what teams keep waiting for. Partial What does not work yet: a need does not yet become a draft on its own once it passes the owner's threshold.
Clear roles, written down
Roles are records in the team's repository: a system owner, one owner per area, a guild of three to seven people across design, engineering, content and accessibility, contributors and consumers. You can see who decides what. Working
Exceptions with an end date
An exception records the rule, the reason, who asked, who granted it and an expiry date, at most 90 days later. When it expires, the issue comes back on its own and is flagged for renewal or closure. Open exceptions count in the system's health. Working
Breaking changes are known before they ship
Loom compares versions of a component's contract and says whether a change is breaking. Working What does not work yet: release automation, changelogs and batching breaking changes into a scheduled major release. Concept
Deprecated items carry a replacement and a removal date, and the audit lists every product that still uses them. Partial What does not work yet: migration pull requests in those products.
Rituals with agendas drafted from data
Weekly triage, a monthly health review, office hours: your organisation records how it actually works. Loom drafts each agenda from the queue, expiring exceptions, deprecations due and health measures, and prepares a calendar invite and a Slack or Teams message. A team of three or fewer gets no standing meetings by default. Partial What does not work yet: posting to a real Slack or Teams workspace. Notifications in Slack and Teams are planned. Concept
Health you can report
Four groups of measures: adoption, drift, flow (proposal lead time, service levels met, open exceptions) and quality. Anything without a source says "not measured". Working
One queue, with due dates you can plan around
This is the support queue in Loom's control area, with sample records: every item has an owner, a service level in working days and a due date.
One support queue
Real screen, sample records
Every change follows the same path
How a change moves
Diagram- Intakea request from a person or an agent
- Proposalan owner is named; due date set
- Builda draft, labelled when an agent wrote it
- Reviewdue date shown; a delegate takes over when the owner is away
- Release Conceptchangelog and version
Autonomy is set for each area, by its owner
The modes work like the permission modes of a coding agent such as Claude Code, with allow and deny rules on top.
- Observe
Loom reports what it sees. Nothing changes.
- Suggest default
Loom drafts changes. A person approves each one.
- Auto with guardrails
Routine changes merge when every check passes. Anything else waits for a person.
- Full
Changes merge when the required checks pass, with no review: the owner accepts that risk in writing. Any person can revert a change with one click afterwards.
We show our own numbers
- The queue is real. Service-level timers, delegate routing and holiday calendars run on governance records today, on our reference system and a synthetic second system, both labelled as sample. Working
- The discovery report includes a phased roadmap. It combines the audit, the team survey and the health check into a roadmap with how success is measured and a draft quote. It has run on sample systems, not yet with a client. Partial
- The audit gives one baseline. The same eight areas across the health check, the audit and the control area, so progress can be compared over time. Working
A design system should remove surprises from delivery, not add them. That starts with knowing who decides, and by when.
Questions
Does Loom replace our project tool? No. Loom manages the design system's own queue and records. Connections to Jira and Linear are planned, not built.
How much process does this add? Very little. Every change follows the same four steps: propose, review, accept, release. Small teams get fewer rituals.
Can we change the service level? Yes. Your organisation sets it, and it skips your holidays.
How do we see whether the system is improving? The four health measures show the current state today. Trends need a history of audits, which Loom does not store yet.