Authority
Who legitimately holds the relevant competence or sets the authoritative state.
immo.quick · Explained simply
How authority becomes a permitted action.
The architecture answers a specific question: Is this action permitted under the conditions that apply now? It separates the origin of authority, checks on prerequisites, technical permission and evidence of actual execution.
Example: An approval is withdrawn.
The earlier approval may remain visible in a business system. What matters is current authority. The controlled execution path must therefore account for the applicable state before the action takes effect. Passing an individual check does not replace that decision.
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.
What must hold together.
Who may act? Which rules apply? In which jurisdiction? At what time? Which other prerequisites are mandatory? If a required condition is missing, there is no valid execution right. Integration must enforce that result on the actual execution path.
The questions behind the process
- 1
Subject
What exactly is being checked or protected?
- 2
Basis
Which authority, rules and evidence apply?
- 3
Check
Which conditions hold and which are missing?
- 4
Evidence
What was actually established or executed?
Orientation sketch: the actual checks and integration depend on the system and use case.
The next step
Describe a specific operation and the systems involved. Together we can identify the required foundations and the checking path needed to establish the deployment.
Request a conversationFind the relevant detail
In plain language
How does the Machine Law architecture work?
It separates authoritative permission, prerequisite checks, current execution rights, bounded technical permission and actual effect. Passing an individual check does not by itself grant execution permission.
Open technical documentation and existing verification tools
The existing technical reference remains accessible here. Technical labels and historical test statements apply to their documented scope; they do not establish general operational approval.
THE CURRENT ARCHITECTURE
From institutional authority to controlled execution.
The architecture separates authoritative sources, rule evaluation, execution rights, capabilities and the actual effect. This separation prevents a positive check or administrative access from becoming permission to execute on its own. Evidence records the basis on which an action was permitted or blocked.
AUTHORITATIVE SOURCE
NORMATIVE STATE
DOMAIN DETERMINATION
EXECUTION RIGHTS CLOSURE
BOUND CAPABILITY
EXECUTION PLANE
EVIDENCE
AUTHORITY DEFINES THE CONDITIONS. THE SYSTEM DETERMINISTICALLY RESOLVES THEIR EXECUTION EFFECT. THE EXECUTION PLANE DECIDES NOTHING.
CODED VISUAL · AUTHORITY PATH
A hard boundary between knowledge and the right to act.
This is not a process diagram making a runtime claim. It visualises only the public architectural layers and their separation.
AUTHORITY → STATE → DETERMINATION → CLOSURE → CAPABILITY → EXECUTION PLANE → EVIDENCECLAIM-SAFE ARCHITECTURE VIEW
01
AUTHORITATIVE SOURCEEXTERNAL ORIGIN02
NORMATIVE STATEBOUND INPUT03
DOMAIN DETERMINATIONDETERMINATION04
EXECUTION RIGHTS CLOSUREA · R · J · T · D05
BOUND CAPABILITYSTATE-BOUND06
EXECUTION PLANENO GOVERNANCE AUTHORITY07
EVIDENCEPROVENANCE / BINDINGA gate determination creates no external authority.
EXECUTION RIGHTS GRAPH
Five dimensions must close.
Rule
Which governed rule state applies to the exact action.
Jurisdiction
Which legal or institutional space governs the action.
Time
Whether authority, rule and relevant state remain valid at the execution boundary.
Dependency
Which additional mandatory conditions must exist before the consequence may become executable.
5/5 REQUIRED CONDITIONS CLOSED → EXECUTION RIGHT MAY EXIST · ANY REQUIRED DIMENSION ABSENT → NO VALID EXECUTION RIGHT
LAYER BOUNDARIES
What each layer can do — and what it cannot.
Gate Catalog
CAN Deterministically determine encoded domain conditions.
CANNOT Create execution permission or institutional authority.
Execution Rights Layer
CAN Resolve whether the modeled authoritative state establishes a valid execution path.
CANNOT Create authority that does not exist outside the system.
Execution Plane
CAN Verify capability, verify state binding, execute, consume capability and record evidence.
CANNOT Govern, reinterpret policy or mint its own right to act.
Evidence Layer
CAN Preserve integrity, provenance, state binding and execution relationship.
CANNOT Turn false input into truth or substitute for substantive legal assessment.
CANONICAL MACHINE-READABLE SUMMARY
One architecture. Explicit boundaries.
This concise summary is written for technical due diligence, search engines and machine retrieval systems. It does not replace the specification or evidence artifacts.
CATEGORYInstitutional Trust Infrastructure
AUTHORITYExternal; not created by the system
GATESDomain gates determine; control surfaces verify/bind/enforce; neither creates execution permission
EXECUTION RIGHTSClosure across Authority, Rule, Jurisdiction, Time, Dependency
CAPABILITYBound technical execution carrier after complete closure
EVIDENCEEstablishes integrity and binding; not automatic substantive legal correctness
CROSS-LAW DEPENDENCY ENGINE
Legal interactions become visible without manufacturing legal authority.
115 versioned legal instruments → authority-bound catalog state → dependency/pattern match → institutional execution policy → determination → receipt. Authority Composition and Interaction Profile remain visible as structured outputs.
STATE-REALITY ASSURANCE · UNIVERSAL PRE-AUTHORITY BOUNDARY
Just because the system sees it does not mean it may act on it.
SRA separates runtime and observed reality from authority and execution. 20 formal invariants, a non-compensable threshold engine and 46/46 modeled scenarios with expected outcomes. Reality may inform authority. It may never create it.
What the evidence actually establishes
A receipt records a specific state or event. Assessment therefore depends on more than verifiable integrity: it requires identifying the event that is bound and the sources, rules and execution data available.
Determination
A gate establishes whether its formally defined conditions are satisfied. A PASS does not grant an execution right on its own.
Execution Right
Authority, rule state, jurisdiction, time and mandatory dependencies must align for the specific action.
Capability
A narrowly bound technical permission may follow from a valid execution right. Issuance does not prove that execution occurred.
Actual effect
Only evidence of the completed action establishes execution. Integrity alone guarantees neither source truth nor legal recognition.
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