> ## Documentation Index > Fetch the complete documentation index at: https://docs.ainomos.ch/llms.txt > Use this file to discover all available pages before exploring further. # Roles and permissions > Organisation roles, room responsibilities, and who can do what in Ainomos. Ainomos gives rights in two separate ways. **Organisation roles** apply across the whole organisation: running the settings, handling maintenance, or reading one kind of decision everywhere. **Room responsibilities** say who decides inside one room: its owners, deciders and curators. Being a member of a room lets you work in it. Only a responsibility lets you decide there. ## Organisation roles Decisions come in three types: architecture decisions (ADR), business decisions (BDR) and security decisions (SDR). Some roles read one type everywhere. | Role | What it allows | | - | - | | **Member** | Everyone. Asks questions in their rooms, reads answers and their evidence, proposes decisions and knowledge, and requests a time-limited exception. | | **Platform admin** | Changes the organisation's settings, manages people, roles, visibility and the identity provider, adds anyone to any room, and creates rooms anywhere. Being admin gives no right inside a room: an admin reads a room's content only as a member, and decides only with a responsibility of their own. | | **Maintainer** | Switches maintenance on and off, and keeps access while the organisation is closed for maintenance. See [system status](https://docs.ainomos.ch/admin/system-status.md). | | **Architecture reader** | Reads ADRs in every room, member or not. Never writes. | | **Security reader** | Reads SDRs in every room. Never writes. | | **Business reader** | Reads BDRs in every room. Never writes. | | **Auditor** | Reads every decision type in every room, read-only. Meant for a dedicated account. | Readers and auditors find these decisions under **Cross-room decisions** in the knowledge library. A reader role only widens reading. Deciding still needs a responsibility in the room. ### Grant or revoke an organisation role Who can do this: platform admins. Open **Settings**, then **Roles & permissions**. Under **Who holds what**, each role lists the people who hold it. To grant a role, find a person in that row and choose **Add**. To revoke it, choose the cross on the person's name. Ainomos asks you to confirm, applies the change at once and records it as evidence. * The **Room owner** row is for reading only. Owners are **Granted inside the room**. * Maintainers are granted on the person's sheet under [Users](https://docs.ainomos.ch/admin/users.md), where every other role can be granted too. * The last active platform admin cannot be revoked. * The auditor role cannot go to an account that already holds a role in your organisation's top room. Invitations add people to the top room by default, so give the auditor a separate account. * A role that comes from your identity provider is controlled there. ## Room responsibilities | Responsibility | What it means | | - | - | | **Owner** | Responsible for everything in the room until they delegate a task. Whoever creates a room, or requested it, becomes its owner. A room can have several owners and always keeps at least one. | | **Decider** | Accepts or rejects drafts of one decision type in the room. A type can have several deciders. | | **Curator** | Looks after the room's memories: their visibility, dreaming, the review of imported documents, and the links between records. A curator acts for the whole room or for one memory. | Each delegation is a part of the owner's own rights, so the owner can always do what a decider or curator does. When nobody holds a delegation, the task falls back: drafts go to the owner, and a memory without its own curator is looked after by the room's curators, or by the owner when there are none. The room then shows **Responsible: owner**. That is normal, not an error. Apps never hold a responsibility. ### Who can do what in a room | Action | Owner | Decider | Curator | Member | Platform admin | | - | - | - | - | - | - | | Ask, read answers, open evidence | Yes | Yes | Yes | Yes | As a member | | Propose drafts, knowledge and links | Yes | Yes | Yes | Yes | As a member | | Accept or reject a draft | Yes | Their type | No | No | No | | Accept that one decision replaces another | Yes | Type of the replaced one | No | No | No | | Accept other links between records | Yes | No | Yes | No | No | | Import documents, run dreaming, look after memories | Yes | No | Yes | No | No | | Approve an exception to a rule | Yes | No | No | No | No | | Grant responsibilities, change room settings | Yes | No | No | No | Owner only, see below | | Add and remove members | Yes | No | No | No | Yes | | Create a sub-room | Yes | Request | Request | Request | Yes | ### What is inherited Responsibilities are not inherited down the tree. When a room is created, the parent's deciders are copied into it once, and after that each room keeps its own. Owning a department gives no rights in its teams. Rules do pass down; see [rooms](https://docs.ainomos.ch/admin/rooms.md). ### Grant a responsibility Who can do this: owners of the room. **1. Open the room's responsibilities** Open the room, choose **Room details** and go to **Responsibilities**. **2. Choose what to grant** Under **Grant a responsibility**, pick the **Responsibility**: **Owner**, **Decider** for ADR, BDR or SDR, **Curator for the whole room**, or **Curator for memory** for one memory. **3. Choose who** Under **Grant to**, choose **Person** and pick them. The person must already be a member of the room; add them under **Members** first. **4. Grant it** Choose **Add**. To take a responsibility back, choose **Remove** next to the holder. The last owner cannot be removed. Add another owner first. Removing someone from the room also ends their responsibilities there. A platform admin who does not own the room may grant or remove the **Owner** only, and must answer **Why are you changing the owner?**. Ainomos keeps the reason in the evidence. Use this to hand over a room whose only owner has left. ### Groups from your identity provider A responsibility can also go to a group in your identity provider. In the same form, choose **Group** under **Grant to**, then the **Identity provider** and the **Group**. The section shows how many members have signed in so far. * Rights apply at each group member's next sign-in, and they join the room as members. * Removing the group, or changing what it maps to, ends the rights it granted at once. * A person also granted by hand keeps their rights. * A group that holds a room's last owner cannot be removed. Who can do this: a platform admin who is also an owner of the room. Groups need an identity provider connected directly to Ainomos. Organisation roles can come from groups too, set up under [identity and single sign-on](https://docs.ainomos.ch/admin/identity-and-sso.md). ## Check what someone can do Open **Settings**, then **Users**, open the person and choose **Show rights**. The preview lists, for each of their rooms, what they may do and where each right comes from, for example **from an owner responsibility**. It also shows their organisation roles and their direct views under [user visibility](https://docs.ainomos.ch/privacy/visibility.md). Ainomos works this out with the same checks that protect the real actions. ## The platform operator The people who run your installation are not accounts of your organisation, so there is no role to grant them. An operator who enters your organisation to help has full administrator rights there. A strip at the top of their screen names your organisation, and each of their actions goes into a separate operator log. ## Related * [Users](https://docs.ainomos.ch/admin/users.md) * [Rooms](https://docs.ainomos.ch/admin/rooms.md) * [User visibility](https://docs.ainomos.ch/privacy/visibility.md) * [Exceptions](https://docs.ainomos.ch/knowledge/exceptions.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.