> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nitsor.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Nitsor is a pre-release product. Every page in this documentation carries an availability status in its frontmatter (`availability`) and, as the first element of its body, a link labelled `Available now`, `Limited design-partner access`, or `Planned - not available yet`. That label is binding: it says whether a reader can use the behaviour the page describes.
> A page written in the present tense is not a claim that the behaviour ships. Where the availability label says `Planned - not available yet`, the page describes a target contract and there is no runnable product, screen, command, or public interface behind it.
> Every readiness claim this documentation makes lives on the Product status page. If any statement elsewhere disagrees with the capability status matrix on that page, the matrix is correct.
> Reading this documentation grants no product access and no permission. No agent can create or approve a Nitsor release.

# Roles and provenance

> Learn how identity, permissions, authorship, review, approval, and change history are intended to remain distinct.

<a className="nit-availability" data-availability="target-contract" href="/product-status#status-definitions" aria-label="Planned — not available yet. Read the status definitions."><span aria-hidden="true" className="nit-availability__dot" />Planned — not available yet</a>

**Status: Planned — not available yet.** This page is a target contract: a precise description of the identity and permission model Nitsor is intended to provide. No such product system is available today.

## 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.

| Permission          | Owner | Admin | Member | Billing |
| ------------------- | ----- | ----- | ------ | ------- |
| account:read        | Yes   | Yes   | Yes    | Yes     |
| account:update      | Yes   | Yes   | No     | No      |
| members:read        | Yes   | Yes   | Yes    | No      |
| members:write       | Yes   | Yes   | No     | No      |
| billing:read        | Yes   | Yes   | No     | Yes     |
| billing:write       | Yes   | No    | No     | Yes     |
| storage:read        | Yes   | Yes   | Yes    | No      |
| storage:write       | Yes   | Yes   | No     | No      |
| notifications:read  | Yes   | Yes   | Yes    | No      |
| notifications:write | Yes   | Yes   | No     | No      |
| projects:write      | Yes   | Yes   | No     | No      |

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.

One person may hold several roles, but a protected decision may require separation—for example, an approver who is not the proposal author.

**Status: Planned — not available yet.** The following matrix describes the intended authority of each working role. No product enforces it today, and it is not the workspace table above.

| Working role          | Propose | Review                              | Adjudicate | Approve release | Configure the project |
| --------------------- | ------- | ----------------------------------- | ---------- | --------------- | --------------------- |
| Annotator             | Yes     | No                                  | No         | No              | No                    |
| Reviewer              | No      | Yes                                 | No         | No              | No                    |
| Domain expert         | No      | Yes, usually within a limited scope | No         | No              | No                    |
| Adjudicator           | No      | No                                  | Yes        | No              | No                    |
| Release approver      | No      | No                                  | No         | Yes             | No                    |
| Project administrator | No      | No                                  | No         | No              | Yes                   |

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.

A workspace admin is not therefore an adjudicator, and an adjudicator needs no billing permission. A merged table would invite exactly that misreading, and it would blur an implemented capability together with a planned one.

## 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.

| Question                   | Human identity                                               | Machine identity                                                                           |
| -------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------ |
| Who is it?                 | A named person.                                              | A model, automated runner, or agent, with its own identity rather than a borrowed account. |
| What may it do?            | Whatever its roles grant in a project.                       | Only the narrow set of actions its task needs.                                             |
| How long does it last?     | As long as the person is a member.                           | Time-limited where practical, so an unused credential stops working.                       |
| What version acted?        | Not applicable; a person is not versioned.                   | The tool, model, or runner version is recorded with the work.                              |
| Who is accountable?        | The person, directly.                                        | A named responsible operator, in addition to the machine identity itself.                  |
| How is its output treated? | A proposal still needs review under the project's rule.      | A proposal that stays identifiable as machine-authored through review and merge.           |
| Can it approve?            | Yes, if the role grants it and the person is not the author. | No. A machine suggestion is never a human approval.                                        |

## 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.

Recording more fields does not automatically create trust. The system must make their meaning, integrity, and retrieval reliable.

**Status: Planned — not available yet.** The table names the intended purpose and writer of each field. No product writes these records today.

An auditor usually arrives with one question: given this value, who or what could have produced it? Each row exists to remove one way of answering “we cannot tell”.

| Field                           | Why it exists                                                                         | Who or what writes it                                                        |
| ------------------------------- | ------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Authoring identity and role     | Names the actor behind the change and the authority they held while making it.        | The system, from the authenticated principal — never typed in by the author. |
| Parent state and branch         | Says which earlier state the change was made against, so it can be reconstructed.     | The system, from the version record at the time of the change.               |
| Source references               | Ties the change to the specific source data it interprets.                            | The system, from the project's registered source references.                 |
| Taxonomy version                | Fixes what each label name meant when the change was made, not what it means now.     | The system, from the taxonomy in force for the project.                      |
| Tool, model, or runner version  | Distinguishes work produced by different versions of the same tool or model.          | The tool or runner, reported under its own machine identity.                 |
| Declared transformation         | Records resampling, cropping, or conversion that changed the data before the change.  | The process that performed it, declared rather than inferred.                |
| Timestamps and relevant checks  | Orders events and records which automated checks ran and what they found.             | The system.                                                                  |
| Review outcomes and reasons     | Preserves the assessments, including disagreement, that led to the result.            | Each reviewer, as an attributable record.                                    |
| Approving or rejecting identity | Names who accepted responsibility for the final decision, separately from the author. | The system, from the authenticated approver.                                 |

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](/concepts/review-consensus-adjudication) to define how their outcomes combine.

<table className="nit-page-details" aria-label="Page details">
  <tbody>
    <tr><th scope="row">Outcome</th><td>Define the minimum role and provenance evidence your workflow would require.</td></tr>
    <tr><th scope="row">Availability</th><td>Planned — not available yet</td></tr>
    <tr><th scope="row">Audience</th><td>Program and operations teams, Reviewers and domain experts, Security and software teams</td></tr>
    <tr><th scope="row">Prerequisites</th><td>Know who proposes, reviews, and approves changes today</td></tr>
    <tr><th scope="row">Last verified</th><td>2026-07-30</td></tr>
  </tbody>
</table>