RIGHTS BEFORE CAPABILITY
Ein positives Gate-Ergebnis reicht nicht. Erst Rights Closure kann ein gültiges Execution Right erzeugen.
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.
INSTITUTIONAL TRUST INFRASTRUCTURE · IMMO.QUICK SERVERLESS EDITION
BEVOR EIN SYSTEM AUSFÜHRT, MUSS EIN GÜLTIGES EXECUTION RIGHT EXISTIEREN.
immo.quick Serverless Edition ist eine eigenständige Infrastrukturklasse innerhalb der Oberkategorie Institutional Trust Infrastructure: Execution Rights Infrastructure. Sie bestimmt vor produktiver Wirkung, ob Authority, Rule State, Jurisdiction, Purpose, Time, Dependencies und Scope zu einem gültigen Execution Right schließen und ob daraus eine eng gebundene technische Capability folgen darf.
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.
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“.
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
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.