Die Kette, T0 bis T4.
Fünf Stufen, jede mit einer eigenen Zusicherungsart. Nicht jede Stufe ist von außen prüfbar, und das Manifest sagt das offen, statt es zu verschweigen.
T0
Ursprung der Autorität
INTERN
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
Deterministische Gate-Evaluierung
INTERN
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
Versiegelung des Belegs
ÖFFENTLICH PRÜFBAR
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
Kettenbindung
ÖFFENTLICH PRÜFBAR
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
Souveräne Multi-Zeugen-Verankerung
INTERN
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
Kryptografische Primitive.
Klassisch und quantenresistent in einem Artefakt, keine proprietäre Kryptografie.
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
Der Gate Catalog, 20 Kategorien.
Der vollständige Katalog aus dem Manifest. Für jedes einzelne Gate mit Rechtsgrundlage und Beispielen siehe die 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 weitere
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 weitere
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 weitere
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 weitere
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 weitere
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 weitere
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 weitere
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 weitere
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 weitere
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 weitere
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
Die kontrollierten Vokabulare.
Jede Aussage im Manifest verwendet eines dieser Vokabulare, keine Freitext-Interpretation.
ASSURANCE_VOKABULAR
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_ROLLEN_VOKABULAR
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
AUTORISIERUNGS_VOKABULAR
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_VOKABULAR
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_VOKABULAR
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_VOKABULAR
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.
Ein Gate-Urteil ist keine Ausführungserlaubnis. Diese Felder aus dem Manifest legen das technisch fest.
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
Was wir nicht behaupten.
Der wichtigste Teil des Manifests. Absichtlich genauso prominent wie alles andere.
- 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.
Bekannte Einschränkungen.
- 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.
Öffentlich heißt nicht durchsuchbar.
Zwei verschiedene Dinge werden hier bewusst getrennt, und diese Trennung ist die eigentliche Grenze der öffentlichen Verifikation, nicht ein Nachgedanke.
ÖFFENTLICH
Das Capabilities-Manifest und der öffentliche Schlüsselsatz (JWKS). Beides sind Standards-Dokumente, kein Geheimnis, keine Mandantendaten. Jeder darf sie lesen, das war der Zweck ihrer Veröffentlichung.
NICHT ÖFFENTLICH
Das einzelne Receipt selbst. Es gibt keinen Such-Endpoint, keine Liste, keine Möglichkeit, Receipts nach Mandant, Zeitraum oder Verdict zu durchsuchen. Wer ein Receipt verifizieren will, muss es bereits besitzen.
Diese Hürde ist Absicht, nicht Lücke. Ein Receipt gelangt in legitimiertem Kontext zu einer verifizierenden Partei, als Empfänger einer Accountable Receiving Boundary, als Auditor oder Regulator, der es anfordert, oder als betroffene Person, die von ihrem Auskunftsrecht nach Art. 15 DSGVO Gebrauch macht. Die Kryptografie stellen wir bereit. Wer das Receipt bekommt und was darin offengelegt wird, entscheidet der Mandant, der es versiegelt hat, nicht die Plattform.
Woran erkennen wir den autorisierten Prüfer? Gar nicht, das ist Absicht.
Die Autorisierung passiert upstream, nicht bei der Verifikation. Der Prüfer wird nicht von uns autorisiert, sondern vom Mandanten, in dem Moment, in dem dieser entscheidet, das Receipt zu teilen. Die Autorisierung ist der Akt des Teilens selbst, sie lebt in der Geschäftsbeziehung, nicht in unserer Infrastruktur. Wir führen keine Liste autorisierter Prüfer, prüfen keine Identität, stellen kein Login aus und haben keinen Einblick, wer verifiziert.
Würden wir den Prüfer erkennen, wären wir der Vertrauensarbitrator, genau das soll die Architektur verhindern. Die Verifikation ist identitätsagnostisch, sie prüft, ob das Receipt echt ist, nicht wer es prüft. Die Grenze liegt beim Besitz, nicht bei der Identität: wer das Receipt hat, darf es prüfen, wer es nicht hat, bekommt keines.
KANAL-KONTROLLE
Der Mandant teilt das Receipt über einen vertrauenswürdigen Kanal, persönliche Übergabe, verschlüsselter Auditoren-Tresor, regulatorisches Portal. Wer den Kanal nicht hat, bekommt das Receipt nicht. Das ist die primäre Kontrolle.
NUTZUNGSPOLITIK IM RECEIPT
Ein optionales Feld authorized_verifier_scope deklariert den vorgesehenen Prüfer und eine Frist. Das ist keine technische Sperre, wer das Receipt hat, kann trotzdem verifizieren, aber ein Verstoß gegen die Deklaration ist forensisch nachvollziehbar.
SCOPED SHARE-TOKEN
Ein Share-Link mit eingebettetem Empfänger-Hash, optional, nicht Standard, weil er die Verifikation an eine Online-Prüfung binden würde und damit die Offline-Verifizierbarkeit bricht.
Alle drei Ebenen liegen beim Mandanten, nicht bei uns. Unsere Aufgabe ist es, die Kryptografie korrekt zu machen und keine Receipts preiszugeben, nicht, Identitäten zu prüfen. Wer teilt, autorisiert. Wer besitzt, darf prüfen.
Häufige Fragen zur öffentlichen Verifikation.
Ist die Verifikation kostenlos?
Ja. Jede Person, die ein Receipt besitzt, kann es kostenlos gegen den öffentlichen Proof-JWKS verifizieren. Die kostenpflichtige Grenze ist die lizenzierte Aufnahme (Accountable Receiving Boundary), die Receipts für eine Institution versiegelt. Die Verifikation eines bereits versiegelten Receipts kostet nichts und erfordert kein Konto.
Was passiert mit meiner Privatsphäre?
Die Verifikation überträgt ausschliesslich kryptografisches Material, öffentliche Schlüssel, Hashes und die kanonische Payload des Receipts. Es werden keine persönlichen Daten übertragen, um eine Signatur zu prüfen. In Receipts eingebettete personenbezogene Daten sind feldweise über separate Verschlüsselungs-Schlüssel verschlüsselt. Nach Ablauf der gesetzlichen Aufbewahrungsfrist werden diese Schlüssel vernichtet (Crypto-Shredding), während die Hash-Chain intakt bleibt. Der Verifizierer sieht nur das, was der Receipt-Autor in das Receipt aufgenommen hat, nichts darüber hinaus.
Finden API-Aufrufe statt oder wird ein Server kontaktiert?
Ja. Die Verifikation ruft den öffentlichen Proof-JWKS (die Ed25519- und ML-DSA-65-öffentlichen Schlüssel) sowie das zu prüfende Receipt ab. Beides sind schreibgeschützte öffentliche Endpunkte. Kein Schreibpfad, keine Sitzung, keine Telemetrie an den versiegelnden Mandanten. Der JWKS ist frei veröffentlichbar, er enthält kein Geheimnis.
Ist ein Login erforderlich?
Nein. Anonyme Verifikation ist die ausdrückliche Designabsicht, kein Zugangsnachweis nötig, weil die öffentlichen Schlüssel per Definition öffentlich sind. Ein Verifizierer benötigt nichts ausser dem Receipt und dem öffentlichen JWKS. Ein Login existiert nur auf der institutionellen Seite, beim Betreiber, der Receipts versiegelt, nicht bei der Partei, die sie prüft.
Warum diese Trennung?
Die Trennung ist bewusst: Versiegelung ist lizenziert und rechenschaftspflichtig. Verifikation ist offen und anonym. Eine Seite trägt die Haftung, die andere den Beweis.
Für Maschinen genauso lesbar wie für Menschen.
Das kanonische Manifest steht unter einer festen, versionierten URL, mit Inhalts- und Manifest-Digest zur Integritätsprüfung.
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