Policy Builder | Developer Docs

Policy Builder ist der Arbeitsbereich für den Richtlinienlebenszyklus unter /policy-studio. Die Hauptroute und der dialogbasierte Builder erfordern policy:read. Direkte Operationen unter /policy-studio/operations erfordern policy:publish.

Zuständigkeit

Richtlinienkatalog, Geltungsbereich, Versionen, Regeln und Begründungscodes.
Geführte und erweiterte Regelerstellung.
Simulation anhand des bereitgestellten Kontexts einer Decision Request.
Übermittlung zur Prüfung, Freigabe, Veröffentlichung, Integrität des kompilierten Packs und Rollback.
Bindungen zwischen Richtlinien und Agents sowie Umgebungen.
Evidence-Export für genau eine Richtlinienversion über die gemeinsame Evidence Factory. Das zurückgegebene Manifest wird vor dem Download auf diesen Richtlinien-Snapshot geprüft.

Die Tabs der Richtliniendetails sind Overview, Scope, Rules, Diff, Simulate, Signature und Versions.

Lebenszyklus einer Builder-Sitzung

Das Öffnen von /policy-studio/builder ist schreibgeschützt. Policy Builder erstellt eine Sitzung, sobald ein Autor die erste Nachricht sendet oder Start draft auswählt. Gleichzeitige erste Aktionen verwenden für diesen Tenant und Autor dieselbe offene leere Sitzung. Leere Sitzungen enthalten keine Nachrichten, keinen Richtlinienzustand, kein ausgewähltes Profil, kein Ergebnis der Richtlinienprüfung, keine Token-Nutzung und keinen abgeschlossenen Turn. Die Sitzungsliste entfernt leere Sitzungen nach 24 Stunden. Das Auflisten von Sitzungen führt diese Bereinigung aus, daher sind wiederholte Bereinigungsläufe sicher.

Veröffentlichte Richtlinien-Packs sind versioniert und signiert. Laufzeitentscheidungen führen Kennung und Version der Richtlinie in Decision Desk, Lineage Explorer, Audit Trail und Evidence Room.

Übergaben an Administratoren

Policy Builder bereitet eine Übergabe an einen Plattformadministrator vor, wenn eine dialogbasierte Sitzung Verbindungs-, Berechtigungs-, Konfigurations- oder Laufzeitvalidierungsarbeiten an einen Tenant-Administrator übergibt. Die Ursprungssitzung zeichnet die zugestellte Übergabe auf und verlinkt ihre Detailroute unter /policy-studio/admin-handoffs/[sessionId]/[handoffId]. Der Posteingang unter /policy-studio/admin-handoffs listet die für den Tenant zugestellten Übergaben.

Die Detailansicht zeigt Zuordnungen zu Geschäftsschritten, Operationen, erforderliche Berechtigungen und Namen von Zugangsdatenfeldern, Konfigurationsfelder, Validierungsschritte, ungelöste Entscheidungen und Quellen. Ein autorisierter Tenant-Administrator kann die Verbindungsarbeit im Tool Catalog auf dem Tab Connections mit der ursprünglichen Bundle-Revision sowie dem Kontext von Ursprungssitzung, Übergabe, Connector und Anforderung fortsetzen.

Die Posteingangsdaten erfordern tenant_admin oder super_admin und policy_builder_session:read. Detaildaten erfordern policy_builder_session:read und sind für den Eigentümer der Ursprungssitzung, tenant_admin oder super_admin zulässig. Tenant-Scoping gilt für beide Daten-APIs, und Autorisierungsfehler legen keine Übergabedaten offen.

Richtlinienlebenszyklus

flowchart LR
  D["Entwurf"] --> S["Simulation"]
  S --> R["Prüfung"]
  R --> P["Signiertes Pack veröffentlichen"]
  P --> E["Laufzeitauswertung"]
  E --> O["allow / warn / require approval / block"]
  P --> B["Rollback"]

Blockierte Entwürfe bleiben im Richtlinienkatalog und sind über einen Filter für blockierte Entwürfe erreichbar, der jeden offenen Abhilfe-Blocker zeigt. Gespeicherte Links auf die eingestellte Richtlinien-Abhilferoute leiten dauerhaft in den Katalog auf dem Rules-Tab mit aktiviertem Filter weiter. Ein Link mit Richtlinienkennung und Version öffnet diesen Entwurf.

Serverseitige Validierung und Autorisierung bleiben für Prüfung, Veröffentlichung und Rollback maßgeblich.