Logs, Reports und Telemetrie machen Aktivität sichtbar. Sichtbarkeit ist wertvoll, erzeugt oder entzieht aber keine Ausführungsberechtigung.
Observation zeigt einer Institution, was passiert ist. Prediction schätzt, was passieren könnte. Intervention verändert eine bereits laufende Trajektorie. Machine Law stellt davor eine eigenständige Kontrollfrage, bevor eine begrenzte Capability entstehen kann: Existiert für genau diese Handlung jetzt ein gültiges Execution Right?
Logs, Reports und Telemetrie machen Aktivität sichtbar. Sichtbarkeit ist wertvoll, erzeugt oder entzieht aber keine Ausführungsberechtigung.
Modelle können Risiko, Drift oder Konsequenzen schätzen. Wahrscheinlichkeit kann eine Determination informieren, ist aber keine institutionelle Autorität.
Eskalation, Pause und Override können Governability erhalten. Ein Interventionsrecht ist dennoch nicht dasselbe wie das Recht hinter der ursprünglichen Ausführung.
Machine Law schließt den relevanten Autoritätszustand für die konkrete Handlung. Fehlt eine erforderliche Closure, soll im governeden Ausführungspfad keine gültige begrenzte Capability folgen.
Die Execution-Rights-Architektur ist formalisiert, gehärtet und eingefroren. Rights Closure, gebundene Capabilities, registrierte Execution Surfaces, aktuelle Right-Revalidierung, Replay-Schutz, Reassessment und portable Verifikation bilden eine durchgängige fail-closed Kontrollkette.
Der zuvor offene Nonce-Reuse-Vektor wurde im zentralen produktiven Enforcement-Pfad geschlossen. Replay-Prüfung, Nonce-Verbrauch, Corruption-Verifikation, globale Conformance und Freeze-Entscheidung verwenden jetzt gebundene, fail-closed Zustände statt unabhängiger grüner Einzelanzeigen.
0 failed · nonce_reuse → EXECUTION_DENIED.
Applicable variants across 10 registered production execution surfaces.
Suites passed · overall_pass = true.
Only when control conditions and binding global conformance both pass.
Interne technische Verifikation des aktuellen implementierten Zustands. Keine Drittzertifizierung, keine Behauptung universeller Unangreifbarkeit und keine Aussage über nicht modellierte Angriffsvektoren.
FINMA, BaFin, NIST, NSA, EU und US-Regierungsstrategien konvergieren auf kontinuierliche Autorisierung, Zero Trust, Resilienz, Evidenz und durchsetzbare Grenzen. Sehen Sie, wie immo.quick diese Kontrolleigenschaften bereits auf der Execution-Rights-Ebene operationalisiert.
Ein Unternehmen kann beobachtbar, steuerbar und sogar unterbrechbar bleiben, während die Autorisierungsfrage noch ungeklärt ist. immo.quick trennt diese Ebenen, statt sie gleichzusetzen.
Die Architektur kann kodierte Regeln und autoritative Zustände verarbeiten, erforderliche Bedingungen auflösen, eine Capability an den unterstützten Autorisierungszustand binden und Evidenz innerhalb expliziter Claim Boundaries erhalten.
Institutionelle Autorität entsteht außerhalb der Maschine. Ein Gate Judgment ist kein Execution Right. Kryptografische Integrität ist kein Rechtsurteil.
Intervention kann Ausführung stoppen. Execution Rights bestimmen, ob eine gültige Capability überhaupt entstehen darf.
Wenn Agenten und automatisierte Systeme Zahlungen, regulierte Workflows, klinische Prozesse, kritische Infrastruktur und öffentlichen Vollzug berühren, ist eine nachträgliche Erklärung weniger wertvoll als eine beweisbare Grenze vor der Handlung. Die institutionelle Frage lautet nicht mehr nur, ob Software handeln kann. Sie lautet, ob Software den Autoritätszustand nachweisen kann, unter dem diese Handlung ausführbar wurde.
Verantwortung auf dem Papier von den technischen Bedingungen trennen, die eine ausführbare Capability entstehen lassen.
Autorität, Regelzustand, Dependencies und Evidenz nachvollziehen, ohne ein Modell zum souveränen Entscheider zu machen.
Fehlerhafte Ausführung kann zu Remediation, rechtlichen, operativen und bilanziellen Risiken werden. Die Due-Diligence-Frage ist, ob die Kontrollschicht strukturell, prüfbar und schwer substituierbar ist.
immo.quick behauptet nicht, dass Software rechtliche oder souveräne Autorität erzeugt. Die Architektur bindet Ausführung an extern legitime Autorität und veröffentlicht die Grenze dessen, was ihre Evidenz belegen kann.
Die Execution Rights Infrastructure wurde nicht nur auf den Happy Path geprüft. Der Audit greift gezielt Capability-Bindings, Closure, Zustandswechsel, Dependency-Graphen und Runtime-Invarianten an. Das Ziel ist nicht statistische Robustheit, sondern deterministisches Fail-Closed-Verhalten.
39/39 Tests bestanden. 0 Bypass-Pfade im getesteten Umfang erkannt. Eine Non-Spine-Capability wird mit SPINE_ISSUANCE_REQUIRED blockiert.
Manipulation von Action, Subject, Executor, Gültigkeit, State-Referenzen, Scope, max_uses, Environment oder Determination Hash → INVALID_CAPABILITY_BINDING.
4/5 geschlossene Dimensionen reichen nicht. Authority, Rule, Jurisdiction, Time und Dependencies müssen vollständig schließen. Für physische Dependencies reicht auch ein vorhandener Messwert oder eine gültige Signatur nicht automatisch aus: ERI-INV-017 und ERI-INV-018 verlangen geschlossene Reality-Consistency- und Verified-Provenance-Bedingungen. Unaufgelöste Divergenz oder nicht ausdrücklich verifizierte Provenance blockiert fail-closed.
Ändert sich Authority oder Dependency zwischen Revalidation und Execution, blockiert der Atomic Execution Check.
Die erneute Verwendung einer bereits konsumierten Capability wird deterministisch erkannt und blockiert.
Orphan Nodes, Missing Edges, Circular Dependencies und stale Nodes werden als ungültiger Dependency-Graph erkannt.
Öffentliche Architektur-Claims werden gegen das tatsächliche Runtime-Verhalten geprüft.
Eine bereits gültig verwendete Capability wird erneut zur Ausführung vorgelegt. Das ist keine probabilistische Wiederholung und keine AI-Neuberechnung. Gleiche Capability + gleicher Idempotency-Key liefert denselben bereits bekannten Zustand; eine erneute Ausführungsabsicht mit abweichendem Key nach Consumption wird als REPLAY_DETECTED blockiert.
Technische Conformance-Evidenz des getesteten Systemstands. Keine Drittzertifizierung und keine Aussage absoluter Unangreifbarkeit.