Space Kernel Praxis

Operator-Leitfaden für Entscheidungen im Agentic Cooperation Space: Aus den Space-Kernel-Kernbegriffen werden konkrete Prüfpfade und Checklisten für tägliche Arbeit.

1. Kernformel als Operationsregel

Die Kernel-Formel beschreibt, welche Bausteine vorhanden sein müssen, damit ein Space steuerbar und auditierbar ist. In der Praxis bedeutet das: keine State-Änderung ohne klare Zuordnung von Actor, Role, Plan, Work und Transaction.

Individual Actors + Compositions = Composite Actors Space + (Individual + Composite Actors) + Roles + Work + Artifacts + Plans + State + Relations + Rules + Views + Boundaries + Interfaces + Communication Events = Agentic Cooperation Space
Actor-agnostisch fraktal skalierbar fail-closed Story-getrieben

2. Decision Tree: Von Beobachtung zur Aktion

Dieses Entscheidungsraster verhindert Rabbit Holes: erst Ontologie klären, dann Gate-Pfad wählen, dann erst handeln.

1. Space klären: In welchem Space passiert die Beobachtung? (lokal, federiert, unklar)
2. Actor identifizieren: Individual Actor oder Composite Actor? Wer darf entscheiden?
3. Role prüfen: Hat der Actor in diesem Kontext die nötige Role + Skill?
4. Plan/Work ableiten: Ist ein deterministischer Plan vorhanden? Falls nein: BLOCK.
5. Boundary/Interface prüfen: Interner Schritt oder Cross-Boundary-Interaktion?
6. Transaction erzwingen: Führt die Aktion zu State Change? Wenn ja: TX-Record Pflicht.
7. Evidence sichern: Ohne reproduzierbare Evidenz kein GO.
Kein Actor = BLOCK Kein Plan = BLOCK Kein TX bei State Change = BLOCK Keine Evidenz = BLOCK

3. Kernbegriffe als Operator-Checklisten

Die folgenden Karten übersetzen die Core Terms in konkrete Prüfhandlungen. Jede Karte enthält die Minimalfragen vor einer GO-Entscheidung.

Space

  • Ist der Scope klar abgegrenzt?
  • Ist Ownership des Kontexts dokumentiert?
  • Sind externe Abhängigkeiten markiert?

Actor (Individual/Composite)

  • Wer handelt konkret?
  • Handelt ein einzelner Actor oder eine Composition?
  • Ist Actor-ID für Audit verfügbar?

Role

  • Passt die Role zum Operationstyp?
  • Gibt es Reviewer/Author-Konflikt?
  • Ist Skill-Anforderung gedeckt?

Relation & Affiliation

  • Welche Beziehungen ändern sich?
  • Sind Relations explizit statt implizit?
  • Wurde Affiliation (Team/Node) dokumentiert?

Capability

  • Welche Capability wird benötigt?
  • Ist sie im Profil erlaubt?
  • Gibt es Deny-Constraints?

Plan

  • Ist der Plan deterministisch und reproduzierbar?
  • Sind Inputs/Outputs klar?
  • Ist ein Rollback-Schritt vorhanden?

Work

  • Entspricht die Ausführung dem Plan?
  • Abweichungen als neue TX dokumentiert?
  • Zeitpunkt und Verantwortliche erfasst?

Artifact

  • Liegt das Artefakt am richtigen Ort (Placement)?
  • Ist es versioniert und auffindbar?
  • Ist Sensitivität klassifiziert?

State

  • Welcher Zustand ändert sich konkret?
  • Ist pre/post-state dokumentiert?
  • Ist der Change reversibel oder superseded?

Rule

  • Welche Regel hat Vorrang?
  • Wird fail-closed eingehalten?
  • Ist eine Ausnahme dokumentiert und genehmigt?

View

  • Ist die Sicht für den Empfänger passend?
  • Bleibt die Semantik gleich über alle Views?
  • Ist der Audit-Pfad unabhängig von der View stabil?

Domain

  • Welcher fachliche Bereich ist betroffen?
  • Sind Domain-Grenzen respektiert?
  • Ist Cross-Domain-Impact markiert?

Boundary

  • Boundary-Typ klar? (internal/semi/federated)
  • Ist Zugriff explizit erlaubt?
  • Werden Denials geloggt?

Interface

  • Welcher Kanal wird genutzt? (Human/Agent/API/CLI)
  • Ist Interface nur Präsentationsmodus oder verändert es Semantik?
  • Werden Übergaben validiert?

Event / Communication Event

  • Ist es ein reines Signal oder State-Change?
  • Intra-Space: als Transaction erfasst?
  • Inter-Space: über Interface + Federation Channel abgesichert?

Composition

  • Gemeinsamer Plan vorhanden?
  • Mitglieder-Rollen konsistent?
  • Bleibt die Composition aktiv oder muss sie dissolven?

Transaction

  • Sind Pflichtfelder vollständig?
  • Append-only gewährleistet?
  • Reviewer/Approvals hinterlegt?

4. Typische Fehlerbilder und Gegenmaßnahmen

FehlerbildSymptomSofortmaßnahme
Actor vs Entity-Verwechslung Objekt wird als passiv behandelt, obwohl es Kontextwirkung hat Alles als Actor mit Role modellieren; Rolle statt Ontologie wechseln
Team als Sonderobjekt Eigene Regeln für Teams außerhalb des Actor-Modells Team als Composite Actor führen, gleiche Gate-Logik anwenden
Interface als Entscheidungsträger API/CLI-Modus verändert fachliche Semantik Interface nur als Kommunikationsmodus behandeln, Semantik im Kernel halten
Event ohne Transaction State ändert sich, aber kein Audit-Eintrag Sofortige Nacherfassung als Transaction inkl. pre/post-state
Boundary-Bypass Direkter Zugriff ohne expliziten Grant Fail-closed: Zugriff stoppen, Grant + TTL + Review nachziehen

5. GO-Checkliste vor jeder State-Änderung

Kernel-Minimum

  • Actor eindeutig identifiziert
  • Role + Capability passend und nachweisbar
  • Plan deterministisch
  • Boundary/Interface geprüft
  • Transaction vorbereitet
  • Evidence-Pfad definiert

Fail-Closed Trigger

  • Unklarer Scope
  • Unklare Ownership
  • Fehlender Reviewer bei Risikoänderung
  • Nicht reproduzierbare Ausführung
Alle Checks erfüllt = GO Mindestens ein Trigger = BLOCK/ESCALATE

6. Quellen

P-CORE-001 P-CORE-004 P-STORY-002 P-ROLE-001 P-COMP-001 P-BOUND-001 P-TXN-001