Non optional base layers
Universal Serverless Edition controls that cannot be disabled by tenant preference.
immo.quick · Explained simply
Shared technology. Your organization’s own rules.
Every organization has its own responsibilities, activities and prerequisites. A tenant profile defines which of them apply to a deployment. Shared technology must preserve those distinctions.
Internal verification status · 14 October 2026
An approval applies to a named scope.
The tenant, profile version and protected scope must match the tested action. Changes and revocations belong in the authoritative decision path. Evidenced separation of test and production paths does not replace release of the specific institutional operating scope.
Internal effect path tested. Operational release pending.
Test scope, register evidence and release statusA bank and a hospital need different prerequisites.
A payment may depend on amount, recipient and payment authority. A protective activity may require different evidence. Profiles must represent these requirements and bind them to the appropriate operations. Choosing a module must not disable a mandatory rule.
A profile is checked, approved and versioned.
Changes must be traceable. A new version must not silently continue under an old approval. Editing and approval permissions are defined, and tenants’ data and access must remain separate. This separation is part of acceptance testing for the actual deployment.
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
What is a tenant profile?
It describes the conditions applying to an organization and deployment. Changes, approvals and versions must remain traceable. Profile choices must not disable mandatory rules.
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.
TENANT GOVERNANCE · SECTOR AWARE INFRASTRUCTURE
Shared infrastructure. Governance specific to each institution.
The Serverless Edition derives a tenant’s governance profile from its sectors, jurisdictions, activities, risks and deployment conditions. Mandatory controls remain binding; conditional controls become mandatory when their trigger applies. Requirements across sectors are resolved together, without weakening stronger obligations through less restrictive settings.
TENANT CONFIGURATION ≠ EXECUTION AUTHORITY · MULTI SECTOR COMPOSITION ⇒ STRONGEST APPLICABLE REQUIREMENT PREVAILS
A control profile that keeps obligations intact.
Example: an institution operates in finance and healthcare. Both contexts contribute to one governance profile. A weaker sector setting must not reduce a stronger applicable obligation. The profile determines requirements; it does not grant an execution right.
FIVE REQUIREMENT CLASSES
Optionality ends where governance begins.
Mandatory from sector context
Controls that follow from the active sector and its governance semantics.
Triggered by activity or risk
Becomes mandatory when a defined state or activity occurs.
Genuinely selectable
Only where no system, sector or conditional trigger creates a requirement.
Remains outside the context
Irrelevant functionality is not forced into the tenant profile.
MULTI SECTOR TENANTS
Multiple selections do not create module islands.
A tenant may combine Finance and AEG, Defence and Export, Healthcare and Pharma, or Telecommunications and Messaging. Sectors are not simply switched on next to one another. Their mandatory conditions are compiled into one Governance Context. A weaker requirement may never downgrade a stronger one.
SECTORS[]JURISDICTIONS[]ACTIVITIES[]RISK ATTRIBUTESDEPLOYMENTGOVERNANCE PROFILESTRONGEST REQUIREMENT
SECTOR PROVISIONING MATRIX
The provisioning logic deliberately distinguishes fixed, conditional and optional controls.
| Sector | Provisioning | Governance composition |
|---|---|---|
| Telecommunications | SECTOR_REQUIRED | Endpoint Authority, provider classification, telecom legal packs, lawful access |
| Messaging & Social Communications | SECTOR_REQUIRED | Endpoint Authority, 12 MSG invariants, messaging surfaces, interoperability |
| Agentic Execution Governance | SECTOR_REQUIRED | Agent execution surfaces, agent authority, Endpoint Authority where technically relevant |
| Defence | SECTOR_REQUIRED | Defence authority, export, technology transfer, classified controls, Endpoint Authority |
| Finance | SECTOR_REQUIRED for transactional effect | Financial authority, payment and settlement controls, Endpoint Authority |
| Healthcare | SECTOR_REQUIRED for clinical or patient data effect | Healthcare authority, privacy, clinical controls, Endpoint Authority |
| Government | SECTOR_REQUIRED for sensitive systems | Institutional authority, registers, remote administration, Endpoint Authority |
| Energy | SECTOR_REQUIRED for OT and control | OT/SCADA authority, remote control, Endpoint Authority |
| Real Estate | CONDITIONALLY_REQUIRED | Payment, identity, signing and sensitive registry activities |
| Logistics / Heavy Industry | CONDITIONALLY_REQUIRED | Operational devices, fleet, OT, machine control |
| Sport / Music Rights | OPTIONAL or CONDITIONALLY_REQUIRED | Only for matching activities, rights or privileged workflows |
ENDPOINT AUTHORITY IN TENANT LOGIC
The new authority layer is not blindly enabled everywhere.
Telecommunications, Messaging, AEG, Defence and Cybersecurity make Endpoint Authority sector required. In Finance, Healthcare, Government and Energy, the requirement depends on transactional, clinical, administrative or OT effect. In Real Estate, Logistics and Heavy Industry, it is activated only for matching activities or risks. This preserves specialization without diluting existing sector logic.
Monotonic merge rule: FINAL_REQUIREMENT = STRONGEST_APPLICABLE_REQUIREMENT. Multi sector composition must never reduce an existing requirement.
WHY THIS MATTERS
Multifunctional without becoming arbitrary.
The shared engine always asks the same core question: does a valid Execution Right exist for this exact action now? The sector determines which Authorities, Rules, Jurisdictions, Dependencies and additional boundaries must be satisfied. The system logic remains stable while each tenant receives its own governance topology.
Continue your review
Questions and clear answers
What is a tenant?
A tenant is an institutionally bounded operating and governance context. Its requirements derive from factors including sectors, jurisdictions, activities and risks.
Can an institution disable mandatory controls?
The documented governance model distinguishes mandatory baseline and sector controls, conditionally required controls, optional functions and inapplicable functions. A preference does not override a requirement.
Does a tenant profile create an execution right?
No. The profile determines applicable requirements. A valid execution right for the specific action must be resolved separately under the relevant current conditions.
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.