STATE-REALITY ASSURANCE · SRA
DIE VORGRENZE VOR AUTHORITY

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

Moderne Systeme sehen unglaublich viel: Sensoren melden Zustände, APIs liefern Status, Fahrzeuge senden Telemetrie und KI-Agenten interpretieren Ereignisse. Das Problem beginnt, wenn aus einer Beobachtung stillschweigend eine Befugnis wird. Genau dort setzt State-Reality Assurance an.

SRA entscheidet nicht, ob eine Wirkung erlaubt ist. SRA entscheidet, ob das, was die Runtime über die Welt behauptet, überhaupt belastbar genug ist, um der Authority-Ebene vorgelegt zu werden.
Reality may influence the question. It may never write the answer.
20SRA-INVARIANTEN
46/46MODELLIERTE EXPECTED OUTCOMES
0BOUNDARY-BYPASS BEOBACHTET
falseexecution_permitted
DAS PROBLEM

Beobachtung ist noch keine Wahrheit. Wahrheit ist noch keine Authority.

Ein Sensor kann korrekt messen. Eine API kann erreichbar sein. Ein Agent kann eine Lage perfekt beschreiben. Und trotzdem darf daraus nicht automatisch eine reale Wirkung entstehen. Denn Beobachtung beantwortet nur: „Was scheint gerade der Fall zu sein?“ Authority beantwortet eine andere Frage: „Was darf daraus folgen?“

01 · SENSOR
„Die Tür ist offen.“

Das ist ein Zustand. Keine Berechtigung, die Tür zu verriegeln, einen Alarm auszulösen oder jemanden auszusperren.

02 · API
„Der Account ist aktiv.“

Das sagt nichts darüber aus, ob der Account diese konkrete Wirkung jetzt, für dieses Objekt und diesen Zweck erzeugen darf.

03 · KI-AGENT
„Ich habe genug Informationen.“

Genug Information ist keine Ausführungsbefugnis. Wissen und Authority bleiben getrennt.

DAS VISUAL

Runtime endet hier.

Die stärkste Eigenschaft von SRA ist nicht ein Score. Es ist die Grenze. Links darf die Welt beobachtet werden. Rechts beginnt Authority. Dazwischen liegt eine kontrollierte Assurance-Schleuse.

SRA ist keine weitere Authority-Familie. Es ist die universelle Vorgrenze, die bestimmt, welcher beobachtete Zustand überhaupt in Authority-Evaluation eingehen darf.

WARUM DAS ENTSCHEIDEND IST

Die gefährlichsten Fehler sehen oft plausibel aus.

SRA ist für genau die Situationen gebaut, in denen ein System formal „genug Daten“ zu haben scheint, die Daten aber für die konkrete Wirkung nicht belastbar genug sind.

FAHRZEUGEin Fahrzeug meldet: „Eigentümer unverändert.“

Die Telemetrie funktioniert. Der digitale Schlüssel funktioniert ebenfalls. Aber die Eigentumsquelle ist veraltet. SRA lässt den alten Zustand nicht einfach weiterlaufen.

STALE → CLOSURE NICHT WIEDERVERWENDBAR
KI-AGENTEin Agent meldet mit hoher Sicherheit einen Zustand.

Hohe Modellkonfidenz ist kein Provenance-Nachweis. Das Modell darf beschreiben, planen und anfordern. Es darf seinen eigenen Output nicht in Authority verwandeln.

MODEL OUTPUT → ASSURANCE, NIEMALS AUTHORITY
QUELLEN20 APIs bestätigen denselben Wert.

Wenn alle 20 auf denselben kompromittierten Upstream zurückgehen, sind es epistemisch nicht 20 unabhängige Quellen. SRA erkennt gemeinsame Provenance-Ketten.

SOURCE COUNT ≠ INDEPENDENT EVIDENCE COUNT
REPLAYEin früher gültiges Artefakt wird erneut vorgelegt.

Das Artefakt kann kryptografisch echt sein und trotzdem für den neuen Kontext nicht mehr genügen. State-, Policy-, Dependency- oder Zeitänderungen erzwingen Neubewertung.

VALID ARTIFACT ≠ CURRENT SUFFICIENCY
FÜNF EBENEN

Vom Beobachten zur Wirkung, ohne die Ebenen zu vermischen.

01 · REALITYWas geschieht?

Sensoren, APIs, Telemetrie und externe Ereignisse liefern Rohbeobachtungen.

02 · ASSURANCEWas wissen wir belastbar?

SRA prüft Herkunft, Frische, Sichtbarkeit, Konsistenz, Abhängigkeiten und Unsicherheit.

03 · AUTHORITYWas darf daraus folgen?

Erst jetzt werden Rights, Mandate, Regeln, Scope, Zweck und Jurisdiktion bewertet.

04 · EXECUTIONWelche Wirkung darf entstehen?

Nur ein geschlossener, aktueller Execution Right kann eine ausführbare Capability tragen.

05 · EVIDENCEWarum wurde erlaubt oder verhindert?

Der Receipt bindet Entscheidung, Zustand, Kontext und Ergebnis nachvollziehbar.

WAS SRA PRÜFT

Nicht „Wie viele Daten haben wir?“, sondern „Wie belastbar ist dieser Zustand?“

1
HerkunftWoher stammt die Beobachtung, und lässt sich ihre Provenienz nachvollziehen?
2
FrischeIst der Zustand für genau diese Domäne noch aktuell genug?
3
BeobachtbarkeitSehen wir wirklich den relevanten Zustand oder nur einen Ausschnitt?
4
KonsistenzWidersprechen sich Quellen in einer für die Wirkung materiellen Weise?
5
UnabhängigkeitSind mehrere Quellen tatsächlich unabhängig oder nur Kopien derselben Upstream-Quelle?
6
UnsicherheitIst die verbleibende Unsicherheit klein genug, um Authority-Evaluation überhaupt zuzulassen?
DIE WICHTIGSTE REGEL
execution_
permitted = false
IMMER · NICHT BERECHNET · NICHT ÜBERSCHREIBBAR

SRA kann niemals Execution erlauben. Auch ein perfekter Assurance-Zustand öffnet nur die Tür zur Authority-Evaluation.

GESAMTARCHITEKTUR

SRA schützt den Eingang. Continuing Authority schützt den Moment der Wirkung.

Damit entsteht eine symmetrische Architektur: Vor Authority wird geprüft, was überhaupt als belastbarer Zustand eintreten darf. Am Point of Effect wird erneut geprüft, ob das Recht noch existiert.

SRAWhat may enter Authority?
AUTHORITY CLOSUREWhat right exists?
CONTINUING AUTHORITYDoes that right still exist?
POINT OF EFFECTMay the effect occur now?
EVIDENCEWhy was it allowed or blocked?
AEG sagt: „The model may think. Authority stays outside the model.“
SRA ergänzt: „The runtime may observe. Authority stays outside the runtime.“
KONTEXT & REPLAY

Ein echtes Artefakt kann trotzdem das falsche Artefakt sein.

SRA bindet Assurance an den konkreten Entscheidungskontext. Resource, Effect Class, Domain, Tenant, Jurisdiktion, Policy-Version, Snapshot-Version, Gültigkeitsfenster und Provenance Roots gehören zusammen. Passt der Kontext nicht, reicht das Artefakt nicht.

SRA-INV-019
Assurance Context Binding

Ein Artefakt für Fahrzeug A darf nicht für Fahrzeug B, ein OTA-Artefakt nicht für Ownership und ein fremder Tenant-Kontext nicht für die aktuelle Entscheidung verwendet werden.

SRA-INV-020
No Assurance Replay

State Change, Policy Change, materielle Dependency-Änderung oder Ablauf machen ein früheres Artefakt unzureichend für einen neuen Authority Closure.

ROOT LAUNDERING
Viele Quellen sind nicht automatisch viele Beweise.

Gemeinsame Upstream-Elemente werden berücksichtigt, damit scheinbar unabhängige Quellen denselben kompromittierten Ursprung nicht verstecken können.

INTERNE VERIFIKATION

Die Grenze wird nicht nur beschrieben. Sie wird angegriffen.

Die interne adversariale SRA-Suite prüft unter anderem Threshold Downgrade, Policy/Artifact Mismatch, Artifact Replay, Cross-Domain Reuse, Root Laundering, Time Manipulation, Partial Observability, Artifact Substitution, Assurance-after-Authority und Reassessment Suppression.

46/46MODELLIERTE EXPECTED OUTCOMES
20FORMALISIERTE SRA-INVARIANTEN
0BEOBACHTETE BOUNDARY-BYPASSES
1RUNTIME-DERIVED OBJECT BEYOND THE BOUNDARY
Claim Boundary: Diese Zahlen beschreiben den aktuellen internen, modellierten und ausgeführten SRA-Teststand. Sie sind keine externe Zertifizierung, keine regulatorische Freigabe und keine Aussage universeller Sicherheit.
FÜR TECHNISCHE REVIEWER

Die technische Tiefe bleibt verfügbar. Sie steht nur nicht mehr im Weg.

Wer tiefer prüfen will, findet die formale Logik hier kompakt — nach der Erklärung, nicht davor.

E_base = P^wP · F^wF · O^wO · C^wC · D^wD · A^wA · N^wN
E = E_base · (1-U)^wU

ESTABLISHED → SUFFICIENT → DEGRADED → CONFLICTING → STALE → INSUFFICIENT → UNKNOWN

AUTHORITY_EVALUATION_PERMITTED ⇏ EXECUTION_ALLOWED
execution_permitted = false
FAQ

Die drei Fragen, die SRA sofort klären soll.

Ist SRA eine weitere Authority-Familie?

Nein. SRA liegt davor. Es ist die universelle Vorgrenze, die bestimmt, ob beobachteter Zustand ausreichend abgesichert ist, um überhaupt in Authority-Evaluation einzugehen.

Kann ein hoher SRA-Score Execution erlauben?

Nein. SRA autorisiert niemals Execution. execution_permitted bleibt konstant false. Auch ESTABLISHED oder SUFFICIENT erlauben nur den Eintritt in die Authority-Evaluation.

Warum reicht es nicht, mehrere Quellen zu haben?

Weil mehrere Quellen denselben Ursprung haben können. SRA berücksichtigt Source Independence und gemeinsame Provenance-Ketten, damit 20 abhängige APIs nicht wie 20 unabhängige Belege wirken.