Review Gate Reference

Sieben geschützte Operationen (RG-001 bis RG-007) sowie Bypass-Erkennung. Jede blocking=true Operation ist ein harter Stop — kein Workaround.

1. Grundprinzip Review Gates (P-REVW-001–P-REVW-003)

Review Gates sind obligatorische HITL-Kontrollpunkte für bestimmte hochriskante Operationen. Kein automatisierter Prozess, kein Agent und kein Skript kann ein blocking Gate überspringen. Die Gate-Registrierung ist die authoritative Quelle — ein Gate, das nicht hier steht, existiert nicht als geschützte Operation.

P-REVW-001
HITL Gates für alle hochriskanten Operationen sind obligatorisch. Fail-closed bei fehlenden Artefakten.

P-REVW-002
Gates sind in der Enforcement-Registry verzeichnet. Nicht-gelistete Operationen unterliegen keinem Gate.

P-REVW-003
Bypass = kritische Violation. Automatischer Alert an Space Lead + eskaliertes TX-Log.

Gate-Artefakt-Modell

review_gate:
  id: RG-XXX
  operation: <operation_type>
  required_artefacts: [...]         # Fehlende → BLOCK
  additional_requirements: [...]    # Kontextabhängig
  ttl: <hours>                      # Artefakt-Ablauf (ab Creation)
  blocking: true | false
  bypass_detection:
    triggers: [...]
    consequence: BLOCK | WARN

2. Die 7 geschützten Operationen

RG-001 Profile Upgrade BLOCKING

Operation	`profile_upgrade` — Hochstufen eines Nodes auf ein höheres Capability Profile
TTL	72 Stunden (3 Werktage)
Blocking	Ja — kein Upgrade ohne Gate-Freigabe
Pflicht-Artefakte	`upgrade_request`, `capability_review`
Warum geschützt	Jedes Profile-Upgrade erweitert den Zugang zu potenziell riskanten Features (z.B. Cosmic-Tier). Unbewachter Upgrade = unkontrollierte Capability-Eskalation.

RG-002 Cosmos Feature Activation BLOCKING

Operation	`cosmos_feature_activation` — Aktivierung eines Cosmic-Tier-Features
TTL	48 Stunden
Blocking	Ja
Pflicht-Artefakte	`feature_request`, `risk_acknowledgement` (zusätzliche Pflicht)
Warum geschützt	Cosmic Features sind per Definition hochriskant. Risk Acknowledgement muss explizit benannt sein — kein implizites Einverständnis.

RG-003 Federation Cross-Org BLOCKING

Operation	`federation_cross_org` — Öffnung einer Cross-Organisation-Federation
TTL	24 Stunden
Blocking	Ja
Pflicht-Artefakte	`federation_proposal`, plus `boundary_spec_ref` (Boundary-Spezifikation muss existieren)
Warum geschützt	Öffnet Grenzen zwischen autonomen Organisationen. Ohne explizite Boundary-Spec kein Consent-Nachweis. Kürzeste TTL wegen dynamischer Cross-Org-Risiken.

RG-004 Go/No-Go Decision BLOCKING

Operation	`go_no_go_decision` — Freigabe einer Deployment/Rollout-Entscheidung
TTL	168 Stunden (7 Tage)
Blocking	Ja
Pflicht-Artefakte	`readiness_assessment`, plus `hitl_signal` muss exakt `"READY-FOR-HITL-GO-NO-GO"` enthalten
Warum geschützt	Kritischste Entscheidung im Deploy-Prozess. Nur explizites HITL-Signal gilt — keine Mehrdeutigkeit erlaubt. Längste TTL für ausreichend Review-Zeit.

RG-005 Node Ops Round Execution WARN ONLY

Operation	`node_ops_round_execution` — Ausführung einer vollständigen Ops-Runde auf einem Node
TTL	8 Stunden
Blocking	Nein — nur Warnung, kein Hard Stop
Pflicht-Artefakte	`ops_round_plan`
Warum	Routine-Operationen sind weniger riskant, benötigen aber Aufsicht. Warn-Mode ermöglicht flussarmen Betrieb bei gleichzeitiger Transparenz.

RG-006 Seed-to-Node Projection BLOCKING

Operation	`seed_to_node_projection` — Ausstrahlung eines Seed in einen produktiven Node
TTL	168 Stunden (7 Tage)
Blocking	Ja
Pflicht-Artefakte	`projection_manifest`, plus `state_hash_pre` UND `state_hash_post` (Zustandsverifikation)
Warum geschützt	Seed-Projektionen sind irreversibel — ein Node wird dauerhaft konfiguriert. State-Hashes beweisen deterministische, unmanipulierte Projektion (P-PROJ-008).

RG-007 Theme IP Usage BLOCKING · 1-YEAR TTL

Operation	`theme_ip_usage` — Nutzung von Theme in externen/kommerziellen Outputs
TTL	8760 Stunden (1 Jahr)
Blocking	Ja
Pflicht-Artefakte	`ip_clearance_statement` (einmal jährlich)
Ausnahmen (exempt)	`internal_dev_only`, `inspiration_reference` — kein Gate nötig
Warum geschützt	IIO-Theme-Assets sind proprietäres IP. Jährliche Clearance verhindert unbewusste Lizenz-Verletzungen ohne unnötigen Overhead für interne Nutzung.

3. Bypass Detection

Alle Prozesse werden auf Bypass-Versuche überwacht. Folgende Trigger lösen automatisch eine Reaktion aus:

Trigger	Reaktion	Schwere	Erklärung
`missing_review_artefact`	BLOCK + Alert	CRITICAL	Pflicht-Artefakt fehlt vollständig. Gate gilt als nicht bestanden.
`stale_artefact`	BLOCK + Alert	CRITICAL	Artefakt überschreitet TTL. Veraltete Freigaben sind ungültig — neue Review nötig.
`non_human_actor`	BLOCK + Alert	CRITICAL	Review wurde von einem nicht-menschlichen Actor signiert. Nur echte menschliche Freigabe gilt.
`unsigned_artefact`	BLOCK	BLOCK	Artefakt nicht kryptographisch/manuell signiert. Herkunft unbeprüfbar.

Bypass-Consequence TX

bypass_detection_tx:
  trigger: missing_review_artefact | stale_artefact | non_human_actor | unsigned_artefact
  gate_ref: RG-XXX
  operation_attempted: <operation_type>
  actor_id: <attempting_actor>
  timestamp: <ISO-8601>
  consequence: BLOCK | BLOCK+critical
  alert_sent_to: [space_lead, responsible_owner]

P-REVW-001 P-REVW-002 P-REVW-003