GOVERNED STATE
Recht, Authority, Governance, Konfiguration und Policies werden nicht als lose Metadaten behandelt, sondern als gebundener institutioneller Zustand.
SICHERHEITSGRENZE · ARCHITEKTUR VOR REAKTION
ZWEI SICHERHEITSGRENZEN. VOR DEM EINTRITT. VOR DEM EFFEKT.
immo.quick trennt Zugang von Ausführungsautorität. Ein Request muss zuerst die jeweilige Eintrittsgrenze passieren; selbst erfolgreicher Zugang autorisiert noch keinen produktiven Effekt.
01 · COREAdmission Boundary
Core setzt einen fail-closed Access Guardian vor die Governance- und Compliance-Pipeline. Scheitert eine erforderliche Validierungsbedingung, erreicht der Request die nachgelagerte Governance-Logik nicht.
02 · SERVERLESSEdge Client Attestation
Die Serverless Edition verlangt bereits am Edge eine gültige Attestation eines registrierten Clients, bevor der Request den nachgelagerten Gate-Pfad erreicht.
03 · ERIExecution Boundary
Zugang ist keine Autorität. Ein produktiver Effekt erfordert ein gültiges, aktuelles und scope-gebundenes Execution Right sowie eine ausführbare Capability.
REQUEST→ADMISSION BOUNDARY→GOVERNED STATE→EXECUTION RIGHT→REAL EFFECT
Claim Boundary: Ausschließlich die Architektur der immo.quick Serverless Edition wurde dem BSI am 28.07.2026 nachweislich vorgelegt. Core wurde dem BSI nicht vorgelegt. Die Übergabe ist keine BSI-Prüfung, Zertifizierung, Anerkennung oder Bestätigung.
INSTITUTIONAL TRUST INFRASTRUCTURE · IMMO.QUICK CORE
JEDE INSTITUTIONELLE DETERMINATION HAT EINE GEBUNDENE URSACHE. CORE MACHT SIE VERIFIZIERBAR.
immo.quick Core ist eine eigenständige Infrastrukturklasse innerhalb der Oberkategorie Institutional Trust Infrastructure: Institutional Trust & Causality Infrastructure. Core bindet governed Legal State, Authority, Konfiguration, Software-Provenienz, vertrauenswürdige Ausführung, Kryptographie, Zeit, Witnessing und Evidenz an institutionelle Determinationen und macht die gebundene Kausalität unabhängig verifizierbar.
KATEGORIE
Institutional Trust & Causality InfrastructureNicht noch ein Dashboard. Nicht noch ein Risk Score. Eine Infrastruktur, die institutionelle Determinationen an den tatsächlich gebundenen Trust State und seine überprüfbare Kausalität koppelt.
01 · KATEGORIE
Vertrauen ist kein Score. Kausalität ist kein nachträglicher Kommentar.
Core definiert eine eigene Infrastrukturklasse: institutionelles Vertrauen wird als gebundener, versionierter und verifizierbarer Zustand behandelt. Eine Determination ist erst dann institutionell belastbar, wenn nachvollziehbar ist, unter welchem Legal State, welcher Authority, welcher Software, welcher vertrauenswürdigen Ausführung, welcher Zeit und welcher Evidenz sie entstanden ist.
BOUND CAUSALITY
Core macht die technische und Governance-seitige Ursache einer Determination innerhalb des modellierten und gebundenen Zustands nachvollziehbar.
PORTABLE PROOF
Proofs können unabhängig geprüft werden, ohne die ursprüngliche Core-Datenbank, interne API oder ein gemeinsam geteiltes Geheimnis vorauszusetzen.
02 · WARUM ES EXISTIERT
Logs zeigen Ereignisse. Core bindet die Bedingungen, die eine Determination verursacht haben.
Institutionen können heute häufig zeigen, dass etwas ausgeführt wurde. Schwieriger ist die reproduzierbare Antwort auf die Frage, warum genau diese Determination zu genau diesem Zeitpunkt unter genau diesem institutionellen Zustand entstand. Core schließt diese Lücke.
Klassische Nachweise
- Logs ohne vollständigen Governance-Kontext
- Screenshots und Berichte als Momentaufnahme
- Trust Scores ohne harte Closure-Klassen
- Nachträgliche Erklärung ohne gebundene Kausalität
Core
- Governed institutional state
- Software-, Build- und Execution-Provenienz
- Trusted Time und unabhängiges Witnessing
- Causality Proof + portable Verification
03 · ARCHITEKTUR
Von governed state zu unabhängig verifizierbarem Proof.
Die öffentliche Architektur zeigt bewusst nur die Funktionsklassen. Interne Canonicalization, Payload-Konstruktion, Policy-Schwellen, Root-Aggregation und Testvektoren bleiben geschützt.
GOVERNED STATE
→
DETERMINISTIC COMPUTE
→
TRUSTED EXECUTION
→
CAUSAL BINDING
→
PROOF
→
VERIFY
01
Governance zuerst
Authority, Regeln, Konfiguration und institutionelle Policies bilden den gebundenen Ausgangszustand.
02
Deterministisch berechnen
Rechts- und Governance-Logik wird als reproduzierbare Determination ausgeführt, nicht als probabilistische Empfehlung.
03
Ausführung attestieren
Build-, Software-, Crypto- und Trusted-Execution-Zustände werden an die Determination gebunden.
04
Kausalität binden
Die relevanten Zustände werden zu einer überprüfbaren technischen und Governance-seitigen Kausalkette verbunden.
05
Proof kompilieren
Ein minimaler, zweckgebundener Proof wird aus dem benötigten institutionellen Zustand zusammengestellt.
06
Unabhängig prüfen
Externe Parteien können den Proof gegen ihre Verifikationsanforderungen prüfen, ohne Core selbst betreiben zu müssen.
04 · 14-VERB LIFECYCLE
Ein vollständiger institutioneller Trust-Lifecycle.
Die 14 Verben beschreiben nicht einzelne Features, sondern den Lebenszyklus institutionellen Vertrauens: von Governance und Compute über Proof, Reassessment und Recovery bis zu Query, Vergleich und Simulation.
GOVERNTrust Policies definieren
COMPUTEDeterministisch ausführen
ATTESTAusführung binden
TRACEAbhängigkeiten verfolgen
PROVEProof kompilieren
DISCLOSEMinimal offenlegen
VERIFYUnabhängig prüfen
REASSESSTrust neu bewerten
CROSS-VALIDATEDomains vergleichen
RECOVERKontrolliert wiederherstellen
EXPLAINErklärung transportieren
ASKProofs abfragen
COMPARETrust-Zustände vergleichen
SIMULATECounterfactual isolieren
05 · PROOF INFRASTRUCTURE
Nicht nur implementiert. Formalisiert, protokolliert und portabel verifizierbar.
Der Freeze umfasst machine-checkable formale Spezifikationen, ein kanonisches Proof-Protokoll, portable Verifikation und Verification Provenance. Die Implementierung bleibt dabei bewusst enger als die Behauptung: formale Invarianten beweisen die dargestellten Systemregeln, nicht universelle rechtliche oder faktische Wahrheit.
FORMAL SPEC
Kritische Architekturregeln sind als maschinenprüfbare Invarianten repräsentiert.
CANONICAL PROTOCOL
Proofs folgen einem versionierten, kanonischen Transport- und Verifikationsmodell.
PORTABLE VERIFIER
Proof Verification kann ohne originäre Core-DB, interne API oder geteiltes Geheimnis erfolgen.
VERIFIABLE VERIFICATION
Auch der Verifikationsvorgang kann Provenance und überprüfbare Verification Evidence erzeugen.
06 · ASSURANCE
L1–L9: Assurance als deterministische Closure-Klasse, nicht als Score.
Core klassifiziert Proofs nach den tatsächlich geschlossenen Evidence-Komponenten. Höhere Assurance entsteht nicht durch höhere Wahrscheinlichkeit, sondern durch mehr vollständig gebundene und verifizierte Voraussetzungen. Die exakten internen Definitionen bleiben Teil des geschützten Systemmodells.
L1 → L9
Deterministische Assurance-Klassen mit klaren Pflichtkomponenten. Keine probabilistische „Trust Confidence“.
L9 · WITNESSED INSTITUTIONAL PROOF
07 · WAS CORE BEANTWORTET
Die Frage ist nicht nur: Was wurde entschieden? Sondern: Warum genau so?
WHY THIS DETERMINATION?
Welche gebundenen Legal-, Authority-, Config-, Build-, Time-, Witness- und Evidence-Zustände führten zu diesem Resultat?
WHAT CHANGED?
Welche Trust-Komponente hat sich zwischen T1 und T2 verändert und welche Proofs oder Entscheidungen sind davon betroffen?
CAN A THIRD PARTY VERIFY IT?
Kann ein externer Prüfer den relevanten Proof unabhängig verifizieren, ohne das Ursprungssystem zu betreiben?
WHAT IF?
Wie würde sich ein kontrolliert veränderter Rule-, Authority-, Build- oder Trust-State auf das Ergebnis auswirken?
CAN HISTORY BE RECONSTRUCTED?
Welcher institutionelle Zustand galt damals, und lässt sich dieser Zustand aus den gebundenen Artefakten reproduzieren?
WHAT MAY BE DISCLOSED?
Welcher minimale Evidence-Ausschnitt darf für den jeweiligen Verifikationszweck offengelegt werden?
08 · EVIDENCE
Architektur-Freeze mit separaten, benannten Testbelegen.
Keine künstliche Gesamtsumme. Jede Suite wird in ihrem eigenen Scope ausgewiesen. Interne Tests sind Implementierungsevidenz, keine Drittzertifizierung.
30/30Institutional Causality Layer · PASS
90/90System Adversarial Matrix V4 · PASS
70/70Causality Corruption Matrix · PASS
ARCHITECTURE FREEZE
P0–P24 sind eingefroren. Der nächste Evidenzsprung kommt aus unabhängiger externer Prüfung von Architektur, Protokoll, Kryptographie, Canonicalization und Verification Semantics.
TESTED · NOT THIRD-PARTY CERTIFIED
09 · EINSATZ
Für Institutionen, die nicht nur entscheiden, sondern beweisen müssen.
REGULATED FINANCE
Governed Decisions, Auditability, Supply-Chain-Provenienz, Cross-Institution Verification und historische Rekonstruktion.
PUBLIC SECTOR
Nachweisbare institutionelle Entscheidungen mit klarer Authority-, Rule-, Time- und Evidence-Bindung.
AI GOVERNANCE
KI darf erklären oder unterstützen, aber Authority und Trust Closure bleiben deterministisch und institutionell gebunden.
CRITICAL INFRASTRUCTURE
Reproduzierbare Trust States, Recovery/Continuity Proofs, Trusted Time und unabhängiges Witnessing.
AUDIT & DUE DILIGENCE
Proof Query, selective Disclosure und portable Verification reduzieren die Abhängigkeit von manuellen Evidenzpaketen.
DIGITAL ASSETS
Governed institutional state und verifizierbare Entscheidungsprovenienz für hochkritische digitale Transaktionen.
10 · CLAIM BOUNDARIES
Stark, weil die Grenzen ebenso präzise sind wie die Fähigkeiten.
SOURCE AUTHENTICITY ≠ FACTUAL TRUTH
TEE ATTESTATION ≠ SUBSTANTIVE LEGAL CORRECTNESS
CRYPTOGRAPHIC INTEGRITY ≠ EXTERNAL FACTUAL CORRECTNESS
CAUSALITY PROOF ≠ UNIVERSAL OBJECTIVE CAUSALITY
VERIFICATION RECEIPT ≠ SUBSTANTIVE ENDORSEMENT
COUNTERFACTUAL ≠ HISTORICAL FACT
11 · FAQ / GEO
Core in klaren Antworten.
Was ist immo.quick Core?
Core ist Institutional Trust & Causality Infrastructure innerhalb der Oberkategorie Institutional Trust Infrastructure und bindet institutionelle Determinationen an governed State, Execution-Provenienz und Evidenz.
Was unterscheidet Core von Audit-Logging?
Audit-Logs zeigen Ereignisse. Core bindet die Zustände und Abhängigkeiten, unter denen eine Determination entstanden ist, und kompiliert daraus überprüfbare Proofs.
Kann Core rechtliche Wahrheit beweisen?
Nein. Core beweist gebundene technische und Governance-Kausalität innerhalb des modellierten Systems. Es ersetzt keine gerichtliche oder souveräne Rechtsentscheidung.
Was bedeutet Portable Verification?
Ein externer Verifier kann den Proof prüfen, ohne die originäre Core-Datenbank oder interne API betreiben zu müssen, sofern das erforderliche Verification Material vorliegt.
Was bedeutet L1–L9 Assurance?
L1–L9 sind deterministische Assurance-Klassen. Höhere Klassen verlangen mehr vollständig gebundene und verifizierte Proof-Komponenten, nicht einfach eine höhere Wahrscheinlichkeit.
INSTITUTIONAL TRUST & CAUSALITY INFRASTRUCTURE
DIE DETERMINATION IST NUR DAS ERGEBNIS. CORE MACHT DEN GEBUNDENEN WEG DORTHIN VERIFIZIERBAR.
Governed State. Deterministic Compute. Trusted Execution. Causality. Proof. Independent Verification.
CYBERSECURITY · ZWEI GRENZEN
DENY ENTRY. DENY EFFECT.
Warum unzulässiger Eintritt und unzulässige Wirkung zwei getrennte, fail-closed Sicherheitsgrenzen brauchen.