Layer Integration

Die Integrationsschicht zeigt, wie die einzelnen IIO-Layer als ein gemeinsames Kontrollmodell zusammenwirken. Sie ist keine zusätzliche Fachdomäne, sondern die verbindende Gate-Logik über alle Schichten.

1. Der komplette Stack in Ausführungsreihenfolge

Integration Layer — zeigt Abhängigkeiten, Gate-Kaskaden und fail-closed Zusammenhänge

Diagram Semantics — gemeinsame Notation und Auditierbarkeit von Visualisierungen

Skill Registry — welche Capabilities für welche Rollen verfügbar sind

Boundary — wer was sehen und ändern darf

Transaction — wie Zustandsänderungen einheitlich geloggt werden

Composition — wie mehrere Actors zu Composite Actors werden

Role — wie Actors in einem Kontext gebunden und constrained werden

Story — warum Actors handeln und welche Narrative konsistent bleiben müssen

Ontology — Actor, Intelligent Actor, Composite Actor, Communication Event

Foundation — struktureller Boden, keine zusätzlichen Fachpremises

2. Drei zentrale Abhängigkeitsachsen

Achse	Verlauf	Fail-Closed-Regel
Ontology → alle Layer	Keine Schicht darf Human und Agent ontologisch trennen; alle sind Intelligent Actors	Wenn ein Layer actor-type Sonderrechte einführt, entsteht ein Design-Widerspruch
Story → operative Layer	Story liefert Purpose, Konflikt und Pfad für Role, Composition, Transaction und Boundary	Widerspricht eine Transaction der Story, wird sie invalid oder muss zurückgerollt werden
Role ↔ Boundary ↔ Skill	Permission entsteht nur, wenn Role, Access und Skill gleichzeitig passen	Ein fehlender Gate-Check blockiert die gesamte Operation

3. Das Permission Triangle

Die operative Entscheidung „Darf Actor X diese Arbeit ausführen?“ entsteht aus dem Zusammenspiel von Role, Boundary und Skill Registry.

Permission Request
  1. Actor exists?                 -> NO  => DENY
  2. Role in Composition exists?   -> NO  => DENY
  3. Role permits operation?       -> NO  => DENY
  4. Boundary allows access?       -> NO  => DENY
  5. Skill registered?             -> NO  => DENY
  6. Actor has required skill?     -> NO  => DENY / supervised mode
  7. Proficiency sufficient?       -> NO  => DENY
  ALL PASS                         -> ALLOW + TX LOG

Role

Definiert, welche Operationen ein Actor im Kontext überhaupt ausführen darf.

Boundary

Prüft, ob diese Role auf das konkrete Ziel zugreifen darf.

Skill

Prüft, ob der Actor die nachgewiesene Capability mit ausreichender Proficiency besitzt.

4. Composition → Transaction → Boundary

Koordination ist im IIO-Modell nur dann vollständig, wenn gemeinsame Arbeit auch einheitlich aufgezeichnet und gegen Grenzen geschützt wird.

Schritt	Bedeutung
Composition	Shared Story, Shared Plan, Shared State und Member-Rollen werden vereinigt
Transaction	Jede koordinierte Aktion wird als einheitlicher Zustandswechsel aufgezeichnet
Boundary	Externe Sicht und interne Sicht werden sauber getrennt; Verstöße sind fail-closed

Damit wird aus „Zusammenarbeit“ eine formal prüfbare Form von kollektiver Agency.

5. Ein durchgehendes Beispiel

Work: "Feature X ausliefern"
  Story:          "Wir liefern Qualität unter Zeitdruck"
  Role:           lead, contributor, reviewer
  Composition:    team-backend als Composite Actor
  Transaction:    implementation + review + approval werden geloggt
  Boundary:       stakeholder bekommt read-only, kein Schreibzugriff
  Skill:          contributor braucht implementation, reviewer braucht critical_analysis
  Diagram:        zeigt Dispatch und Audit-Trail
  Result:         ein kontrollierter, vollständig auditierbarer Flow

6. Warum diese Schicht wichtig ist

Ohne Integration Layer	Mit Integration Layer
Einzelne Specs bleiben isoliert nebeneinander stehen	Alle Specs werden als gemeinsames Kontrollmodell lesbar
Gate-Lücken bleiben verborgen	Fehlende Checks werden als Kaskadenbruch sichtbar
Teams sehen nur lokale Regeln	Teams verstehen, warum eine lokale Regel systemweit relevant ist

P-CORE-004 P-STORY-002 P-ROLE-004 P-COMP-003 P-TXN-005 P-BOUND-002 P-SKILL-002 P-DIAG-006