Roles, Permissions, and States Reference
What each role can do, how permissions are scoped, what each recorded state means, and which access paths work together.
Roles, permissions, and states answer different access questions. Use the comparison below, then verify the specific decision and state for the object you are handling.
Your existing agent keeps the goal, context, model, edits, native builds and tests, and final decisions. The Compute Kit prepares permitted work and the approved MCP or API connection. Participating people's Macs perform supported work only when the relevant role, permission, scope, and compatible access path allow it.
Compare the terms
| Term | What it tells you | What it does not prove |
|---|---|---|
| Role | The responsibility or kind of work an actor may handle. Owner, Admin, Manager, Finance, Member, Billing, and Viewer are examples. | That the actor may open a source or change a setting. |
| Permission | Whether an actor may use a capability for a source, purpose, and condition now. Scope can include an organization, team, device, resource, or time limit. | That a role label, plan card, or earlier approval covers a different scope. |
| State | The recorded condition of an object or decision now, such as waiting, ready, or no longer active. | Why the state is true, that every resource is in scope, or that the state proves execution. |
Follow an access decision
Example: check one access decision
Suppose a person needs to use one resource on one Mac. Start with the requester, capability, source, purpose, and conditions. Check the current permission, its scope and review date, then read the resource's exact state and timestamp. The role gives context; the permission sets the boundary; the state shows what the record says now.
The current Team area shows local plan or capability information available on this Mac. It does not provide a complete people roster or prove that a descriptive role is assigned elsewhere. A label in an example or old record is not evidence of a current assignment.
There is no universal Lithi state enum. Preserve the exact state contract's spelling and case. If scope is missing, expired, narrowed, paused, denied, or revoked, stop; an absent affirmative decision is not permission. A changed label alone does not explain a transition. A role or permission does not make every agent compatible, and a compatible MCP or API connection still needs approved access.
Verify before relying on the result
- Identify the object, actor, source, purpose, and environment.
- Read the current state and timestamp.
- Find the permission supporting the specific capability.
- Check scope, reviewer, transition reason, and revocation path.
- Stop when the answer depends on information this Mac does not receive.
Use the smallest record that supports the conclusion. Keep private messages, credentials, tokens, and unrelated records out of screenshots and support notes. When purpose changes or work ends, narrow or revoke the applicable grant and recheck the resulting state.