1. Docs
2. Reference

Roles and Capabilities

The two-level access model — system roles and the platform admin flag, plus board seats — and exactly which capability each grants.

#Two Levels

1. System role — at most one per user: author, auditor or service, or none.
2. Platform admin — a separate flag for operating the instance.
3. Board seats — chair, decision maker, reviewer, secretary or observer, per board.

Governance rights — approving, deciding — come only from board seats. The platform admin flag is operational and grants no right in any review, session, position or declaration: a platform admin with no seat and no role sees everything and changes nothing. That is segregation of duties by construction.

#Capabilities by System Role and Flag

Classifying an application — setting it by hand, resetting it to derived, verifying it, or asking for an AI suggestion — needs verify. A classification is content, so the platform admin, an auditor and a decision maker who holds only a seat (no system role) are refused. See Criticality and Business Services.

#Capabilities by Seat

A seat's capabilities apply to reviews routed to its board; the route gate admits a seat held on any board and the handler then checks the specific board. Any seat also grants export_evidence.

¹ In areas mode the chair has no vote; the capability matters only for count-mode policies that list the chair. ² A documented simplification: these four are held by the chair of any board, not scoped to one board.

#Rules That Are Not Capabilities

• The author never acts on their own item — no position, no declaration, no resolution — whatever seats they hold. A chair who authored an item nominates an acting chair for it.
• Decision makers record their own positions. Nobody records on their behalf; a delegate records as themselves for the seat.
• Delegation is per session, one hop, and never to an auditor, a service account, or the author of an agenda item.
• Only the assignee records a requested assessment's result; only its author updates a provided one.
• Withdrawal is the submitter's own act.

#The Route Gate

Every /api request passes one gate. Rules are matched top-down by method and path; holding any listed capability passes, and the handler then performs the exact check (which board, which area, whose item). Two defaults keep it safe:

• Any GET needs only read.
• Any mutation not explicitly listed requires manage_platform, so a new route is closed until someone opens it deliberately.

/api/health, /api/auth/* and /api/hooks/* are exempt: the hooks authenticate with their own secret. A refusal is 403 with the capability and, from board checks, a reason.

#Legacy Names

Older role names are accepted from Entra app roles, stored settings and request bodies:

Something unclear or out of date? Write to hello@archigov.com or open an issue on GitHub.