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.
1 · Foundation Layer — Unified Control Model
Das Fundament. Keine eigenen Premises — strukturelle Integrationsschicht, die alle anderen Layer verbindet.
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.
| Premise | AussageStatement | KonsequenzConsequence |
|---|---|---|
P-CORE-001 | Alle handlungsfähigen Entitäten sind Actors | Keine Sonderregeln für Tools, APIs, Systeme |
P-CORE-002 | Actor = Individual | Composite | Alle Interaktion folgt demselben Schema |
P-CORE-003 | Unterschied zwischen Actors = Communication Mode (nicht Typ) | Machine-Optimized vs Narrative-Optimized — kein ontologischer Bruch |
P-CORE-004 | Kein ontologischer Unterschied Human/Agent | Wenn Layer Human/Agent trennt → sofortiger BLOCK → Design Error |
P-CORE-005 | Fractal Composition: universelle Actor-Regeln auf allen Ebenen | Team ist Actor. Org ist Actor. Federation ist Actor. Alle gleichen Regeln. |
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.
Eine Story hat 8 Pflicht-Elemente:
| Premise | RegelRule |
|---|---|
P-STORY-001 | Jeder Actor muss eine vollständige Story haben (alle 8 Elemente) |
P-STORY-002 | Story → Plan-Transformation ist deterministisch: gleiche Story → gleiche Plan-Struktur |
P-STORY-003 | Bei Composite Actor: Member-Stories müssen mit der zusammengesetzten Story vereinbar sein |
P-STORY-004 | Story muss über alle Schichten konsistent sein (one-liner ↔ genesis ↔ world ↔ decomposition) |
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.
| Core Role | KannCan | Constraints |
|---|---|---|
| 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 |
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.
| Phase | ValidierungenValidations | Fail-Closed-Trigger |
|---|---|---|
| Forming | Member-Stories kompatibel; Rollen klar; Shared Plan vorhanden; Decision Model deklariert | Inkompatible Member-Story → BLOCK (P-COMP-003) |
| Active | Externe Welt sieht Composite als Single Actor; Transaktionen werden Composite zugeschrieben | Mitglied verletzt Composition-Boundary → ACCESS_DENIED geloggt |
| Dissolved | Goal erreicht / unauflösbare Konflikte | Alle Shared Artifacts archiviert; Final-State-Snapshot erforderlich |
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.
Pflichtfelder jeder Transaktion:
txn-<uuid>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.
| Boundary-TypBoundary Type | Wer darf rein?Who May Enter? | Use Case | Fail-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):
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.
mcp_verified · workspace_verified · model_only · attestation| Evidence Class | BedeutungMeaning | HITL nötig?HITL Required? |
|---|---|---|
mcp_verified | Durch MCP-Tool-Run verifizierbarer Skill | Nein (automatisch) |
workspace_verified | Durch Workspace-Artefakte nachweisbar | Optional (Review) |
model_only | Nur durch Modell-Fähigkeit; keine externe Verifikation | Ja (Human override) |
attestation | Durch menschliche Bestätigung/Zertifizierung | Ja (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.
| Premise | RegelRule |
|---|---|
P-DIAG-001 | Eine Notation für alle Layer — kein separates Diagramm pro Subsystem |
P-DIAG-003 | Diagramme zeigen role-based dispatch (nicht actor-typ-basierte Unterscheidung) |
P-DIAG-004 | Transaction Flows: sequentiell + timestamped |
P-DIAG-005 | Stories vollständig mit allen 8 Elementen |
P-DIAG-006 | Mermaid-Rendering: machine-verifiable → Code aus Spec generierbar |
P-DIAG-007 | Boundaries 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