Layer-Architektur Deep-DiveLayer Architecture Deep-Dive

Alle 9 formalen Layer des IIO Unified Control Model — Definitionen, Premises, Cross-Layer-Abhängigkeiten, Fail-Closed-Gates, und wie sie als Ganzes funktionieren.

0 · Der vollständige Layer-Stack (Ausführungsreihenfolge)0 · The Complete Layer Stack (Execution Order)

Layer werden von unten nach oben ausgeführt. Kein Layer darf einen darunter liegenden überspringen. Ein BLOCK in einem unteren Layer blockiert alle oberen.

I
Integration Layer Dieses Dokument — zeigt Abhängigkeiten + fail-closed Gates
9
Diagram Semantics Layer P-DIAG-001–007 · Visuelle Notation aller Systeme
8
Skill Registry Layer P-SKILL-001–007 · Wer hat welche Fähigkeiten?
7
Boundary Layer P-BOUND-001–007 · Wer kann was sehen/ändern?
6
Transaction Layer P-TXN-003–007 · Wie werden Zustandsänderungen aufgezeichnet?
5
Composition Layer P-COMP-001–007 · Wie koordinieren mehrere Actors?
4
Role Layer P-ROLE-001–005 · Welche Berechtigungen hat ein Actor im Kontext?
3
Story Layer P-STORY-001–004 · Was wird erreicht? (Warum?)
2
Ontology Layer P-CORE-001–005 · Was ist ein Actor? (Grundtypen)
F
Foundation Layer Strukturell · Unified Control Model · Role-based Dispatch
Schlüsselregel: Jedes Layer beantwortet eine präzise Frage. Kein Layer übernimmt die Verantwortung eines anderen. Alle Layer folgen identischen Actor-agnostischen Mustern.

1 · Foundation Layer — Unified Control Model

Das Fundament. Keine eigenen Premises — strukturelle Integrationsschicht, die alle anderen Layer verbindet.

F
Foundation Layer
Keine Premises — Strukturelle Kontrolle
KernaussageAgent, Mensch, Team, Skill sind keine verschiedenen Kategorien — sie sind Rollen im universellen Actor-Modell
Actor-ModellIndividual Actor (1 Mensch / 1 Agent) | Composite Actor (Team, Org, Federation)
Dispatch-PrinzipRole-based dispatch: Ich bin wer ich BIN im Kontext (nicht wer ich bin im Allgemeinen)
Fail-Closed DefaultKein explizites ALLOW = DENY. Kein Actor = kein Zugang.
Die Foundation ist das "Meta-Layer" — sie definiert, wie alle anderen Layer miteinander verbunden sind. Ändert man hier etwas, ändert man alles.

2 · Ontology Layer — Was ist ein Actor?2 · Ontology Layer — What is an Actor?

P-CORE-001 bis P-CORE-005. Grundtypen und Identitätsregeln des gesamten Systems.

2
Ontology Layer
P-CORE-001 bis P-CORE-005
PremiseAussageStatementKonsequenzConsequence
P-CORE-001Alle handlungsfähigen Entitäten sind ActorsKeine Sonderregeln für Tools, APIs, Systeme
P-CORE-002Actor = Individual | CompositeAlle Interaktion folgt demselben Schema
P-CORE-003Unterschied zwischen Actors = Communication Mode (nicht Typ)Machine-Optimized vs Narrative-Optimized — kein ontologischer Bruch
P-CORE-004Kein ontologischer Unterschied Human/AgentWenn Layer Human/Agent trennt → sofortiger BLOCK → Design Error
P-CORE-005Fractal Composition: universelle Actor-Regeln auf allen EbenenTeam ist Actor. Org ist Actor. Federation ist Actor. Alle gleichen Regeln.
Häufiger Fehler: Code/Docs die zwischen "human user" und "AI agent" unterscheiden, verletzen P-CORE-004. Korrekt: beide sind Individual Actors mit unterschiedlichem Communication Mode.

3 · Story Layer — Warum existiert ein Actor?3 · Story Layer — Why Does an Actor Exist?

P-STORY-001 bis P-STORY-004. Jeder Actor hat eine Story. Stories sind nicht optional.

3
Story Layer
P-STORY-001 bis P-STORY-004

Eine Story hat 8 Pflicht-Elemente:

originWoher kommt dieser Actor?
purposeWarum existiert er?
actorsWer ist beteiligt? (Self-ref für Individual)
conflictWelche Spannungen navigiert er?
pathWohin entwickelt er sich?
artifactsWas produziert/pflegt er?
stateAktueller Zustand + Übergänge
evidenceWas beweist die Story?
PremiseRegelRule
P-STORY-001Jeder Actor muss eine vollständige Story haben (alle 8 Elemente)
P-STORY-002Story → Plan-Transformation ist deterministisch: gleiche Story → gleiche Plan-Struktur
P-STORY-003Bei Composite Actor: Member-Stories müssen mit der zusammengesetzten Story vereinbar sein
P-STORY-004Story muss über alle Schichten konsistent sein (one-liner ↔ genesis ↔ world ↔ decomposition)
Story (Warum)
Plan (Was)
Work (Ausführung)
Artifacts (Output)
State + Evidence

4 · Role Layer — Wie erhält ein Actor Berechtigungen?4 · Role Layer — How Does an Actor Gain Permissions?

P-ROLE-001 bis P-ROLE-005. Eine Rolle ist KEIN Jobtitel — sie ist eine kontextbezogene Einschränkung.

4
Role Layer
P-ROLE-001 bis P-ROLE-005
Core RoleKannCanConstraints
Contributor Work/Artifacts/State-Änderungen hinzufügen Work muss im Plan deklariert sein; immer geloggt
Reviewer Qualität/Sicherheit/Kohärenz bewerten, approven Objektivitätsbindung; kein Interessenkonflikt
Coordinator Work über Teammitglieder verteilen, Prioritäten managen Transparente Kommunikation; kein unilaterales Neudefinieren von Zielen
Owner Boundary definieren, Guardrails setzen, letzte Entscheidung Audit-haftbar; kann Boundary nicht anonym ändern
Observer Lesen, Analysieren, Dokumentieren Keine Modifikation; nur Reporting
Multi-Homing: Ein Actor kann gleichzeitig mehrere Rollen in verschiedenen Kontexten haben. Alice ist Lead in team-backend und Contributor in team-design. Rollen sind kontext-gebunden, nicht global.

5 · Composition Layer — Individual → Collective

P-COMP-001 bis P-COMP-007. Wenn mehrere Actors gemeinsam arbeiten, entsteht ein Composite Actor — mit eigenem externen Interface.

5
Composition Layer
P-COMP-001 bis P-COMP-007
Forming
Story-Check (P-STORY-003)
Active = Composite Actor
Dissolved
PhaseValidierungenValidationsFail-Closed-Trigger
FormingMember-Stories kompatibel; Rollen klar; Shared Plan vorhanden; Decision Model deklariertInkompatible Member-Story → BLOCK (P-COMP-003)
ActiveExterne Welt sieht Composite als Single Actor; Transaktionen werden Composite zugeschriebenMitglied verletzt Composition-Boundary → ACCESS_DENIED geloggt
DissolvedGoal erreicht / unauflösbare KonflikteAlle Shared Artifacts archiviert; Final-State-Snapshot erforderlich
Fractal-Prinzip: Ein Composite Actor folgt exakt denselben Regeln wie ein Individual Actor. Von außen ist kein Unterschied sichtbar. Intern gilt dasselbe Actor/Role/Story-Schema rekursiv.

6 · Transaction Layer — Wie wird Zustand aufgezeichnet?6 · Transaction Layer — How is State Recorded?

P-TXN-003 bis P-TXN-007. Jede Zustandsänderung ist eine Transaktion — unveränderlich, mit vollem Audit-Trail.

6
Transaction Layer
P-TXN-003 bis P-TXN-007

Pflichtfelder jeder Transaktion:

idtxn-<uuid>
actorID + Typ + Rolle im Kontext
contextspace_id, plan_id, story_id, composition_id
targetWas ändert sich? (artifact | state | plan …)
pre_state / post_stateSnapshot vorher + nachher + state_hash
evidencelog | artifact | signature | test-pass
approvalsWer hat approved? Wann? Mit welcher Rolle?
audit.fail_closed_gatesListe aller geprüften Gates
reversibilitycan_reverse? auto_rollback_on_error?
statuscommitted | pending_approval | failed | rolled_back
Sicherheitsregel: Eine TX ohne Actor-ID, ohne Evidence, ohne Gate-Liste = invalid TX → wird niemals committet. Kein Workaround erlaubt.

7 · Boundary Layer — Wer kann was sehen/ändern?7 · Boundary Layer — Who Can See/Change What?

P-BOUND-001 bis P-BOUND-007. Boundaries sind rollen-basiert — nicht actor-typ-basiert. Vier Boundary-Typen.

7
Boundary Layer
P-BOUND-001 bis P-BOUND-007
Boundary-TypBoundary TypeWer darf rein?Who May Enter?Use CaseFail-Closed
Internal Nur Composition-Mitglieder Team-internes Arbeiten DENY für alle Externen ohne Ausnahme
Semi-Permeable Mitglieder + designierte Externe (mit Grant) Externer Auditor, Contractor Kein aktiver Grant = DENY; abgelaufener Grant = DENY
Federated Delegates zweier Compositions Team-zu-Team-Koordination Delegate kann nur vorschlagen; Heimat-Composition entscheidet
No Boundary Nur self Privater Workspace vor Publication Kein externer Zugang; keine Ausnahmen

7-Gate Access Check (alle müssen pass sein):

Actor exists?
Role in Composition?
Role permits op?
Boundary allows?
Skill registered?
Actor has skill?
Proficiency ok?
ALLOW + log txn

8 · Skill Registry Layer — Welche Fähigkeiten werden benötigt?8 · Skill Registry Layer — What Capabilities Are Required?

P-SKILL-001 bis P-SKILL-007. Skills sind actor-agnostisch: Mensch und Agent haben identisch strukturierte Skills.

8
Skill Registry Layer
P-SKILL-001 bis P-SKILL-007
Evidence Classesmcp_verified · workspace_verified · model_only · attestation
Evidence Typestest_suite_pass · artifact_sample · certification · workflow_log
Proficiency Levelsnovice → practitioner → expert
Skill Domaintechnical · process · domain-specific · meta
Evidence ClassBedeutungMeaningHITL nötig?HITL Required?
mcp_verifiedDurch MCP-Tool-Run verifizierbarer SkillNein (automatisch)
workspace_verifiedDurch Workspace-Artefakte nachweisbarOptional (Review)
model_onlyNur durch Modell-Fähigkeit; keine externe VerifikationJa (Human override)
attestationDurch menschliche Bestätigung/ZertifizierungJa (Reviewer nötig)

9 · Diagram Semantics Layer — Wie visualisieren wir alles?9 · Diagram Semantics Layer — How Do We Visualize Everything?

P-DIAG-001 bis P-DIAG-007. Eine Notation für alle Layer. Diagramme sind machine-verifiable.

9
Diagram Semantics Layer
P-DIAG-001 bis P-DIAG-007
PremiseRegelRule
P-DIAG-001Eine Notation für alle Layer — kein separates Diagramm pro Subsystem
P-DIAG-003Diagramme zeigen role-based dispatch (nicht actor-typ-basierte Unterscheidung)
P-DIAG-004Transaction Flows: sequentiell + timestamped
P-DIAG-005Stories vollständig mit allen 8 Elementen
P-DIAG-006Mermaid-Rendering: machine-verifiable → Code aus Spec generierbar
P-DIAG-007Boundaries korrekt markiert mit Typ (internal/semi-permeable/federated/none)

10 · Cross-Layer Abhängigkeitsmatrix10 · Cross-Layer Dependency Matrix

Jeder Layer hängt von darunterliegenden ab. Diese Matrix zeigt die kritischen Abhängigkeiten und Fail-Closed Kaskaden.

Layer Hängt ab vonDepends On Fail-Closed-KaskadeFail-Closed Cascade Beispiel-TriggerExample Trigger
Story Ontology (Actor-Typen) Wenn Actor nicht existiert → Story kann nicht beginnen Actor-ID fehlt im Intake
Role Story (Kontext) + Ontology (Actor) Wenn Story undefined → Rolle hat keinen Kontext → DENY Role-Zuweisung ohne aktiven Plan
Composition Role (Mitglieder-Rollen) + Story (Shared Story) Member-Story inkompatibel mit Composition-Story → BLOCK Formation Widersprüchliche Purpose-Statements
Transaction Alle oberen Layer (Actor, Role, Story, Composition) Fehlende Gate-Liste im TX → TX invalid → nie committiert TX ohne approvals bei pending_approval-Status
Boundary Role (Permissions) + Composition (Members) Kein aktiver Grant → DENY (unabhängig vom Actor-Typ) Abgelaufener External-Grant
Skill Registry Role (required_by_roles) + Transaction (evidence) model_only ohne Human Override → DENY für kritische Operationen Agent übernimmt Owner-Rolle ohne Attestation
Diagram Semantics Alle Layer (visualisiert alles) Diagramm zeigt Human/Agent-Unterschied → Verletzt P-CORE-004 → Design Error UI mit separaten "AI Chat" und "User" Pfaden

11 · End-to-End: Feature Delivery durch alle Layer11 · End-to-End: Feature Delivery Through All Layers

Konkretes Beispiel: team-backend liefert ein Feature aus. Jeder Layer in der Kaskade.

LAYER F — Foundation:
  Actor-Modell aktiv. Role-based Dispatch initialisiert.

LAYER 2 — Ontology:
  alice = Individual Actor (substrate: biological)
  validator-bot = Individual Actor (substrate: computational)
  team-backend = Composite Actor (members: alice, bob, validator-bot)

LAYER 3 — Story:
  team-backend.story = { origin: "2024-Q1", purpose: "API Service Delivery",
    conflict: "legacy tech debt", path: "microservice migration",
    artifacts: [api-handler], state: "active", evidence: [...] }
  ✓ P-STORY-001: 8 Elemente vorhanden
  ✓ P-STORY-003: Member-Stories kompatibel

LAYER 4 — Role:
  alice: role=Lead in team-backend
  bob: role=Contributor
  validator-bot: role=Reviewer (deterministic verification only)

LAYER 5 — Composition:
  team-backend: status=active, governance=lead-decides
  External interface: single Composite Actor ID
  ✓ P-COMP-001: Fractal-Regeln aktiv

LAYER 6 — Transaction:
  txn-deploy-001: { actor: team-backend (executing: alice, role:Lead),
    target: artifact-api-handler, operation: approve+deploy,
    evidence: [tests passing, review-sign-off],
    approvals: [alice (lead), validator-bot (reviewer)],
    audit.fail_closed_gates: [actor, story, role, boundary, composition, skill, transaction, audit],
    status: committed }

LAYER 7 — Boundary:
  team-backend: boundary=internal (nur members sehen deploy-state)
  stakeholders: semi-permeable grant → sehen nur release-notes

LAYER 8 — Skill Registry:
  alice.skills: [code-review-python:practitioner, architecture-design:practitioner]
  validator-bot.skills: [deterministic-verification:expert (mcp_verified)]
  ✓ Alle required skills für Lead+Reviewer vorhanden

LAYER 9 — Diagram Semantics:
  Deployment-Diagramm zeigt role-based dispatch (nicht "human alice")
  Boundaries korrekt markiert (internal / semi-permeable)
  ✓ P-DIAG-001–007 eingehalten

RESULT: DEPLOY AUTHORIZED → committed als txn-deploy-001