immo.quick entscheidet nicht, ob eine Ausführung sicher aussieht. Es stellt deterministisch fest, ob überhaupt ein gültiges Recht zur Ausführung existiert.
Konventionelle Kontrollarchitekturen entscheiden, ob eine bereits vorgesehene Ausführung zugelassen oder gestoppt wird. immo.quick setzt früher an: Es stellt fest, ob überhaupt ein gültiges Recht existiert, aus dem eine ausführbare Capability entstehen darf.
Klicken Sie eine Bedingung an, um sie umzuschalten. Das Ergebnis reagiert live.
Kann eine operative Bedingung legitim beeinflussen, ob eine Ausführung stattfinden darf, ist sie eine Autorisierungsabhängigkeit. Sie erzeugt keine zweite diskretionäre Entscheidungsautorität im Ausführungszeitpunkt.
Illustratives clientseitiges Modell der Entscheidungslogik. Keine Verbindung zu Produktionsdaten oder echten Ausführungsrechten.
WARN ist eine Domain-Klassifikation, kein Ausführungszustand. Ein Gate-WARN führt nicht zu einer "vielleicht"-Ausführung. Das Execution-Right-Ergebnis bleibt binär: VALID oder ABSENT.
Ein normales System könnte sagen: „Execution denied.“ immo.quick kann fundamentaler sagen:
Es existierte kein gültiges Ausführungsrecht. Deshalb wurde keine ausführbare Capability erzeugt.
Nicht: „Wir hatten eine Transaktion und haben sie gestoppt.“ Sondern: „Die Transaktion erhielt niemals die technische Befugnis, ausführbar zu werden.“
Ein ExecutionCapabilityToken darf nicht dauerhaft ausführbar bleiben, nur weil es bei seiner Ausstellung einmal gültig war. Deshalb bindet immo.quick die Capability kryptografisch an den Authorization State, aus dem das Ausführungsrecht entstanden ist.
Die authority_provenance_hashes binden die bei der Autorisierung gültigen AuthorityCredentials an den Authorization State Root. Damit lässt sich nicht nur prüfen, welcher Zustand ein Ausführungsrecht hervorgebracht hat, sondern auch, auf welcher nachweisbaren Autoritätsprovenienz dieser Zustand beruhte.
Verliert die Autorisierungsgrundlage ihre Gültigkeit, verliert die Capability ihre Ausführbarkeit.
Ändert sich eine ausführungsrelevante Autorisierungsgrundlage, muss diese Änderung selbst auf einer gültigen Authority-Basis beruhen. Erst ein authority-bound Invalidation Record kann die Ausführbarkeit einer bestehenden Capability verändern.
Keine nachträgliche Neuinterpretation durch die Execution Plane.
Normative Mutationen benötigen eine gültige Authority-Basis. Operative execution-bearing Dependencies müssen dagegen deterministisch in den maßgeblichen Authorization State einfließen. Die Execution Plane interpretiert weder das eine noch das andere neu.
Eine Capability darf nicht durch bloßen internen Schreibzugriff invalidiert werden.
immo.quick erzeugt keine normative Autorität. Gesetz, Regulierung, Mandat, Vertrag, institutionelle Regel oder eine andere zulässige Authority Source bestimmt den normativen Zustand. Das System prüft deterministisch, ob für eine konkrete Governance-Mutation eine gültige Autoritätsgrundlage existiert.
Für eine GOVERNANCE_INVALIDATION muss deshalb ein gültiger GovernanceAuthorityProof existieren. Dieser bindet die AuthorityCredential, ihren Scope, die Governance Action, den betroffenen Authorization State Root und den maßgeblichen Wirksamkeitszustand.
KEIN GÜLTIGER GOVERNANCE AUTHORITY PROOF → KEIN INVALIDATION RECORD
Die Mutation wird nicht dadurch legitim, dass sie im System gespeichert wurde. Sie darf überhaupt erst gespeichert werden, wenn ihre normative Grundlage bereits nachgewiesen ist.
Sie prüft die Capability, ihre exakte Bindung und den für die Ausführung maßgeblichen autoritativen Ordnungszustand. Sie interpretiert dabei weder AuthorityCredentials noch Rechtsquellen. Eine bereits legitimierte Invalidation wird ausschließlich über ihren gebundenen Invalidation State und ihre autoritative Sequence berücksichtigt.
Die Execution Plane regiert nicht. Sie löst keine Autorität neu auf. Sie setzt eine bereits deterministisch etablierte Autorisierungsordnung durch.
Eine Capability kann gültig ausgestellt worden sein und trotzdem vor ihrer tatsächlichen Consumption von einer späteren gültigen Authority-Mutation betroffen sein. Deshalb verwendet immo.quick für Invalidation und Consumption eine gemeinsame monotone AuthorizationStateSequence.
Eine nach dem autoritativen Execution Cut wirksam geordnete Invalidation kann eine bereits abgeschlossene Consumption nicht rückwirkend verändern.
Historische Ausführung wird nicht neu interpretiert. Der maßgebliche Authorization State und seine autoritative Reihenfolge bleiben im Evidence Record gebunden.
Wall Clock Timing, Request Scheduling und Datenbanksichtbarkeit entscheiden damit nicht über das Authorization Outcome. Request Scheduling kann beeinflussen, welche Operation die frühere autoritative Sequence erhält. Sobald diese Ordnung jedoch feststeht, folgt das Ergebnis deterministisch aus genau dieser Ordnung.
Concurrent Invalidation und Capability Consumption werden über eine gemeinsame monotone autoritative Sequenz geordnet.
Zweiter paralleler Versuch:
Eine Capability kann dieselbe Zustandsänderung nicht zweimal autorisieren.
consumption_attempt_id
Eine Capability für 200.000 CHF → Konto B darf nicht plötzlich für 500.000 CHF → Konto C verwendet werden.
Ein übliches System: Capability wird akzeptiert, Ausführung beginnt, Zielsystem fällt aus. Was jetzt? Retry? Vielleicht ausgeführt, vielleicht nicht.
Beide Endzustände werden über die ExecutionConsumptionReceipt dokumentiert.
Die ExecutionConsumptionReceipt bindet neben dem Consumption-Ergebnis auch die maßgebliche execution_cut_sequence und den authorization_state_root. Dadurch bleibt forensisch rekonstruierbar, unter welchem autoritativen Ordnungszustand die Consumption stattfand.
KEIN MEHRDEUTIGER DRITTER ZUSTAND.
Ist der erforderliche Prerequisite Execution Proof nicht gültig geschlossen, kann das davon abhängige Ausführungsrecht nicht entstehen.
Das ist wesentlich stärker als Workflow-Orchestrierung. Es heißt nicht „Schritt 2 startet nach Schritt 1“, sondern:
Das Recht, Schritt 2 durchzuführen, existiert nicht, solange der erforderliche Ausführungsbeweis aus Schritt 1 nicht existiert.
Die Frage eines Auditors lautet sonst sofort: „Haben Sie nur diese Autorität geprüft oder alle relevanten?“ Mit Exhaustion:
Alle zulässigen Authority-Pfade innerhalb des definierten admissible authority universe wurden deterministisch aufgelöst. Null gültige Ausführungspfade existierten.
Der Sektor verändert die Regel. Die Ausführungsarchitektur ändert sich nicht.
Der aktuelle Public Evidence Record demonstriert das zugrunde liegende Prinzip der Authority Supersession und deterministischen Zero Action Enforcement. Die Execution Authorization Infrastructure v1.4.0 erweitert dieses Prinzip um explizite Execution Rights, authority-bound Invalidation und deterministische Ordnungsauflösung zwischen Authorization State Mutation und Capability Consumption.
Der Beweis bleibt unveränderlich. Die Architektur darf sich weiterentwickeln.
Wir veröffentlichen keine Behauptungen ohne Beweis. Wir veröffentlichen den Datensatz, die Grenze und den Verifier.
Wir autorisieren nicht jetzt und führen später aus. Wir lösen das Recht am Rand der Ausführung auf.