Modellintention ist keine Authority
Ein Agent darf planen und Tools anfordern. Die Ausführungsberechtigung bleibt außerhalb des Modells.
INSTITUTIONAL TRUST INFRASTRUCTURE · IMMO.QUICK SERVERLESS EDITION
Ausführungsrechte prüfen. Wirkung kontrollieren.
Die immo.quick Serverless Edition ist eine eigenständige Infrastruktur für institutionelle Ausführungsrechte. Bevor eine geschützte Handlung wirksam wird, führt sie Befugnis, Regelstand, Rechtsraum, Zweck, Zeit und verbindliche Abhängigkeiten zusammen. Erst ein gültiges Execution Right kann die Grundlage für eine eng begrenzte Capability bilden; deren Gültigkeit wird unmittelbar vor der Ausführung erneut geprüft.
HARTE SYSTEMREGEL
NO VALID EXECUTION RIGHT.NO CAPABILITY.
NO EXECUTION.
Determination ist nicht Authorization. Admin ist nicht Authority. Break Glass ist kein Bypass. Simulation ist nicht Production.
Die Serverless Edition wird als institutionelle Kontrollschicht in bestehende Systeme, Workflows, Plattformen und Agenten eingebunden.
Serverless Edition erklärt
Die Serverless Edition fügt bestehenden Systemen eine kontrollierte Ausführungsgrenze hinzu, ohne deren fachliche Funktion zu ersetzen.
Banking-Anwendungen, Enterprise-Plattformen, AI-Agenten, Workflows oder operative Systeme können technisch bereits handeln. Die Serverless Edition übernimmt nicht deren fachliche Logik. Sie prüft vor einer geschützten Wirkung, ob die für genau diese Handlung erforderlichen institutionellen Bedingungen aktuell erfüllt sind.
Der Anschluss kann über API, Workflow Hook, Event-Pipeline, AI-Agent-Interlock oder strukturierte Daten- und Dateieinspeisung erfolgen. Entscheidend ist, dass die Serverless Edition am tatsächlichen Point of Effect wirksam angebunden ist und ein BLOCK nicht durch einen alternativen technischen Pfad umgangen werden kann.
SERVERLESS EDITION · EXECUTION RIGHTS INFRASTRUCTURE
Serverless kontrolliert nicht nur den Zugang. Es kontrolliert den Übergang zur Wirkung.
Die Serverless Edition ist hardwareunabhängig. Ihre primäre Sicherheitsgrenze entsteht aus aktuellen Execution Rights, eng gebundenen Capabilities, Point-of-Effect-Revalidation und forensischer Evidence.
01 · REQUESTAktion wird angefordert
Actor, Action, Resource und Purpose werden explizit bestimmt.
02 · AUTHORITYQuelle prüfen
Authority muss legitim, aktiv, scope-gebunden und nachvollziehbar originiert sein.
03 · CLOSUREPflichtdomänen schließen
Rule, Jurisdiction, Time, Purpose, Dependencies und weitere Pflichtdomänen müssen zusammenpassen.
04 · CAPABILITYRecht technisch binden
Capability ist enger als das Recht, zeitlich begrenzt und nicht frei wiederverwendbar.
05 · EFFECTNoch einmal prüfen
Vor produktiver Wirkung wird der aktuelle Authority- und State-Stand erneut validiert.
06 · RECEIPTEntscheidung rekonstruierbar machen
Evidence bindet, was erlaubt oder blockiert wurde und auf welchem aktuellen Zustand dies beruhte.
Erreichbarkeit ist keine Permission
API, Fahrzeug, Endpoint oder Dienst kann erreichbar sein und trotzdem am Point of Effect blockiert werden.
Historische Freigabe reicht nicht
Ändern sich Mandat, Jurisdiktion, Widerruf oder Dependency, muss die Wirkung neu bewertet werden.
SICHERHEITSGRENZE · ARCHITEKTUR VOR REAKTION
ZWEI SICHERHEITSGRENZEN. VOR DEM EINTRITT. VOR DEM EFFEKT.
immo.quick trennt Zugang von Ausführungsautorität. Ein Request muss zuerst die jeweilige Eintrittsgrenze passieren; selbst erfolgreicher Zugang autorisiert noch keinen produktiven Effekt.
01 · COREAdmission Boundary
Core setzt einen fail-closed Access Guardian vor die Governance- und Compliance-Pipeline. Scheitert eine erforderliche Validierungsbedingung, erreicht der Request die nachgelagerte Governance-Logik nicht.
02 · SERVERLESSEdge Client Attestation
Die Serverless Edition verlangt bereits am Edge eine gültige Attestation eines registrierten Clients, bevor der Request den nachgelagerten Gate-Pfad erreicht.
03 · ERIExecution Boundary
Zugang ist keine Autorität. Ein produktiver Effekt erfordert ein gültiges, aktuelles und scope-gebundenes Execution Right sowie eine ausführbare Capability.
REQUEST→ADMISSION BOUNDARY→GOVERNED STATE→EXECUTION RIGHT→REAL EFFECT
Claim Boundary: Ausschließlich die Architektur der immo.quick Serverless Edition wurde dem BSI am 28.07.2026 nachweislich vorgelegt. Core wurde dem BSI nicht vorgelegt. Die Übergabe ist keine BSI-Prüfung, Zertifizierung, Anerkennung oder Bestätigung.
01 · KATEGORIE
Governance beginnt nicht nach der Ausführung. Sie beginnt vor der technischen Möglichkeit.
Execution Rights Infrastructure ist keine neue Bezeichnung für Monitoring. Die Kategorie definiert eine technische Grenze zwischen „Bedingungen sehen gut aus“ und „diese konkrete Aktion darf jetzt technisch ausführbar werden“.
RIGHTS BEFORE CAPABILITY
Ein positives Gate-Ergebnis reicht nicht. Erst Rights Closure kann ein gültiges Execution Right erzeugen.
CAPABILITY BEFORE EFFECT
Ein Right führt nicht direkt zu Wirkung. Es darf nur eine eng gebundene technische Capability erzeugen.
EVIDENCE AT EXECUTION
Die tatsächliche Execution wird mit Right, Capability, Surface, Zeit und Evidence verbunden.
02 · KANONISCHE KETTE
Von der Anfrage bis zur Evidence gibt es keinen stillen Sprung.
Jede Stufe hat eine andere Bedeutung. Determinations liefern Fakten über modellierte Bedingungen. Rights Closure entscheidet, ob ein Recht geschlossen werden kann. Capability macht die erlaubte Aktion technisch ausführbar. Enforcement prüft direkt an der Wirkungsgrenze.
REQUEST
→
DETERMINATIONS
→
RIGHTS CLOSURE
→
EXECUTION RIGHT
→
BOUNDED CAPABILITY
→
ENFORCEMENT
→
EXECUTION
→
EVIDENCE
03 · ERSTER BURGGRABEN
Control what may execute.
Der erste Burggraben kontrolliert die eigene produktive Umgebung. Das Ziel ist nicht nur zu prüfen, sondern capability-freie Umgehungspfade im registrierten Scope technisch zu verhindern.
RIGHTS CLOSURE
Mandatory Conditions müssen vollständig schließen. Keine Confidence Scores, kein AI Recommendation Path.
BOUNDED CAPABILITY
Subject, Action, Resource, Purpose, Scope, Environment und Validity bleiben eng gebunden.
EXECUTION SURFACE REGISTRY
Produktive API-, Event-, Queue-, Batch-, Admin-, Recovery- und Break-Glass-Pfade müssen registriert und enforced sein.
POINT-OF-EXECUTION REVALIDATION
Right, Revocation, Freshness, Context und Capability Class werden unmittelbar vor Wirkung erneut geprüft.
REPLAY RESISTANCE
Persistenter, atomarer Nonce-State verhindert Wiederverwendung und Race-Condition-basierten Doppelverbrauch.
BREAK GLASS ≠ BYPASS
Notfallausführung braucht eigene Authority, Closure, Capability und verstärkte Evidence.
04 · ZWEITER BURGGRABEN
Control what executions from others you are willing to accept.
Interoperability verschiebt Vertrauen von einer Behauptung zur unabhängigen Prüfung. Eine Gegenpartei muss nicht glauben, dass ein fremdes System autorisiert war. Sie kann den portablen Execution-Rights-Proof verifizieren und anschließend ihre eigene Acceptance Policy anwenden.
PORTABLE PROOF
→
INDEPENDENT VERIFY
→
ACCEPTANCE POLICY
→
ACCEPT / REJECT
→
ACCEPTANCE RECEIPT
NO AUTHORITY TRANSFER
Remote Acceptance erzeugt weder lokale Authority noch ein lokales Execution Right.
POLICY-SPECIFIC ACCEPTANCE
Jede Institution entscheidet nach ihrer eigenen Policy. Derselbe valide Proof kann bei A akzeptiert und bei B abgelehnt werden.
MUTUAL INTERLOCK
Für sensible Transaktionen können beide Seiten ihre Rights beweisen und die jeweils andere Seite unabhängig akzeptieren.
05 · WARUM DIE KATEGORIE FEHLTE
Die meisten Systeme kontrollieren Entscheidungen. ERI kontrolliert technische Ausführbarkeit.
Beobachten / Bewerten
- Output prüfen
- Risiko scorieren
- Warnung erzeugen
- An Menschen eskalieren
- Nach der Ausführung dokumentieren
Execution Rights Infrastructure
- Authority und Conditions vor Execution schließen
- Nur dann Capability ausstellen
- Capability direkt am Execution Surface erzwingen
- Revocation/Freshness unmittelbar berücksichtigen
- Execution Evidence an Right + Capability binden
06 · WAS ES VERHINDERT
Nicht „mehr Kontrolle“. Weniger unerlaubte technische Möglichkeit.
ADMIN WITHOUT RIGHT
Eine Admin-Rolle allein darf keine produktive Execution autorisieren.
STALE AUTHORITY
Eine ehemals gültige Authority wird nicht automatisch weiter vertraut.
WRONG SCOPE
Eine Capability für Ressource A oder Purpose X darf nicht auf Ressource B oder Purpose Y erweitert werden.
REPLAY
Eine bereits konsumierte Capability darf nicht erneut Wirkung entfalten.
ALTERNATE PATH
Ein alternativer produktiver Surface darf die zentrale Capability-Prüfung nicht umgehen.
SIMULATION ESCAPE
Counterfactuale oder simulierte Rights dürfen nie in produktive Capability Issuance gelangen.
07 · PORTABLE PROOF
Verify the right without trusting the issuer.
Portable Execution Rights Proofs machen die Bindung zwischen Right, Capability und Execution extern verifizierbar. Der aktuelle Frozen-Proof-Pfad bindet sein tatsächliches Crypto-Profil und lehnt unbekannte oder widersprüchliche Protokoll-, Schema-, Canonicalization- und Algorithmuszustände ab.
ECDSA P-256 · SHA-256 · 256-bit CSPRNG NONCE
Öffentlich verifizierbare Attribution und Integrität. Keine pauschale Behauptung universeller rechtlicher Nichtabstreitbarkeit.
FROZEN PROOF PROFILE
08 · STATE REALITY CONSISTENCY
Realität kann Ausführung invalidieren, ohne selbst Authority zu werden.
ERI-INV-017 trennt autoritativen Zustand, Beobachtung, physische Realität und Ground Truth. Für physische Dependencies müssen die geltenden Provenance-, Freshness-, Independence- und Attestation-Bedingungen am Execution Cut schließen. Unaufgelöste Divergenz führt zu DENY oder REASSESSMENT, nicht zu einer Mehrheitsentscheidung über Wahrheit.
OBSERVATION ≠ AUTHORITY
Sensorik, Monitoring oder externe Evidence kann Divergenz sichtbar machen. Sie schreibt Governance State nicht selbst um.
CONSENSUS ≠ PHYSICAL TRUTH
Mehrheit ist kein Wahrheitsbeweis. Widersprechende unabhängige Quellen erzeugen STATE_DIVERGENCE und schließen die Dependency nicht.
UNCERTAINTY → DENY
Machine Law behauptet nicht, unbeobachtete Realität zu erzeugen. Es verhindert, dass ungelöste Unsicherheit stillschweigend zu Execution Permission wird.
09 · VERIFIED PROVENANCE
Eine gültige Signatur ist noch kein vertrauenswürdiger physischer Zustand.
ERI-INV-018 macht explizit verifizierte Provenance zur Voraussetzung für Trusted Execution Evidence bei physischen Attestations. Ein vorhandener provenance_root reicht nicht. provenance_verified muss ausdrücklich true sein. false oder fehlend bedeutet PROVENANCE_INCOMPLETE und fail-closed BLOCK.
VALID SIGNATURE ≠ VERIFIED PROVENANCE ≠ TRUSTED EXECUTION EVIDENCE
Authentizität zum Schlüssel, verifizierte Herkunft und execution-relevantes Vertrauen sind drei getrennte Aussagen.
FAIL CLOSED
10 · EVIDENCE
Die Architektur ist eingefroren. Die Testaussagen bleiben scope-genau.
113/113Execution Rights Conformance V2 · PASS
37/37Freeze Hardening · PASS
15/15Interoperability Conformance · PASS
16 + 2State-Reality Baseline + Provenance-Negativfälle · interne Verifikation
GLOBAL ENFORCEMENT MATRIX V3
0 detektierte erfolgreiche Bypass-Pfade im getesteten Scope. Das ist interne Implementierungsevidenz, keine Behauptung globaler Unumgehbarkeit oder Drittzertifizierung.
TESTED SCOPE
11 · EINSATZ
Überall dort, wo Software nicht nur entscheiden, sondern Wirkung erzeugen kann.
AI AGENTS
Agenten können Proofs präsentieren, aber keine Authority erfinden. Aktionen bleiben an verifizierbare Rights und lokale Acceptance gebunden.
PAYMENTS & TREASURY
Kritische Transfers können an konkrete Rights, Scope, Purpose, Capability und Execution Evidence gebunden werden.
CRITICAL APIs
API-, Queue-, Webhook- und Service-Aufrufe können vor Wirkung capability-pflichtig gemacht werden.
ADMIN & RECOVERY
Admin-, Recovery- und Emergency-Pfade bleiben innerhalb derselben Rights-Verfassung.
CROSS-INSTITUTION B2B
Counterparties können portable Rights Proofs unabhängig prüfen und eigene Acceptance Policies anwenden.
PUBLIC SECTOR
Ausführungsrechte für hochkritische Verwaltungs-, Register- oder Infrastrukturaktionen können vor der Wirkung gebunden werden.
12 · CLAIM BOUNDARIES
Die Maschine darf nur behaupten, was ihre gebundene Evidenz tatsächlich trägt.
DETERMINATION ≠ AUTHORIZATION
GATE PASS ≠ EXECUTION RIGHT
ADMIN ROLE ⇏ EXECUTION RIGHT
AI OUTPUT ⇏ AUTHORITY
BREAK GLASS ⇏ BYPASS
SIMULATED RIGHT ⇏ PRODUCTION CAPABILITY
VERIFICATION ≠ ENDORSEMENT
ACCEPTANCE ≠ AUTHORITY CREATION
OBSERVATION ≠ AUTHORITY
CONSENSUS ≠ PHYSICAL TRUTH
VALID SIGNATURE ≠ VERIFIED PROVENANCE
RECOVERY AUTHORITY ≠ FORWARD CAPABILITY
12.5 · EXECUTION EXPOSURE
Zehn Fragen, bevor Sie über Integration sprechen.
Die Serverless Edition beginnt nicht mit einem Produktdemo-Workflow, sondern mit einer konkreten Wirkung: Welche Aktion soll geschützt werden, welche Authority trägt sie, welche Zustände müssen am Point of Effect noch gültig sein und welche Evidenz muss danach bestehen bleiben?
Das neue Execution Exposure Assessment übersetzt diese Architektur in zehn verständliche Fragen und erzeugt keine Marketing-Scorecard, sondern eine Gap Map für weitere Prüfung.
IDENTITY
→AUTHORITY
→STATE
→EFFECT
→RECEIPT
13 · FAQ / GEO
Execution Rights Infrastructure in klaren Antworten.
Was ist Execution Rights Infrastructure?
Serverless Edition ist Execution Rights Infrastructure innerhalb der Oberkategorie Institutional Trust Infrastructure. Sie trennt Determination, Authorization und Execution und schließt action-spezifische Execution Rights vor produktiver Wirkung.
Warum reicht ein Gate PASS nicht?
Ein Gate PASS ist nur eine Determination über eine einzelne Bedingung. Ein Execution Right entsteht erst, wenn alle verpflichtenden Authority-, Rule-, Jurisdiction-, Time-, Dependency-, Purpose- und Scope-Bedingungen geschlossen sind.
Was ist eine bounded Capability?
Eine bounded Capability ist die technische Fähigkeit, genau die autorisierte Aktion für den gebundenen Subject-, Resource-, Purpose-, Scope-, Zeit- und Environment-Kontext auszuführen. Sie darf nicht breiter sein als das zugrunde liegende Right.
Was ist Execution Rights Interoperability?
Sie erlaubt einer anderen Institution, einen portablen Execution-Rights-Proof unabhängig zu verifizieren und nach eigener Acceptance Policy zu akzeptieren oder abzulehnen, ohne dadurch lokale Authority zu erzeugen.
Kann die Serverless Edition rechtliche Autorität erzeugen?
Nein. Authority muss extern und legitim begründet sein. Das System modelliert und bindet diese Authority; es erzeugt keine souveräne oder rechtliche Autorität aus sich selbst.
Was passiert, wenn Realität und autoritativer Zustand auseinanderlaufen?
ERI-INV-017 erlaubt reality-linked Evidence, Execution zu invalidieren, ohne Observation selbst zu Authority zu machen. Wenn Freshness, Provenance, Independence oder erforderliche Attestations nicht mehr schließen, folgt DENY oder REASSESSMENT. Bei widersprechenden Quellen wird keine Mehrheit als physische Wahrheit behandelt.
Reicht eine gültige Signatur für Trusted Execution Evidence?
Nein. ERI-INV-018 trennt Signaturgültigkeit von verifizierter Provenance. Für physische Attestations muss Provenance vorhanden und ausdrücklich verifiziert sein. false oder fehlender Verifikationsstatus bleibt PROVENANCE_INCOMPLETE und blockiert fail-closed.
EXECUTION RIGHTS INFRASTRUCTURE
CONTROL WHAT MAY EXECUTE. PROVE WHY IT WAS ALLOWED.
Und wenn eine andere Institution beteiligt ist: Control what executions from others you are willing to accept.
CYBERSECURITY · ZWEI GRENZEN
DENY ENTRY. DENY EFFECT.
Warum unzulässiger Eintritt und unzulässige Wirkung zwei getrennte, fail-closed Sicherheitsgrenzen brauchen.
STATE-REALITY ASSURANCE · UNIVERSAL PRE-AUTHORITY BOUNDARY
Nur weil das System etwas sieht, darf es noch lange nichts tun.
SRA trennt Runtime und beobachtete Realität von Authority und Execution. 20 formale Invarianten, eine nicht-kompensierbare Schwellenwert-Engine und 46/46 modellierte Szenarien mit erwartetem Outcome. Reality darf Authority informieren. Sie darf sie niemals erzeugen.
TENANT OPERATING MODEL · FINALIZED
Finalisiertes Tenant Operating Model
30 zentrale Actions. Attention-First. File-First Intake. Berechtigungen, Entscheidungen, Belege und Integrationen in einer gemeinsamen Bedienlogik – bei unveränderter Authority-Grenze.
Was ein Nachweis tatsächlich belegt
Ein Receipt dokumentiert einen bestimmten Zustand oder Vorgang. Für die Beurteilung zählt deshalb nicht nur, ob seine Integrität überprüfbar ist, sondern welches Ereignis es bindet und welche Quellen, Regeln und Ausführungsdaten vorliegen.
Prüfergebnis
Ein Gate stellt fest, ob seine formal definierten Bedingungen erfüllt sind. Ein PASS erteilt für sich allein kein Ausführungsrecht.
Execution Right
Befugnis, Regelstand, Rechtsraum, Zeit und verpflichtende Abhängigkeiten müssen für die konkrete Handlung zusammenpassen.
Capability
Eine eng gebundene technische Berechtigung kann aus einem gültigen Ausführungsrecht folgen. Ihre Ausgabe belegt noch keinen Vollzug.
Tatsächlicher Effekt
Erst der dokumentierte Vollzug belegt die ausgeführte Handlung. Integrität allein garantiert weder Quellenwahrheit noch rechtliche Anerkennung.