Serverless Onboarding: von der bestehenden Institution zur kontrollierten Ausführungsgrenze.
Die Serverless Edition ist darauf ausgelegt, bestehende institutionelle Systeme zu ergänzen, nicht sie pauschal zu ersetzen. Das Onboarding beginnt deshalb nicht mit einem neuen Frontend, sondern mit der Frage, welche konkrete Wirkung geschützt werden soll und an welcher technischen Stelle ein BLOCK diese Wirkung tatsächlich verhindern muss.
Nicht das Dashboard wird integriert. Die Ausführungsgrenze wird definiert.
Jeder Schritt erzeugt konkrete technische und institutionelle Abnahmekriterien. Dadurch wird früh sichtbar, ob ein Vorgang wirklich kontrollierbar ist oder ob der Zielprozess über nicht inventarisierte Bypass-Pfade weiterhin Wirkung erzeugen könnte.
Protected Actions definieren
Zahlungen, Freigaben, AI-Aktionen, Registeränderungen, Datenübertragungen oder andere folgenrelevante Vorgänge werden inventarisiert. Entscheidend ist, welche Handlung institutionell kontrolliert werden muss.
Authority-Quellen modellieren
Es wird festgelegt, welche Mandate, Rollen, Vollmachten, institutionellen Zuständigkeiten oder externen Autoritätsquellen für die jeweilige Handlung relevant sind. Eine technische Rolle wird dabei nicht automatisch als Authority behandelt.
Daten und Nachweise anbinden
Interne Systeme, Register, APIs, Dokumente, strukturierte Exporte und externe Quellen werden dem jeweiligen Prüfkontext zugeordnet. Für jede Quelle müssen Aktualität, Provenienz und Verhalten bei Ausfall definiert sein.
Jurisdiktionen und Rule Domains aktivieren
Für die geschützten Handlungen wird bestimmt, welche Rechtsräume und sektoralen Kontrollfamilien greifen. Dadurch werden fachliche Gates nicht pauschal, sondern kontextabhängig aktiviert.
Point of Effect verbinden
Die Serverless Edition wird technisch an den realen Wirkungspunkt gekoppelt: zum Beispiel an Payment Execution, Freigabe, Registry Commit, Agent Action oder einen anderen geschützten Effekt. Nur dort kann ein BLOCK tatsächlich präventiv wirken.
Adversarial Acceptance testen
Vor dem Go-live werden positive und negative Fälle geprüft: Widerruf, Stale Data, Source Outage, Replay, parallele Requests, Cross-Gate-Konflikte und privilegierte Manipulationsversuche.
Evidence und Betrieb etablieren
Receipts, Aufbewahrung, Schlüsselmanagement, Regeländerungen, Monitoring und unabhängige Verifikation werden in den Betriebsprozess überführt. Das Ergebnis ist kein Projektstatus, sondern ein dauerhaft kontrollierter Ausführungspfad.
Bestehende Systeme bleiben bestehen. Die Kontrollgrenze wird dort ergänzt, wo sie gebraucht wird.
Institutionen können unterschiedliche Integrationsformen kombinieren. Entscheidend ist, dass die gewählte Form die geschützte Wirkung tatsächlich kontrolliert und die für den Entscheidungszustand relevanten Daten zuverlässig verfügbar macht.
API / Request-Response
Bestehende Anwendung ruft die Serverless Edition unmittelbar vor einer geschützten Aktion auf.
Workflow / Platform Hook
Ein vorhandener Prozess bindet die Ausführungsentscheidung an einen definierten Freigabe- oder Commit-Punkt.
Event Pipeline
Relevante Zustandsänderungen werden als Events eingespeist und können bestehende Execution Rights neu bewerten.
AI / Agent Interlock
Ein Agent darf Aktionen vorschlagen; die institutionelle Authority wird außerhalb des Modells aufgelöst und geprüft.
Data & File Intake
JSON, XML, CSV, XLSX, PDF und strukturierte Systemexporte können als Ausgangsdaten in kontrollierte Prüfpfade überführt werden.