Positive checking state
The record documents a substantive state, not execution permission.
Open evidence
immo.quick Serverless Edition™ · Explained simply
Before software acts, it must have the right to act.
A login, an approval or a successful check does not establish whether an action is permitted now. The immo.quick Serverless Edition™ addresses that boundary: immediately before a payment, a data transfer or another protected action. It brings the required conditions together and allows the action only through the integrated, controlled path.
Discuss a protected actionAuditor evidence pathFor auditors and supervisors
The institutional artifact chain: verify each claim separately.
A passed check is not execution permission. These six stages explain the question each artifact answers and the limit of its claim.
- 1
Domain determination
What was checked and what was the result?
- 2
Institutional reliance
May our institution rely on this record for this purpose?
- 3
Current execution right
Do authority, rules, jurisdiction, time and prerequisites hold together?
- 4
Bounded technical permission
Which precisely bounded action may the software perform?
- 5
Actual execution
What actually happened on the controlled execution path?
- 6
Evidence of effect
Which evidence binds the decision and observed effect?
Later state change
A later sanctions match changes the basis. The earlier record remains as historical evidence.
Open evidenceReliance refused
An existing record need not be sufficient for another institution’s purpose.
Open evidenceThe artifacts establish their respective states and bindings. They are not complete evidence of production execution. Historical validity does not establish present executability.
Two systems. Clear architecture boundaries.
The immo.quick Serverless Edition™ uses no Trusted Execution Environments (TEEs) and no enclaves. TEE and enclave technologies are used exclusively in immo.quick Core™. The two products are independent systems. Core™ is not a prerequisite for the Serverless Edition™.
The Serverless Edition™ checks defined conditions at the integrated execution path and records the decision in cryptographically verifiable evidence. TEE attestation is not part of its architecture. Hardware-backed isolation and enclave attestation belong to the Core™ architecture profile.
Internal verification status · 14 October 2026
From an execution right to a result read back.
An approval can have been valid and later lose its basis. In the internally tested workflow, the Serverless Edition™ binds issuance, revocation and consumption to the same authoritative ordering. A revocation ordered before the execution cut blocks consumption; a retry does not create a second internal test effect.
Bind the execution right
The action, protected scope, room and epoch belong to the bound object.
Decide on current state
Revocation and consumption are decided within the same authoritative ordering.
Execute once
A durable instruction reaches the internal recipient and the concrete test action.
Read the result back
Instruction status, acknowledgement and the result read back are documented separately.
Internal effect path tested. Operational release pending.
Internal reports dated 14 October 2026: both individual approvals and the internal operational verification are still pending. The documented tests do not release every sector or validate external target systems. Historical validity does not establish present executability.
For auditors: register export and evidence boundaries
The internal export report records 21 signed parts from 15 registers, containing 1,811 rows. A shared index lists their checksums; one sample recomputed outside the application matched its SHA-256 checksum. This documents the register export. Completeness of the entire source tree must be assessed separately.
Basis: internal execution and export reports. Private raw evidence is not published here. These statements summarise those reports and do not constitute independent certification.
Missing or empty operational keys are rejected; S5 with a separate acceptance key is reported as passed. HSM and external time-authority assurance are not claimed and are not additional prerequisites for this internal scope.
For auditors
State changes between checking and acting must not go unnoticed.
This gap is known as Time-of-Check to Time-of-Use, or TOCTOU. Rechecking alone does not close it. Authoritative state changes and the execution decision must follow the same binding ordering; the recipient must also be integrated into the protected effect path. Internal tests establish their named scope, not universal closure across every possible target system.
The approval remains. The circumstances change.
A payment was approved in the morning. Later, authority is withdrawn, evidence expires or the recipient changes. A system that relies only on the earlier approval may still process the payment. This is the gap between decision and effect that the architecture is designed to close.
One payment. Three minutes. One decisive question.
In the fictional case from The Moment Before, a €25 million transfer is ready. The decisive authority ends at 16:44. The money is due to leave at 16:47. The question is not merely who originally approved it. Is this exact payment still permitted now?
What the system does, step by step.
The process starts with a specific action, rather than a general risk score. The actor, action, destination and purpose are bound together. A change requires a new check.
1 · Define the action
Bind the exact payment to its actor, amount, recipient and purpose.
2 · Check the conditions
Authority, applicable rules, jurisdiction, time and required evidence must all hold.
3 · Decide before the effect
If a condition is missing or uncertain, the protected execution path remains blocked.
4 · Record the decision
A verifiable receipt records the conditions supporting the decision. Actual execution is established separately.
Conditions valid: The exact bound action may be allowed through the controlled path.
Condition missing or uncertain: No execution through that path. The reason is recorded.
What makes this different.
A dashboard shows a state. An alert asks someone to respond. A log records what happened. The Serverless Edition™ adds a technical decision before the protected effect. It integrates with the execution paths of existing business systems.
Where this boundary matters.
For payments, it governs the path to the transfer of money. For AI agents, it constrains the actions an agent can actually trigger. For data transfers, it checks the recipient, purpose and prerequisites. In government, healthcare and industry, it applies to actions whose consequences go beyond an incorrect screen message.
An independent system.
The Serverless Edition™ is an independent system. immo.quick Core™ is also independent and is not a prerequisite for Serverless™. The substantive checks, authority management and evidence generation belong to the Serverless Edition™. Deployment connects it to the protected actions in your organization.
What an effective deployment requires.
Prevention is possible only where the actual execution path is integrated. Another interface, background process or administrative route must not bypass the check. Authoritative permissions, rules and evidence must also be available and current. These exact paths must be tested in each deployment.
Start with one action.
We begin with a specific question: Which action in your organization must never happen under certain circumstances? We then identify the responsible authority, applicable rules, required evidence and every route to execution. That determines the necessary integration and what acceptance testing must establish.
Discuss a protected actionThree terms worth knowing.
Execution right
The current conditions establishing that this exact action is permitted.
Capability
A narrowly bounded technical permission for the integrated software. It applies only to the specified action and conditions.
Receipt
Verifiable evidence of a check, decision or execution. It does not automatically prove the truth of every source used.
Common questions
Is a normal user permission insufficient?
It establishes which functions someone may generally use. It does not automatically establish whether a specific action remains permitted under changed circumstances.
Does an AI decide what is permitted?
The described checking path evaluates defined conditions. An AI response or probability does not replace missing authority or mandatory evidence.
Do we need to replace our software?
The approach integrates with existing systems. Every route to the protected action must actually pass through the check.
Has every deployment been fully verified?
No. Architecture, implemented functions and demonstrated operation in a specific deployment are separate claims. The available evidence identifies its scope and limits.
For technical review
Explore the technical pages and evidence to inspect the architecture. Results apply to their stated scope, not automatically to every deployment.
In plain language
What does the Serverless Edition™ control?
It addresses the integrated execution path of a specific protected action. Authority and required conditions must hold at the relevant moment. Effectiveness depends on actual integration and acceptance testing.
Has the Serverless Edition™ been released for internal production use?
Not according to the documented status dated 14 October 2026. The internal effect path and register delivery have been reported; both individual approvals and the internal operational verification remain pending. Release applies only to the explicitly tested baseline and named scope.
The book about the moment before effect
The Moment Before · Rami Cherri
Machine Law™, AI governance and execution rights™ explained clearly. The English edition has 348 pages. Hardcover, paperback and e-book formats have separate ISBNs and direct links to tredition, Amazon and buecher.de on the book page.
See editions, ISBNs and retailers