The chain, T0 through T4.
Five stages, each with its own kind of assurance. Not every stage is externally checkable, and the manifest says so openly instead of glossing over it.
T0
Authority Origination
INTERNAL
before any receipt is sealed, the authority source is validated against a registered AuthorityCredential, checking validity, jurisdictional scope match, and delegation permission. An authority that cannot be traced to a legitimate, registered, active source cannot be originated into the authorization chain
EXECUTION ROLE: ENFORCING_INPUT
T1
Deterministic Gate Evaluation
INTERNAL
each Gate in the catalog evaluates its input against a hard-coded rule table. The evaluator's source contains no probabilistic model, no heuristic, and no free-text interpretation. Same inputs produce the same verdict, f(x) = Law. Every gate declares execution_authority=false, a gate PASS is domain determination, not execution permission
EXECUTION ROLE: DOMAIN_DETERMINATION_ONLY
T2
Receipt Sealing
PUBLICLY VERIFIABLE
each receipt is sealed with HMAC-SHA256 over canonical data (deep recursive key sorting) and co-signed with a hybrid post-quantum signature (Ed25519 + ML-DSA-65). The signature is produced by a process separate from the evaluating gate
EXECUTION ROLE: RECORDING
T3
Chain Binding
PUBLICLY VERIFIABLE
each receipt carries a prev_receipt_hash and a chain_link (SHA-256 of certification_hash:prev_receipt_hash). The chain is append-only, a tampered receipt breaks the chain at the point of modification
EXECUTION ROLE: RECORDING
T4
Sovereign Multi-Witness Anchoring
INTERNAL
periodic Merkle-root anchoring across multiple independent, non-US jurisdiction witnesses (DE/CH/LU). A 2-of-N quorum is required for the evidentiary anchoring profile designed for independent judicial and regulatory review. The anchor is periodic and per-window, not per-request
EXECUTION ROLE: POST_HOC_OBSERVATION
Cryptographic primitives.
Classical and quantum-resistant in one artifact, no proprietary cryptography.
classical_signature
Ed25519 (FIPS 186-5), EdDSA
post_quantum_signature
ML-DSA-65 (NIST FIPS 204), CRYSTALS-Dilithium, Security Category 3 (≈ AES-192)
hash_function
SHA-256 (NIST 180-4)
hmac
HMAC-SHA256 over canonical JSON with deep recursive key sorting
domain_separation
neutral 'immoquick' branding, no platform-specific identifiers in cryptographic domain-separation strings
key_ceremony
Shamir threshold secret sharing, no single party holds the full signing key
key_rotation
deterministic key rotation drill with forensic proof hash binding
130 gates, 20 categories.
The complete catalogue from the manifest. For each individual gate with legal basis and examples, see the Gate Directory.
Infrastructure / Edge
3 Gates
- gate0CoreDispatch, Enforced Edge Grid durable core re-execution
- gate0EdgeIntercept, Enforced Edge Grid write-side interception
- gate0EdgeReconciliation, Enforced Edge Grid core-edge reconciliation
AML / KYC (Gate 2)
14 Gates
- gateAML, FATF-list screening / PEP / transaction monitoring
- gateCTA, USA Corporate Transparency Act / FinCEN BOI
- gateUKMLR, UK Money Laundering Regulations 2017
- gateSwissAMLA, Swiss Anti-Money Laundering Act (GwG SR 955.0)
- + 10 more
Banking & Finance
10 Gates
- gateBankingCompliance, BaFin KWG / DORA / DSGVO
- gateBaselLiquidity, Basel III LCR/NSFR/CET1
- gateMarketAbuse, MiFID II MAR / BMR
- gateCBDC, Digital Currency / Ledger Pre-Check
- + 6 more
Government & Constitution
7 Gates
- gateGovernmentActs, VwVfG / Gate 0 / DSGVO
- gateProcurement, EU 2014/24 ESG / Tariftreue
- gateTaxExecution, POS USt/VOst UStG
- gateBundID, eIDAS 910/2014
- + 3 more
Real Estate & FDI
2 Gates
- gateRealEstateTransactions, UBO / Escrow / ESG
- gateForeignDirectInvestment, AWV §55 / EU-FDI 2019/452
Transatlantic & Export Controls
10 Gates
- gateUSExportControls, EAR 15 CFR
- gateEUDPF, EU Data Privacy Framework
- gateOFAC, OFAC / IEEPA 31 CFR
- gateTransatlanticConflict, EU/US legal conflict at T=0
- + 6 more
EU Extended
6 Gates
- gateEUTaxonomy, VO 2020/852 DNSH + SFDR
- gateCSRD, RL 2022/2463 ESRS E+S+G
- gateEUESG, SFDR / MiFID II ESG preferences
- gateEUFinance, MiFID II / CRR / CRD / Solvency II
- + 2 more
International
4 Gates
- gateGloBE, OECD Pillar 2 15% Minimum Tax
- gateOECDUngp, Anti-Bribery + UNGPs 2011
- gateUNCAC, UN Convention against Corruption 2003
- gateIHR, WHO IHR 2005 + WTO-SPS
DE Cross-Section
6 Gates
- gateDELaws, GwG/KWG/WpHG/BDSG/BSIG/ZAG/GrEStG/KAGB
- gateWHGAwSV, PFAS + Trinkwasser
- gateBBodSchG, Altlasten-Haftungstransfer
- gateTALuft, Immissionsschutz PM10/NO2/SO2
- + 2 more
Sector-Specific Industry
14 Gates
- gateTelecom, TKG v2 / BSI / NIS2
- gateDefenseExport, KWKG / AWG / EU-Dual-Use / ITAR
- gatePharmaMedical, MDR / AMG / EU-FMD / GMP / EUDRA
- gateChemicalHazmat, REACH / Seveso III / CLP
- + 10 more
Sport Governance
4 Gates
- gateSportDecision, VAR Protocol / Betting Integrity
- gateMotorsportDecision, Cost Cap / Parc Fermé / Super License
- gateAntiDoping, WADA Prohibited List
- gateTransfers, PSR / FFP / Squad Cost
Regional / National Laws
20 Gates
- gateUSLaws, US Federal Law (Dodd-Frank / SOX / BSA)
- gateUKLaws, UK Common Law (Companies Act / PRA / FCA)
- gateCHLaws, Switzerland (OR / FINMA / ZGB)
- gateATLaws, Austria (ABGB / FMA / WAG)
- + 16 more
Forensic Meta-Gates
7 Gates
- gateAuthorityChainCheck, authority chain validation at T=0 (independent legitimacy aware)
- gateSuspensionOverride, authorised suspension with proof
- gateLogVerify, receipt integrity / Merkle chain verification
- gateARandfaelleTestMatrix, three named edge cases / determinism probe
- + 3 more
AI Governance & Automated Decision-Making
6 Gates
- gateAIProhibitedPractices
- gateSocialBenefits, SGB X/II / Art. 22 DSGVO / BVerfGE 125,175
- gateTaxAdministration, §88 Abs. 5 AO
- gateCreditScoring, EuGH C-634/21 (SCHUFA) / §31 BDSG
- + 2 more
Tax Reporting & Cross-Border Transparency
1 Gates
Critical Infrastructure & Resilience
1 Gates
AI Act & AI Governance
3 Gates
- gateGPAIProvider
- gateAITransparency
- gateAIHighRiskConformity
Digital Infrastructure Law
4 Gates
- gateDataAct
- gateDataGovernanceAct
- gateDMA
- gateCRA
Financial Market Infrastructure
4 Gates
- gateBRRD
- gateEMIR
- gateCSDR
- gateDGSD
Asset Management & Securities Financing
4 Gates
- gateAIFMD
- gateUCITS
- gateSFTR
- gateSecuritisation
The controlled vocabularies.
Every statement in the manifest uses one of these vocabularies, no free-text interpretation.
ASSURANCE_VOCABULARY
DETERMINISTIC_EVALUATIONat the gate level: same inputs, same verdict, no model, no heuristic, no probability, f(x) = Law
AUTHORIZATION_DETERMINISMsame canonical input, same authoritative state and same authoritative ordering point produce the same execution-right outcome
HMAC_SHA256_INTEGRITY_SEALHMAC-SHA256 integrity seal over canonical receipt data using a non-public symmetric key; not an independently public verification mechanism
HYBRID_PQC_SIGNATUREEd25519 + ML-DSA-65 post-quantum signature, classical and quantum-resistant in one artifact
MERKLE_CHAIN_BINDINGSHA-256 chain link binding each receipt to its predecessor, append-only, tamper-evident
AUTHORITY_PROVENANCE_HASHexplicit declaration of which authority source legitimises a receipt, separable from the causal chain
SOVEREIGN_MULTI_WITNESS_ANCHORperiodic Merkle-root anchoring across multiple independent non-US jurisdictions (DE/CH/LU)
EXECUTION_RIGHT_ABSENCEfailure of any mandatory closure condition results in ABSENT execution right; no executable capability is created, the transaction cannot proceed not because it was blocked, but because no execution right exists
CRYPTO_SHREDDINGPII destruction via encryption-key shredding after legal retention period, hash chain remains intact
BI_TEMPORAL_VERSIONINGvalid-time and transaction-time bi-temporal ledger, rules can be retroactively audited at any point in time
SHAMIR_THRESHOLD_COSIGNShamir secret sharing threshold cosignature, no single party holds the full signing key
SIX_EYES_APPROVALdual-control multi-signature with independent approver roles, no single-actor execution. Threshold approval is an anti-manipulation control and does not itself create normative authority
EXECUTION_RIGHTS_GRAPHfive mandatory closure nodes (AUTHORITY, RULE, JURISDICTION, TIME, DEPENDENCY) resolved at T0, all must close for a capability to exist
AUTHORIZATION_STATE_ROOTSHA-256 fingerprint binding Authority, Rule, Jurisdiction, Time and Dependency state, including authoritative provenance, into the authorization state from which the execution right was derived, sealed into every capability, checked by the execution plane
GOVERNANCE_AUTHORITY_PROOFcryptographic proof that a valid AuthorityCredential authorises a specific governance mutation, no CapabilityInvalidationRecord may exist without one
MONOTONIC_SEQUENCE_BINDINGsingle monotonic AuthorizationStateSequence counter allocates deterministic ordering between invalidation and consumption, not wall clock, not replication speed
ZERO_RETROACTIVITYan invalidation with sequence > execution_cut_sequence cannot retroactively unauthorise a consumption that already won the cut, the past is closed
DETERMINISTIC_CHAINED_CAPABILITIEScapability B may require capability A to be CONSUMED first, sealed via prerequisite_chain_hash, re-verified at issuance and consumption
SINGLE_USE_CAPABILITYeach ExecutionCapabilityToken is consumed exactly once, a second attempt yields BLOCK_CAPABILITY_ALREADY_CONSUMED, not a retry
NEGATIVE_EXECUTION_RIGHT_PROOFat ABSENT, a signed proof seals that every admissible path for every mandatory node was traversed and none was valid, not merely that the requested ref was invalid
GATE_ROLE_VOCABULARY
DOMAIN_DETERMINATION_ONLYgate determines domain conditions but grants no execution authority
EVIDENCE_INPUTgate output may become evidence input to the Execution Rights Graph
NOT_APPLICABLEgate does not apply to the submitted domain state
AUTHORIZATION_ROLE_VOCABULARY
EXECUTION_RIGHTS_CLOSUREthe Execution Rights Graph resolves whether all five mandatory closure nodes close at T0, VALID may produce a capability, ABSENT produces a negative proof
CAPABILITY_ENFORCEMENT_ONLYthe Execution Plane enforces capability boundaries atomically, it interprets no authority, it checks only whether a valid, uninvalidated, unconsumed capability exists
STAGE_EXECUTION_SEMANTICS_VOCABULARY
ENFORCING_INPUTcomputed before authorization closure and capable of preventing the required closure conditions from being satisfied
OBSERVING_ONLYno return path into admission, execution or enforcement
POST_HOC_OBSERVATIONruns after the transaction and cannot affect it
RECORDINGproduces a forensic artefact as part of serving the request
STATUS_VOCABULARY
SEALEDa receipt received an HMAC-SHA256 integrity seal and was Merkle-chain-bound with a deterministic verdict
DELTA_FLAGGEDa material divergence was detected and recorded, but the transaction was not blocked
ATTESTATION_INCOMPLETEa required attestation was missing; the required authorization closure could not complete
BLOCKEDa critical rule failure caused dispositiv refusal at T=0, domain outcome only; does not itself represent execution authorization
NO_DECISIONthe gate was not applicable to the submitted input
DOMAIN_WORKFLOW_VOCABULARY
HUMAN_REVIEW_REQUIREDdomain workflow requires human review; this does not create execution permission, execution_right remains ABSENT until a new complete execution right is established
Execution authorization scope.
A gate verdict is not an execution permission. These fields from the manifest establish that technically.
gate_execution_authority
None
rights_graph_required
None
execution_right_states
VALID, ABSENT
capability_required_for_execution
True
six_eyes_approval_enforced
None
shamir_threshold_cosign
None
What we do not claim.
The most important part of the manifest. Deliberately given the same prominence as everything else.
- immo.quick is not a certification body, a registrar, or an accreditation authority.
- Nothing here establishes regulatory compliance. No compliance status is determined automatically by this manifest or by the chain it describes.
- This manifest is a description of implemented mechanism, not a warranty, an audit opinion, or a guarantee of future behaviour.
- Not every gate runs on every transaction. The active gate set is tenant- and sector-specific.
- Not every receipt is individually blockchain-anchored. Anchoring is periodic and per-window.
- Sovereign multi-witness anchoring is in placeholder status, witness contracts are pending.
- The authority chain does not claim that every authority source is legitimate. It claims that every receipt's authority source is traceable, verifiable, and revocable.
- No score is derived anywhere in this model. Reliability is observed and counted, never judged or ranked.
- The platform does not provide legal advice. All compliance analysis is positioned as forensic divergence testing (Divergenzanalyse), not legal opinion.
- A gate PASS is not execution permission. Gates provide domain determination. The Execution Rights Graph deterministically resolves whether an already authoritatively grounded execution right exists. These are separable and independently verifiable.
- The system does not create authority. It binds execution to authority that already exists, provenance is verified, never invented.
Known limitations.
- The T0-T4 architecture is implemented and internally verified for the gates listed in gate_catalog. External sovereign witness participation remains pending. Not every sector deploys the full gate catalog, the active gate set is tenant-specific.
- Sovereign multi-witness anchoring (T4) is periodic and per-window, not per-request. Individual receipts are provably chain-bound; the anchor proves the chain was intact at the window boundary.
- Witness contracts for sovereign anchoring are in placeholder status, the architecture is deterministic, the witness agreements must be concluded before production.
- ML-DSA-65 post-quantum signatures are implemented and persisted. NIST FIPS-204 standardisation is final; production rollout follows standard publication.
- In most domains, failure of a mandatory condition results in an ABSENT execution right. No ExecutionCapabilityToken is created and consequence-bearing execution therefore has no executable path.
- In rights-sensitive domains (social benefits, employment termination), a critical domain condition may produce HUMAN_REVIEW_REQUIRED as a workflow outcome. This does not create execution permission; execution_right remains ABSENT until a new complete execution right is established.
- Authority invalidation follows explicit authority provenance and authorization-state dependencies. Merkle-chain linkage remains an integrity relation and does not by itself create normative dependency between receipts.
- Execution authorization requires that all five closure nodes (AUTHORITY, RULE, JURISDICTION, TIME, DEPENDENCY) close at T0 for a capability to exist. At ABSENT, a NegativeExecutionRightProof seals that every admissible path was traversed, not merely that the requested ref was invalid.
- A CapabilityInvalidationRecord may only exist when a valid GovernanceAuthorityProof establishes the authoritative basis for that exact mutation. Not an administrator, not an internal process, not the system itself. The system does not create authority, it binds execution to it.
Public does not mean searchable.
Two different things are deliberately separated here, and this separation is the actual boundary of public verification, not an afterthought.
PUBLIC
The capabilities manifest and the public key set (JWKS). Both are standards documents, not a secret, not tenant data. Anyone may read them, that was the point of publishing them.
NOT PUBLIC
The individual receipt itself. There is no search endpoint, no listing, no way to browse receipts by tenant, time range, or verdict. Whoever wants to verify a receipt must already possess it.
This hurdle is intentional, not a gap. A receipt reaches a verifying party through a legitimised context, as the recipient of an Accountable Receiving Boundary, as an auditor or regulator requesting it, or as the affected person exercising their right of access under GDPR Art. 15. We provide the cryptography. Who receives the receipt and what it discloses is decided by the tenant that sealed it, not by the platform.
How do we recognise the authorised verifier? We do not, and that is deliberate.
Authorisation happens upstream, not at verification. The verifier is not authorised by us, but by the tenant, at the moment the tenant decides to share the receipt. Authorisation is the act of sharing itself, it lives in the business relationship, not in our infrastructure. We keep no list of authorised verifiers, check no identity, issue no login, and have no visibility into who verifies.
If we recognised the verifier, we would become the trust arbitrator, exactly what the architecture is meant to prevent. Verification is identity agnostic, it checks whether the receipt is genuine, not who is checking it. The boundary sits at possession, not identity: whoever has the receipt may check it, whoever does not have it gets none.
CHANNEL CONTROL
The tenant shares the receipt over a trusted channel, hand delivery, an encrypted auditor vault, a regulatory portal. Whoever lacks the channel does not get the receipt. This is the primary control.
RECEIPT-INTERNAL USE POLICY
An optional authorized_verifier_scope field declares the intended verifier and a deadline. This is not a technical lock, whoever has the receipt can still verify it, but violating the declaration is forensically traceable.
SCOPED SHARE TOKEN
A share link with an embedded recipient hash, optional, not the default, because it would tie verification to an online check and break offline verifiability.
All three layers sit with the tenant, not with us. Our job is to get the cryptography right and never expose receipts, not to check identities. Whoever shares, authorises. Whoever possesses, may verify.
Frequently asked questions about public verification.
Is verification free?
Yes. Anyone who holds a receipt can verify it for free against the public proof JWKS. The paid boundary is the licensed intake, the Accountable Receiving Boundary, that seals receipts for an institution. Verifying an already sealed receipt costs nothing and requires no account.
What happens to my privacy?
Verification transmits only cryptographic material, public keys, hashes, and the receipt's canonical payload. No personal data is transmitted to check a signature. Personal data embedded in receipts is encrypted field by field with separate encryption keys. Once the statutory retention period expires, those keys are destroyed (crypto shredding), while the hash chain stays intact. The verifier sees only what the receipt's author included in the receipt, nothing beyond that.
Are there API calls, is a server contacted?
Yes. Verification fetches the public proof JWKS (the Ed25519 and ML-DSA-65 public keys) and the receipt being checked. Both are read only public endpoints. No write path, no session, no telemetry to the sealing tenant. The JWKS is freely publishable, it contains no secret.
Is a login required?
No. Anonymous verification is the explicit design intent, no credential required, because the public keys are public by definition. A verifier needs nothing beyond the receipt and the public JWKS. A login exists only on the institutional side, at the operator that seals receipts, not at the party checking them.
Why this separation?
The separation is deliberate: sealing is licensed and accountable. Verification is open and anonymous. One side carries the liability, the other carries the proof.
Just as readable for machines as for people.
The canonical manifest lives at a fixed, versioned URL, with a content digest and a manifest digest for integrity checking.
canonical_url: https://immoquick.eu/immoquick-capabilities.json
architecture_version: 1.4.0
rule_package_version: 2.0.0
content_digest: sha256:09085929ce5d2b7d04c1b75635f5f5af61b074050dfb5b703a4fc7993c8459e5
manifest_digest: sha256:b2ffb90d5c47aa0c726eab2526a93bc2858c7247532104f461ec40eccab08c50