Actors, roles and review policy
Who does what in a fleet: the roles an actor can hold, the seat a role reserves, and which models are allowed to review whose work.
For the owner deciding who — and what — may decide.
After reading it you can say which actor may touch what, why a role reserves a seat, and how a second opinion on a change is arranged.
Before you start: read Concepts for the vocabulary, or human gates if you only need the decision half.
This is the part that separates a fleet from a script that dispatches an agent and merges the result. A fleet has actors, an actor holds a role, a role decides what that actor may touch — and the work of judging work is given to a different actor than the one who did it.
| the page | what it settles |
|---|---|
| Roles | the roles an actor can hold, and what each one may and may not do |
| Seats: who runs where | what a seat is, why a role reserves one, and what happens when the wrong role is dispatched onto it |
| Review policy | which models review, when a review is owed, and how a second opinion is arranged |
Why roles rather than permissions alone. A permission class says what a session may RUN. A role says what an actor may DECIDE. Those are different questions, and a system that answers only the first can still let the author of a change approve it.
What this section does not cover
⚠ How an actor proves who they are is Identity; this section starts after that proof exists. ⚠ What a session may RUN — the tool and filesystem grants — is a permission class under Configuration, not a role.