Sprache:

immo.quick · Verständlich erklärt

Wie aus einer Befugnis eine erlaubte Handlung wird.

Die Architektur beantwortet eine konkrete Frage: Darf diese Handlung unter den jetzt geltenden Bedingungen stattfinden? Dazu trennt sie die Herkunft einer Befugnis, die Prüfung der Voraussetzungen, die technische Berechtigung und den Nachweis der tatsächlichen Ausführung.

Ein Beispiel: Eine Freigabe wird zurückgenommen.

Die alte Freigabe bleibt möglicherweise in einem Fachsystem sichtbar. Entscheidend ist aber die aktuelle Befugnis. Der kontrollierte Ausführungsweg muss deshalb den geltenden Zustand berücksichtigen, bevor die Handlung Wirkung erzeugt. Eine erfolgreiche Einzelprüfung ersetzt diese Entscheidung nicht.

Zwei Systeme. Klare Architekturgrenzen.

Die immo.quick Serverless Edition nutzt keine Trusted Execution Environments (TEEs) und keine Enclaves. TEE- und Enclave-Technologien werden ausschließlich in immo.quick Core genutzt. Beide Produkte sind eigenständige Systeme. Core ist keine Voraussetzung für die Serverless Edition.

Die Serverless Edition prüft definierte Bedingungen am integrierten Ausführungspfad und dokumentiert die Entscheidung kryptografisch nachvollziehbar. Eine TEE-Attestierung ist kein Bestandteil ihrer Architektur. Hardwaregestützte Isolation und Enclave-Attestierung gehören zum Core-Architekturprofil.

immo.quick Serverless Edition · immo.quick Core

Was zusammenpassen muss.

Wer darf handeln? Welche Regeln gelten? In welchem Rechtsraum? Zu welchem Zeitpunkt? Welche weiteren Voraussetzungen sind zwingend? Fehlt eine erforderliche Grundlage, entsteht kein gültiges Ausführungsrecht. Die technische Einbindung muss dieses Ergebnis am tatsächlichen Ausführungsweg durchsetzen.

Die Fragen hinter dem Ablauf

  1. 1

    Gegenstand

    Was genau soll geprüft oder geschützt werden?

  2. 2

    Grundlagen

    Welche Befugnisse, Regeln und Nachweise sind maßgeblich?

  3. 3

    Prüfung

    Welche Bedingungen sind erfüllt, welche fehlen?

  4. 4

    Beleg

    Was wurde tatsächlich festgestellt oder ausgeführt?

Orientierungsskizze: Die konkrete Prüfung und Integration hängen vom jeweiligen System und Einsatz ab.

Der nächste Schritt

Beschreiben Sie einen konkreten Vorgang und die beteiligten Systeme. Gemeinsam lässt sich bestimmen, welche Grundlagen benötigt werden und welcher Prüfweg den Einsatz belegen muss.

Gespräch anfragen

Passende Vertiefung finden

Kurz erklärt

Wie funktioniert die Machine-Law-Architektur?

Sie trennt die maßgebliche Befugnis, die Prüfung der Voraussetzungen, das aktuelle Ausführungsrecht, die begrenzte technische Berechtigung und die tatsächliche Wirkung. Eine erfolgreiche Einzelprüfung erteilt für sich allein keine Ausführungserlaubnis.

Technische Dokumentation und bestehende Prüfwerkzeuge öffnen

Hier bleibt die bisherige Fachreferenz zugänglich. Ihre technischen Bezeichnungen und historischen Prüfaussagen sind im jeweiligen dokumentierten Umfang zu lesen; sie sind keine pauschale Betriebsfreigabe.

Institutional Trust Infrastructure →
DIE AKTUELLE ARCHITEKTUR

Von institutioneller Befugnis zur kontrollierten Ausführung.

Die Architektur trennt maßgebliche Quellen, Regelprüfung, Ausführungsrecht, Capability und tatsächlichen Vollzug. Diese Trennung verhindert, dass ein positives Prüfergebnis oder ein administrativer Zugriff allein als Erlaubnis zur Ausführung gilt. Der Nachweis hält fest, auf welcher Grundlage eine Handlung freigegeben oder blockiert wurde.

AUTORITATIVE QUELLE
NORMATIVER ZUSTAND
DOMAIN-BESTIMMUNG
EXECUTION-RIGHTS-CLOSURE
GEBUNDENE CAPABILITY
AUSFÜHRUNGSEBENE
EVIDENZ
DIE AUTORITÄT DEFINIERT DIE BEDINGUNGEN. DAS SYSTEM LÖST DEREN AUSFÜHRUNGSWIRKUNG DETERMINISTISCH AUF. DIE AUSFÜHRUNGSEBENE ENTSCHEIDET NICHTS.
Kanonische Ausführungsgrenze: Authority liegt vor Determination, Execution Rights und Capability.
Kanonische Ausführungsgrenze: Authority liegt vor Determination, Execution Rights und Capability.
CODED VISUAL · AUTHORITY PATH

Eine harte Grenze zwischen Wissen und Handlungsrecht.

Die Darstellung ist kein Prozessdiagramm mit Laufzeitbehauptung. Sie visualisiert ausschließlich die öffentlichen Architekturschichten und ihre Trennung.

AUTHORITY → STATE → DETERMINATION → CLOSURE → CAPABILITY → EXECUTION PLANE → EVIDENCECLAIM-SAFE ARCHITECTURE VIEW
01
AUTHORITATIVE QUELLEEXTERNAL ORIGIN
02
NORMATIVER ZUSTANDBOUND INPUT
03
DOMAIN-BESTIMMUNGDETERMINATION
04
EXECUTION RIGHTS CLOSUREA · R · J · T · D
05
GEBUNDENE CAPABILITYSTATE-BOUND
06
AUSFÜHRUNGSEBENENO GOVERNANCE AUTHORITY
07
EVIDENZPROVENANCE / BINDING
Ein Gate-Urteil erzeugt keine externe Authority.
EXECUTION RIGHTS GRAPH

Fünf Dimensionen müssen geschlossen sein.

A

Autorität

Wer die relevante Kompetenz legitim innehat oder den autoritativen Zustand setzt.

R

Regel

Welcher governte Regelzustand auf die konkrete Handlung anwendbar ist.

J

Jurisdiktion

Welcher rechtliche oder institutionelle Raum die Handlung bestimmt.

T

Zeit

Ob Autorität, Regel und relevanter Zustand an der Ausführungsgrenze weiterhin gültig sind.

D

Abhängigkeit

Welche weiteren zwingenden Bedingungen vorliegen müssen, bevor die Konsequenz technisch ausführbar werden darf.

5/5 ERFORDERLICHE BEDINGUNGEN GESCHLOSSEN → AUSFÜHRUNGSRECHT KANN BESTEHEN · FEHLT EINE ERFORDERLICHE DIMENSION → KEIN GÜLTIGES AUSFÜHRUNGSRECHT
SCHICHTGRENZEN

Was jede Schicht tun kann — und was nicht.

Gate-Katalog

KANN Kodierte Domain-Bedingungen deterministisch bestimmen.

KANN NICHT Ausführungserlaubnis oder institutionelle Autorität erzeugen.

Execution-Rights-Schicht

KANN Auflösen, ob der modellierte autoritative Zustand einen gültigen Ausführungspfad begründet.

KANN NICHT Autorität erzeugen, die außerhalb des Systems nicht existiert.

Ausführungsebene

KANN Capability und Zustandsbindung prüfen, ausführen, die Capability verbrauchen und Evidenz aufzeichnen.

KANN NICHT govern, Policy neu interpretieren oder ein eigenes Handlungsrecht erzeugen.

Evidenzschicht

KANN Integrität, Provenienz, Zustandsbindung und Ausführungsbeziehung bewahren.

KANN NICHT Falsche Eingaben in Wahrheit verwandeln oder eine materielle rechtliche Bewertung ersetzen.

Eine Architektur. Klare Grenzen.

Diese Kurzfassung ist für technische Due Diligence, Suchmaschinen und maschinelle Retrieval-Systeme formuliert. Sie ersetzt weder die Spezifikation noch die Evidenzartefakte.

KATEGORIEInstitutional Trust Infrastructure
AUTORITÄTExtern; wird nicht durch das System erzeugt
GATESDomain-Gates bestimmen; Kontrolloberflächen verifizieren/binden/erzwingen; keine erzeugt Ausführungserlaubnis
EXECUTION RIGHTSClosure über Authority, Rule, Jurisdiction, Time, Dependency
CAPABILITYGebundener technischer Ausführungsträger nach vollständiger Closure
EVIDENZBelegt Integrität und Bindung; keine automatische materielle Rechtsrichtigkeit
CROSS-LAW DEPENDENCY ENGINE

Rechtsinteraktionen werden sichtbar, ohne Rechtsautorität zu erfinden.

115 versionierte Rechtsinstrumente → autoritätsgebundener Katalogzustand → Dependency/Pattern Match → institutionelle Execution Policy → Determination → Receipt. Authority Composition und Interaction Profile bleiben als strukturierte Outputs sichtbar. Die State Reality Consistency Boundary trennt zusätzlich autoritativen Zustand von physischer Wahrheit: Reality-linked Evidence kann Execution invalidieren, ohne selbst Authority zu werden. Bei physischen Attestations ist explizit verifizierte Provenance eine Closure-Bedingung.

STATE-REALITY ASSURANCE · UNIVERSAL PRE-AUTHORITY BOUNDARY

Nur weil das System etwas sieht, darf es noch lange nichts tun.

SRA trennt Runtime und beobachtete Realität von Authority und Execution. 20 formale Invarianten, eine nicht-kompensierbare Schwellenwert-Engine und 46/46 modellierte Szenarien mit erwartetem Outcome. Reality darf Authority informieren. Sie darf sie niemals erzeugen.

ACATS · RED-TEAM VERIFICATION

Intern getestet. Extern bestätigt. Extern reproduziert.

120 modellierte Angriffsszenarien gegen die Authority-Grenze. 105 Expected-Negative-Tests, 15 positive Kontrollen, 0 unerwartete Fehler. Der externe Prüfer beaufsichtigte und bestätigte die interne Prüfung und reproduzierte den Teststand zusätzlich in einer eigenständigen externen Ausführung.

120/1200 unexpected failures8× S5 geblocktRELEASE_READY
ACATS Red-Team-Test ansehen →

Was ein Nachweis tatsächlich belegt

Ein Receipt dokumentiert einen bestimmten Zustand oder Vorgang. Für die Beurteilung zählt deshalb nicht nur, ob seine Integrität überprüfbar ist, sondern welches Ereignis es bindet und welche Quellen, Regeln und Ausführungsdaten vorliegen.

Prüfergebnis

Ein Gate stellt fest, ob seine formal definierten Bedingungen erfüllt sind. Ein PASS erteilt für sich allein kein Ausführungsrecht.

Execution Right

Befugnis, Regelstand, Rechtsraum, Zeit und verpflichtende Abhängigkeiten müssen für die konkrete Handlung zusammenpassen.

Capability

Eine eng gebundene technische Berechtigung kann aus einem gültigen Ausführungsrecht folgen. Ihre Ausgabe belegt noch keinen Vollzug.

Tatsächlicher Effekt

Erst der dokumentierte Vollzug belegt die ausgeführte Handlung. Integrität allein garantiert weder Quellenwahrheit noch rechtliche Anerkennung.

Aussagegrenzen und Nachweisumfang

Das Buch zur Frage vor der Wirkung

Der Moment davor · Rami Cherri

Machine Law, KI-Governance und Ausführungsrechte verständlich erklärt. Die deutsche Fassung hat 386 Seiten. Hardcover, Softcover und E-Book sind mit eigenen ISBN und direkten Links zu tredition, Amazon und buecher.de auf der Buchseite aufgeführt.

Ausgaben, ISBN und Händler ansehen
INSTITUTIONELLER PRÜFPFAD