Cross-cutting roles and auditor
Four cross-room roles that a platform admin grants or that are assigned through SSO mappings. Architecture, security, and business each read one decision type across all rooms; the auditor reads every type. The roles only read. Deciding stays with the role held in the respective room.
What the cross-cutting roles are
Section titled “What the cross-cutting roles are”The three functional roles are each bound to a single decision type and read it in every room on the platform, including rooms outside their own. The auditor reads all four decision types across all rooms.
Architecture
Reads architecture decisions (ADR) in every room.
Security
Reads security decisions (SDR) in every room.
Business
Reads business decisions (BDR) in every room.
Auditor
Reads every decision type (ADR, BDR, SDR, DREAM) in every room.
Read only, never write
Section titled “Read only, never write”A cross-cutting role opens read access across room boundaries only. It never allows creating, editing, or accepting or rejecting decisions. That stays with the role held in the respective room.
Holding a cross-cutting role together with a room role still only lets you decide in the rooms where the room role allows it. The cross-cutting role only extends reading, never deciding.
Granting and revoking
Section titled “Granting and revoking”Only platform admins grant or revoke cross-cutting roles by hand, under Settings → Users, column “Cross-cutting roles”. Clicking a role chip asks for confirmation and grants or revokes the role immediately. You can’t revoke roles assigned through SSO here; the identity provider controls them.
A user can hold several functional roles at once, for example architecture and security together. The auditor role isn’t an addition to these three. It is its own, broader case (see “The auditor: a special case”).
The auditor: a special case
Section titled “The auditor: a special case”Because the auditor can read everything, the role is meant for separate accounts without a room assignment in the platform room. If an account already holds a room role in the platform room, NomOS refuses the grant with a clear message.
This guardrail is intentional. It prevents the same account from being both operationally active in the platform room and unrestricted in what it can audit.
Evidence
Section titled “Evidence”Every grant and revocation of a cross-cutting role is recorded as evidence, with person, role, and time. This follows the same pattern as granting platform-admin rights.
Directory: “Last seen” and origin
Section titled “Directory: “Last seen” and origin”The user list also shows when an account was last active in NomOS (“Last seen”). If no timestamp is known, a dash appears instead of a date.
The “via SSO” badge shows that the account has signed in to NomOS at least once. Invited accounts also carry it after their first sign-in.
Where the roles take effect
Section titled “Where the roles take effect”Anyone holding a cross-cutting role or the auditor role sees the “Cross-room decisions” entry in the knowledge library, cross-room and read-only. The entry appears as soon as there is at least one readable decision. More on that: Help: decisions and verdicts
Rights preview: what a person can actually do
Section titled “Rights preview: what a person can actually do”Under Settings → Users, Show rights in each row expands a preview: per room the role, a badge for named responsibility (named owner, named decision maker), and the list of capabilities: decide decisions, decide exceptions, import documents, manage members, edit agent instructions, switch the agent door. Plus the cross-room reading rights and the enabled direct views.
Every right names its source: platform role, room role, named decision maker, or named responsibility. The server computes the preview with the same checks that protect the real actions. A person who is only named as owner therefore sees that exceptions and the agent door stay bound to the owner role.