Model intent is not authority
An agent may plan and request tools. Execution authority remains outside the model.
INSTITUTIONAL TRUST INFRASTRUCTURE · IMMO.QUICK SERVERLESS EDITION
Validate execution rights. Control real-world effects.
immo.quick Serverless Edition is an independent infrastructure for institutional execution rights. Before a protected action takes effect, it brings together authority, rule state, jurisdiction, purpose, time and mandatory dependencies. A valid Execution Right can form the basis for a narrowly scoped capability, whose validity is checked again at the point of execution.
HARD SYSTEM RULE
NO VALID EXECUTION RIGHT.NO CAPABILITY.
NO EXECUTION.
Determination is not authorization. Admin is not authority. Break glass is not a bypass. Simulation is not production.
The Serverless Edition connects as an institutional control layer to existing systems, workflows, platforms and agents.
Serverless Edition explained
Serverless Edition adds a controlled execution boundary to existing systems without replacing their business function.
Banking applications, enterprise platforms, AI agents, workflows and operational systems may already be technically capable of acting. Serverless Edition does not replace their business logic. It evaluates whether the institutional conditions required for that exact protected effect are currently complete.
Integration can use APIs, workflow hooks, event pipelines, AI-agent interlocks or structured data and file intake. What matters is that the Serverless Edition is coupled to the real point of effect and cannot be bypassed by an alternative technical path.
SERVERLESS EDITION · EXECUTION RIGHTS INFRASTRUCTURE
Serverless does not only control access. It controls the transition to effect.
The Serverless Edition is hardware-independent. Its primary control boundary is formed by current execution rights, tightly bound capabilities, point-of-effect revalidation and forensic evidence.
01 · REQUESTAction is requested
Actor, action, resource and purpose are made explicit.
02 · AUTHORITYValidate source
Authority must be legitimate, active, scope-bound and traceably originated.
03 · CLOSUREClose mandatory domains
Rule, jurisdiction, time, purpose, dependencies and other mandatory domains must all match.
04 · CAPABILITYBind the right technically
The capability is narrower than the right, time-bound and not freely reusable.
05 · EFFECTCheck again
Before productive effect, current authority and state are validated again.
06 · RECEIPTMake the decision reconstructable
Evidence binds what was allowed or blocked and the current state on which that decision rested.
Reachability is not permission
An API, vehicle, endpoint or service can be reachable and still be blocked at the point of effect.
Historical approval is insufficient
If mandate, jurisdiction, revocation or dependency changes, the effect must be reassessed.
SECURITY BOUNDARY · ARCHITECTURE BEFORE REACTION
TWO SECURITY BOUNDARIES. BEFORE ENTRY. BEFORE EFFECT.
immo.quick separates admission from execution authority. A request must first pass the relevant admission boundary; even successful access does not itself authorize a production effect.
01 · COREAdmission Boundary
Core places a fail-closed Access Guardian before the governed compliance pipeline. A request that fails a required validation condition does not reach the downstream governance logic.
02 · SERVERLESSEdge Client Attestation
The Serverless Edition requires a registered client to establish valid attestation before the request reaches the downstream gate path.
03 · ERIExecution Boundary
Access is not authority. A productive effect requires a valid, current and scope-bound Execution Right and an executable capability.
REQUEST→ADMISSION BOUNDARY→GOVERNED STATE→EXECUTION RIGHT→REAL EFFECT
Claim boundary: only the architecture of the immo.quick Serverless Edition was demonstrably submitted to the BSI on 28 July 2026. Core was not submitted. Submission is not a BSI audit, certification, endorsement or confirmation.
01 · CATEGORY
Governance does not begin after execution. It begins before technical capability exists.
Execution Rights Infrastructure is not a new label for monitoring. The category defines a technical boundary between “conditions look acceptable” and “this exact action may now become technically executable.”
RIGHTS BEFORE CAPABILITY
A positive gate result is not enough. Only rights closure can produce a valid Execution Right.
CAPABILITY BEFORE EFFECT
A right does not directly cause effect. It may only produce a tightly bound technical capability.
EVIDENCE AT EXECUTION
The actual execution is bound to right, capability, surface, time and evidence.
02 · CANONICAL CHAIN
From request to evidence, there is no silent jump.
Each stage has a different meaning. Determinations establish facts about modeled conditions. Rights closure decides whether a right can close. Capability makes the permitted action technically executable. Enforcement checks directly at the boundary of effect.
REQUEST
→
DETERMINATIONS
→
RIGHTS CLOSURE
→
EXECUTION RIGHT
→
BOUNDED CAPABILITY
→
ENFORCEMENT
→
EXECUTION
→
EVIDENCE
03 · FIRST MOAT
Control what may execute.
The first moat controls the institution’s own productive environment. The goal is not merely to check, but to prevent capability-free bypass paths within the registered scope.
RIGHTS CLOSURE
Mandatory conditions must fully close. No confidence scores, no AI recommendation path.
BOUNDED CAPABILITY
Subject, action, resource, purpose, scope, environment and validity remain tightly bound.
EXECUTION SURFACE REGISTRY
Productive API, event, queue, batch, admin, recovery and break-glass paths must be registered and enforced.
POINT-OF-EXECUTION REVALIDATION
Right, revocation, freshness, context and capability class are revalidated immediately before effect.
REPLAY RESISTANCE
Persistent atomic nonce state prevents reuse and race-condition-based double consumption.
BREAK GLASS ≠ BYPASS
Emergency execution requires its own authority, closure, capability and enhanced evidence.
04 · SECOND MOAT
Control what executions from others you are willing to accept.
Interoperability moves trust from assertion to independent verification. A counterparty does not have to believe that another system was authorized. It can verify the portable Execution Rights proof and then apply its own acceptance policy.
PORTABLE PROOF
→
INDEPENDENT VERIFY
→
ACCEPTANCE POLICY
→
ACCEPT / REJECT
→
ACCEPTANCE RECEIPT
NO AUTHORITY TRANSFER
Remote acceptance creates neither local authority nor a local Execution Right.
POLICY-SPECIFIC ACCEPTANCE
Each institution decides under its own policy. The same valid proof can be accepted by A and rejected by B.
MUTUAL INTERLOCK
For sensitive transactions, both sides can prove their rights and independently accept the other party.
05 · WHY THE CATEGORY WAS MISSING
Most systems control decisions. ERI controls technical executability.
Observe / evaluate
- Review output
- Score risk
- Generate warning
- Escalate to humans
- Document after execution
Execution Rights Infrastructure
- Close authority and conditions before execution
- Only then issue capability
- Enforce capability directly at execution surface
- Apply revocation/freshness immediately
- Bind execution evidence to right + capability
06 · WHAT IT PREVENTS
Not “more control.” Less unauthorized technical possibility.
ADMIN WITHOUT RIGHT
An admin role alone must not authorize productive execution.
STALE AUTHORITY
Previously valid authority is not trusted indefinitely.
WRONG SCOPE
A capability for resource A or purpose X cannot be widened to resource B or purpose Y.
REPLAY
A consumed capability cannot cause effect again.
ALTERNATE PATH
An alternate productive surface must not bypass central capability enforcement.
SIMULATION ESCAPE
Counterfactual or simulated rights must never reach production capability issuance.
07 · PORTABLE PROOF
Verify the right without trusting the issuer.
Portable Execution Rights Proofs make the binding between right, capability and execution externally verifiable. The current frozen proof path binds its actual crypto profile and rejects unknown or inconsistent protocol, schema, canonicalization and algorithm states.
ECDSA P-256 · SHA-256 · 256-bit CSPRNG NONCE
Publicly verifiable attribution and integrity. No blanket claim of universal legal non-repudiation.
FROZEN PROOF PROFILE
08 · STATE REALITY CONSISTENCY
Reality can invalidate execution without becoming authority.
ERI-INV-017 separates authoritative state, observation, physical reality and ground truth. For physical dependencies, the applicable provenance, freshness, independence and attestation conditions must close at the Execution Cut. Unresolved divergence results in DENY or REASSESSMENT, not a majority vote on truth.
OBSERVATION ≠ AUTHORITY
Sensors, monitoring or external evidence can reveal divergence. They do not rewrite governance state by themselves.
CONSENSUS ≠ PHYSICAL TRUTH
A majority is not proof of truth. Conflicting independent sources produce STATE_DIVERGENCE and prevent dependency closure.
UNCERTAINTY → DENY
Machine Law does not claim to manufacture unobserved reality. It prevents unresolved uncertainty from silently becoming execution permission.
09 · VERIFIED PROVENANCE
A valid signature is not yet trusted physical state.
ERI-INV-018 makes explicitly verified provenance a prerequisite for trusted execution evidence in physical attestations. A present provenance_root is not sufficient. provenance_verified must explicitly be true. false or absent means PROVENANCE_INCOMPLETE and fail-closed BLOCK.
VALID SIGNATURE ≠ VERIFIED PROVENANCE ≠ TRUSTED EXECUTION EVIDENCE
Authenticity relative to a key, verified origin, and execution-relevant trust are three distinct claims.
FAIL CLOSED
08 · EVIDENCE
The architecture is frozen. Test claims remain scope-specific.
113/113Execution Rights Conformance V2 · PASS
37/37Freeze hardening · PASS
15/15Interoperability conformance · PASS
GLOBAL ENFORCEMENT MATRIX V3
0 detected successful bypass paths in the tested scope. This is internal implementation evidence, not a claim of global impossibility or third-party certification.
TESTED SCOPE
09 · USE CASES
Anywhere software can create real effects, not merely decisions.
AI AGENTS
Agents can present proofs but cannot invent authority. Actions remain bound to verifiable rights and local acceptance.
PAYMENTS & TREASURY
Critical transfers can be bound to specific rights, scope, purpose, capability and execution evidence.
CRITICAL APIs
API, queue, webhook and service calls can be made capability-mandatory before effect.
ADMIN & RECOVERY
Admin, recovery and emergency paths remain inside the same rights constitution.
CROSS-INSTITUTION B2B
Counterparties can independently verify portable rights proofs and apply their own acceptance policies.
PUBLIC SECTOR
Execution rights for high-criticality administrative, registry or infrastructure actions can be bound before effect.
12 · CLAIM BOUNDARIES
The machine may only claim what its bound evidence actually supports.
DETERMINATION ≠ AUTHORIZATION
GATE PASS ≠ EXECUTION RIGHT
ADMIN ROLE ⇏ EXECUTION RIGHT
AI OUTPUT ⇏ AUTHORITY
BREAK GLASS ⇏ BYPASS
SIMULATED RIGHT ⇏ PRODUCTION CAPABILITY
VERIFICATION ≠ ENDORSEMENT
ACCEPTANCE ≠ AUTHORITY CREATION
OBSERVATION ≠ AUTHORITY
CONSENSUS ≠ PHYSICAL TRUTH
VALID SIGNATURE ≠ VERIFIED PROVENANCE
RECOVERY AUTHORITY ≠ FORWARD CAPABILITY
12.5 · EXECUTION EXPOSURE
Ten questions before you talk about integration.
The Serverless Edition does not start with a product-demo workflow. It starts with a concrete effect: which action must be protected, which authority grounds it, which states must still be valid at the point of effect, and what evidence must remain afterwards?
The new Execution Exposure Assessment translates that architecture into ten clear questions and produces no marketing scorecard, but a gap map for further review.
IDENTITY
→AUTHORITY
→STATE
→EFFECT
→RECEIPT
13 · FAQ / GEO
Execution Rights Infrastructure in clear answers.
What is Execution Rights Infrastructure?
Serverless Edition is Execution Rights Infrastructure within the umbrella category Institutional Trust Infrastructure. It separates determination, authorization and execution and closes action-specific Execution Rights before productive effect.
Why is a gate PASS not enough?
A gate PASS is only a determination about one condition. An Execution Right exists only when all mandatory authority, rule, jurisdiction, time, dependency, purpose and scope conditions are closed.
What is a bounded capability?
A bounded capability is the technical ability to perform exactly the authorized action for the bound subject, resource, purpose, scope, time and environment context. It cannot be broader than the underlying right.
What is Execution Rights Interoperability?
It allows another institution to independently verify a portable Execution Rights proof and accept or reject it under its own acceptance policy, without creating local authority.
Can the Serverless Edition create legal authority?
No. Authority must be legitimately grounded externally. The system models and binds that authority; it does not create sovereign or legal authority by itself.
What happens when reality and authoritative state diverge?
ERI-INV-017 allows reality-linked evidence to invalidate execution without turning observation into authority. If freshness, provenance, independence or required attestations no longer close, the result is DENY or REASSESSMENT. Conflicting sources are not resolved by treating a majority as physical truth.
Is a valid signature enough for trusted execution evidence?
No. ERI-INV-018 separates signature validity from verified provenance. For physical attestations, provenance must be present and explicitly verified. false or absent verification status remains PROVENANCE_INCOMPLETE and blocks fail-closed.
EXECUTION RIGHTS INFRASTRUCTURE
CONTROL WHAT MAY EXECUTE. PROVE WHY IT WAS ALLOWED.
And when another institution is involved: control what executions from others you are willing to accept.
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.
TENANT OPERATING MODEL · FINALIZED
Finalized Tenant Operating Model
30 primary actions. Attention-first. File-first intake. Permissions, decisions, receipts and integrations in one operating logic – with the authority boundary unchanged.
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.