Decisions and verdicts

Every answer carries a verdict: checked and backed, advisory basis, without a reliable basis, blocked, or inferred. Behind it are decisions (decision records): governed knowledge with a lifecycle, decision makers, and evidence.

What a decision is

A decision (decision record) captures a determination of the room, as ADR (architecture), BDR (business), SDR (steering), PURPOSE (room purpose), or RELATION (taxonomy). The system creates DREAM records itself; you can’t accept them by hand. Only accepted decisions flow into the answers as applicable determinations. Drafts and rejected decisions don’t apply.

Drafts are created in two places: in the chat («Adopt as ADR draft» turns an answer into a draft including its evidence) or in the knowledge library («＋ New record»; existing records can also be imported). You can prepare a decision draft manually. This is neither an automatically detected approval gap nor an approval. Review the type, title, and basis before saving.

Verdict glossary

The verdict above every answer says what it stands on. These are the states:

Checked & backed

The answer is based on the room’s entries and cites at least one accepted or explicitly rejected decision. The citations are numbered in the basis list. Only this state carries the full seal. If the answer is based on the room’s entries but on no such decision, the verdict is «Advisory basis». In chat, this record is deliberately compact while preserving verdict, citations, and evidence.

No reliable basis

The room’s governed knowledge has nothing on the question. The answer appears with a dimmed seal as a plain «Answer», never as a verified record.

Blocked

A runtime check stopped the run: the secret scan (SEC-01), the personal data scan (DAT-03), the model approval for the room’s data class, or a budget stop. Instead of an answer, a block card appears with the reason, the responsible owner, and, for guardrails, a direct exception request.

Approval required

A rule would have blocked the run, but an approved, time-limited exception applies. Such runs appear in the recent records as «approval granted»; the exception is part of the evidence.

Case approval required

The answer is backed and the room’s purpose applies, but the explicit approval for this case is missing. The line names the responsible person. The card below offers «Prepare request»: a prefilled BDR draft in this room’s knowledge workspace that takes the same path as any draft.

Inferred, not binding

No direct rule exists, but the subject of the question clearly belongs to a governed category (is-a). The derivation is shown transparently and does not bind.

Basis and evidence

For backed answers, the basis list names every citation: title, origin, owner, and authority. «Binding» means that the source is retrieved with priority and presented to the model as authoritative. «Advisory» only informs. There is no technical check of the answer against the source.

Every run leaves evidence: «Show evidence» opens it as an overlay, and «Download evidence» delivers it as JSON, for blocked runs too. The «Model» and «Cost» lines show only what the evidence proves: numbers appear for runs that verifiably went through the model gateway, so a displayed 0 is always a measured zero. Without that proof, the lines read «tokens not recorded» (cost without a usage measurement) or «No model call» (runs without inference, such as a governance act like renaming a room). A model without proof of use carries the «(configured)» marking and does not count as used. A blocked run alone does not prove that no model was called. For a named model without call or cost evidence, the display remains explicitly unknown.

Some evidence records also carry a governance act. This is a different kind of line from a policy verdict. It states what was done (the act, for example «change_membership» or «rename_room»), what it changed (the subject), and, where it applies, the value before and after, plus a reason if one was given. It lives in its own section of the evidence record and appears only when an act actually happened.

When a room holds more accepted decisions than a single answer can carry, NomOS does not select alphabetically: the room’s own decisions come before inherited ones, and then the maintained priority of a connection sets the order. The governance owner sets this priority, and every change gets an evidence record. A prerequisite that a decision in the answer depends on always travels along; the cap affects only prerequisites explicitly marked as optional. The answer still reports how many decisions are recorded in total.

You can maintain a connection’s priority directly in the knowledge graph: clicking a connection opens the editor on the right with the current value and its origin. «Preview effect» shows before saving which decisions enter or leave the answer’s selection under the new value. The value never changes whether a rule applies, only the order. On a prerequisite (depends_on), the editor also carries the «mandatory» flag: confirmed prerequisites are mandatory by default, and a downgrade to optional needs an occasion. Beside the type, the inspector names what the relation does and keeps three things separate: the confirmed effect (binary: it applies or it does not), the selection priority (an ordering role within the retrieval budget, not a truth score), and, only for a proposed relation, the proposal confidence (the typing proposal’s own number, neither truth nor a selection weight). A «Confirmed» or «Proposed» label marks the state, and a run field states that usage is not determinable here. The room’s governance owner can set the value, and every member can read it; every change requires an occasion and lands in the evidence record as a governance event. The «Referenced by» section shows which imported knowledge parts reference a decision; it is a display, not an edge.

Lifecycle of a decision

A record passes through fixed statuses. Only two of them apply:

Draft

The only editable state: title, content, properties, tags and relations can be changed. Its author, including whoever proposed it from a chat answer or through an agent, and the room’s deciders can edit or archive it.

Accepted

Accepted by the responsible decision maker and given a number. From then on, the decision applies and flows into the room’s answers and into agent queries.

Accepted with changes

Accepted with a documented change note. Also applies.

Rejected

Rejected with an optional reason. The proposal does not apply.

Superseded

Replaced by a newer record («Superseded by …»). No longer applies.

Archived

Removed from the active set. Kept for traceability.

Accepted records are read-only. Corrections run through a new record that marks the old one as superseded.

An approval given by mistake is not a correction: nothing was decided, so nothing gets replaced. Whoever can approve can take the approval back with a mandatory reason. The record returns to draft and is open for decision again. The approval and the withdrawal stay visible in the history, and anything the approval already set in motion is named there, but not undone.

The record’s «Origin and changes» section shows its history as steps rather than prose: the source (chat run, Dreaming proposal, agent dialogue, import, or manual), the proposal’s acceptance, the approval with person and date, approvals taken back, and the supersession. Where a target exists the step is a link: «Open evidence» opens the run behind the step through the same room-gated evidence access the run history uses, and a named record opens on click. What the record does not carry is not shown and never invented; the document text stays untouched. A superseded record says so at the top and links the version in force.

Who decides

For each decision type, the room can name a decision maker (decision maker matrix). If one is named, only that person decides; in addition, a platform admin in the room can always decide, so that no decision stays blocked. Without a named decision maker, the room owner, the governance owner, or a platform admin of the room decides. The backend enforces this on every accept and reject. Anyone who is not responsible gets an error message (403).

RELATION and learning loop

If NomOS answers «No reliable basis», a second pass checks whether the subject of the question clearly belongs to a category that the room has a rule about. If so, an inference appears («X is a Y»), visibly labeled as an inference and not binding.

«Propose association» turns it into a RELATION draft (subject is-a object). Once the decision maker accepts it, the room knows the mapping permanently; future answers in the room and its sub-rooms use it. This is how NomOS learns under governance: the machine proposes, and humans approve.

An automated pass can find declared but still untyped links in a room (is_a, refines, depends_on, conflicts_with) and group them into a rule, for example «X is_a Y applies to every referenced pair». This produces exactly one proposal per rule, not one per link: confirming hundreds of individual cases one after another looks like review but stops being reading. One decision therefore settles every link the rule covers at once: accepting activates them all, rejecting revokes them all permanently, and they are never proposed again.

Dreaming also counts how often two connected decisions were cited in the same answer and proposes a retrieval priority for the connection from that. This always happens as a proposal in the inbox, never as a direct write. Only acceptance by the governance owner writes the value (source «observed») with evidence. A rejection is final, and a connection maintained by hand is never overwritten.

Honest limits

How to read a grounded answer: «Checked & backed» means that every cited source exists and went into the answer. It does not guarantee every single sentence. The answer is instructed to keep three statements apart: «not documented in the sources», «not approved», and «proven impossible». It does not upgrade dispatch readiness to delivery and adds no dates, quantities, names, or approvals that appear in no source. When a basis is missing, it names the concrete open question instead of filling it. Still check numbers, dates, and commitments against the cited sources.

• «Checked & backed» means: grounded in governed knowledge. It does not mean that the content is guaranteed to be true. Quality depends on how well the memories are maintained.
• The inference only knows category membership (is-a) and only speaks up on a clear match. When in doubt, it stays silent.
• Accepted RELATIONs act in the answer path; hard rule enforcement (blocking) does not traverse them yet.
• A verdict rates the individual run at the state of that moment. If the knowledge changes later, the old evidence record remains unchanged. It documents what applied then.

History and follow-up questions

Conversations are per workspace and per person: the history column on the left shows only your own conversations in this room. Follow-up questions continue in the active conversation, so «and what applies to externals?» resolves from the history.

The most recent turns flow into the new answer as context; citations apply per answer. Citations, verdict, and evidence are fetched and checked fresh for every answer, never inherited from earlier answers. The evidence record states the context that was included («Conversation context»).

Deleting removes only the history. The evidence records of the answers remain, because they serve the audit.

Answers appear live while they are being generated; in the meantime, the header shows «Being checked …». Verdict, citations, and evidence appear only once the complete answer has been checked. If the transfer breaks off, nothing is sealed and nothing is saved.

In an empty workspace, quick questions remain available as starters but can be hidden directly. The preference is stored locally in the browser; the room’s recent evidence sits behind the “Evidence” control next to the input field.

The room selector sits in the workspace bar above the chat, not in the rail: it stays visible and usable while the rail is collapsed. It names the active room with its parent room and data class, lists the room hierarchy with indentation guides (it shows deeper levels as a count instead of ever-growing indentation), and creates a new sub-room through its last entry. It opens on a search field: type any part of a room name, and the list narrows to the matching rooms, shown flat because their parent rooms need not be among them. The entry for a new room stays below them even when nothing matches.

The room’s context sits behind the “Context” control next to the input field and answers first what matters when asking: which room with data class and origin, which sources and rules apply, which model is requested, and what restricts this task. Hashes, identifiers, and counters fold under “Technical details”, each value with its own copy button. For the budget, the context also names who enforces: a hard stop is stated only where the room has its own model key; without one, the limit of the room that pays applies.

Drafts from the agent dialogue (propose_decision)

Connected agents and MCP clients can capture pending decisions as drafts straight from the dialogue (MCP tool propose_decision, with context, options and recommendation). Such drafts carry an origin note (“proposed by …”) and additionally appear in the Inbox. One proposer can hold a limited number of open drafts per room (10 by default). A platform admin sets the installation value on the platform page External agents. The room’s governance owner or a platform admin can set a different value for one room in the room details, with a mandatory reason. Every change is recorded as evidence, and deciding a draft frees a slot.

Approval follows the same path as for any draft: the responsible decision maker reviews context, options, and recommendation, and then accepts or rejects. Agents can never accept a decision themselves; the server enforces this. Once approved, the decision flows into the room’s answers.

Cross-room decisions (cross-room, role holders only)

Anyone holding a cross-cutting role (architecture, security, or business) or the auditor role sees an additional «Cross-room decisions» entry at the top of the room list in the knowledge library. It sits below the library’s own «All rooms» entry, but has a different authorization. It shows exactly the decision types that the role covers (ADR, SDR, or BDR, or all four for the auditor) across every room, with a room chip on each entry.

The view is strictly read-only: no creating, no editing, no accepting or rejecting. Clicking the room chip switches to that room’s normal view, where your own room role applies again.

Without a cross-cutting role, the entry is missing. This is intended and not an error. To have a cross-cutting role granted: Help: cross-cutting roles and auditor