Every capability we describe on this site, with its real state, from our claims register (docs/product/claims.json, updated 2026-10-26). The build checks every page against it: a page may describe only what runs today, and plans appear only under "Coming next". Today: 41 runs today, 53 runs in part, 7 coming next, 1 our commitments.
Runs today
Built, tested and in use.
| Capability | State | What it does today |
|---|---|---|
| Agent package (AGENTS.md and rules) | Runs today | Conversion writes AGENTS.md plus generated rules for the system (251 for the reference system). |
| Agent replay | Runs today | Playback of a recorded session of a scripted agent against the Loom MCP server, with real server output (docs/launch/mcp-demo-transcript.md, from npm run mcp:demo). |
| Agent run logs with cost caps | Runs today | |
| AI-generated drafts are labelled | Runs today | |
| AI-generated reports are labelled | Runs today | |
| Any MCP agent can use your system | Runs today | |
| Audit explorer | Runs today | Real audit output: per-area scores, checks and top findings for takenote (an open-source app at a pinned commit), Loom Base and Loom's own control area, each with the command that produced it (data/audit-areas-*.json, written by npm run site:data and scripts/site/interactives/score-us.ts). No private client system is shown. |
| Audit of our reference system | Runs today | Shown as aggregate scores on the Proof page. |
| Before and after: values become tokens | Runs today | Token names, values and statuses come from the DTCG file Loom's conversion generated for takenote; the after rule is written by Loom's token codemod (npm run site:before-after) from a takenote excerpt, with confidence levels (high: exact; medium: colour tolerance or a SCSS variable), and a test fails when the page differs from the codemod's output. Values the codemod does not swap (a px token against a rem value, no matching token) stay as they are with the reason. The page compares the computed styles of both buttons in the browser. |
| Breaking-change detection | Runs today | diffContracts classifies contract changes as major, minor or patch, including the 0.5% visual threshold. |
| Composition checks | Runs today | check_composition flags raw values, re-implementations, unlabelled and raw form controls, two primary actions in a region, style overrides and pattern rule breaks, applying governance severities and exceptions. The 25 Oct live test caught 6 of 9 planted issues; the three misses were fixed with tests. |
| Content and voice checks | Runs today | Content rule records (phrases and patterns over interface copy, with allow patterns) checked by check_composition, audit_code and the rules command. |
| Deprecation tracking | Runs today | Deprecation records feed audit_code (every use reported with replacement and date) and the system page, and become migration rules: a token, component or prop with a named replacement is a rename, prose is a manual step (npm run migrate -- spec|simulate|apply --project <id>; MCP simulate_migration and plan_migration default to the system's deprecations). Opening the pull requests is the migration-prs claim. |
| Design tokens generated from code (DTCG) | Runs today | A DTCG 2025.10 token file generated from code with evidence per value (primitive and semantic tiers), checked per $type by the conversion validator. For a system with a token config (loom/tokens.json): the component tier, mode axes (light and dark, density, motion, locale) and brand layers with their own mode values; npm run tokens -- build writes CSS custom properties, Tailwind v4 @theme and a v3 preset, a typed CSS-in-JS module and DTCG files that load back identical in every context and brand; npm run tokens -- check finds alias cycles, dangling aliases, missing modes, tier and lock breaks and contrast failures per mode and brand. Run on Loom Base (six themes plus a Harbor brand skin) and Harbor UI (component tier and a dark mode); not yet on a client's tokens. |
| DESIGN.md export | Runs today | Shown as aggregate scores on the Proof page. Not yet: Only default-mode token values (per-mode values are not in Loom's records); not linted with the official DESIGN.md command-line tool; not yet delivered to a client repository as a pull request. |
| Exceptions that expire | Runs today | Time-boxed exceptions (at most 90 days) downgrade matching findings to info and expire automatically; accessibility exceptions count only when the accessibility owner grants them. |
| Figma Professional plan support | Runs today | Tested in one Figma Professional file: variables (one mode), a partial library, read-back compared with code. |
| Free health check | Runs today | Free self-assessment in the browser: 16 core questions over the 8 rubric areas plus an optional deep section, client-side scoring per area, unknowns shown as blind spots. |
| Governance records in your repository | Runs today | Governance records in the client repository's loom/ folder (roles, areas, layers, rules, exceptions, proposals, patterns, deprecations, rituals) with schemas; rules with owner, rationale, severity and scope; warn by default with owner promotion per area; accessibility always error. Seeded records for the reference system and a synthetic second system are labelled Sample. |
| Health check privacy | Runs today | Only contact details, profile context and area scores leave the browser, and only when the full report is requested; individual answers and free text stay local. |
| Health measures | Runs today | Four health groups (adoption, drift, flow, quality) from measurements and records, with 'not measured' where there is no source. |
| Health over time | Runs today | Each audit run stored as a small snapshot of scores and counts in the system's loom/history/ (npm run history -- --record, loom history --record, the weekly steward, npm run sense); trends per area, band changes, usage per consumer folder and drift signals against the previous run, shown in the terminal, the control area (product tour), the HTML report and to agents (get_health_history). Run on Harbor UI (two runs) and Loom Base (one run); not yet in a client's repository. |
| Internal pilots (25 October 2026) | Runs today | Two internal pilots on our own products on 25 Oct 2026 found audit gaps for non-standard apps (generated files double-counted, token modules missed, utility-class values, one score per client); fixes merged with tests. No client has used Loom yet. |
| Layer versions and compatibility | Runs today | Layer versions and parent compatibility ranges in governance records; layerCompatibility and releaseImpact show which layers a parent release leaves out of range. |
| Localisation readiness checks | Runs today | The audit checks four localisation readiness items, and the content records are checked for length per locale, casing, CJK and RTL readiness. npm run l10n -- run renders every component example pseudo-localised and in each target locale (real translations where content tokens hold them, otherwise the locale's expansion) with the system's own components in Chromium, and reports clipped, truncated and overflowing text and text a component renders by itself. Run on Loom Base's 69 components (68 of 74 examples render statically); not yet on a client's components. |
| Loom audits itself | Runs today | Loom's own control area scores 22/100 on Loom's audit (Loose threads); Loom Base scores 75/100 (Holding together). Re-run on 25 Oct 2026 (night) with the commands in data/audit-areas-control-area.json and data/audit-areas-loom-base.json; earlier runs gave 26 and 73. Published by owner decision (25 Oct, eighth batch). |
| Loom's service on our reference system | Runs today | Shown as aggregate scores on the Proof page. |
| MCP server for agents | Runs today | MCP server with 36 tools: 32 that read and check (search_system, get_entity, get_tokens, get_guidelines, get_rules, get_design_md, check_composition, audit_code, intake_need, list_unmet_needs, get_flow, search_illustrations, get_illustration, search_content, get_content, get_localisation, get_health_history, simulate_migration, plan_migration, get_accessibility_passport, find_conflicts, get_version_plan, get_campaigns, get_design_debt, track_requests, find_reuse, get_roadmap, get_academy_path, get_lesson, check_tokens, get_token_layers, check_brand) and 4 that write drafts, off unless the host turns them on (propose_change, request_exception, report_need, draft_branch); 4 resources and 1 prompt; timings per call are measured in the recorded session on Loom Base. |
| One contract per component | Runs today | Conversion drafts one contract per component with every missing field marked as a question; behaviour as data for the components Loom writes (Loom Base's 69 and the three loom-parity components). |
| One public rubric | Runs today | One public 8-area rubric shared by the health check, the audit and the control area. |
| Pattern checks | Runs today | Pattern records with machine-checkable do/don't rules; check_composition validates against them, with layer variants within lock levels. |
| Promotion checks | Runs today | checkPromotion lists each promotion condition (definition of ready, owner at the target layer, design, engineering and accessibility sign-off) as met or missing with its evidence. |
| Review queue with service levels | Runs today | Review queue with service-level timers in working days, organisation holidays and routing to delegates when the owner is away or the service level is near. |
| Runs locally | Runs today | |
| The audit engine | Runs today | Audits a repository (React, TypeScript, CSS, plain HTML/CSS/JS apps) without running it, scores the 8 rubric areas with evidence per check, and lists the decisions only a person can make. Verified on code it was never tuned for (packages/loom-parity, 2.4 s). |
| This register and its gate | Runs today | Every site status points to this register; tests/unit/site-claims.test.ts checks label against status and evidence paths, and npm run site:build runs it first, so an overclaim stops the deploy. |
| This site's DESIGN.md | Runs today | This site's own DESIGN.md (the Selvedge site rules) is published at /DESIGN.md, copied into the site by the build and linked from every footer and the resources page; Loom Base's exported DESIGN.md is published at /design-md/loom-base.md. |
| Token authentication for the MCP server | Runs today | Static bearer token of at least 32 characters, constant-time compare, refuses to start without one. Not MCP OAuth. |
| Untrusted content is fenced | Runs today | Tool results fence, neutralise and flag content quoted from the client's repository, docs and Figma as untrusted data. Lowers prompt-injection risk; does not prevent it. |
| Usage scan of consumer code | Runs today | Usage scan of one or several consumer folders per run, with counts per folder: system usage, raw colours and pixel values that bypass tokens, local copies of system components, unruled elements. Copies are found by name and then checked in the syntax tree: a component that renders the system component it is named after is a wrapper, a CSS class counts only when scanned markup applies it, and audit_code matches the head of a name (ProductCard, not CardList). Stored history and trends come from loom/history/. Static scan, so adoption is a lower bound; tested on Harbor UI's two consumer folders. |
| Visual brand rules and an illustration library | Runs today | Brand rules in loom/brand-rules.json (allowed and forbidden colour pairings, the token palette, type families and pairings, logo clear space, minimum size and backgrounds as declared rules, voice terms and casing from the content records), checked by npm run brand -- check, by MCP check_brand and by the audit, which reports the findings in the brand area. Sample rules for Harbor UI and proposed rules for Loom Base; only accepted, authored rules earn audit credit, so no client's rules have been checked yet. |
Runs in part
The part that runs is described first; the rest is named.
| Capability | State | What it does today |
|---|---|---|
| A home for each role | Runs in part | A home per role in the control area: the week's queue, decisions waiting, exceptions expiring, what agents did, links to the role's own views (the PM page, roadmap board, dashboard and monthly report, campaigns and the debt ledger) and the measured benefit: the 90-day measures read from loom/history and real evaluations in loom/evals, review time and service levels kept from the proposals; shown in the product tour with Harbor UI sample records. Not yet: Not yet run on a client's records. Harbor stores no real evaluation, so its agent on-system rate reads Not measured; drift caught before merge is read only from health snapshots that record it, and nothing writes that number yet. |
| A packaged CI step | Runs in part | packages/action: a composite GitHub Action that runs `loom ci` on the client's runner. On pull requests: the PR reviewer, the contract conformance check on the changed lines and the AI-authorship labels, in one comment updated per push, with check annotations; the check fails only on blocking findings (errors as area owners set them, accessibility errors always). Weekly: the steward's data-only draft pull request. `loom init` writes the workflow. Tested end to end on a throwaway repository by running the action's script locally against the mocked GitHub API. Not yet: Not yet run on GitHub's runners or in a client repository; not published to the Marketplace; the CLI is built on the runner from the action's checkout (about 20 seconds). |
| Accept-or-revert flow for conflicts | Runs in part | Conflicting proposals are detected (two open proposals on the same component, token, pattern or rule; a proposal that contradicts an accepted, released or declined decision or a deprecation) and shown with both sides, a recommended resolution, a suggested outcome per open proposal and the decider, in the review queue of the control area, the weekly triage agenda (agenda source conflicts), npm run conflicts and the MCP tool find_conflicts. Loom recommends; the owner decides. Shown on Harbor UI's sample records; Loom Base has no proposals. Not yet: Figma-versus-repository drift is reported but not resolved: the accept-or-revert flow for drift is not built; no client has used conflict detection. |
| Accessibility checks | Runs in part | For components Loom writes (Loom Base's 69 components): axe on every web state, the accessibility tree on every native state, keyboard and focus scripts. Not yet: A client's own components (the client path covers Button, Switch and Dialog); contrast excluded under jsdom; no device runs. |
| Accessibility passport | Runs in part | A per-component accessibility passport built from the system's own test results and contracts (named in loom/accessibility.json): parity tests per platform, axe in a browser per colour mode, keyboard scripts, focus visible, contrast of the component's token pairs per mode, manual screen-reader passes, keyboard and screen-reader notes, known gaps and the date last verified. Generated for Loom Base's 69 components, shown on each component page of the Library, exportable as JSON, Markdown and CSV (npm run a11y:passport) and served by the MCP tool get_accessibility_passport. Not yet: No manual screen-reader pass has been recorded, so that check reads not run on every component; it is evidence for a conformance review, not a European Accessibility Act conformance claim; Harbor UI has no test evidence; not run for a client. |
| Adoption campaigns | Runs in part | Adoption campaigns measured from usage snapshots in loom/usage/: progress per team, a burndown with the plan line, codemod or migration links, nudges drafted for the owner to approve, and a campaign review; shown in the Ops space and through loom campaign and get_campaigns. Not yet: Not yet run on a client's usage history; Harbor's history is mostly sample data, and nudges are drafts, not sent. |
| Agents run on your machines | Runs in part | The command line and the MCP server run on the client's machines. The PR reviewer and the weekly steward run inside the Loom GitHub Action on the client's runner with the client's own model key from repository secrets (BYOM); without a key they run Loom's deterministic checks only and say so in the comment, the job summary and an annotation. Tested with the mocked GitHub API and a simulated Anthropic API. Not yet: Not yet run in a client's CI and no real model API has been called through the action; Loom cloud is planned. |
| AI-generated pull requests are labelled | Runs in part | Every pull request the PR writer opens carries the loom:agent-generated label and a disclosure built from the provenance record (model and provider when reported); the run fails if the label is missing. The Loom action also labels pull requests written by coding agents (ai-generated, plus loom:agent-generated when they carry Loom output) from the pull request's author, commit identities, Co-authored-by trailers and Generated-with lines, and lists the reasons in its comment. Tested against a simulated GitHub API and on a throwaway repository against the mocked GitHub API. Not yet: Not yet run against a real repository; labelling pull requests Loom did not open works on GitHub only. |
| Autonomy modes as records | Runs in part | Autonomy mode per area is a governance record and the stricter-mode rule is enforced. Every pull request and comment an agent makes (reviewer, intake, radar, support and chat, steward, release, governance pull requests) writes an autonomy record next to the run log: the areas touched with owner and mode, the mode asked for and used, the gates that changed it (eval gate, Observe, Full refused), the outcome and link, the reviewers and how to undo it; Loom never merges. npm run autonomy shows each area's mode, what each agent action becomes under it today, and the recorded actions. Not yet: Agents acting on their own under Auto or Full (merging, reverting); the Full-mode risk acceptance and the one-click revert; records are not tamper-evident and have not been produced in a client's CI. |
| Bring your own model | Runs in part | Any MCP agent, with any model, can use the server. Not yet: Provider setup for agents Loom runs (in development). |
| Components written from contracts (React and React Native) | Runs in part | React and React Native generation from one behaviour contract, with axe, keyboard and parity tests: Loom Base's 69 components, and Button, Switch and Dialog on the client path. Not yet: Generation for a client's own components; visual regression (planned). |
| Contract tests for agents | Runs in part | `loom conform` and the Loom action check code on any diff against the system's contracts in four areas (allowed components, tokens, props and values, accessibility) with the system's governance applied, counting only added or edited lines, and print a per-area report; exit 1 when an error remains. Not yet: Not yet run on a client's repository or on real agent output. Comparing models on the same tasks is the evaluation harness, which has not run with a real model yet. |
| Control area | Runs in part | System page built from governance records and the audit, with sample records labelled. Not yet: Inbox actions and parts of the dashboard run on labelled sample data; not authenticated; Loom's own control area scores 26/100 on its own audit. |
| Deletion at the end of an engagement | Runs in part | npm run engagement:close deletes every working copy, cache and derived artefact of an engagement, checks nothing remains and writes a receipt with a SHA-256 per deleted file. Not yet: Not yet used in a client engagement. |
| Design debt ledger | Runs in part | A design debt ledger derived from audit findings, exceptions and divergences, each item with an owner, a size (S to XL, never hours or money), its age and the teams it affects, planned and paid in sprints; shown in the Ops space and through loom debt and get_design_debt. Not yet: Not yet run on a client's records; sizes are estimated by a stated rule until an owner records one. |
| Discovery report | Runs in part | Combines audit, control baseline, survey and health check into a Markdown and printable HTML report with risks, a recommended path, a phased roadmap and a draft quote inside the owner's discovery band. |
| Draft writes by agents | Runs in part | Draft writes over MCP, off by default (--allow-writes or LOOM_MCP_WRITES=drafts): propose_change drafts a proposal with rationale and affected items that enters the review queue; request_exception writes an exception request routed to the person who may grant it; report_need logs a need for the radar; draft_branch commits to a loom/agent/ branch and opens a draft pull request through the one PR writer. Every write is attributed to the client and model, kept in a write ledger, rate-limited per client, size-limited and idempotent by client request id. No tool accepts, approves, grants, merges or releases; tests assert it, end to end over the SDK's in-memory transport. Not yet: draft_branch has run against simulated git hosts only, never a client repository. The management space does not show agent drafts yet (scripts/mcp-queue.ts lists them). Client identity is self-reported and not verified; the HTTP server still uses one shared token. |
| Figma library audit | Runs in part | Audits a Figma library on the rubric (REST API, an offline export, or Loom's Figma plugin reading the open file) and reports code-to-Figma drift. Tested on a real Figma file that Loom built for the purpose, not a client's: Loom Base in Loom's own Figma account (Selvedge variables in light and dark, six components, a sample screen with planted drift). It found every planted problem: three detached instances, raw fills including an instance override, twelve off-scale spacing values, unstyled text and an off-library text style. Not yet: Not yet run on a client's file. The plugin's audit is unit-tested on data captured from that file but has not been run as a plugin inside Figma desktop. Read by REST on a Professional plan, a file has no variables (Enterprise only) and detachment is inferred from layer names; the plugin reads both. |
| Figma, Storybook and CI connections | Runs in part | MCP server and command-line audits. Figma variables (one mode) and a partial library, tested on the reference system through an agent and Figma's connector; Loom Base variables (light and dark) and six components bound to them, built in a new test file the same way. Storybook stories from contracts are registered separately (storybook-stories). Not yet: CI package, GitHub App, Jira and Linear. |
| Git hosts (GitHub, GitLab, Azure DevOps) | Runs in part | One git-host interface with GitHub, GitLab and Azure DevOps adapters and one PR writer that opens labelled draft pull requests with provenance. Not yet: Tested against simulated hosts only; not yet run on a client repository. |
| GitHub App | Runs in part | App manifest with three permissions, JWT to installation-token exchange scoped to one repository (broader grants refused), GitHub adapter and fine-grained token fallback, tested against a simulated GitHub API. Not yet: The App is not registered on GitHub and has not been installed on a client repository. |
| Layers (system of systems) | Runs in part | A generated layers map (primitive tokens, semantic tokens, component tokens, components, patterns and flows, pages) with where each token is used, directly and through the layers above, and which tokens nothing uses: a Library page per system, npm run tokens -- layers and MCP get_token_layers, on Loom Base and Harbor UI. Not yet: The governance layers view (standing in a region or product layer and trying a change against the lock levels) still runs on sample data. |
| Lead data retention | Runs in part | Daily retention job built and tested. Not yet: Not deployed (placeholder D1 id). |
| Look stays the same (screenshot diff) | Runs in part | Pixel-diff of before and after screenshots against the 0.5% per screen rule, with a coloured diff image and a non-zero exit when over the limit. Not yet: Screenshots are not captured automatically for every route; not yet used in a conversion. |
| Loom Academy | Runs in part | Loom Academy: role paths (designer, developer, PM, system owner, area owner, Ops lead, content, accessibility) and a general track, generated from the system's records; lessons checked by real work in the repository (an on-system pull request, a proposal, a decision, a fixed practice finding, the MCP setup); certificates with verification pages that turn due for refresh when the records change; reviewer nudges; the Ops lead view in the CLI, the Library and the Ops space; loom academy in the CLI and two read-only MCP tools. Not yet: It runs on Harbor sample records and a synthetic repository only; no client has used it. Refreshers and nudges are not sent outside the pull request, there is no public Loom-hosted certificate verification, and readiness does not yet map to permissions in the role model. |
| Loom Base | Runs in part | Loom Base v1: 69 behaviour-as-data contracts, React and React Native output, 453 of 453 parity tests, 1,113 axe runs with 0 failing across colour modes, 2,436 of 2,436 contrast pairs at WCAG 2.2 AA, 26 of 26 keyboard scripts, 11 templates; platform audit 73/100. The site reads these numbers from packages/base/COVERAGE.md at build time. Not yet: All components beta pending owner review; builds as an npm package and a shadcn-compatible registry but neither is published; visual baselines not yet generated on the CI runner; some native forms partial; no message catalogue, Figma library or release tooling; Loom's own screens are not yet on it. |
| Loom Base as a starter | Runs in part | Forks Loom Base outside the repository, themes it from an app's audit (light and dark), prunes it to the components used, writes plain CSS tokens and a migration plan, and seeds governance sized to the team. Not yet: Run on one of our own apps so far. |
| Management space | Runs in part | Edits to severities, exceptions, owners, delegates, service levels, autonomy and rituals become drafts against loom/; an accepted draft becomes a pull request the owner merges. Not yet: Tested against simulated git hosts, not a client repository. Roles are verified against the git host (CODEOWNERS and team membership) when an identity snapshot is given; the live server does not fetch one on each request yet. |
| Migration pull requests | Runs in part | npm run migrate: a migration spec from deprecation records or a contract diff plus the renames a person confirms (never a guessed rename); a codemod for renamed components (imports and references, namespace members, aliased when renaming is unsafe), props, literal values and tokens, with changed defaults written out; a patch and a pull-request body per consumer with manual steps as a checklist; opened as a draft through the git-host PR writer (Suggest, labelled, never merged). Run on the Harbor UI 2.0 sample consumers and simulated hosts; MCP plan_migration returns the patch and body. Not yet: Not yet run in a client repository or on a real git host; no before and after screenshots in the pull request; one pull request per run (no fan-out across consumer repositories); no model for judgement calls. |
| Migration simulator | Runs in part | npm run migrate -- simulate and MCP simulate_migration: for a deprecation or a contract diff, the files, call sites and consumers reached and how many sites the migration codemod rewrites against those a person must change, measured by a dry run on consumers with source and estimated from loom/usage counts for consumers known only by usage data (prop values and tokens counted as unknown). Run on the Harbor UI 2.0 sample (three consumers with source, one usage-only) and on Loom Base's page templates. Not yet: Counts call sites, not rendered screens; not yet run on a client's consumers; release:check does not run it automatically. |
| Mini audit in the browser | Runs in part | An in-browser subset of the audit on pasted CSS, SCSS or token JSON: the audit's own stylesheet reader, colour and contrast code, tier detection, DTCG validation and rubric scoring, on its own page (/demos/mini-audit/) and on the See page. 10 of 11 Foundations checks and 1 of 7 Usage checks run; nothing is sent anywhere. Not yet: The other six rubric areas and everything that needs a repository (components, usage across files, governance, tests). Mode and contrast checks read only the paste. The page labels it a subset. |
| Monthly report | Runs in part | A monthly one-page report in plain words (loom report monthly), HTML with print CSS that fits one A4 page, from measured data only, with a section for what is not measured yet. No savings or money figures are computed. Not yet: Sample records only; no sponsor has received one. PDF comes from the browser's print, not a generated file. |
| Notifications in Slack and Teams | Runs in part | A Slack support bot: answers which component or token to use with citations from the system's records and says when it is not sure; files needs as draft proposals with the owner from the ownership model; routes exception requests (reason and expiry) to the owner, who approves or declines in Slack, an approval opening a draft pull request on loom/exceptions.json; reminders before expiry; ritual agendas and the digest drafted for the owner to approve before posting. Slash command, signed requests, Socket Mode and an app manifest with minimal scopes. Tested against a fake Slack, including a scripted end-to-end conversation. Not yet: Not yet installed in a real Slack workspace. Teams is later: its message parsing exists, its adapter does not. |
| Ops space | Runs in part | An Ops space in the control area (at a glance, team and roles, rituals, support queue, onboarding, comms centre, continuity), drawn from the records in loom/; shown in the read-only product tour with sample records. Not yet: It has not yet run on a client's records, and comms are drafted for an owner to approve, not sent. |
| Parity tests across platforms | Runs in part | Parity tests for every component Loom has generated: Loom Base's 69 components (453 of 453 pass: 273 web in jsdom, 180 React Native in the Jest preset, read from packages/base/COVERAGE.md) and the three loom-parity components of the client path (Button, Switch, Dialog). Not yet: Device runs; generating a client's own components this way. |
| Product-manager views | Runs in part | Product-manager views from the loom/ records: every ask to the system team with status, owner and the 2-working-day service level (met, missed, on track, at risk, overdue); a team needs radar from asks, unmet searches, local copies found by the code audit and usage per team folder; a reuse finder for approved patterns, signed-off flows and stable components; plain release notes in roadmap terms; team usage. In the static stakeholder site (loom dashboard build), the CLI and the MCP tools track_requests and find_reuse. Not yet: Run only on Harbor UI sample records and a synthetic CLI repository; no client has used it. Team attribution needs loom/teams.json; nothing is sent to Slack or Teams. |
| Prototyping with the system's components | Runs in part | The workbench Composer builds pages from system components, for the reference system, on the dev server. Not yet: Other systems; agent-built prototypes from a brief. The product tour shows a screenshot. |
| Public website snapshot | Runs in part | Reads a public website politely (robots.txt, sitemaps, 15 pages) and measures the implied design system; only outside-in areas are scored, each with a confidence level. Not yet: Verified on a synthetic site in tests; pages behind sign-in and real app screens are out of reach. |
| Release automation and changelogs | Runs in part | npm run release (plan, notes, pr) computes the semver bump per package from the contract diff since the last release, accepted and signed-off proposals and deprecations; blocks a major without a codemod that exists or a migration pull request, and names child layers the next version leaves; writes the changelog section in the system's recorded voice (agreed terms, casing), release notes for designers and for developers, the contracts snapshot and the release record; and opens the release pull request as a draft (ready for review only for a patch or minor in an Auto area). Runs on Harbor UI's sample records (1.4.0 to 1.5.0) and on Loom Base's first release; MCP tool get_version_plan. Not yet: Run in a client's repository or CI; pull requests opened only on an in-memory host and the local mock git host, never on GitHub; no changesets or release channels; majors are flagged for the quarterly batch but not scheduled; Loom never publishes or merges, by design. |
| Rituals prepared from data | Runs in part | Ritual records with agendas drafted from data, an .ics invite and Slack (Block Kit) and Teams (Adaptive Card) messages. The Slack bot drafts each agenda the day before and sends it to the ritual's owner, who approves it before it is posted (never sent automatically unless configured). Not yet: Not connected to a real Slack or Teams workspace; calendar delivery is a download. |
| Roles and permissions | Runs in part | Fourteen roles (owners, Ops lead, guild, product designer, front-end developer, product manager, engineering lead, executive sponsor and the AI agent) with a permissions matrix and RACI for decisions D1 to D19, enforced by authorise() with the standing rules and delegation; roles verified against CODEOWNERS and team membership; the kickoff sign-off of roles and RACI recorded as a D14 decision; the tables in governance.md and the Library generated from the same data. Not yet: Verified against a simulated git host in tests; the live server does not fetch identities on each request, and the Loom GitHub App does not yet request the Members: read permission team membership needs. |
| Rules command for any CI | Runs in part | npm run rules -- check and the `loom` CLI (loom lint, loom conform, loom ci) apply the governance rules and exit 1 when an error remains, so they run in any CI; `loom init` writes a ready-made GitHub Actions workflow that runs them on every pull request. Not yet: The CLI is not published to npm, and the ready-made workflow has not yet run on GitHub's runners or in a client repository. |
| Semantic search | Runs in part | search_system can rank with the client's own embeddings model. Not yet: Tested against a local mock model only, not a real provider. |
| Sensors that watch for drift | Runs in part | The scheduled scan sensor: npm run sense (or the weekly steward job) audits the system, stores a loom/history/ snapshot with drift signals against the previous run (band and score drops, more re-implementations, raw values or unruled elements, lower adoption), lists them at the top of the steward's data-only draft pull request, and runs the radar so needs over the threshold become drafts. Pull-request checks run through the reviewer agent. Not yet: No Figma watcher and no agent telemetry; the scheduled jobs are workflow templates that have not run in a client's CI. |
| Spam check on forms | Runs in part | Cloudflare Turnstile widget on the health check contact step; the endpoint verifies each token with siteverify, rejects missing or invalid tokens (400) and fails closed (503) without a secret. Unit and browser tested with Cloudflare's test keys. IPs are used only by the in-memory rate limiter and never stored. Not yet: The owner set the TURNSTILE_SECRET Pages secret (Production) on 25 Oct 2026, but the live site does not yet serve this code; the check runs from the first production deploy that includes it. Change to working once a real submission on the live site is verified and stored. |
| Stakeholder dashboard | Runs in part | A live read-only dashboard as a static site the client's CI builds and publishes (loom dashboard build), with no Loom server: the 90-day value proof (agent on-system rate from real evaluations only, the health trend from loom/history, review time with service levels kept), risks and decisions made. Not measured is said wherever a source is missing. Not yet: The GitHub Actions template (ci-examples/loom-dashboard.github-actions.yml) has not run in a client repository. The agent on-system rate shows Not measured until a real evaluation is stored. Light theme only. |
| Storybook stories generated from contracts | Runs in part | Loom generates Storybook stories from component contracts: for the reference system, 733 stories render in a real browser, 538 of 663 visibly differ from the component's default, and every one that does not says why. Not yet: Stories for a client's own system; visual regression on the stories (planned). |
| System roadmap board | Runs in part | A system roadmap board generated from accepted decisions, radar needs over the threshold, needs several teams share and component requests, each item with its evidence; written to loom/roadmap/ (ROADMAP.md, roadmap.json) and published with the dashboard; votes by handle in loom/roadmap/votes.json, with email addresses, phone numbers and links refused (loom roadmap vote). Not yet: Voting is through a pull request or the CLI: the static page has no vote button. Sample records only. |
| Team survey | Runs in part | Team survey per role with the health check's questions, encrypted in the respondent's browser to the consultant's key (ECDH P-256, HKDF, AES-GCM); no group under 5 shown on its own; design versus engineering comparison. Not yet: Run with synthetic answers only; collecting responses is manual; no Japanese text. |
| Unmet needs become drafts on their own | Runs in part | Needs over the owner's threshold become drafts when the radar agent runs (npm run agent -- radar, the weekly CI job, npm run sense): one draft pull request with an inbox item, a draft proposal and the loom/proposals record for the review queue; never merged. Dedupe rule: needs grouped by a normalised key, and a need already in loom/proposals is held back (a declined one returns after 90 days). Owner assignment from the ownership model (routeDecision, delegates when the decider is away). Not yet: Run against a mocked git host and locally only, not yet in a client's CI; the research half (pattern research for the guild) is a concept. |
| Unmet needs log | Runs in part | search_system and intake_need log needs with no strong match; list_unmet_needs groups them with request counts, distinct requesters and the owner's threshold. Not yet: The log is local per deployment, and requesters are self-reported client names or team labels (stored hashed), not verified. |
| Visual review of pull requests | Runs in part | loom review --visual: before and after screenshots of the changed components and routes (the Loom Base visual regression settings), a pixel diff, axe on both sides and the reviewer's findings in one pull request comment; the client's own model writes the critique, suggest-only; without a key the comment has the deterministic findings and the visual diff only. Not yet: Proven on a fixture repository and a mocked git host, not yet on a client's pull request; the model reads the findings and diff numbers, not the images. |
| Your code stays in your repository | Runs in part | Loom reads the repository and writes its output as local files (--out) that people review and commit or open as pull requests. Not yet: Opening pull requests automatically, with checks on each (planned, PRD SHP-12). |
Coming next
Plans. None of these runs yet.
| Capability | State | What it does today |
|---|---|---|
| Agents acting under autonomy modes | Concept | |
| Ask the system in plain language | In development | Retrieval-only early version in the product tour. |
| Figma Enterprise plan support | Planned | Not yet: Not tested on an Enterprise file. The Variables REST API and Library Analytics (usage across files) are Enterprise-only; on other plans the plugin reads variables from the open file instead. |
| Figma Organization plan support | Planned | Not yet: Publishing Loom's component-to-code mapping to Figma Code Connect needs an Organization or Enterprise library: Figma refused it on Loom's Professional test file (26 October 2026). Until then the mapping lives in the plugin data and the plugin shows the code for a selected instance. |
| Loom cloud | Planned | |
| Provider setup for agents Loom runs | In development | |
| Public documentation | Planned |
Our commitments
Promises about how we work with your data.
| Capability | State | What it does today |
|---|---|---|
| No training on your data | Commitment |