Rules and exceptions

Rules are a room’s governance determinations. They flow into its constitution and inherit downward. Every rule is labeled: as runtime-enforced if a technical check enforces it, otherwise as documentary only.

What a rule is

A rule (policy) is a governance determination with a key, rule text, owner and validity. It flows into the room’s constitution; sub-rooms inherit it automatically.

Room owners create, edit and retire the rules of their room. Retired own rules can be reactivated or, when no exception history references them, deleted permanently. Inherited rules apply too, but are managed at the parent room and are read-only here. In addition, the platform baseline applies: rules that the platform’s runtime checks enforce in every room. The rules page lists them in their own group.

“Rule” and “document” are stages of one path: an imported document or regulation is advisory knowledge at first (it supports answers). Room owners can raise an accepted part to a rule in the rule editor. The rule then acts through the constitution; only SEC-01 and DAT-03 are technically enforced.

The three rule types

Hard rule

No exceptions possible; an exception request is rejected. The system blocks technically only where a runtime check exists for the rule (SEC-01). Otherwise, the rule acts through the constitution.

Guardrail

With an exception path: a time-limited exception is possible. The system blocks technically only where a runtime check exists for the rule (DAT-03). Otherwise, the rule acts through the constitution.

Convention

Context only: informs model and users, never blocks.

How a rule is enforced

Every rule carries a label. «runtime-enforced» means that a technical check really applies: the secret scan (SEC-01) and the personal data scan (DAT-03). Everything else is «documentary only»: it acts through the constitution, meaning through the instructions given to the model, without a technical block. Independently of the rules, the model approval per data class and the budget stops can also stop a run.

The label is visible on every rule card. What is not runtime-enforced is not sold as hard.

Effect in the chat: the block card

When a runtime check blocks the run, a block card appears instead of an answer: «Blocked by …» with the rule text, the policy owner, and, if present, the detected matches.

For guardrails, the card directly offers «Request exception (time-limited)». If a scanner fails, the system blocks the run (fail-closed) and says so. An outage is never presented as a finding.

The card also links the evidence of the withheld run («Show evidence»): the same room-gated evidence view that a normal answer opens, with the rule decision and the detected category, never the withheld text. For a personal-data match, it also names the allowed continuation: rooms classified for personal data allow such an answer. So you can request an exception or ask the owner of a fitting room for access instead of ending at the block. The room owner, governance owner, or platform admin of the room where the rule lives decides on the exception; for DAT-03, this is the top-level room.

Exception workflow

1. Request: any room member can request an exception to a rule, with a reason and an optional scope. You can do this directly on the rule or from the block card.
2. Decide: the room owner, governance owner, or platform admin of the room where the rule lives decides in the Inbox. Clicking the row opens the request details with justification and scope. In the Inbox, a decision reason is required for both decisions; when approving, you also choose the expiry in days (suggested: 14). The reason is recorded on the decision and in the evidence record.
3. End: the exception lapses automatically on its expiry date or earlier through revocation. The same roles that decide can revoke it. The requester can withdraw a still-pending request themselves.

Hard rules have no exception path. A request is rejected with a clear message.

Approved, still-valid exceptions appear directly on the relevant rule (status, expiry, requester). You can request exceptions there, and authorized people can also revoke them. Every revocation is recorded with person and time, and with a reason if one was given.

An approved exception also takes effect in the answer itself: the assistant knows the active exception (rule, purpose, expiry) and no longer refuses an answer by citing the suspended rule. Instead, it briefly points out the exception in force. The run’s evidence record captures the applied exception.

Templates

Templates help you start; you can adjust them before creating. A template creates a rule that acts through the constitution. Only SEC-01 and DAT-03 are checked technically:

• No secrets in code: source code and answers without secrets, tokens, or passwords.
• No export of C2/C3 data: protected data classes are meant to stay inside the domain. There is no runtime export check.
• Tool calls need owner approval: human-in-the-loop for risky agent actions.
• External agents in monitor mode only: enforcement only after a track record.
• Production-like changes only with approval: four-eyes principle before production-like effect.

Import documents

You don’t have to retype existing official PDF documents. The import («Import» in a room’s library, or «Import documents» on a memory’s page) splits them into reviewable sections. Only what a human accepts in the review enters the memory.

After acceptance, you’ll find the documents in the “Documents & regulations” section of the memory that contains them. There you can inspect them and maintain header metadata (title, reference, version, valid-from, roles) and parts. Every change is recorded as evidence.

Imported documents are knowledge and act as advice. They don’t automatically become rules; raising them to a rule is a separate, governed step. You can sort the table of imported documents by column and search it.

To the guide: import documents

Relation-type weights

A room can decide how strongly a relation type weighs in its own answers. The weight multiplies the retrieval priority of that type’s connections before per-answer selection. Allowed values range from 0 to 2: 1.0 is neutral, 0 removes the type from selection, values below 1 weaken it, and values above 1 boost it.

The weights sit under “Rules” once you have chosen a room. The room’s governance owner sets them; every member can read them. Every change needs an occasion and is recorded as evidence (ADR-066).

Who is the governance owner

A room’s governance owner sets the relation type weights. This role is deliberately not granted automatically. The room owner assigns it in the “Governance owners” section under “Rules”, and can assign it to themselves. The authority holds only while the holder stays a member of the room: someone who leaves is shown as no longer a member and can be revoked.

Assigning and revoking are governance acts and are recorded as evidence. Every member can see who holds the governance owner; only the room owner assigns or revokes it. Until someone holds it, the weight editors stay read-only for everyone.

Type a room’s relations

Imported decisions often arrive linked but untyped: a plain relates_to says two decisions belong together without saying how. On the rules hub, the Type relations panel shows how many such untyped links the room carries and lets the room owner run the typing pass for that room.

The pass never types an edge on its own. It files proposals into the inbox, where you confirm the rule each typing follows; a typing becomes active only after you accept it. A non-owner sees the panel read-only and cannot run it.