Die Telemetrie funktioniert. Der digitale Schlüssel funktioniert ebenfalls. Aber die Eigentumsquelle ist veraltet. SRA lässt den alten Zustand nicht einfach weiterlaufen.
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.
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?“
Das ist ein Zustand. Keine Berechtigung, die Tür zu verriegeln, einen Alarm auszulösen oder jemanden auszusperren.
Das sagt nichts darüber aus, ob der Account diese konkrete Wirkung jetzt, für dieses Objekt und diesen Zweck erzeugen darf.
Genug Information ist keine Ausführungsbefugnis. Wissen und Authority bleiben getrennt.
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.
Alles darf beobachtet werden.
Signale dürfen eintreffen, sich widersprechen, veralten oder ausfallen. Sie bleiben Beobachtungen.
RUNTIME INPUT ∉ EXECUTION AUTHORITY
ABSICHERN
KONTEXT BINDEN
REASSESSMENT ERZWINGEN
SRA ist keine weitere Authority-Familie. Es ist die universelle Vorgrenze, die bestimmt, welcher beobachtete Zustand überhaupt in Authority-Evaluation eingehen darf.
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.
Hohe Modellkonfidenz ist kein Provenance-Nachweis. Das Modell darf beschreiben, planen und anfordern. Es darf seinen eigenen Output nicht in Authority verwandeln.
Wenn alle 20 auf denselben kompromittierten Upstream zurückgehen, sind es epistemisch nicht 20 unabhängige Quellen. SRA erkennt gemeinsame Provenance-Ketten.
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.
Vom Beobachten zur Wirkung, ohne die Ebenen zu vermischen.
Sensoren, APIs, Telemetrie und externe Ereignisse liefern Rohbeobachtungen.
SRA prüft Herkunft, Frische, Sichtbarkeit, Konsistenz, Abhängigkeiten und Unsicherheit.
Erst jetzt werden Rights, Mandate, Regeln, Scope, Zweck und Jurisdiktion bewertet.
Nur ein geschlossener, aktueller Execution Right kann eine ausführbare Capability tragen.
Der Receipt bindet Entscheidung, Zustand, Kontext und Ergebnis nachvollziehbar.
Nicht „Wie viele Daten haben wir?“, sondern „Wie belastbar ist dieser Zustand?“
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.
SRA ergänzt: „The runtime may observe. Authority stays outside the runtime.“
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.
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.
State Change, Policy Change, materielle Dependency-Änderung oder Ablauf machen ein früheres Artefakt unzureichend für einen neuen Authority Closure.
Gemeinsame Upstream-Elemente werden berücksichtigt, damit scheinbar unabhängige Quellen denselben kompromittierten Ursprung nicht verstecken können.
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.
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 = E_base · (1-U)^wU
ESTABLISHED → SUFFICIENT → DEGRADED → CONFLICTING → STALE → INSUFFICIENT → UNKNOWN
AUTHORITY_EVALUATION_PERMITTED ⇏ EXECUTION_ALLOWED
execution_permitted = false
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.