immo.quick Core: checks, evidence and sovereign deployment

First: Can this operation proceed to further checks?

Gate 0 precedes the execution pipeline. It checks registered constitutional conflict patterns: Are there incompatible legal requirements that prevent ordinary processing? The operation is considered with its jurisdictions and other governing inputs.

Then: Nine gates from input to result.

Each gate has a distinct task. The architecture links checking steps through their hashes. If a required prerequisite is missing, the defined path must stop. Passing one gate is not a complete approval.

1. G1

   Identity

   Check identities and beneficial ownership.

2. G2

   Sanctions

   Check parties against the configured sanctions sources and record matches.

3. G3

   Jurisdictions

   Combine the applicable jurisdictions and their conflicts.

4. G4

   Frameworks

   Evaluate applicable rules and thresholds for the operation.

5. G5

   Risk

   Calculate risk using defined criteria and trigger required enhanced review or blocking.

6. G6

   Authority and independence

   Evaluate the authority chain and modelled independence of maker and checker.

7. G7

   Seal evidence

   Bind the checking steps into a cryptographic evidence package.

8. G8

   Commit immutable records

   Record the event in the intended immutable ledger, including refusals.

9. G9

   Issue the result

   Issue the result with its operation identifier and supporting conditions.

Two times. One traceable history.

Core distinguishes when a fact applied from when the system recorded it. These are valid time and transaction time. When a rule changes or a fact becomes known later, the basis of the earlier decision remains traceable. Historical replay requires archived inputs, rule versions and evidence.

Two approvers are not enough if both share the same dependencies.

The GLD component examines modelled independence between maker and checker. The specification describes four stages: differences in decision foundations, time decay, proximity in shared networks and correlation of prior responses. This provides a testable assessment within the model, not general proof that people can never collude.

Process rules and make conflicts visible.

Core includes rule compilers, a legal corpus registry, applicability checks and conflict resolution. A rule compiler maps defined rule foundations into the checking path. Changes are versioned and can be compared. A conflict is not resolved by silently favouring one side: the documented resolution or escalation path matters.

The technical environment is part of the evidence.

The architecture includes isolated execution environments, controlled keys and evidence about the environment used. The specification names Nitro Enclaves, hardware security modules and additional trust environments. Each deployment profile must identify the hardware, signatures and time sources actually used. An architectural component is not automatically active in every installation.

A refusal is also an important result.

Core provides evidence for both accepted and refused operations. Selective disclosure supports the intended review scope without unnecessarily revealing all data. Causality tools connect results to their foundations. Verifiers, reproducibility checks and adversarial tests examine whether the documented binding holds.

Change and recovery remain inside the control model.

A frozen state, a new rule version or recovery after a disruption each require their own foundations. The functional map includes recovery planning, recovery authority and revalidation. Emergency access does not replace authority or silently bypass the intended evidence path.

Ten sectors, with their own substantive requirements.

The specification covers banking and finance, insurance, wealth management, real estate, mergers and acquisitions, cloud and technology, defence and dual-use, government, energy and crypto-assets. Sector integration determines rules, evidence and decision criteria. A shared conflict matrix does not establish market authorization in every jurisdiction it includes.

Separate current scope from expansion plans.

The supplied specification identifies the EU and Switzerland as the active base. The UK and UAE, then Singapore, the US and Australia are expansion paths; Japan and India are later plans. The 47-jurisdiction conflict matrix describes the basis for conflict analysis. A specific deployment still depends on approved rule versions, local legal assessment and an accepted deployment profile.

What we explicitly distinguish.

The specification describes qualified-signature integration as QES-ready and in preparation. This does not establish that all production evidence already carries qualified signatures. Cryptographic integrity, substantive assessment and legal recognition are separate questions. A Core result is not a court judgement or, by itself, blanket liability discharge, regulatory approval or guaranteed recognition in every jurisdiction.

The institution defines its trust perimeter.

Shared architectural objectives: controlled key custody, no unnecessary data access and checks before intended execution. The deployment profile must establish which properties are technically enforced.

Institutional onboarding, not self-service.

Core particularly addresses central banks, supervisors, systemically important institutions, sovereign funds and government bodies. Onboarding begins with institutional access review, followed by trust perimeter, jurisdictions, infrastructure, key procedures, legal assessment and acceptance testing. Core is not a prerequisite for the independent Serverless Edition.

Foundations and evidence