Entscheide und Verdikte

Jede Antwort trägt ein Verdikt: geprüft und belegt, beratende Basis, ohne belastbare Grundlage, blockiert oder abgeleitet. Dahinter stehen Entscheide (Decision Records): governtes Wissen mit Lebenszyklus, Entscheidern und Beleg.

Was ein Entscheid ist

Ein Entscheid (Decision Record) hält eine Festlegung des Raums fest, als ADR (Architektur), BDR (Business), SDR (Steuerung), PURPOSE (Zweck) oder RELATION (Taxonomie). DREAM-Records erzeugt das System selbst; sie lassen sich nicht von Hand annehmen. Nur angenommene Entscheide fliessen als geltende Festlegungen in die Antworten ein. Entwürfe und abgelehnte Entscheide gelten nicht.

Entwürfe entstehen an zwei Orten: im Chat («Als ADR-Entwurf übernehmen» macht aus einer Antwort einen Entwurf samt Beleg) oder in der Wissens-Bibliothek («＋ Neuer Record»; bestehende Records lassen sich auch importieren). Du kannst einen Entscheidungsentwurf selbst vorbereiten. Das ist keine automatisch erkannte Freigabelücke und keine Freigabe. Typ, Titel und Grundlage sind vor dem Speichern zu prüfen.

Verdikt-Glossar

Das Verdikt über jeder Antwort sagt, worauf sie steht. Diese Zustände gibt es:

Geprüft & belegt

Die Antwort stützt sich auf Einträge des Raums und zitiert mindestens einen angenommenen oder ausdrücklich abgelehnten Entscheid. Die Belege stehen nummeriert in der Grundlage-Liste. Nur dieser Zustand trägt das volle Siegel. Stützt sich die Antwort auf Einträge des Raums, aber auf keinen solchen Entscheid, lautet das Verdikt «Beratende Basis». Im Chat erscheint dieser Record bewusst kompakt, während Verdikt, Belege und Evidence erhalten bleiben.

Ohne belastbare Grundlage

Das governte Wissen des Raums gibt zur Frage nichts her. Die Antwort erscheint mit gedimmtem Siegel als blosse «Antwort», nie als geprüfter Beleg.

Blockiert

Eine Laufzeit-Prüfung hat den Lauf gestoppt: der Secret-Scan (SEC-01), der Personendaten-Scan (DAT-03), die Modell-Freigabe für die Datenklasse des Raums oder ein Budget-Stopp. Statt einer Antwort erscheint eine Block-Karte mit dem Grund, dem zuständigen Owner und, bei Leitplanken, dem direkten Ausnahme-Antrag.

Freigabe nötig

Eine Regel hätte den Lauf blockiert, doch eine genehmigte, befristete Ausnahme greift. Solche Läufe erscheinen in den letzten Belegen als «Freigabe erteilt»; die Ausnahme steht im Nachweis.

Fallfreigabe erforderlich

Die Antwort ist belegt und der Raum-Zweck gilt, aber für diesen Fall fehlt die ausdrückliche Freigabe. Die Zeile nennt die zuständige Person. Die Karte darunter bietet «Antrag vorbereiten» an: einen vorbefüllten BDR-Entwurf im Wissen-Workspace dieses Raums, der denselben Weg geht wie jeder Entwurf.

Abgeleitet, nicht bindend

Keine direkte Regelung, aber das Subjekt der Frage gehört eindeutig zu einer geregelten Kategorie (is-a). Die Ableitung wird transparent ausgewiesen und bindet nicht.

Grundlage und Beleg

Bei belegten Antworten führt die Grundlage-Liste jeden Beleg auf: Titel, Herkunft, Owner und Geltung. «Bindend» heisst: Die Quelle wird bevorzugt abgerufen und dem Modell als massgeblich vorgelegt. «Beratend» informiert nur. Eine technische Prüfung der Antwort gegen die Quelle findet nicht statt.

Jeder Lauf hinterlässt einen Nachweis (Evidence): «Evidence anzeigen» öffnet ihn als Overlay, «Evidence herunterladen» liefert ihn als JSON, auch für blockierte Läufe. Die Zeilen «Modell» und «Kosten» zeigen nur, was der Nachweis belegt: Zahlen stehen bei Läufen, die nachweislich über den Modell-Gateway liefen; eine angezeigte 0 ist darum immer eine gemessene Null. Fehlt dieser Nachweis, steht «Token nicht erfasst» (Kosten ohne Nutzungsmessung) oder «Kein Modellaufruf» (Läufe ohne Inferenz, etwa Governance-Akte wie eine Raum-Umbenennung). Ein Modell ohne Nutzungsnachweis trägt die Markierung «(konfiguriert)» und gilt nicht als verwendet. Ein blockierter Lauf allein beweist nicht, dass kein Modell aufgerufen wurde. Fehlen bei einem benannten Modell Aufruf- und Kostennachweise, bleibt die Anzeige ausdrücklich unbekannt.

Manche Belege tragen zusätzlich einen Governance-Akt. Das ist eine andere Art von Zeile als ein Policy-Verdikt. Sie hält fest, was getan wurde (der Akt, etwa «change_membership» oder «rename_room»), was sich dadurch änderte (das Subjekt) und, wo zutreffend, den Wert davor und danach, dazu einen Grund, sofern einer angegeben wurde. Sie steht in einem eigenen Abschnitt des Belegs und erscheint nur, wenn wirklich ein Akt stattgefunden hat.

Übersteigt die Zahl der angenommenen Entscheide, was eine einzelne Antwort tragen kann, wählt NomOS nicht alphabetisch aus: Entscheide des eigenen Raums kommen vor den geerbten, danach ordnet die gepflegte Priorität einer Verbindung. Diese Priorität setzt der Governance-Owner, und jede Änderung erhält einen Beleg. Eine Voraussetzung, von der ein Entscheid der Antwort abhängt, reist immer mit; die Kappung trifft nur ausdrücklich als optional markierte Voraussetzungen. Wie viele Entscheide insgesamt erfasst sind, weist die Antwort weiterhin aus.

Die Priorität einer Verbindung lässt sich direkt im Wissens-Graphen pflegen: Ein Klick auf eine Verbindung öffnet rechts den Editor mit dem aktuellen Wert und seiner Herkunft. «Wirkung ansehen» zeigt vor dem Speichern, welche Entscheide unter dem neuen Wert in die Auswahl der Antwort eintreten oder sie verlassen. Der Wert ändert nie, ob eine Regel gilt, nur die Reihenfolge. Bei einer Voraussetzung (depends_on) trägt der Editor zusätzlich die Flagge «zwingend»: Bestätigte Voraussetzungen sind standardmässig zwingend, eine Herabstufung auf optional braucht einen Anlass. Neben dem Typ benennt der Inspektor, was die Relation tut, und hält drei Dinge getrennt: die bestätigte Wirkung (binär: sie wirkt oder nicht), die Auswahl-Priorität (eine Reihenfolge-Rolle im Abrufbudget, kein Wahrheitswert) und, nur bei einer vorgeschlagenen Relation, die Vorschlags-Konfidenz (die eigene Zahl des Typisierungs-Vorschlags, weder Wahrheit noch Auswahlgewicht). Ein Label «Bestätigt» oder «Vorgeschlagen» zeigt den Zustand, und ein Lauf-Feld sagt, dass die Verwendung hier nicht ersichtlich ist. Setzen darf der Governance-Owner des Raums, lesen alle Mitglieder; jede Änderung verlangt einen Anlass und landet als Governance-Ereignis im Beleg. Der Abschnitt Referenziert von zeigt, welche importierten Wissens-Teile auf einen Entscheid verweisen; das ist eine Anzeige, keine Kante.

Lebenszyklus eines Entscheids

Ein Record durchläuft feste Status. Nur zwei davon gelten:

Entwurf

Der einzige bearbeitbare Zustand: Titel, Inhalt, Eigenschaften, Tags und Verknüpfungen lassen sich ändern. Bearbeiten oder archivieren dürfen ihn sein Autor, auch wer ihn aus einer Chat-Antwort oder über einen Agenten vorgeschlagen hat, und die Entscheider des Raums.

Angenommen

Vom zuständigen Entscheider angenommen und mit einer Nummer versehen. Der Entscheid gilt ab dann und fliesst in die Antworten des Raums und in die Abfragen von Agenten ein.

Mit Änderungen angenommen

Angenommen mit dokumentierter Änderungsnotiz. Gilt ebenfalls.

Abgelehnt

Mit optionalem Grund abgelehnt. Der Vorschlag gilt nicht.

Ersetzt

Von einem neueren Record abgelöst («Ersetzt durch …»). Gilt nicht mehr.

Archiviert

Aus dem aktiven Bestand genommen. Bleibt für die Nachvollziehbarkeit erhalten.

Angenommene Records sind schreibgeschützt. Korrekturen laufen über einen neuen Record, der den alten als ersetzt markiert.

Eine versehentliche Freigabe ist keine Korrektur: Es wurde nichts entschieden, also wird auch nichts ersetzt. Wer freigeben darf, kann die Freigabe mit Pflicht-Begründung zurücknehmen. Der Record kehrt zum Entwurf zurück und steht wieder zur Entscheidung. Freigabe und Rücknahme bleiben im Verlauf sichtbar, und was die Freigabe bereits ausgelöst hat, wird dort benannt, aber nicht rückgängig gemacht.

Der Abschnitt «Entstehung und Änderungen» im Record zeigt die Geschichte als Schritte statt als Fliesstext: Quelle (Chat-Lauf, Träumen-Vorschlag, Agenten-Dialog, Import oder manuell), Annahme des Vorschlags, Freigabe mit Person und Datum, zurückgenommene Freigaben und die Ablösung. Wo ein Ziel existiert, ist der Schritt ein Link: «Nachweis öffnen» öffnet den Lauf hinter dem Schritt über denselben raumgebundenen Nachweis-Zugriff wie die Lauf-Historie, ein genannter Record öffnet sich per Klick. Was der Record nicht trägt, wird nicht angezeigt und nie erfunden; der Dokumenttext bleibt unverändert. Ein ersetzter Record sagt es zuoberst und verlinkt die gültige Fassung.

Wer entscheidet

Je Entscheidungstyp kann der Raum einen Entscheider festlegen (Entscheider-Matrix). Ist einer festgelegt, entscheidet nur diese Person; zusätzlich kann ein Plattform-Admin im Raum immer entscheiden, damit kein Entscheid blockiert bleibt. Ohne Festlegung entscheiden der Raum-Owner, der Governance-Owner oder ein Plattform-Admin des Raums. Das Backend erzwingt das bei jeder Annahme und Ablehnung. Wer nicht zuständig ist, erhält eine Fehlermeldung (403).

RELATION und Lernschleife

Antwortet NomOS «ohne belastbare Grundlage», prüft ein zweiter Durchgang, ob das Subjekt der Frage eindeutig zu einer Kategorie gehört, über die der Raum eine Regel hat. Wenn ja, erscheint eine Ableitung («X ist ein Y»), sichtbar als Ableitung gekennzeichnet und nicht bindend.

Per «Assoziation vorschlagen» wird daraus ein RELATION-Entwurf (Subjekt is-a Objekt). Nimmt der Entscheider ihn an, kennt der Raum die Zuordnung dauerhaft; künftige Antworten im Raum und in seinen Unterräumen nutzen sie. So lernt NomOS unter Governance dazu: Die Maschine schlägt vor, Menschen geben frei.

Ein automatischer Durchgang kann in einem Raum bereits erklärte, aber noch ungetypte Verbindungen (is_a, refines, depends_on, conflicts_with) finden und zu einer Regel bündeln, etwa «X is_a Y gilt für alle referenzierten Paare». Dafür entsteht genau ein Vorschlag pro Regel, nicht einer je Verbindung: Wer Hunderte Einzelfälle nacheinander abnickt, prüft formal, liest aber nicht mehr wirklich. Ein Entscheid setzt darum alle von der Regel abgedeckten Verbindungen zugleich: Annehmen aktiviert sie alle, Ablehnen widerruft sie alle dauerhaft, und sie werden nie erneut vorgeschlagen.

Das Träumen zählt ausserdem, wie oft zwei verbundene Entscheide in derselben Antwort zitiert wurden, und schlägt daraus eine Abruf-Priorität für die Verbindung vor. Das geschieht immer als Vorschlag im Posteingang, nie als direkter Schreibvorgang. Erst die Annahme durch den Governance-Owner schreibt den Wert (Quelle «observed») mit Beleg. Eine Ablehnung ist endgültig, und eine von Hand gepflegte Verbindung wird nie überschrieben.

Ehrliche Grenzen

So liest du eine belegte Antwort: «Geprüft & belegt» bedeutet, dass jede zitierte Quelle existiert und in die Antwort eingeflossen ist. Es garantiert nicht jeden einzelnen Satz. Die Antwort ist angehalten, drei Aussagen auseinanderzuhalten: «in den Quellen nicht dokumentiert», «nicht freigegeben» und «nachweislich unmöglich». Sie stuft Versandbereitschaft nicht zu Lieferung hoch und ergänzt keine Daten, Mengen, Namen oder Freigaben, die in keiner Quelle stehen. Fehlt eine Grundlage, nennt sie die konkrete offene Frage, statt sie zu füllen. Prüfe Zahlen, Termine und Zusagen trotzdem gegen die zitierten Quellen.

• «Geprüft & belegt» heisst: auf governtem Wissen gegründet. Es heisst nicht, dass der Inhalt garantiert wahr ist. Die Qualität hängt an der Pflege der Gedächtnisse.
• Die Ableitung kennt nur Kategorien-Zugehörigkeit (is-a) und meldet sich nur bei eindeutiger Zuordnung. Im Zweifel schweigt sie.
• Angenommene RELATIONs wirken im Antwort-Pfad; die harte Regel-Durchsetzung (Blockieren) traversiert sie derzeit nicht.
• Ein Verdikt bewertet den einzelnen Lauf zum damaligen Stand. Ändert sich das Wissen später, bleibt der alte Beleg unverändert. Er dokumentiert, was damals galt.

Verlauf und Folgefragen

Unterhaltungen sind pro Arbeitsraum und pro Person: Die Verlaufs-Spalte links zeigt nur die eigenen Unterhaltungen des Raums. Folgefragen laufen in der aktiven Unterhaltung weiter, so versteht sich «und was gilt dabei für Externe?» aus dem Verlauf.

Die letzten Vorturns fliessen als Kontext in die neue Antwort ein; die Belege gelten je Antwort. Belege, Verdikt und Evidence werden für jede Antwort frisch geholt und geprüft, nie aus früheren Antworten übernommen. Der Evidence-Nachweis weist den mitgegebenen Kontext aus («Verlaufs-Kontext»).

Löschen entfernt nur den Verlauf. Die Evidence-Nachweise der Antworten bleiben bestehen, weil Belege der Prüfung dienen.

Antworten erscheinen live, während sie entstehen; der Beleg-Kopf zeigt dabei «Wird geprüft …». Verdikt, Belege und Evidence erscheinen erst, wenn die vollständige Antwort geprüft ist. Bricht die Übertragung ab, wird nichts gesiegelt und nichts gespeichert.

Im leeren Arbeitsraum bleiben Schnellfragen als Einstieg verfügbar, können aber direkt ausgeblendet werden. Die Einstellung bleibt lokal im Browser gespeichert; die letzten Belege des Raums liegen unter «Belege» neben dem Eingabefeld.

Die Raum-Auswahl liegt in der Arbeitsraum-Leiste über dem Chat, nicht in der Schiene: Sie bleibt sichtbar und bedienbar, wenn die Schiene eingeklappt ist. Sie nennt den aktiven Raum mit Eltern-Raum und Datenklasse, listet die Raum-Hierarchie mit Einrückungslinien (tiefere Ebenen zeigt sie mit einer Zahl statt immer weiterer Einrückung) und legt über den letzten Eintrag einen neuen Unter-Raum an. Sie öffnet mit einem Suchfeld: Ein beliebiger Teil des Raumnamens genügt, und die Liste zeigt nur noch die Treffer, flach, weil deren Eltern-Räume nicht darunter sein müssen. Der Eintrag für einen neuen Raum bleibt darunter stehen, auch wenn nichts passt.

Der Kontext des Raums liegt unter «Kontext» neben dem Eingabefeld und beantwortet zuerst, was beim Fragen zählt: welcher Raum mit Datenklasse und Herkunft, welche Quellen und Regeln gelten, welches Modell angefordert wird und was diese Aufgabe einschränkt. Hashes, Kennungen und Zähler stehen aufklappbar unter «Technische Details», jeder Wert mit eigener Kopier-Schaltfläche. Beim Budget nennt der Kontext auch, wer durchsetzt: Ein harter Stopp steht nur, wo der Raum einen eigenen Modell-Schlüssel hat; ohne eigenen Schlüssel gilt das Limit des Raums, der zahlt.

Entwürfe aus dem Agenten-Dialog (propose_decision)

Angebundene Agenten und MCP-Clients können anstehende Entscheidungen direkt aus dem Dialog als Entwurf erfassen (MCP-Tool propose_decision, mit Kontext, Optionen und Empfehlung). Solche Entwürfe tragen einen Herkunfts-Hinweis («vorgeschlagen von …») und erscheinen zusätzlich im Posteingang. Eine vorschlagende Identität kann pro Raum nur eine begrenzte Zahl offener Entwürfe halten (standardmässig 10). Den Wert der Installation setzt ein Plattform-Admin auf der Plattform-Seite «Externe Agenten». Der Governance-Owner des Raums oder ein Plattform-Admin kann in den Raumdetails mit Pflichtbegründung einen eigenen Wert für den Raum setzen. Jede Änderung wird als Beleg festgehalten; wer einen Entwurf entscheidet, schafft wieder Platz.

Für die Freigabe gilt derselbe Weg wie für jeden Entwurf: Der zuständige Entscheider prüft Kontext, Optionen und Empfehlung und nimmt an oder lehnt ab. Agenten können einen Entscheid nie selbst annehmen; das erzwingt der Server. Nach der Freigabe fliesst der Entscheid in die Antworten des Raums ein.

Querblick Entscheide (raumübergreifend, nur für Rollen-Inhaber)

Wer eine Quer-Rolle (Architektur, Sicherheit oder Business) oder die Auditor-Rolle hält, sieht in der Wissens-Bibliothek oben in der Raum-Liste zusätzlich den Eintrag «Querblick Entscheide». Er steht unterhalb des bibliothekseigenen Eintrags «Alle Räume», hat aber eine andere Berechtigung. Er zeigt genau die Entscheid-Typen, für die die Rolle gilt (ADR, SDR oder BDR, bei Auditor alle vier), über sämtliche Räume hinweg, mit einem Raum-Chip an jedem Eintrag.

Die Sicht ist strikt nur lesend: kein Anlegen, kein Bearbeiten, kein Annehmen oder Ablehnen. Ein Klick auf den Raum-Chip wechselt in die normale Sicht dieses Raums, wo wieder die eigene Raum-Rolle gilt.

Ohne Quer-Rolle fehlt der Eintrag. Das ist so vorgesehen und kein Fehler. Wer eine Quer-Rolle vergeben bekommen soll: Hilfe: Quer-Rollen und Auditor