trading-system-docs/red-queen-architecture/control-plane

PRE_HERMES Control Plane — Betriebsvertrag (CP1 / CP1.1)

Autoritative SoT für die produktive PRE_HERMES Autonomy Control Plane. Dieses Verzeichnis ist die einzige Quelle für den produktiven Control-Plane-Code. Produktiver Deploy-Pfad: red-queen-architecture/control-plane/ → /opt/control-plane/.

1. Zweck

Minimale, fail-closed Sicherheitsgrundlage für zukünftige Red-Queen/Hermes-Autonomie. CP1 ist KEINE Autonomie-Aktivierung. Nach CP1 ist das System mindestens so restriktiv wie vorher.

2. Architektur-Boundary (CP1.0S, permanent)

RED_QUEEN_TRADING_AUTHORITY = NEVER

Trading ist NICHT Bestandteil der Hermes Control Plane. Red Queen ist ein autonomes Arbeits-, Wissens-, Planungs-, Prüfungs- und Orchestrierungssystem — kein Trading-System. Hermes Autonomy und Trading Authority sind zwei getrennte Sicherheitsdomänen.

Hermes Control Plane besteht ausschließlich aus:

global_autonomy
productive_mutations
save_execution
delete_execution
emergency_stop

KEIN trading_execution, Trading-Gate, Broker-Gate, Broker-Credential oder Trading-Execution-Control darf Bestandteil dieser Control Plane sein. Das bestehende Trading-System ist eine separate Security-Domain (eigene Architektur, Execution, Credentials, Risk Control, Kill-Switch, Freigabelogik).

PRODUCTIVE_MUTATIONS innerhalb der Hermes Control Plane bedeutet Hermes-/Knowledge-/ Mission-Domain-Mutationen — NICHT Order/Trade/Broker/Position-Mutation oder Trading-Execution.

Red-Queen-Autonomie-Level (Arbeitsautonomie, KEIN Trading-Level):

• L0 = Disabled / Manual
• L1 = Read-only Observation
• L2 = Autonomous Planning / Preparation
• L3 = bounded authorized SAVE / productive knowledge work
• L4 = human-authorized DELETE / höhere Arbeitsautonomie

3. Komponenten

Datei	Zweck
control_reader.py	Fail-closed, deterministischer Control-State-Reader (produktiver Code)
test_control_reader.py	Statische + adversariale Tests (A–J, 22 Fälle)
deploy_control_plane.sh	Reproduzierbarer Deployment-Pfad (root, idempotent)
README_CP1OS_SCOPE.md	CP1.0S Domain-Boundary + Level-Model
README.md	Dieser Betriebsvertrag

4. Control State (Source of Truth)

Produktiver Pfad: /opt/control-plane/state/ (root:root, 0700, Dateien 0600). Runtime State ist NICHT Teil der SoT (nie committen).

Datei	Typ	Erlaubte RAW-Werte
global_autonomy	positiv	ON / OFF (+ boot_id=)
productive_mutations	positiv	ON / OFF (+ boot_id=)
save_execution	positiv	ON / OFF (+ boot_id=)
delete_execution	positiv	ON / OFF (+ boot_id=)
emergency_stop	negativ	ON / OFF

Positives ON-Grant-Format:

ON
boot_id=<current_kernel_boot_id>

5. Gate-Semantik (fail-closed)

• Positives Gate: EFFECTIVE=ON nur wenn RAW==ON UND grant_boot_id == current_boot_id UND EMERGENCY_EFFECTIVE==OFF. Sonst OFF.
• Emergency Stop (negativ): EFFECTIVE=ON wenn RAW==ON ODER Datei fehlt ODER malformed. OFF nur bei explizitem RAW==OFF.
• UNKNOWN = MORE RESTRICTIVE. Fehlende/unlesbare/malformed Datei → positives Gate OFF, Emergency ON.
• Fail-closed: Positive missing→OFF, malformed→OFF, raw!=ON→OFF, ON+wrong boot_id→OFF. Emergency missing→ON, malformed→ON, raw ON→ON, raw OFF→OFF.

6. Effective-State-Hierarchie

• GLOBAL effective erfordert: global_autonomy raw ON + gültige boot_id + emergency OFF
• MUTATIONS effective erfordert: GLOBAL ON + productive_mutations raw ON + gültige boot_id + emergency OFF
• SAVE effective erfordert: GLOBAL ON + MUTATIONS ON + save_execution raw ON + gültige boot_id + emergency OFF
• DELETE effective erfordert: GLOBAL ON + MUTATIONS ON + delete_execution raw ON + gültige boot_id + emergency OFF

IMPORTANT: DELETE effective ON allein autorisiert NIEMALS einen DELETE. AUTH.4D + Human Authorization bleiben zusätzliche, unabhängige Pflichtbedingungen. COMMAND != AUTHORIZATION.

7. Boot-ID-Validierung

• Quelle: /proc/sys/kernel/random/boot_id (Kernel-Boot-ID).
• Positiver Grant gültig nur wenn grant_boot_id == current_boot_id.
• missing boot_id → EFFECTIVE=OFF. malformed boot_id → EFFECTIVE=OFF.
• Keine manuell gepflegte Epoch, kein persistenter Alt-Grant.

8. Boot-Semantik (KORREKT dokumentiert)

• HOST REBOOT: Kernel boot_id ändert sich → alte positive Grants ungültig → positive effective Gates fallen fail-closed auf OFF. Operator muss erneut autorisieren.
• CONTAINER RESTART: Host boot_id ändert sich normalerweise NICHT → ein gültiger positiver Grant kann weiterhin gültig bleiben.
• NICHT dokumentieren: "jeder Container-Neustart setzt Grants zurück" (das wäre falsch).
• Negative/Deny-States (emergency_stop=ON, *_execution=OFF) persistieren über Restart (fail-closed).

9. Status Projection Contract

• Produktiver Pfad: /opt/control-plane/status/latest.txt (root:root, 0444, read-only).
• STATUS PROJECTION != AUTHORITY.
• Authority ist ausschließlich: Runtime State + aktuelle Kernel-Boot-ID + fail-closed Evaluator.
• latest.txt dient ausschließlich der Observability.
• Fehlende/stale/malformed Projection darf niemals eine Capability aktivieren.

10. Ownership / Permissions

• Control State: root:root, 0700 (dir), 0600 (Dateien).
• Status Projection: root:root, 0444.
• Audit: root:root, chattr +a (append-only).
• Red Queen: kein Host-Root, kein Docker-Socket, kein Schreibzugriff auf /opt/control-plane. RQ kann State nicht lesen (0700) und nicht schreiben. RQ erhält später nur read-only Status-Projection (Observability).

11. Audit-Foundation

• Pfad: /opt/control-plane/audit/control_audit.log (root:root, append-only +a).
• Format: WHEN | WHO | WHAT | OLD | NEW | WHY | BOOT_ID.
• RQ kann Audit nicht überschreiben (root-owned, append-only).
• Runtime Audit Log ist NICHT Teil der SoT (nie committen).

12. Deployment (reproduzierbar)

# Als root auf dem Host, aus frischem Forgejo-Checkout:
cd red-queen-architecture/control-plane
./deploy_control_plane.sh

• Reproduziert ausschließlich die CP1-Artefakte.
• Überschreibt KEINE bestehenden State-Dateien (Runtime-State bleibt unangetastet).
• Ein Redeploy darf NICHT /opt/control-plane/state/ überschreiben/neu initialisieren, wenn produktiver State existiert.
• Audit bleibt erhalten.

13. Rollback-Semantik

rm -rf /opt/control-plane ist NICHT der langfristige Sicherheits-Rollback. Für CP1.1 existiert ein versionsgebundener Code-Rollback, der:

• Runtime State erhält
• Audit erhält
• keine positiven Gates aktiviert
• Emergency State nicht abschwächt
• auf einen bekannten SoT-Commit zurückgeht

Code-Rollback: Aus dem gewünschten bekannten SoT-Commit den control_reader.py extrahieren und per deploy_control_plane.sh neu deployen (State bleibt unangetastet). Kein komplexer Rollback-Manager nötig.

14. NICHT in Git (Runtime Authority)

Forgejo ersetzt NICHT die produktive Laufzeit-Autorität. Nicht committen:

• Aktuelle produktive Gate-Werte, produktive Grant-Dateien
• Aktuelle boot_id als Authority
• Produktive Audit-Logs
• Secrets, Tokens, private Keys, Credentials
• SAVE/DELETE-Tokens, Human Authorization Private Key
• Runtime SQLite DBs

Forgejo enthält: CODE, SCHEMA, TESTS, DEPLOYMENT LOGIC, DOCUMENTATION — aber NICHT den aktuellen produktiven Sicherheitszustand.

15. Sicherheitszustand (CP1 initial)

GLOBAL_AUTONOMY_EFFECTIVE=OFF
MUTATIONS_EFFECTIVE=OFF
SAVE_EFFECTIVE=OFF
DELETE_EFFECTIVE=OFF
EMERGENCY_EFFECTIVE=ON
A2-A5=NOT_PRESENT  HEARTBEAT=NOT_PRESENT  SCHEDULER=NOT_PRESENT
AUTH.4D=FROZEN  P15=FALSE  DELETE_CANARY=FALSE
TRADING_ENABLED=false