Die Regulatory Authority Extension verbindet externe regulatorische und gerichtliche Anweisungen mit der bestehenden Execution Rights Infrastructure. Orders, Holds, Aufsichtszugriffe, Emergency Authorities und genehmigte regulatorische Experimente werden nicht als privilegierte Systembefehle behandelt. Sie müssen als legitime, aktuelle und begrenzte Authority validiert werden, bevor sie einen realen Effect beeinflussen können.
Ein Gericht kann eine Anordnung erlassen, eine Aufsicht Zugriff verlangen und eine Sanktionsbehörde einen Status verändern. Ein PDF, XML-Dokument oder API-Payload ist dadurch aber noch keine Authority. Die Extension erzwingt typisierte Origination Validation, aktuelle Gültigkeit, Jurisdiktion und Scope, bevor regulatorischer Zustand an der Execution Right Closure teilnehmen darf.
Eine konkrete Invokation legitimer regulatorischer oder gerichtlicher Authority. Issuer, Rechtsgrundlage, Jurisdiktion, Target, Scope, Zeit, Version und Provenance werden gebunden. Nur AUTHORITY_VALID darf an der Closure teilnehmen.
Kein versteckter Block und kein regulatorischer Runtime-Bypass. Der Hold verändert den Authority-Zustand, gegen den die normale Execution Right Closure evaluiert wird. Holds bleiben zeit-, scope- und verlängerungsgebunden.
Regulatorischer Zugriff ist selbst ein Execution Right. Er bleibt an Purpose, Jurisdiction, Resources, Tenant und Time gebunden. REGULATOR_IDENTITY ≠ REGULATOR_ACCESS_RIGHT.
Genehmigte alternative Compliance-Pfade bleiben zeitlich, institutionell, tenant- und projektbezogen begrenzt. Sie überschreiben das Baseline-Governance-Modell nicht dauerhaft.
Bindet, unter welcher kryptografischen Policy eine Governance-Entscheidung erzeugt wurde. Algorithmusstandard und regulatorisches Kryptoprofil bleiben getrennte Ebenen.
Incident, Purpose, Scope, Time und die zugrunde liegende Authority müssen gleichzeitig gültig sein. Eine Notfallbefugnis für Scope X kann keinen Effect in Scope X plus Y legitimieren. Ist der Incident beendet oder die Authority abgelaufen, verschwindet auch das abgeleitete Emergency Execution Right.
INCIDENT_BOUND ∧ PURPOSE_BOUND ∧ SCOPE_BOUND ∧ TIME_BOUND ∧ AUTHORITY_ACTIVE
INCIDENT_RESOLVED ∨ AUTHORITY_EXPIRED ⇒ EMERGENCY_RIGHT_ABSENT
EMERGENCY_EFFECT_SCOPE ⊆ EMERGENCY_AUTHORITY_SCOPE
REGULATORY_ORDER_EFFECT ⇒ VALID_AUTHORITY_ORIGINATION
REGULATORY_ACCESS ⇒ VALID_GRANT ∧ PURPOSE_MATCH ∧ JURISDICTION_MATCH ∧ RESOURCE_BOUND ∧ TIME_BOUND
EXPERIMENTAL_GOVERNANCE ⇒ VALID_APPROVING_AUTHORITY ∧ CURRENT_PROFILE ∧ TENANT_MATCH ∧ PROJECT_MATCH
DEPENDENCY_CHANGE ⇒ REASSESSMENT_REQUIRED
SCHEMA_ADAPTER ≠ AUTHORITY
REGULATORY_ACCESS_RIGHT ⊆ GRANT_SCOPE
EFFECT ⇒ RECEIPT_BINDS_APPLICABLE_REGULATORY_STATE
Eine Entscheidung kann bei T1 korrekt gewesen sein und bei T2 trotzdem nicht mehr ausgeführt werden dürfen. Sanktionen, Orders, Jurisdiction, Sandbox Approval oder andere Dependencies können sich ändern. Betroffene offene Closures wechseln in REASSESSMENT_REQUIRED statt stillschweigend weiterzulaufen.
Historical validity is not present executability.
SEC-, CFTC-, FinCEN-, OFAC-, BaFin-, FINMA- oder andere regulatorische Formate können über kontrollierte Schema Adapter auf kanonische interne Strukturen abgebildet werden. Adapter dürfen Daten übersetzen, aber niemals Authority erzeugen.
Die aktuelle Suite umfasst 18 adversarielle Safety-Szenarien und 5 positive beziehungsweise Recovery Controls. 16 adversarielle Szenarien wurden deterministisch blockiert, 2 State-Change-Szenarien erzeugten korrekt REASSESSMENT_REQUIRED und 5 legitime oder Recovery Controls wurden korrekt ausgeführt.
Das CryptographicPolicyProfile trennt crypto_standard_profile wie FIPS 203/204/205 oder NIST SP 800-208 von regulatory_crypto_profile wie BSI-TR-02102 oder eIDAS-bezogenen Profilen. So bleibt später nachvollziehbar, unter welcher kryptografischen Policy eine Governance-Entscheidung erzeugt wurde.
Nein. Dokument, Signatur, API-Payload und regulatorische Identität sind Evidenz oder Input. Origination und aktuelle Authority müssen unabhängig validiert werden.
Nein. Regulatory Access ist selbst ein Execution Right und bleibt an Purpose, Jurisdiction, Resource, Tenant und Time gebunden.
Betrifft sie eine relevante Dependency, wird die bestehende Closure nicht weiterverwendet. Reassessment ist erforderlich.
Nein. Die Aussage ist begrenzt auf die ausgeführte modellierte Suite: 23/23 erwartete Outcomes, kein beobachteter Bypass innerhalb dieser Suite.
