The same change, seen by each role
Take one governed change from ask to release. The designer proposes it, the developer receives the migration, the system owner accepts it, the product manager reads the release note, the CTO sees the trend and the CEO reads one page. Pick a role to see the step that role takes. Under each step is what that role's home shows this week: real items and measures from Loom's role homes, computed from the records of a sample system when this site was built.
1 Designer: proposes
You ask once. Before anyone builds, intake searches the system and answers reuse, extend or new, with the evidence. Your ask then waits in one queue with an owner and a due date.
From the designer's home this week:
- Intake searched the system for "Destructive confirmation dialog"extend: The danger-zone pattern partly covers it.
- Destructive confirmation dialogWith Harbor UI engineer for triage, due 2026-10-21
- Date range pickerWith Harbor UI engineer for review, due 2026-10-28
What Loom measures: Review time: 2 working days.
2 Developer: gets the codemod
The change reaches you with its replacement and a date. Loom writes the codemod for the mechanical part and opens the migration as a draft pull request you review, with the manual steps as a checklist. Built and tested on sample consumers and simulated git hosts so far.
From the developer's home this week:
- Move off --primitive-teal-700Use --semantic-action; removed after 2027-01-31 in 2.0.0. The audit lists every use; npm run migrate writes the codemod and opens a draft migration pull request
- Drafted Migration notice: --primitive-teal-700 is deprecatedFor Harbor DS lead to approve before it is sent to Settings product team, Billing product team, Guild
What Loom measures: Drift caught before merge: not measured. Agent output on-system: not measured.
3 System owner: accepts
One named person decides against a checklist, with the evidence Loom could gather already attached. The decision, its reason and who made it are written into the record.
From the system owner's home this week:
- Destructive confirmation dialogD9 pattern, standard: triage by Harbor UI engineer (routed from Harbor DS lead: service level about to be missed)
- Promote SearchInput to a shared SearchFieldD6 component, standard: review by Harbor DS lead (covering for Settings product lead, who is away)
- Brand red for destructive actions in every modeD3 token, standard: triage by Harbor UI engineer (routed from Harbor DS lead: service level about to be missed)
What Loom measures: Review time: 2 working days. Service level kept: 67%.
4 Product manager: reads the release note
Loom drafts the release note from the records in plain words. The owner approves it before it goes out, and your requests carry their service level in the same place.
From the product manager's home this week:
- Harbor core: release notes
- Covers 2026-09-26 to 2026-10-26; current version 1.4.0. No contract diff was given, so breaking changes come from proposals only.
- Breaking changes
What Loom measures: Requests answered on time: 100%.
5 CTO: sees the trend
You see whether the system is getting stronger: how much of what agents write passes your rules, the health score over time, and what is planned to break, with its migration.
From the cto's home this week:
- Breaking removal planned: --primitive-teal-700In 2.0.0, after 2027-01-31; a codemod or migration pull request ships first
What Loom measures: Agent output on-system: not measured. Health score: 48 out of 100 (from 50).
6 CEO: reads one page
A read-only dashboard your own CI publishes, and once a month one page: the health trend, the three 90-day measures and the decisions leadership needs to take, from measured data only.
From the ceo's home this week:
- Harbor UI: leadership report, October 2026
- For Harbor VP Product, from Harbor DS lead. Drafted by Loom from the records on 2026-10-26; "not measured" wherever there is no source. Harbor DS lead edits and approves it before it is sent.
- Stage: Many products
What Loom measures: The three 90-day measures: agent output on-system not measured; health score 48 out of 100 (from 50); review time 2 working days.
Data: sample records of Harbor UI, a synthetic system, computed by Loom's role homes when this site was built (2026-10-26).
Who does what is written down, and checked
Loom names the roles a real organisation has: the system owner, area owners, the accessibility, content, localisation and brand owners, the Ops lead and the guild, product designers, front-end developers and product managers, the engineering lead, the executive sponsor, and the AI agent as a role of its own with narrower permissions. For each of the nineteen kinds of decision, Loom records who may propose, review, accept, grant an exception, release, deprecate or change a rule, and who is responsible, accountable, consulted and informed.
Three rules hold everywhere. Nobody approves their own ask. Only the accessibility owner rules on accessibility. When a change touches two areas, the stricter autonomy mode applies.
Roles are not only declared. Loom checks them against your git host: the teams a person belongs to and the CODEOWNERS entries that name them. An action from someone whose verified identity lacks the role is refused, with the reason. At kickoff, the executive sponsor and the system owner sign the roles and the RACI off, and that sign-off is recorded as a governance decision.
Read who does what in the governance model
Pages for each role
The deepest pages are for the four roles who decide whether a design system is worth running: the design-system owner, the CTO or engineering manager, the product manager, and the CEO and stakeholders. Each page describes a real week with Loom, step by step, with a link to the feature that does each step.
Coming next
We will connect the role homes to a live identity check on every request, so the control area itself refuses an action the moment a person's team membership changes. Today the check runs where Loom records a decision, against a snapshot of the host.