Human Roles

A Definition of Ready or Done item hands its human side to a role, and only a member of that role can approve it. The server enforces it, so it holds for anything calling the API directly too.

Why a role and not a job title

A checklist item used to name its reviewer in prose. “Product Owner” was printed on the item and checked by nothing — anyone who could write to the gate could approve it, and the audit trail recorded a name that meant nothing about authority. A role is real: it has members, and an approval from a non-member is refused.

Two rules worth knowing before you start

A role with no members approves nothing. It does not quietly fall back to “anyone” — that is exactly the gap roles exist to close. The page flags any role that items name and nobody holds, and the gate says so rather than failing vaguely.

Roles are archived, never deleted. A Work Package takes a copy of the checklist item that names a role, so deleting one would strand approvals already recorded. Archiving stops a role being offered for new items; everything that already names it keeps working.

Both rules explain a detail you will notice: a new role starts with you in it, and importing older reviewer names does the same. Creating an empty role would otherwise turn a working checklist into a blocked one the moment it was used.

Any human in the loop

The built-in reviewer, and the default. An item that names it is approved by any member who can write to the gate — the same behaviour every item had before roles existed. Use a named role where it matters, and leave the rest here; a role for every item is bureaucracy, not governance.

Setting them up

Open Studio → Hybrid Team → Human Roles. Only the studio owner can change them: membership of a role decides who may approve work, so it is not an ordinary admin setting. Every change is written to the audit log field by field, because a role gaining a member is a grant of authority.

If your checklists were written before this page existed, it offers to import the reviewer names it finds on them — each becomes a role with you as its only member, ready for you to add the people who really hold it.

What happens at the gate

Assessing an item you do not have the role for is refused, and the refusal names the role so you know who to ask. Three cases are distinguished, because the fix differs: you are not a member; the role is staffed by nobody; the role no longer exists at all. The last two are an owner’s to fix on the Human Roles page.

Two things stay open to everyone who can assess. Recording an item as not met is a finding, not an approval — anyone who can see a problem should be able to say so. And Does not apply (a waiver) keeps its existing owner-or-reviewer authority, with a written reason, because it is the way past an item whose role cannot answer.

Organisation roles

If your studio belongs to an Enterprise organisation with guardrail policies, the organisation’s items name its reviewer roles, not yours. The Human Roles page lists them, and the studio owner chooses which of the studio’s own roles answers for each — or Any human in the loop.

An organisation role you have not mapped is held by nobody. Its items cannot be approved in your studio until you map it. As with your own roles, it does not fall back to “anyone”.

The organisation may require a named role. For such a role, Any human in the loop is unavailable, and a mapping to it made earlier stops counting at once. Choose one of your named roles. Owners and reviewers can still waive an item in the meantime, where the policy allows exceptions.

After your studio leaves an organisation — the roles its existing work packages still name stay listed. You can point one at another of your named roles; nothing else about them changes.

If the page says that new work packages are on hold, your studio’s owner is no longer a member of the organisation. New work packages the policy covers are refused until the organisation adds the owner back or releases the studio; existing ones are unaffected.

Renaming is safe; archiving is safer than deleting. Items reference a role by its id, not its name, so renaming “Product Owner” to “Product Lead” updates everywhere at once and rewrites nothing. An archived role still approves the items that already name it, so archiving cannot strand a package mid-flight.

All AI Product Studio documentation

Build v0.3.2 · deployed 2026-10-19T23:52:31Z