> ## 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.

# Key concepts

> The ideas Ainomos is built on, in plain words, with a link to the page that explains each one.

Ainomos uses a small set of ideas everywhere: rooms, the people responsible for them, the class of their data, their knowledge, and the records every answer leaves. Read this page once and the rest of the documentation will make sense. Each section links to the page with the details.

## Rooms and the room tree

A room is where a team's knowledge lives and where its questions are asked. Rooms form a tree: your organisation at the top, then departments, teams and projects below. Each room has owners, members and a data class, and only its members see its content. Rules set in a room also apply in every room below it. Membership does not pass down: people join each room on their own. See [Rooms](https://docs.ainomos.ch/admin/rooms.md).

## Members and responsibilities

Members work in a room: they ask questions, use its knowledge and see its evidence. Authority in a room comes from a responsibility. The **Owner** is responsible for everything in the room until they hand a task on, and whoever creates a room becomes its owner. A **Decider** accepts or rejects decision drafts of one decision type, and a **Curator** looks after the room's knowledge. A **Platform admin** manages the organisation's settings and people, and some cross-room roles, such as **Auditor**, only read. See [Roles and responsibilities](https://docs.ainomos.ch/admin/roles.md) and [Users](https://docs.ainomos.ch/admin/users.md).

## Data classes

Every room has a data class that says how sensitive its content is: **C0** experimental, **C1** internal, **C2** confidential, **C3** strictly confidential. Every model is allowed certain classes, and a room's content only goes to models allowed for its class. C0 is for trials without protected data. C3 content does not go to a model processed outside your control unless an administrator records an override with a reason. See [Data classes](https://docs.ainomos.ch/privacy/data-classes.md).

## Knowledge

A room's knowledge has four kinds. **Documents** are your files, which Ainomos reads and splits into passages that answers can quote. **Decisions** are governed records with an owner, deciders, a status and a validity date, and answers cite the binding ones. **Rules** shape every answer: a hard rule blocks, a guardrail blocks but allows a time-limited exception, a convention guides. **Exceptions** are those time-limited permissions, approved by the person responsible. See [Knowledge overview](https://docs.ainomos.ch/knowledge/overview.md).

## The inbox and approvals

Nothing important changes in Ainomos without a person deciding. Decision drafts, imported knowledge to review, exception requests and dreaming proposals wait in the **Inbox**. You see the items you may decide and the requests you made yourself, and each decision is recorded. See [Inbox](https://docs.ainomos.ch/chat/inbox.md).

## Evidence

Every answer, and every governed action an app takes through Ainomos, writes an evidence record: the sources it cited, the rules it applied, the result of the checks, the model and the cost. Records are chained, so a later change to one of them shows. You open an answer's evidence from the answer itself, and administrators review all of it in the audit log. See [Reading answers](https://docs.ainomos.ch/chat/reading-answers.md) and [Audit log](https://docs.ainomos.ch/privacy/audit-log.md).

## Dreaming

Dreaming is knowledge upkeep that runs in the background, usually overnight. It finds links nobody entered, contradictions and outdated entries, and turns them into proposals. It decides nothing: every proposal goes to a person. See [Dreaming](https://docs.ainomos.ch/knowledge/dreaming.md).

## Connections: apps and agents

Apps and AI agents connect to Ainomos through MCP, the open standard AI apps use to connect to Ainomos. A personal app, such as a coding tool, signs in as you and reaches the rooms you can open. An organisation app has its own identity and works in the rooms it was given. Both get the same knowledge and rules as the chat, and leave the same evidence. See [Connect apps](https://docs.ainomos.ch/apps/connect-apps.md) and [Organisation apps](https://docs.ainomos.ch/apps/organisation-apps.md).

## Models

A chat model writes the answers. An embedding model turns text into a form Ainomos can search, and an organisation uses exactly one of them. On Ainomos cloud, a new organisation starts on the platform's models with a one-time starter credit, and can connect its own models and keys at any time. Your rooms, rules and records stay the same when models change. See [Models](https://docs.ainomos.ch/models/overview.md).

## Related

* [Quickstart](https://docs.ainomos.ch/get-started/quickstart.md)
* [Finding your way](https://docs.ainomos.ch/get-started/finding-your-way.md)
* [Glossary](https://docs.ainomos.ch/reference/glossary.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.