A first reading needs no access to your code
The health check is a self-assessment in your browser. It asks 16 core questions across the eight areas of our public rubric, with an optional deeper section. You see a score for each area straight away. "Not sure" is a valid answer: unknowns are shown separately as blind spots, because what nobody knows is a finding too. Working
Your answers stay in your browser. If you ask for the full report, we receive your contact details, your profile (role, team size, organisation size) and your score per area. Your individual answers and free text never leave your browser. Working
The audit reads the real system, not a description of it
With access to your repository, the audit reads every token, component and screen. It does not run your code. It scores the same eight areas as the health check, so the two results can be compared, and it lists the evidence for every check. Working
The eight areas are:
- Foundations and tokens
- Components
- Patterns and pages
- Usage
- Governance
- Brand, illustration, microcopy and localisation
- Tools and sync
- AI readiness
Every finding names its evidence and the next step. This one is real output from an audit of takenote, an open-source notes app with no design system (MIT licence, commit e0eddbb):
Usage · 17/100
HIGH · 17 hand-rolled <button>s across 10 files, no shared Button
src/client/components/AppSidebar/ActionButton.tsx:24
src/client/components/AppSidebar/AddCategoryButton.tsx:18
src/client/components/AppSidebar/CollapseCategoryButton.tsx:20
src/client/components/AppSidebar/FolderOption.tsx:66
→ Extract one Button contract (variants, states, a11y) and migrate
call sites; this is the highest-leverage first component.
A finding is not an opinion about how the product looks. It is a fact about how the system is built, with a place in the code and a first fix.
The audit also lists the decisions only a person can make. In its first audit, Story Atelier had 192 open questions in the component contracts: things the code cannot tell us, such as when a component should not be used.
Scores fall into four bands: Tightly woven (90 and above), Holding together (75 to 89), Taking shape (60 to 74) and Loose threads (below 60). The standard is strict on purpose. A good system should not get an easy pass.
Eight areas, one rubric. Pick an area to see what was checked and found.
Story Atelier after Loom's service (filled) and takenote, a different app with no design system (outline), from the audit data. With scripting on, you can switch systems and open each area’s checks and findings.
A system can look complete and still be bypassed
The usage scan reads product code and reports raw colours and pixel values that bypass tokens, local copies of system components, and interface elements that have no contract or rule. Partial
Usage scan · takenote (real audit output, 7,184 lines of product code)
System bypasses per 1,000 lines 20.8
raw colour literals 91 (44 distinct, e.g. #333333 ×5)
raw pixel values 117 (counted at half weight)
token references 209
Distinct UI elements with no contract or rule 13 of 30
What does not work yet: the scan reads one consumer folder per run, and it does not yet keep a history, so you cannot see trends over time. Concept
Figma is read on the same rubric as code
Loom can audit a Figma library on the same rubric and compare it with code, to show where the two disagree. Partial
What does not work yet: the Figma audit has been tested on a synthetic library, not yet on a real client file. Figma variables can only be read on the Enterprise plan; on other plans that check says "not assessable".
What agents could not find becomes a list of needs
When an agent searches your system and finds nothing that fits, Loom records the need instead of letting the agent invent a component. Needs are grouped, counted and checked against a threshold the owner sets. Partial
search_system("date range picker for booking")
No component matches "date range picker".
Closest partial matches: Meter and ProgressBar (covers "range", not "date picker")
list_unmet_needs()
1 unmet need from 1 request; 0 over the threshold
(3 requests from 2+ requesters in 30 days). "date range picker" x1.
Real output from Loom's MCP server on Loom Base, our own design system, recorded in the agent replay.
What does not work yet: turning a need into a draft automatically once it passes the threshold. That full unmet-needs radar is a concept. Concept
Part of a system is visible from the outside
Before a first conversation, a consultant can read a public website the way a visitor would and measure the design system it implies: colours, type, spacing, repeated components, accessibility and microcopy. Only the areas visible from outside are scored, each with a confidence level. The rest say "needs access", never zero. Partial
What does not work yet: pages behind sign-in and real app screens. A discovery needs access for those.
Disagreement between teams is a finding too
In a paid discovery, each discipline answers the same questions as the health check in a team survey. Answers are encrypted in the respondent's browser to the consultant's key, and no group smaller than five people is shown on its own. The result shows where design and engineering see the system differently. Partial
What does not work yet: the survey has run with synthetic answers only, and collecting responses is manual.
Try the audit on your own code
Paste your CSS or tokens. See a first reading at once.
Nothing is sent anywhere. The checks are Loom’s own audit code, built into this page: it reads raw colours, spacing, token tiers, modes and contrast, and scores the two areas a stylesheet can show. The full audit reads your whole repository.
Runs on this page only: no upload, no storage, no tracking. Do not paste secrets anyway.
15 / 100 on the subset · Loose threads · Foundations and tokens 28 · Usage 0
- High2 of 2 semantic/component tokens hold literals instead of aliasing a lower tier
- High3 colour pairs below WCAG AA
- High11 raw colour values in styles (8 distinct)
- Medium13 raw pixel values with no spacing scale to check against
What does not work yet in the mini audit: the other six areas need a repository, so they are not scored on the page.
A low score is not a verdict. It is a list of work, in the order that matters.
Questions
Do you need access to our code for the health check? No. The health check needs no account and no access. The audit needs read access to your repository, and only during an engagement.
Does the audit change anything? No. It reads and reports. It never runs your code and never writes to your repository.
Why did a strong system score 59 at first? Because the rubric asks for 2026 standards: governance as records, AI readiness, brand and content rules that can be checked. Story Atelier is strong on patterns (100) and AI readiness (77), and weak on brand and content rules (24). The score points to work, not to failure. After our service, Story Atelier scores 83 (on our copy, scored with Loom's own open rubric; the founder has not yet accepted the records): five of eight areas are now Tightly woven, while Usage and Brand stay low without the product's code and brand material. Working
Can we see the rubric? Yes. The rubric is public, and the same eight areas are used by the health check, the audit and the control area.