> ## 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. # Rules > Set what must always or never happen in a room, choose how strictly each rule acts, and keep rules current. A rule states what must always or never happen in a room, for example "Customer data never leaves the EU". Each rule has a strength that decides whether it blocks and whether anyone can get an exception. Rules apply to people in the chat and to agents that connect to Ainomos alike. You find a room's rules in **Knowledge**, then **Rules**. Every member of the room can read them. ## The three strengths | Strength | What it means | Exception possible | | - | - | - | | **Hard** | Blocks, and no exception is possible. | No. A request is refused. | | **Guardrail** | Blocks, but an exception can be requested. | Yes, time-limited and approved by a room owner. See [Exceptions](https://docs.ainomos.ch/knowledge/exceptions.md). | | **Convention** | Guidance only, never blocks. | Not needed. | Before the model answers, Ainomos looks up the rules that bear on the question and gives them to the model, and the answer follows them. Two platform rules also run an automatic check before every answer, in every room: | Rule | Strength | What the check does | | - | - | - | | SEC-01 No secrets in prompts or knowledge objects | Hard | Stops a question that contains passwords, API keys, tokens or private keys. | | DAT-03 No personal data in rooms with low protection needs | Guardrail | Withholds an answer with personal data in a room of data class C0 or C1. From C2 on, personal data is allowed. See [Personal data](https://docs.ainomos.ch/privacy/personal-data.md). | Each rule says which way it acts. A rule with an automatic check reads "Checked automatically before every answer." Every other rule reads "Ainomos follows it in its answers; no automatic check runs." Ainomos never presents a rule as enforced when no check runs. ## Where a rule applies A rule applies in its own room and in every room below it. The **Rules** page lists every rule that applies in the room you have open, with **Strength**, **Name**, **State**, **Owner**, **From** and **Updated**. The **From** column says where each rule comes from: * this room: the room's own rules, managed here by its owners, * a room above: inherited rules, which apply here but are managed in the room they come from, * **Platform**: SEC-01 or DAT-03, when no room above lists them. They are enforced in every room. Ainomos places SEC-01 and DAT-03 in your organisation's top room when it is set up. Its owners manage them there, and every other room shows them as coming from that room. Use **From** in the filter bar to show only **This room**, **Rooms above** or **The platform**. Select a row to open the rule in full: its text, how it acts, its active exceptions, and **Details** with key, version and validity. ## Create a rule Who can do this: room owners. **1. Open the editor** On the **Rules** page, select **Create**. You can also choose **Write a rule** from **Create** on the **Knowledge** overview. **2. Start from a template, or from scratch** Under **Start with a template** you find ready rules: **No secrets in code**, **No export of C2/C3 data**, **Tool call requires owner approval**, **External agents in Monitor mode only** and **Near-production changes only with approval**. A template fills the form. You can change every field. **3. Fill in the fields and save** Select **Create**. The rule applies at once, here and in the rooms below. | Field | What to enter | | - | - | | **Key** | Three capital letters, a hyphen and two digits, for example ABC-01. It cannot change later. | | **Title** | A short name for what the rule asks, for example "No secrets in code". | | **Strength** | **Hard**, **Guardrail** or **Convention**, as in the table above. | | **Rule text** | What the rule requires, at least 20 characters. | | **Rationale** | Optional. Why the rule exists. | | **Owner** | The email of the person responsible. It shows on the rule and on block cards. | | **Exceptions allowed** | Fixed by the strength: off for hard rules, on for guardrails. Your choice for conventions. | | **Valid from** and **Valid until** | The period the rule is meant to cover. Leave **Valid until** empty for no end date. | | **Citations** | Optional. Where the rule comes from, one source per line. | > [!NOTE] > > **Valid until** is shown on the rule, but the rule keeps applying after that date. To end a rule, retire it. The folded **Enforcement** section describes how the rule is meant to be enforced: **Layer**, **Check** and **Action**. The strength fixes some of these values. Choosing a check for a rule you write does not start an automatic check. Only SEC-01 and DAT-03 run one. ## Approve rules found in documents When you import a document, Ainomos can find rules in it. These rules do not apply until a room owner approves them. They wait at the top of the **Rules** page under **Pending approval**, and in the owner's [Inbox](https://docs.ainomos.ch/chat/inbox.md) as **Rule to approve**. Who can do this: room owners. Other members see the card with "Waiting for the room owner." **1. Read the card** Each card shows the rule's title, the strength Ainomos suggests, the rule text and the document section it came from. **2. Choose the strength** Pick **Hard**, **Guardrail** or **Convention** under **Strength**. **3. Decide** Select **Approve** to put the rule in force, or **Reject** with an optional reason. A rejected rule never applies. ## See which rules an answer followed Under an answer in the chat, select **Show sources**. The evidence lists the rules Ainomos checked under **Policy decisions**, each with its key, title and outcome. When an automatic check stops a run, a block card appears instead of the answer. It reads **Blocked by** and the rule, shows the rule text and the **Policy owner**, and offers **View rule** and **Show evidence**. For a guardrail it also offers **Request exception (time-limited)**. When an approved exception covers the question, the answer says that the exception is in force instead of refusing. See [Reading answers](https://docs.ainomos.ch/chat/reading-answers.md). ## Change, retire or delete a rule Who can do this: room owners, for the room's own rules. Inherited and platform rules are changed in the room or place they come from. Open the rule's row and choose: * **Edit**: change the rule. Saving creates a new version. The previous version stays traceable in the history. * **Retire**: the rule stops applying, here and below. It stays visible as **Retired** with its history. * **Reactivate**: a retired rule applies again, here and in the rooms below. * **Delete permanently**: removes a retired rule for good. This works only for rules that never had an exception. The evidence stays. > [!WARNING] > > Retiring SEC-01 or DAT-03 switches its automatic check off in every room. Reactivating switches it back on. Every change to a rule writes an evidence record, the audit entry Ainomos keeps for every action. ## Related * [Exceptions](https://docs.ainomos.ch/knowledge/exceptions.md) * [Decisions](https://docs.ainomos.ch/knowledge/decisions.md) * [Import documents](https://docs.ainomos.ch/import/documents.md) * [Data classes](https://docs.ainomos.ch/privacy/data-classes.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.