Regeln und Ausnahmen
Regeln sind die Governance-Vorgaben eines Raums. Sie fliessen in seine Verfassung ein und vererben sich nach unten. Jede Regel ist markiert: als laufzeit-durchgesetzt, wenn eine technische Prüfung sie erzwingt, sonst als nur dokumentiert.
Was eine Regel ist
Abschnitt betitelt „Was eine Regel ist“Eine Regel (Policy) ist eine Governance-Vorgabe mit Schlüssel, Regeltext, Owner und Gültigkeit. Sie fliesst in die Verfassung des Raums ein; Unterräume erben sie automatisch.
Raum-Owner legen die Regeln ihres Raums an, bearbeiten sie und legen sie still. Stillgelegte eigene Regeln können wieder reaktiviert oder, wenn keine Ausnahme-Historie daran hängt, endgültig gelöscht werden. Geerbte Regeln gelten mit, werden aber beim übergeordneten Raum verwaltet und sind hier schreibgeschützt. Zusätzlich gilt die Plattform-Baseline: Regeln, die die Laufzeit-Prüfungen der Plattform in jedem Raum durchsetzen. Die Regeln-Seite führt sie in einer eigenen Gruppe auf.
«Regel» und «Dokument» sind Stufen desselben Wegs: Ein importiertes Dokument oder Reglement ist zunächst beratendes Wissen (es belegt Antworten). Raum-Owner können einen übernommenen Teil im Regel-Editor als Regel erheben. Die Regel wirkt dann über die Verfassung; technisch durchgesetzt werden nur SEC-01 und DAT-03.
Die drei Regel-Typen
Abschnitt betitelt „Die drei Regel-Typen“Harte Regel
Keine Ausnahmen möglich; ein Ausnahme-Antrag wird abgewiesen. Technisch blockiert wird nur, wo eine Laufzeit-Prüfung für die Regel existiert (SEC-01). Sonst wirkt die Regel über die Verfassung.
Leitplanke
Mit Ausnahmepfad: Eine befristete Ausnahme ist möglich. Technisch blockiert wird nur, wo eine Laufzeit-Prüfung für die Regel existiert (DAT-03). Sonst wirkt die Regel über die Verfassung.
Konvention
Nur Kontext: informiert Modell und Nutzer, blockiert nie.
Wie eine Regel durchgesetzt wird
Abschnitt betitelt „Wie eine Regel durchgesetzt wird“Jede Regel trägt eine Markierung. «laufzeit-durchgesetzt» heisst, eine technische Prüfung greift wirklich: der Secret-Scan (SEC-01) und der Personendaten-Scan (DAT-03). Alles andere ist «nur dokumentiert»: Es wirkt über die Verfassung, also über die Vorgaben an das Modell, ohne technische Blockade. Unabhängig von den Regeln stoppen auch die Modell-Freigabe je Datenklasse und die Budget-Stopps einen Lauf.
Die Markierung steht sichtbar an jeder Regel-Karte. Was nicht laufzeit-durchgesetzt ist, wird nicht als hart verkauft.
Wirkung im Chat: die Block-Karte
Abschnitt betitelt „Wirkung im Chat: die Block-Karte“Blockiert eine Laufzeit-Prüfung den Lauf, erscheint statt einer Antwort eine Block-Karte: «Blockiert durch …» mit Regeltext, Policy-Owner und, falls vorhanden, den erkannten Treffern.
Bei Leitplanken bietet die Karte direkt «Ausnahme beantragen (befristet)» an. Fällt ein Scanner aus, blockiert das System den Lauf (fail-closed) und sagt das. Ein Ausfall wird nie als Fund ausgegeben.
Die Karte verlinkt zudem die Evidence des zurückgehaltenen Laufs («Evidence anzeigen»): dieselbe raumgebundene Evidence-Ansicht, die eine normale Antwort öffnet, mit dem Regel-Entscheid und der erkannten Kategorie, nie mit dem zurückgehaltenen Text. Bei einem Personendaten-Treffer nennt sie auch die erlaubte Fortsetzung: Räume mit einer Klassifizierung für Personendaten erlauben eine solche Antwort. Du kannst also eine Ausnahme beantragen oder den Owner eines passenden Raums um Zugang bitten, statt beim Block zu enden. Über die Ausnahme entscheiden Raum-Owner, Governance-Owner oder Plattform-Admin des Raums, in dem die Regel liegt; bei DAT-03 ist das der oberste Raum.
Ausnahme-Workflow
Abschnitt betitelt „Ausnahme-Workflow“- Beantragen: Jedes Raum-Mitglied beantragt eine Ausnahme zu einer Regel, mit Begründung und optionalem Geltungsbereich. Das geht direkt an der Regel oder aus der Block-Karte.
- Entscheiden: Raum-Owner, Governance-Owner oder Plattform-Admin des Raums, in dem die Regel liegt, entscheiden im Posteingang. Ein Klick auf die Zeile öffnet das Antrags-Detail mit Begründung und Geltungsbereich. Im Posteingang ist eine Entscheid-Begründung für beide Entscheide Pflicht; bei einer Genehmigung wählst du zusätzlich die Befristung in Tagen (Vorschlag 14). Die Begründung wird am Entscheid und im Beleg festgehalten.
- Enden: Die Ausnahme erlischt am Ablaufdatum automatisch oder vorher durch Widerruf. Widerrufen können dieselben Rollen, die entscheiden. Einen noch offenen Antrag kann die antragstellende Person selbst zurückziehen.
Harte Regeln haben keinen Ausnahmepfad. Ein Antrag wird mit klarer Meldung abgewiesen.
Genehmigte, noch gültige Ausnahmen erscheinen direkt an der betreffenden Regel (Status, Frist, Antragsteller). Dort lassen sich Ausnahmen beantragen und von Berechtigten auch widerrufen. Jeder Widerruf wird mit Person und Zeitpunkt festgehalten, ein angegebener Grund ebenfalls.
Eine genehmigte Ausnahme wirkt auch in der Antwort selbst: Der Assistent kennt die aktive Ausnahme (Regel, Zweck, Ablauf) und verweigert eine Antwort nicht mehr unter Berufung auf die ausgesetzte Regel. Stattdessen weist er kurz auf die geltende Ausnahme hin. Der Beleg des Laufs hält die angewendete Ausnahme fest.
Vorlagen
Abschnitt betitelt „Vorlagen“Für den Start gibt es Vorlagen; sie lassen sich vor dem Anlegen anpassen. Eine Vorlage legt eine Regel an, die über die Verfassung wirkt. Technisch geprüft werden nur SEC-01 und DAT-03:
- Keine Secrets im Code: Quellcode und Antworten ohne Secrets, Tokens oder Passwörter.
- Kein Export von C2/C3-Daten: Schützenswerte Datenklassen sollen die Domäne nicht verlassen. Eine Export-Prüfung zur Laufzeit gibt es nicht.
- Tool-Aufruf braucht Owner-Freigabe: Human-in-the-loop für riskante Agentenaktionen.
- Externe Agenten nur im Beobachten-Modus: Durchsetzung erst nach Bewährung.
- Produktionsnahe Änderung nur mit Freigabe: Vier-Augen-Prinzip vor produktionsnaher Wirkung.
Dokumente importieren
Abschnitt betitelt „Dokumente importieren“Bestehende amtliche PDF-Dokumente müssen nicht abgetippt werden. Der Import («Importieren» in der Bibliothek eines Raums oder «Dokumente importieren» auf der Seite eines Gedächtnisses) zerlegt sie in prüfbare Abschnitte. Ins Gedächtnis kommt nur, was ein Mensch im Review übernimmt.
Nach der Übernahme findest du die Dokumente im Bereich «Dokumente & Reglemente» des Gedächtnisses, das sie enthält. Dort kannst du sie einsehen und Kopf-Metadaten (Titel, Referenz, Version, Gültig-ab, Rollen) und Teile pflegen. Jede Änderung wird als Beleg protokolliert.
Importierte Dokumente sind Wissen und wirken beratend. Sie werden nicht automatisch zu Regeln; die Erhebung zur Regel ist ein eigener, governter Schritt. Die Tabelle der importierten Dokumente lässt sich nach Spalten sortieren und durchsuchen.
Zur Anleitung: Dokumente importieren
Relationstyp-Gewichte
Abschnitt betitelt „Relationstyp-Gewichte“Ein Raum kann entscheiden, wie stark ein Relationstyp in seinen eigenen Antworten zählt. Das Gewicht vervielfacht die Abruf-Priorität der Kanten dieses Typs, bevor die Auswahl pro Antwort greift. Erlaubt sind Werte von 0 bis 2: 1.0 ist neutral, 0 nimmt den Typ aus der Auswahl, Werte unter 1 schwächen ihn ab, Werte über 1 verstärken ihn.
Die Gewichte stehen unter «Regeln», sobald du einen Raum gewählt hast. Setzen darf sie der Governance-Owner des Raums; jedes Mitglied kann sie lesen. Jede Änderung braucht einen Anlass und wird als Beleg protokolliert (ADR-066).
Wer ist der Governance-Owner
Abschnitt betitelt „Wer ist der Governance-Owner“Die Relationstyp-Gewichte setzt der Governance-Owner eines Raums. Diese Rolle wird bewusst nicht automatisch vergeben. Der Raum-Owner vergibt sie im Abschnitt «Governance-Owner» unter «Regeln» und darf sie sich selbst geben. Die Befugnis gilt nur, solange die Person Mitglied des Raums bleibt: Wer den Raum verlässt, wird als «kein Mitglied mehr» angezeigt und kann widerrufen werden.
Vergeben und Widerrufen sind Governance-Akte und werden als Beleg protokolliert. Jedes Mitglied sieht, wer den Governance-Owner innehat; vergeben oder widerrufen darf ihn nur der Raum-Owner. Solange ihn niemand hält, bleiben die Gewichts-Editoren für alle nur lesbar.
Beziehungen eines Raums typisieren
Abschnitt betitelt „Beziehungen eines Raums typisieren“Importierte Entscheide kommen oft verknüpft, aber untypisiert an: ein blosses relates_to sagt, dass zwei Entscheide zusammengehören, aber nicht wie. Auf der Regeln-Seite zeigt der Bereich «Beziehungen typisieren», wie viele solche untypisierten Verbindungen der Raum trägt, und lässt den Raum-Owner den Typisierungslauf für diesen Raum starten.
Der Lauf typisiert nie selbst eine Verbindung. Er reicht Vorschläge in den Posteingang ein, wo du die Regel bestätigst, der jede Typisierung folgt; eine Typisierung wird erst aktiv, nachdem du sie annimmst. Ein Nicht-Owner sieht den Bereich nur lesend und kann ihn nicht starten.