1 · Operator
Konkreter technischer/organisatorischer Betreiber der Instanz. Root sovereignty is separately bound as: Operator instance; technischer Betrieb allein erzeugt sie nicht.
SEBG · SOVEREIGN EFFECT BASELINE GATE MACHINE
Bevor du neue Regeln setzt, musst du wissen, wie Wirkung bei dir heute tatsächlich entsteht.
SEBG ist eine öffentliche C0-Referenzarchitektur für die Baseline eines bestehenden Wirkungsraums. TBYD empfiehlt sie als Ausgangspunkt, wenn ein Betreiber seine heutige digitale Wirkungsrealität zuerst vollständig sichtbar, bindbar und nachweisbar machen will.
Bestehende fachliche Wirkung darf zunächst weiterlaufen. Die aktive Baseline-Regel dafür heißt `allow-as-before`.
SEBG ist keine Software, kein IT-Scanner und keine allgemeine SES-Pflicht. Diese Seite beschreibt eine C0-Architektur – keine bereits gebundene oder produktiv aktivierte Betreiberinstanz.
SOUVERÄNITÄT + FORMATION · A6 v1.2
Wer betreibt? Wer ist Souverän? Wie wird die Instanz gebildet?
Die Rollen werden getrennt gebunden. Betrieb, Authority, Souveränität und Formation sind nicht dasselbe.
2 · Root-Souveränität: O
- Operator instance: Source-bound effect space described by the existing C0 detail
3 · Delegierte Souveränität
- Customer effect space only where explicitly delegated as a separate sovereignty domain
4 · Authority-only-Rollen
- Delegated authorities within bound scope
- technical/provider carriers
5 · Quelle der Target-Regeln
Engineering-Pfad: the machine-specific Target rule set is defined/authorized in the Target’s own sovereign binding. Vorbereiteter SSMFF-Pfad: Lösungsbetreiber/Publisher liefert Target Rule Templates -> Souverän wählt/autorisiert -> SSMFF bindet. SSMFF authored keine Target Rules.
6 · Formationspfad
Beide: Engineering oder vorbereitete SSMFF-Formation
SSMFF-Rolle: Optionaler vorbereiteter Formationspfad: SSMFF darf Discovery-, Scope-, Binding- und Formationslast für ein vorbereitetes Target tragen; souveräne Entscheidungen bleiben beim Target-Souverän.
7 · Factory-/Target-Grenze
SSMFF Formation Rules != Target Rules. Souveräne Entscheidungen bleiben beim Souverän. Factory Result/Verification/Validation/Readiness != Target C2/C3/C4/PASS. Fehlende Target-Regel oder souveräne Entscheidung bleibt non-PASS.
1 · DAS AUSGANGSPROBLEM
Verantwortung liegt oft beim Betreiber. Wirkung entsteht aber über viel mehr als nur seine Software.
In einem realen Unternehmen können Zugriffe, Freigaben, Kosten, Statusänderungen, Identitäten, Providerergebnisse, Adminhandlungen, KI-Ausgaben oder verzögerte Jobs Folgen erzeugen. Der Betreiber trägt Verantwortung für einen Wirkungsraum, obwohl nicht jeder wirkende Pfad sofort sichtbar oder vollständig verstanden ist.
Menschen und Rollen
Freigaben, Support, Adminhandlungen, Delegationen, Notfallrechte und manuelle Entscheidungen können Wirkung erzeugen.
Organisation und Prozesse
Arbeitsweisen, Ausnahmen, Eskalationen, Recovery-Wege und gelebte Praxis können fachlich genauso relevant sein wie Code.
Drittsysteme und Provider
Status, Scores, Defaults, Lieferungen oder andere externe Inputs können innerhalb der Betreiberinstanz weitere Wirkung auslösen.
Technik
Software, KI, Jobs, Queues, Service Accounts, Konfigurationen und verzögerte Abläufe können effect-relevante Zustände verändern.
SEBG setzt deshalb nicht bei einer IT-Inventarliste an. Es setzt bei der tatsächlichen Wirkungsordnung an.
2 · BASELINE STATT SOFORTIGER UMSTEUERUNG
SEBG bindet zuerst, ohne die bestehende fachliche Wirkung bereits neu zu schreiben.
Im Baseline-Betrieb gilt `allow-as-before`: Ein bestehender fachlicher Ausgang darf zunächst so weiterlaufen wie bisher. Gleichzeitig wird jede effect-relevante Interaktion des beanspruchten Scope an die formale SES-Ordnung gebunden.
heutige WirkungWas passiert heute tatsächlich?
allow-as-beforeDer bestehende fachliche Ausgang bleibt zunächst erlaubt.
gebundene BaselineAuthority, Regelbasis, State, Entscheidung, Evidence und Revalidation werden zugeordnet.
Was Baseline gerade nicht bedeutet
- keine neuen domänenspezifischen Verbote im Baseline-Betrieb
- keine neue domänenspezifische Sperr- oder Widerrufslogik
- keine automatische Veränderung der fachlichen Rollen oder Rechte
- keine Annahme, dass Baseline bloß passive Beobachtung sei
BASELINE-ONLY ist nicht ungeregelt. `allow-as-before` ist selbst eine aktive Regel.
3 · WAS WIRD GEBUNDEN?
Aus einem technischen oder menschlichen Vorgang wird ein nachvollziehbarer Wirkungsweg.
Für einen effect-relevanten Vorgang muss die Baseline nachvollziehbar machen, worum es geht, wer handeln darf, welche Regelbasis gilt, welcher Zustand vorliegt, welche Entscheidung entsteht und welcher Nachweis dazugehört.
Wirkungsgegenstand
Was wird verändert, freigegeben, verzögert, gebunden oder anderweitig wirksam?
Authority
Welche ausdrücklich gebundene Stelle darf diesen Vorgang in diesem Kontext tragen oder entscheiden?
Regelbasis
Welche aktive Regel oder endliche Regelkette gilt? In der Baseline ist der gewöhnliche Ausgang `allow-as-before`.
State und Kontext
Welcher vorherige Zustand und welcher konkrete Kontext sind für die Entscheidung relevant?
Judgment und Konsequenz
Welche formale Entscheidung entsteht und welche definierte Konsequenz oder Nicht-Ausführung gehört dazu?
Evidence und Folgezustand
Kann rekonstruiert werden, warum die Wirkung zählen durfte und welcher Zustand danach entstand?
Object + prior State + Context + Authority + Rule + Judgment + Consequence + follow-on State + Evidence
4 · SCOPE IST DIE VOLLSTÄNDIGKEIT DER WIRKUNGSWEGE
Ein System ist nicht deshalb im SES-Scope, weil es in einem Diagramm steht.
Scope fragt: Über welche Wege kann im beanspruchten Wirkungsraum relevante Wirkung entstehen oder beeinflusst werden? Diese Wege müssen vollständig gebunden, ausdrücklich ausgeschlossen oder als `NOT_CLAIMED` klassifiziert sein.
Direkte Wege
normale Freigaben, Anmeldungen, Transaktionen oder Statusänderungen
Seltene Wege
Break-glass, Support, Wartung, Recovery oder Sonderfreigaben
Zeitversetzte Wege
Jobs, Queues, Scheduler, später synchronisierte Zustände
Verdeckte Wege
Service Accounts, Providerdefaults, Shadow Identities, versteckte Konfiguration oder Code-Logik
Scope Discovery hilft, solche Wege über sichtbare Wirkungsanker zu finden. Es ist aber eine Methode und keine automatische Garantie, dass bereits alles entdeckt wurde.
Scope Closure gilt für einen Zustand zu einem Zeitpunkt T. Neue oder geänderte Wirkungswege erzeugen eine neue Gültigkeitsfrage und müssen revalidiert werden.
Ein ungebundener effect-relevanter Pfad ist kein akzeptierter Rest innerhalb eines grünen Claims. Er ist ein Claim-Problem.
5 · DRITTSYSTEME UND BLACKBOXES
Das andere System muss SES weder unterstützen noch selbst wissen, wie deine SES-Maschine aufgebaut ist.
SES nutzt keine Schnittstelle mit dem Drittsystem als SES-Regel- oder Kooperationsmechanismus. SEBG verarbeitet innerhalb der Betreiberordnung ausschließlich den Input aus dem Drittsystem und den Output an das Drittsystem hinsichtlich ihrer Bedeutung für die eigene Wirkung.
Drittsystem / Provider / Blackbox
liefert Input · empfängt Output · kann technisch ausführen
→
Betreiberordnung
bindet die Bedeutung für gültige Wirkung; der Souverän bleibt Regelquelle
Der Anbieter darf liefern, rechnen, speichern oder technisch ausführen. Dadurch erhält er keine normative Authority über die SES-Maschine.
Auch ein Blackbox-Ergebnis bleibt Input: Ein Score, eine Empfehlung, ein Status oder ein KI-Output wird nicht allein durch seine Herkunft zum gültigen Judgment.
Ein Drittsystem kann aus anderen Umständen wissen oder vermuten, dass SES eingesetzt wird. Der normale Input/Output enthält aber keinen notwendigen SES-spezifischen Nachweis.
SEBG behauptet nicht, das Drittsystem physisch zu kontrollieren. Entscheidend ist, ob dessen effect-relevanter Input innerhalb des beanspruchten Wirkungsraums gültige Wirkung erzeugen darf.
6 · NO EVIDENCE, NO VALID SEBG EFFECT
SEBG-Evidence soll nicht nur zeigen, dass etwas passiert ist, sondern warum es zählen durfte.
Für einen gültigen SEBG-Effekt muss ein Decision-State-Evidence Record entstehen. Fehlt dieser gebundene Nachweis, kann der technische Vorgang trotzdem stattgefunden haben – er entfaltet aber innerhalb des beanspruchten SEBG-Scopes keinen gültigen SEBG-Effekt.
Kein Decision-State-Evidence Record → kein gültiger SEBG-Effekt
Objekt + vorheriger State
Kontext + Authority + Regel
Judgment + Konsequenz
Folgezustand + gebundener Nachweis
Ein Log oder Audit-Trail allein reicht deshalb nicht. Evidence muss die Beziehung zwischen Objekt, vorherigem Zustand, Kontext, Authority, Regelbasis, Entscheidung, Konsequenz und Folgezustand rekonstruierbar machen.
Evidence-Integrität ist trotzdem nicht Wahrheit. Ein unverändert gebundener falscher Input bleibt ein falscher Input. Provenance, Vertrauen in die Quelle und semantische Gültigkeit müssen getrennt behandelt werden.
Die Evidence Chain ist selbst ein effect-relevantes und schutzbedürftiges Objekt. Zugriff, Aufbewahrung, Offenlegung, Löschung und Integritätsbruch müssen ebenfalls geregelt sein.
7 · WAS DIE GEBUNDENE BASELINE DANACH ERMÖGLICHT
Erst die gebundene Wirkungsrealität macht spätere Veränderungen belastbar prüfbar.
Replay
Historische Wirkungsverläufe können nicht-produktiv erneut ausgewertet werden.
Simulation und Rule Dry Runs
Neue Regeln können gegen gebundene historische Wirkung getestet werden, ohne dadurch still produktive Wirkung zu erzeugen.
Migration
Ein Systemwechsel kann als kontrollierte Veränderung von Wirkung, Authority und Zuständen betrachtet werden statt nur als Datentransport.
Login- und Authority-Kontinuität
Identität, Rollen, Delegation und Authority-Kontext können als Wirkungsfortsetzung geprüft werden.
Spätere Domain-Maschinen
Die Baseline liefert die beobachtete und gebundene Ausgangslage, auf der zusätzliche fachliche SES-Regeln entstehen können.
Replay, Simulation und Analyse dürfen in der Baseline nicht still selbst Regeln aktivieren oder produktive Wirkung erzeugen.
8 · DANACH ENTSCHEIDET DER SOUVERÄN
Nicht jeder Sachbereich muss nach der Baseline zusätzliche Regeln erhalten.
Wenn die reale Wirkungsordnung sichtbar und gebunden ist, entscheidet ausschließlich die gebundene Regelquelle der konkreten Betreiberinstanz, was in jedem relevanten Bereich künftig gelten soll.
Zusätzliche fachliche Regeln
Für diesen Bereich werden konkrete zusätzliche Regeln, Konsequenzen, Zustände und Evidence-Anforderungen gebunden.
BASELINE-ONLY
Der Bereich bleibt bewusst unter `allow-as-before` gebunden, ohne zusätzliche domänenspezifische Regelung.
NOT_CLAIMED
Der Bereich liegt ausdrücklich außerhalb des Gültigkeitsclaims dieser konkreten Maschine.
BASELINE-ONLY ≠ ungeregelt ≠ NOT_CLAIMED.
In der SEBG-Baseline können weitergehende Konsequenzkandidaten erfasst oder simuliert werden. Sie werden dadurch nicht automatisch produktiv als neue fachliche Sanktionen ausgeführt.
9 · NICHTTECHNISCHE WIRKUNG
Der Wert einer Baseline liegt nicht nur in Architektur und Technik.
SEBG macht sichtbar, was der Betreiber tatsächlich verantwortet und wodurch diese Wirkung organisatorisch zustande kommt. Daraus können fachliche, organisatorische, Audit- und wirtschaftliche Konsequenzen entstehen.
Verantwortung
Wirkung wird sichtbarer, zurechenbarer und regelbar. Das kann die Ausübung organisatorischer Verantwortung unterstützen, schafft aber nicht automatisch Compliance oder Haftungsfreiheit.
Proportionalität
Ob eine SEBG-Baseline sinnvoll ist, hängt vom konkreten Wirkungsraum ab: Kritikalität, mögliche Schäden, Provider-/SaaS-Abhängigkeiten, Blackboxes, Auditdruck, Migrationsrisiken und manuelle Kontrollkosten können relevant sein.
Audit-Evidence-by-Design
Nachweise entstehen näher am Wirkungsweg. Externe Audits verschwinden dadurch nicht automatisch, aber die nachträgliche Rekonstruktion kann sich verändern.
Kompensationsprozesse
Manuelle Evidence-Sammlung, Kontrolllisten, reine Nachweisprozesse oder nachgelagerte Reporting-Schichten können Reduktionspotenzial haben – aber nur, wenn der Betreiber sie tatsächlich ersetzt oder beendet.
SEBG garantiert keine Kostensenkung und keinen Break-even. Wirtschaftlicher Nutzen ist eine konkrete Betreiberfrage, keine C0-Gültigkeitsaussage.
Ältere wirtschaftliche Premissen aus dem C0-Quelltext – insbesondere konkrete Preisannahmen oder Connector-Sprache – werden auf dieser Website nicht als aktuelle kommerzielle Aussage übernommen. Solche Angaben benötigen eine separate aktuelle Freigabe.
10 · WER BILDET UND PRÜFT DIE KONKRETE SEBG-MASCHINE?
Die Baseline ist eine Maschinenordnung des Betreibers – kein Implementierungsprojekt, das der Programmierer fachlich vervollständigt.
Souverän / Fachverantwortung
Bestimmt den beanspruchten Wirkungsraum, die Regelquelle und welche Bereiche später zusätzlich geregelt oder bewusst Baseline-only bleiben.
Quality · Process · Systems Engineering
Schließt Scope, Authority, Regeln, State, Evidence, Failure, No-bypass und Revalidation zur eindeutigen Maschinenordnung.
Domain / Operations / Audit / Risk / Safety / Legal
Prüft die fachlich relevanten Bedingungen des konkreten Wirkungsraums.
Technical Carrier Engineering
Setzt die bereits geschlossene Maschinenordnung technisch um. Fehlende normative Entscheidungen dürfen nicht durch Implementierungsdefaults ersetzt werden.
Wenn der Implementer entscheiden muss, was eine fehlende Regel bedeutet, ist die SEBG-Maschine noch nicht bereit zur technischen Umsetzung.
11 · WAS DIESE ÖFFENTLICHE C0-ARCHITEKTUR BEWEIST – UND WAS NICHT
C0 beschreibt den Maschinentyp. Die konkrete Gültigkeit entsteht erst in der Betreiberinstanz.
Die öffentliche SEBG-C0 beschreibt die Maschinenarchitektur und ihre Claim-Grenzen. Sie ist keine ausgelieferte Maschine, keine Kundeninstanz und kein Aktivierungsnachweis.
C0
Maschinenarchitektur beschrieben
C1
für die konkrete Maschine notwendige Artefakte geschlossen
C2
geschlossene Artefakte zur konkreten Maschinenordnung gebunden
C3
Aktivierungsbereitschaft der konkreten Instanz bewiesen
C4
konkrete Instanz produktiv aktiviert
Die SEBG-Maschine eines anderen Betreibers ist kein übertragbarer PASS für deine eigene Instanz.
Eine produktive Betreiberinstanz muss nicht veröffentlicht werden. Ihre konkrete Wirkungsordnung kann betriebliches Know-how offenlegen.
12 · VERÖFFENTLICHUNG UND INTEGRITÄT
Versions- und Integritätsdaten gehören zur Publikationsprüfung – nicht zur Erklärung des Maschinentyps.
Die interne Quellprüfung für diese A6-Seite ist an die kanonische SEBG-C0-Quelle gebunden. Die öffentliche Website soll Version, CID sowie MD/PDF/quality.json/SHA jedoch erst anzeigen, wenn diese Veröffentlichung im separaten A7-Publikationsschritt vollständig gebunden und validiert wurde.
A7_PUBLICATION_BINDING_PENDING
Bis dahin erzeugt diese Detailseite ausdrücklich keinen aktuellen CID-, Release- oder Publikationsvollständigkeitsclaim.
13 · SEBG IN SECHS SÄTZEN
Wenn diese Aussagen sitzen, ist die Baseline richtig verstanden.
- SEBG ist eine Baseline-Maschinenarchitektur für bestehende digitale Wirkungsräume – keine Software und kein IT-Scanner.
- TBYD empfiehlt SEBG als Ausgangsbasis, SES selbst schreibt diesen Startweg nicht für jede Maschine vor.
- `allow-as-before` lässt bestehende fachliche Wirkung zunächst weiterlaufen und bindet sie gleichzeitig an die SES-Entscheidungs- und Evidence-Ordnung.
- Scope umfasst jeden effect-relevanten technischen, menschlichen, organisatorischen und prozessualen Weg des beanspruchten Wirkungsraums.
- Ein Provider, eine KI oder ein Blackbox-System liefert Input oder technische Leistung; das macht es nicht zum Souverän oder zum gültigen Judgment.
- Nach der Baseline entscheidet der Souverän, welche Bereiche zusätzliche Fachregeln erhalten, Baseline-only bleiben oder ausdrücklich NOT_CLAIMED sind.
14 · DEIN NÄCHSTER ARBEITSWEG
Von der Referenzarchitektur geht es jetzt zu deiner eigenen Wirkungsrealität – nicht zu einer Installation.
Anwenden
Den eigenen Wirkungsraum bestimmen, Baseline bilden und danach Sachbereiche bewusst weiterregeln oder Baseline-only lassen.
Zum Anwendungsweg →Prüfen
Scope-, Regelvollständigkeits- und Maschinenbildungs-Artefakte für Quality, Process, Systems und Assurance verwenden.
Zu Prüfen →Zurück zu Maschinen
Andere öffentliche Maschinentyp-Architekturen nach Wirkungsproblem ansehen.
Zum Maschinenkatalog →Baseline mit geringem Eingriff — danach Rule Laboratory
SEBG verwendet im Baseline-Betrieb die aktive Regel allow-as-before. Bestehende operative Effekte laufen zunächst weiter. Gleichzeitig werden wirkungsrelevante Interaktionen im beanspruchten Scope an Intake, Scope, Autorität, Baseline-Regel, formale Entscheidung, Zustand, Evidenz und Revalidierung gebunden.
Eine SEBG-Baseline ist kein klassisches Software-Transformationsprojekt. Sie ersetzt die bestehende Systemlandschaft nicht, sondern bindet deren tatsächliche Wirkungen. Dadurch kann ein kleines qualifiziertes Team die Baseline in geeigneten Instanzen mit vergleichsweise geringem Eingriff und in kurzer Zeit bilden. Die konkrete Dauer und der konkrete Aufwand bleiben instanzabhängig und werden insbesondere durch Scope, Zahl und Komplexität wirkungsrelevanter Pfade, Evidenzlage und notwendige Schließung bestimmt.
Der Punkt ist nicht, dass jede Umgebung „schnell“ oder mit einer festen Teamgröße geschlossen werden kann. Der Punkt ist: Die Baseline verlangt keine pauschale Neuimplementierung der gesamten IT-Landschaft. Bestehende operative Wirkung läuft unter allow-as-before weiter, während ihre Wirkungspfade gebunden werden.
Mit der geschlossenen Decision-State-Evidence-Kette verändert sich anschließend auch die Geschwindigkeit weiterer Veränderungen. Die gebundene Instanzrealität trägt Replay, Simulation, Regeldesign, Policy-Dry-Runs, Rule-Impact-Assessment und Migrationsplanung.
Neue oder geänderte Regeln können im Rule Laboratory gegen die tatsächlich gebundene Wirkungsrealität geprüft werden, bevor der Souverän sie aktiviert. Damit muss eine Regeländerung nicht automatisch bei der Rekonstruktion der Ausgangsrealität beginnen und nicht automatisch zu einem klassischen Software-Änderungsprojekt werden. Ob technische Trägeränderungen zusätzlich erforderlich sind, bleibt regel- und instanzabhängig.
Mechanismus: bestehende Wirkungsrealität → SEBG-Baseline → Evidence Chain → Rule Laboratory → Regeln prüfen/erweitern → Souverän aktiviert → Wirkung verändern.
Evidenzintegrität ist dabei nicht semantische Wahrheit. Ein korrekt signierter oder gehashter falscher Eingang bleibt falsch. Evidenz erzeugt auch keine normative Autorität.
Weiterführende Architektur
SES–SEBG–SEEM bleibt eine weiterführende Architektur für passende Anwendungsfälle. Es ist kein verpflichtender Pfad jeder SES-Maschine.