immo.quick does not decide whether an execution looks safe. It deterministically establishes whether a valid right to execute exists at all.
Conventional control architectures decide whether an already-intended execution is permitted or stopped. immo.quick starts earlier: it establishes whether a valid right exists at all, one from which an executable capability may arise.
Click a condition to toggle it. The outcome updates live.
If an operative condition can legitimately affect whether an execution may occur, it is an authorization dependency. It does not create a second, discretionary decision authority at the point of execution.
Illustrative client-side model of the decision logic. No connection to production data or real execution rights.
WARN is a domain classification, not an execution state. A gate WARN does not lead to a "maybe" execution. The execution right outcome remains binary: VALID or ABSENT.
A conventional system could say: “Execution denied.” immo.quick can say something more fundamental:
No valid execution right existed. Therefore no executable capability was created.
Not: “We had a transaction and stopped it.” Instead: “The transaction never received the technical authority to become executable.”
An ExecutionCapabilityToken must not remain executable indefinitely simply because it was valid once at issuance. That is why immo.quick cryptographically binds the capability to the authorization state from which the execution right arose.
The authority_provenance_hashes bind the AuthorityCredentials valid at the time of authorization to the Authorization State Root. This allows verification not only of which state produced an execution right, but also of the provable authority provenance that state rested on.
If the authorization basis ceases to be valid, the capability ceases to be executable.
If an execution-relevant authorization basis changes, that change must itself rest on a valid authority basis. Only an authority-bound invalidation record can change the executability of an existing capability.
No retrospective reinterpretation by the execution plane.
Normative mutations require a valid authority basis. Operative execution-bearing dependencies, by contrast, must flow deterministically into the relevant authorization state. The execution plane reinterprets neither.
A capability must not be invalidated by a mere internal write access.
immo.quick does not create normative authority. Law, regulation, mandate, contract, institutional rule or another admissible authority source determines the normative state. The system deterministically checks whether a valid authority basis exists for a specific governance mutation.
A GOVERNANCE_INVALIDATION therefore requires a valid GovernanceAuthorityProof. It binds the AuthorityCredential, its scope, the governance action, the affected Authorization State Root and the relevant state of effect.
NO VALID GOVERNANCE AUTHORITY PROOF → NO INVALIDATION RECORD
A mutation does not become legitimate by being stored in the system. It may only be stored once its normative basis has already been proven.
It verifies the capability, its exact binding and the authoritative ordering state relevant to execution. It interprets neither AuthorityCredentials nor sources of law. An already legitimized invalidation is considered only through its bound invalidation state and its authoritative sequence.
The execution plane does not govern. It does not re-resolve authority. It enforces an authorization order already established deterministically.
A capability may have been validly issued and still be affected by a later valid authority mutation before its actual consumption. That is why immo.quick uses a shared monotone AuthorizationStateSequence for both invalidation and consumption.
An invalidation ordered as effective after the authoritative execution cut cannot retroactively change an already completed consumption.
Historical execution is not reinterpreted. The relevant authorization state and its authoritative order remain bound within the evidence record.
Wall clock timing, request scheduling and database visibility therefore do not decide the authorization outcome. Request scheduling can influence which operation receives the earlier authoritative sequence. Once that order is fixed, however, the outcome follows deterministically from exactly that order.
Concurrent invalidation and capability consumption are ordered through a shared monotone authoritative sequence.
Second parallel attempt:
A capability cannot authorize the same state change twice.
consumption_attempt_id
A capability for 200,000 CHF → Account B must not suddenly be usable for 500,000 CHF → Account C.
A typical system: capability accepted, execution begins, target system fails. What now? Retry? Maybe executed, maybe not.
Both end states are documented through the ExecutionConsumptionReceipt.
Beyond the consumption outcome, the ExecutionConsumptionReceipt also binds the relevant execution_cut_sequence and the authorization_state_root. This keeps it forensically reconstructible under which authoritative ordering state the consumption took place.
NO AMBIGUOUS THIRD STATE.
If the required prerequisite execution proof is not validly closed, the dependent execution right cannot come into existence.
This is substantially stronger than workflow orchestration. It does not say “Step 2 starts after Step 1.” It says:
The right to perform Step 2 does not exist unless the required execution evidence from Step 1 exists.
Otherwise an auditor's first question is: “Did you check only this authority, or all relevant ones?” With exhaustion:
All admissible authority paths within the defined admissible authority universe were deterministically resolved. Zero valid execution paths existed.
The sector changes the rule. The execution architecture does not change.
The current Public Evidence Record demonstrates the underlying principle of authority supersession and deterministic zero-action enforcement. Execution Authorization Infrastructure v1.4.0 extends that principle with explicit execution rights, authority-bound invalidation and deterministic ordering resolution between authorization state mutation and capability consumption.
The evidence remains immutable. The architecture may evolve.
We do not publish claims without evidence. We publish the record, the boundary and the verifier.
We do not authorize now and execute later. We resolve the right at the edge of execution.