Identity, role, and permission
An identity answers “who or what is acting?” A role groups responsibilities such as annotator, reviewer, final decision-maker, or release approver. A permission answers whether that identity may perform a specific action in a specific project or area. These concepts should remain separate. A job title should not silently grant project-wide access, and a branch name should not grant permission.Workspace roles implemented today
This table describes something narrower than the rest of the page: the permissions the account system implements today for administering a workspace — reading and updating account settings, managing members, handling billing, connecting storage, and configuring notifications. It is not a claim that the annotation-work authority model described further down exists. A member’s workspace role is one of owner, admin, member, or billing. “Yes” means the role holds that permission; “No” means it does not.
Two details are worth reading carefully. An admin holds every permission except the ability to change billing, which stays with the owner and the billing role. A plain member can read but not change: they see account details, the member list, connected storage, and notification settings, and modify none of them.
These roles govern workspace administration. They do not decide who may propose a label, review it, resolve a disagreement, or approve a release — that is a separate vocabulary, described next.
Intended human roles
- Annotator: creates or corrects a specific piece of label work.
- Reviewer: assesses a proposal against instructions and evidence.
- Domain expert: provides specialist judgment, often in a limited scope.
- Final decision-maker (adjudicator): resolves contested outcomes and records the reason.
- Release approver: accepts a complete release candidate under an explicit policy.
- Project administrator: manages membership and project configuration without automatically becoming the author or approver of content.
Read the “No” cells as “not by virtue of this role”. One person may hold several roles and then holds the union of their authority — with one intended exception: the author of a proposal is never its sole approver. Holding both the annotator and the release-approver role does not let someone approve their own work; a second, independent approver is required.
Why the two tables stay separate
Merging the workspace table into this one would produce a single grid that looks authoritative and is wrong. The two use different vocabularies for different questions:- The workspace table answers “who may administer this account?” — it is implemented, and its roles are owner, admin, member, and billing.
- This matrix answers “who may decide the fate of a labelled change?” — it is planned, and its roles are annotator, reviewer, domain expert, adjudicator, release approver, and project administrator.
Intended machine roles
A model, automated runner, or agent should act under its own identity rather than borrow a person’s account. Its permissions should be limited to the work it needs, expire when practical, and remain connected to a version and responsible operator. Machine-authored work should remain identifiable through review and merge. A machine suggestion is not a human approval. This is intended behavior, not an available agent integration. Status: Planned — not available yet. The comparison below states the intended differences between the two kinds of actor. No machine-identity system is available today.Provenance
Provenance means the evidence showing where a change came from and what happened to it. The useful minimum depends on the workflow, but may include:- authoring identity and role;
- parent state and branch;
- source references and taxonomy version;
- tool, model, or runner version;
- declared transformation;
- timestamps and relevant checks;
- review outcomes and decision reasons;
- the identity that approved or rejected the change.
The pattern is that almost nothing is self-reported. Where a field is declared by a tool rather than observed by the system — the transformation row, for instance — that is itself worth knowing, because it is the field a misconfigured pipeline can get wrong without anyone noticing.
Denials and failed actions
The product direction is to retain meaningful authorization outcomes, including denials, so a later investigator can understand attempted actions and policy boundaries. Retention volume, privacy, and operational access need design and implementation evidence.Common mistakes and limits
- Authentication is not authorization.
- Membership is not authorship.
- An administrator is not automatically an approver.
- A service account shared by several tools makes it harder to tell which tool acted.
- An audit log is not useful if events cannot be connected to the content decision.
- This page does not promise a particular identity provider, role schema, or compliance control.
Next step
List the human and machine identities involved in one real workflow, then read Review, consensus, and adjudication to define how their outcomes combine.| Outcome | Define the minimum role and provenance evidence your workflow would require. |
|---|---|
| Availability | Planned — not available yet |
| Audience | Program and operations teams, Reviewers and domain experts, Security and software teams |
| Prerequisites | Know who proposes, reviews, and approves changes today |
| Last verified | 2026-07-30 |