Skip to main content
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.

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 and Users.

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.

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.

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.

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 and Audit log.

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.

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 and Organisation apps.

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.