IIO Architekturbaum

Grafik 1 — IIO Vollständiger ArchitekturbaumFigure 1 — IIO Complete Architecture Tree

Leselogik: Wurzelknoten oben → Stämme (blauer Rand) → Äste (türkis) → Blätter (grün). Klappbare Knoten zeigen dir nur die gerade relevante Tiefe. Jeder Knoten zeigt Pfad und Funktion.

IIO — Intelligent Infrastructure Organism

iio/

Seed-Template · Governance-Rails · Referenzstruktur für alle Nodes
- Base Kernel
  
  iio/base/
  
  Taxonomie · Wissensbasis · Skript- und Artefakt-Fundament
  - Taxonomie & Root-Definition
    
    base/BASE-TAXONOMY.yaml
    
    Objektklassifikation · Strukturregeln · semantische Basis für alle Nodes
  - Agentic Organization
    
    base/agentic-organization/
    
    Rollen · Team-Interfaces · operative Verantwortlichkeit
    - Operations Rails
      
      agentic-organization/ops/
      
      Runbooks · Fallbacks · scripted operations
    - Manual Runbooks
      
      ops/manual-runbooks/
      
      Schritt-für-Schritt-Anweisungen für Operator
    - Fallback Procedures
      
      ops/fallback-procedures/
      
      Fail-closed Entscheidungen bei blockierenden Fehlern
    - Scripted Operations
      
      ops/scripted-operations/
      
      Automatisierbare, verifizierbare Abläufe
  - Library Mesh
    
    base/library/
    
    Referenzwissen · importierte Quellen · Pattern-Kataloge
    - Imported Repositories
      
      library/imported/
      
      Externe Source-Welten als nachvollziehbare Artefakte
    - Reference
      
      library/reference/
      
      Langzeitwissen & Wiederverwendung
    - Archive
      
      library/archive/
      
      Historisierung inaktiver Artefakte
  - Forensic
    
    base/forensic/
    
    Evidenzketten · Ursachenanalyse · reproduzierbare Nachverfolgung
  - Reflection
    
    base/reflection/
    
    Lernschleifen · Retrospektiven · Session-Meta-Analyse
  - Interface
    
    base/interface/
    
    Nutzbare Oberflächen-Kontrakte und Output-Interfaces
  - Manual Base Skill
    
    base/manual/SKILL.md
    
    Operator-Manual Skill · GO/NO-GO-Logik · Architektur-Grafiken
    - Template
      
      base/manual/templates/operator-manual.template.md
      
      Wiederverwendbare Manual-Vorlage mit Pflichtabschnitten
    - Validator
      
      base/manual/scripts/validate-operator-manual.sh
      
      Fail-closed Vertragsvalidierung für jedes erzeugte Manual
    - Example
      
      base/manual/examples/
      
      Referenzdurchläufe für Operator-Onboarding
  - Scripts + Revisions
    
    base/scripts/ · base/revisions/
    
    Automatisierungen & historische Versionsstände des Base-Kernels
  - Public Base Projection
    
    base/public/
    
    Öffentliche Darstellungslogik aus dem Kern
- Specs Governance Layer
  
  iio/specs/
  
  Maschinenlesbare Leitplanken · Agenten-Contracts · Gate-Definitionen
  - Agents
    
    specs/agents/
    
    Agentenrollen · Instruktionsprofile · Modusdefinitionen
  - Governance
    
    specs/governance/
    
    Gate-Logik · fail-closed Regeln · Entscheidungsrahmen
  - Layers
    
    specs/layers/
    
    Layer-Interaktion zwischen Seed und Nodes
  - Transformation
    
    specs/transformation/
    
    Übergangsmodelle · Migrationsregeln · Strukturwechsel
  - Script Specs
    
    specs/scripts/
    
    Automationsverträge · Eingabe/Output-Konformität
- Manual + Operator Surface
  
  iio/manual/
  
  HITL-Steuerflächen · Diagnose- und Kontrollseiten
  - Kontroll-Interfaces
    
    manual/premises-explorer.html
    manual/script-console.html
    manual/git-control-tower.html
    
    Steuerung · Entscheidung · Ausführung
  - State + Forensic Views
    
    manual/system-state.html
    manual/forensic-explorer.html
    manual/mcp-profile.html
    
    Live-Zustand · Fehlerkette · Kontextabhängigkeiten
  - Operator Assessment
    
    manual/agent-self-assessment.html
    manual/library-control.html
    
    Kapabilitätscheck · Library-Kontrolle
  - Architekturbaum
    
    manual/architecture-tree.html
    
    Vollständige Systemkarte · Layer-Landkarte · Kontrollzyklus
  - Operator Manuals
    
    manual/SEED-HITL-OPERATOR-MANUAL.*
    manual/SEED-OPS-MANUAL.md
    
    Verfahrensanleitungen · Rollen- und Aufgabenklarheit
- Data + Public Projection
  
  iio/public/ + iio/docs/
  
  Publikationskanal · Statuskommunikation · Revisionskontrolle
  - Public Delivery
    
    public/index.html
    public/data/*
    
    Aktuelle Systemzustands-Darstellung und Kennzahlen
  - Node State Data
    
    public/data/iio-node-state.js
    public/data/iio-op-layer.js
    
    Maschinenlesbare Zustandsdaten für Live-Views
  - Revisions
    
    public/revisions/
    
    Versionierte Stände · Nachvollziehbarkeit · Rollback-Punkte
  - Session Evidence
    
    docs/session/
    
    Chronologie · Entscheidungen · reproduzierbare Evidenz
- Theme + UI Layer
  
  iio/theme/
  
  Designsystem · Theme-Switching · semantische UI-Konsistenz
  - Theme Packs
    
    theme/b2b/
    theme/iio/
    theme/iio-green/
    theme/intelego/
    
    Kontextabhängige visuelle Sprache je Domain
  - Theme Switch Control
    
    Laufzeitumschaltung und dokumentiertes Verhalten
- Growth + Organisation
  
  iio/growth/ + iio/organisation/
  
  Strategische Skalierung · Storyline · Organisations-Rollout
  - Campaign
    
    growth/campaign/
    
    Programmierte Kommunikations- und Wachstumspfade
  - IIO Organisation
    
    organisation/iio/
    
    Interne Organisationsstruktur des Seed-Trägers

Stamm (dunkelblau links): Strukturelle Kernbereiche mit Steuerwirkung auf alle untergeordneten Ebenen.

Ast (türkis links): Funktionale oder methodische Domänen mit eigenem Regelwerk.

Blatt (grün links): Konkrete Artefakte, Frontends, Datenpfade, ausführbare Outputs.

Wurzel (Schattierung oben): Der IIO-Seed ist der einzige Ursprung — alle Nodes projizieren direkt aus ihm.

Grafik 2 — Layer-Landkarte: Governance bis PublicFigure 2 — Layer Map: Governance to Public

Zeigt den End-to-End Kontrollfluss als Prozessbahnen — nützlich bei Architektur- und Governance-Gesprächen, wenn nicht einzelne Dateien, sondern die Wirkungskette relevant ist.

1 · Governance Backbone

specs/governance Policies → Gate Definitionen → Fail-Closed Kriterien → Agent Contract

2 · Knowledge & Taxonomy

BASE-TAXONOMY → Library Import/Reference → Klassifizierte Artefakte → Forensic Evidence

3 · Operator Surfaces

Manual Views → Premises + Script + Git → Forensic + MCP Profile → Human Decisions

4 · Runtime & Evidence

Node/Op State JS → System State View → Session Docs → Traceable Revisions

5 · Public Projection

public/data/* → public/index.html → public/revisions → External Read Model

6 · Node Projection

IIO Seed Template → Node (z.B. intelego) → lokale Anpassung → Node Public Output

Grafik 3 — Operator-Kontrollzyklus (OODA-Loop in IIO)Figure 3 — Operator Control Cycle (OODA Loop in IIO)

Architektur in Betrieb: Der relevante Loop ist eine Entscheidungskette, kein reiner Dateibaum. Jede Schleife muss evidenzfähig sein und fail-closed bleiben.

OBSERVE

System State lesen → Premises prüfen → Abweichungen markieren → Forensic-Spur sichern

ORIENT

Gate GO / BLOCK → Capability-Matrix prüfen → Risiko einschätzen → Scope eingrenzen

DECIDE

Operation wählen → Rollback definieren → Escalation wenn nötig → Manual freigeben

ACT

Script Console → Git Control Tower → Publikation ausführen → Checkpoint setzen

VERIFY

Forensic Check → Docs/Specs/Public Sync → Revision protokollieren → Next Step festlegen

Grafik 4 — Seed → Node ProjektionsmatrixFigure 4 — Seed → Node Projection Matrix

Zeigt, welche IIO-Bestandteile ein Node übernimmt, lokalisiert oder eigenständig führt. Basis für jedes Node-Onboarding und für Drift-Detection.

IIO Seed BestandteilIIO Seed Component	Node übernimmtNode Adopts	Node lokalisiertNode Localizes	Node eigenständigNode Independent	BemerkungNote
`BASE-TAXONOMY.yaml`	✅	Ergänzungen möglich	—	Basis-Klassifikation unveränderlich
`specs/governance/`	✅	Node-Gates ergänzen	—	Fail-closed Regeln bindend
`specs/agents/`	Referenz	Node-Rollen anpassen	Neue Rollen definieren	—
`manual/`	HITL-Pattern	Node-Seiten ergänzen	Node-Manual-Hub	iio/manual bleibt Seed-nativ
`base/library/`	Importe übernehmen	Eigene Imports	Node-Library-Pfad	Keine Duplikate
`theme/`	Basis-Theme	Node-Theme-Pack	—	Theme-Switcher JS geteilt
`public/`	Strukturmuster	Node public/ eigenständig	Node-Daten	Sync-Pflicht pro Node
`docs/`	Dok-Konvention	Node-Docs	Node-Session	Keine Drift still akzeptieren
`base/agentic-organization/`	Ops-Rail-Pattern	Node-Team-Config	Node-Runbooks	Lane-Prinzip einhalten

Grafik 5 — IIO System-Atlas (Orbit-Map)Figure 5 — IIO System Atlas (Orbit Map)

Diese Grafik zeigt den Systemkern und alle großen Orbit-Domänen: Governance, Operations, Daten, Narrative und externe Projektion. So wird sichtbar, was wirklich im System steckt.

IIO
CORE

base/taxonomy

specs/governance

manual/control

public/data

docs/session

library/reference

forensic/reflection

agent contracts

agentic-organization

theme/interfaces

KernschichtCore Layer

base mit Taxonomie als Stabilitätsanker
agentic-organization als Rollenmaschine
library als Wissensspeicher + Imports

KontrollschichtControl Layer

specs/governance mit fail-closed Gates
manual mit Premises, Script, Forensic
GO/BLOCK und Evidence-Linien

PublikationsschichtPublication Layer

public/data als maschinenlesbares Modell
public/index als menschlicher Read-View
revisions als Nachvollziehbarkeit

Unsichtbares sichtbarMake the Invisible Visible

story-compiler, universes, flows, transactions
publishing-interfaces und reality-map
ops-scripts + templates als Backstage

Grafik 6 — Wirkungsketten: vom Signal bis zur StoryFigure 6 — Effect Chains: From Signal to Story

Nicht nur Struktur, sondern Wirkung: Welche Kette läuft durch, wenn etwas im System beobachtet, entschieden, publiziert und wieder in die Story eingespeist wird.

Kette A — Governance Entscheidung

Premise Signal

Gate Evaluation

GO/BLOCK Decision

Operator Action

Kette B — Operative Ausführung

Script Console

Git Control Tower

State Update

Revision Proof

Kette C — Story + Öffentlichkeit

Docs Session

Spec Sync

Public Projection

Narrative Clarity

Grafik 7 — Subsystem-Inventar: Was steckt alles im IIO-System?Figure 7 — Subsystem Inventory: What is inside the IIO system?

Aus der realen Ordnerstruktur extrahiert: große Domänen und Backstage-Bereiche, die in der normalen Navigation oft verborgen bleiben.

Subsystem	Bereiche im SystemAreas in the System	Funktion in der StoryFunction in the Story	SichtbarkeitVisibility
`base/agentic-organization/`	core, layers, flows, streams, transactions, realities, universes	Organisationsmotor und Rollen-Topologie	meist backstage
`base/agentic-organization/story*`	story, story-compiler	Narrative Kompilierung und Story-Fassung	teilweise sichtbar
`base/agentic-organization/publishing*`	publishing, publishing-interfaces	Output- und Publikationsbahnen	indirekt sichtbar
`base/agentic-organization/ops`	manual-runbooks, scripted-operations, fallback-procedures	Operative Vollzugslogik	operatornah
`base/library/`	imported, reference, archive, scripts	Gedächtnis + Quellenraum	teilweise sichtbar
`base/forensic/`	scripts, templates	Evidenz und Ursachenklärung	sichtbar über Forensic UI
`base/manual/`	SKILL, templates, validator, examples	Operator-Vertrag und Verfahrenssicherheit	indirekt sichtbar
`base/public/`	templates, examples, scripts	Projection-Pipeline zur Public View	halb sichtbar
`base/interface/`	op-cube	UI- und Interaktions-Interface	teilweise sichtbar
`specs/`	agents, governance, layers, scripts, transformation	Regelwerk und Maschinenvertrag	governance-sichtbar
`manual/`	premises, script-console, system-state, git-control-tower, architecture-tree	Operator-Cockpit	voll sichtbar
`public/`	index, data, revisions	Außenansicht und Status-Readout	voll sichtbar
`docs/session/`	Session-Artefakte	Narrative und Entscheidungs-Chronik	teilweise sichtbar
`theme/`	b2b, iio, iio-green, intelego, switcher	Visuelle Sprache und Moduswechsel	sichtbar
`.github/skills/`	skills (z.B. communication-trace-retro)	Agentenspezifische Fähigkeitsmodule	verborgen

Sichtbarkeitsprinzip: Alles ist im System vorhanden, aber nicht alles ist im ersten UI-Layer sichtbar. Diese Inventaransicht macht die verborgenen Subsysteme bewusst, damit Story, Betrieb und Governance auf derselben Karte sprechen.

Grafik 8 — Konstellation der KontrollräumeFigure 8 — Constellation of Control Spaces

Welche Räume zusammenarbeiten: Premises, State, Forensic, Script, Git, Public und Docs. Diese Sicht erklärt die App als lebendes Kontroll-Ökosystem statt als Einzelseiten.

Premises Explorer

Wahrheitsannahmen + Gate-Einstieg
Startpunkt für GO/BLOCK
Policy-Perspektive

System State

Live-Zustand Node + Op Layer
Status-Konsolidierung
Delta-Basis für Entscheidungen

Forensic Explorer

Evidenzkette
Root-Cause Lesbarkeit
Risiko-Nachweis

Script Console

Ausführungspunkt
Deterministische Schritte
Operator-Kontrolle

Git Control Tower

Revisionssicherheit
Nachvollziehbare Änderungspfade
Publikationsdisziplin

Public + Docs

Externe Lesbarkeit
Story-Projektion
Session-Gedächtnis

Grafik 9 — Blind-Spot-Radar: Wo Story und System auseinanderlaufen könnenFigure 9 — Blind Spot Radar: Where Story and System Can Diverge

Diese Radar-Übersicht zeigt die typischen Spannungsfelder. Ziel ist nicht Alarmismus, sondern frühe Sichtbarkeit, damit der Betrieb stabil bleibt.

SpannungsfeldTension Field	SymptomSymptom	Konkreter Gegenanker im SystemConcrete Counter-Anchor in the System	Story-WirkungStory Impact
Struktur vs. Betrieb	Schöne Karte, aber unklare nächste Aktion	Operator-Kontrollzyklus + Script Console	Von Vision zu Handlungsfähigkeit
Governance vs. Tempo	Schnelle Changes ohne Gate-Check	specs/governance + GO/BLOCK Rails	Tempo ohne Vertrauensverlust
Daten vs. Narrative	Public sagt etwas anderes als State	Docs/Specs/Public Sync Pflicht	Konsistente Außenwirkung
Evidence vs. Behauptung	Unbelegte Aussagen im Manual	Forensic + Evidence Matrix	Höhere Glaubwürdigkeit
Tooling vs. Verantwortung	Automatisierung ohne Owner	Owner + Next Step Felder in Manuals	klare Accountability

Grafik 10 — Die IIO-App-Story in 6 BildernFigure 10 — The IIO App Story in 6 Frames

Eine komprimierte Erzählspur für Onboarding, Briefings und Stakeholder-Dialoge.

Bild 1 — Ausgangslage

Komplexes System

Viele Quellen

Verteilte Entscheidungen

Drift-Risiko

Bild 2 — Seed als Boden

Taxonomie

Governance Rails

Manual Contract

Fail-Closed Default

Bild 3 — Operator in Aktion

Premise prüfen

Gate entscheiden

Script ausführen

State verifizieren

Bild 4 — Evidence sichern

Forensic Chain

Revision

Owner/Next

Reproduzierbarkeit

Bild 5 — Story publizieren

Docs

Specs

Public

Gemeinsames Bild

Bild 6 — Skalierung

Seed → Node

Local Adaptation

Kontrollierte Expansion

Lernender Organismus

Grafik 11 — Was dieses System wirklich ist (für Entwickler)Figure 11 — What This System Really Is (for Developers)

Kurzform: IIO ist keine klassische Feature-App, sondern ein Governance-first Operationssystem. Code ist wichtig, aber nur ein Teil einer größeren Transaktionskette aus Rolle, Prämisse, Gate, Evidenz und Veröffentlichung.

1. Was ist der Kern?1. What is the Core?

Ein Seed-System mit Regeln, nicht nur ein UI-Frontend.
Jede Änderung wird als kontrollierter Vorgang betrachtet.
Ziel ist reproduzierbarer Betrieb statt ad-hoc Veränderung.

2. Was ist neu gegenüber normaler Entwicklung?2. What is new compared to normal development?

Fail-closed statt fail-open: unklare Inputs blockieren bewusst.
Story ist ein operatives Objekt, nicht nur Kommunikation.
GO/BLOCK basiert auf Gate-Evidenz, nicht Bauchgefühl.

3. Woraus besteht die Ausführung?3. What is execution composed of?

Actor + Role: Wer darf handeln?
Skill + Boundary: Darf und kann die Einheit das im Scope?
Transaction + Audit: Ist der Schritt später beweisbar?

4. Warum wirkt das für viele neu?4. Why does this feel new to many?

"Done" heißt hier: funktional + regelkonform + evidenzierbar.
Governance ist upstream, nicht nachgelagerte Compliance.
Mensch und AI sind explizit als Team mit Rollen modelliert.

Developer-Übersetzung A — Policy-driven CI/CD

Premise Check

Gate Cascade

Approved Execution

Auditable Release

Developer-Übersetzung B — Event Sourcing für Betrieb

Intent

Transaction

State Projection

Public Read Model

Developer-Übersetzung C — SRE + Product Governance

Observe

Decide

Act

Prove

Frage beim ArbeitenQuestion While Working	Klassischer ReflexClassic Reflex	IIO-ReflexIIO Reflex	NutzenBenefit
Was muss ich jetzt bauen?	Direkt implementieren	Erst Premise/Gate-Scope klären	Weniger Rework und weniger Drift
Ist das fertig?	Tests grün	Tests + Gate + Evidence + Owner	Höhere Betriebssicherheit
Warum wurde blockiert?	Störung im Prozess	Sicherheitsfunktion fail-closed	Fehler früh statt spät
Wie skaliert das?	Mehr Features	Seed → Node Projektion mit Rails	Kontrollierte Expansion
Wie erklärt man das Team?	Architekturdiagramm	Architektur + Entscheidungslogik + Story	Gemeinsames mentales Modell

Grafik 12 — Wie Base-Skills mit Top-Level-Foldern verbunden sindFigure 12 — How Base Skills Connect to Top-Level Folders

Die Base-Skills arbeiten nicht isoliert. Jeder Skill wirkt in den Top-Level-Raum hinein und erzeugt dort prüfbare Artefakte oder Entscheidungen. Diese Tabelle macht die Kopplung explizit.

Base Skill	Primäre Base-DomänePrimary Base Domain	Verbundene Top-Level-FolderConnected Top-Level Folders	KopplungslogikCoupling Logic	Sichtbarer EffektVisible Effect
`base/manual/SKILL.md`	Operator Contract + GO/NO-GO	`manual/`, `specs/`, `public/`, `docs/`	Definiert Manual-Pflichtstruktur, Evidence-Disziplin und Next-Step-Übergabe	Operator-Seiten, Entscheidungsstatus und reproduzierbare Handovers
`base/public/SKILL.md`	Public Projection Layer	`public/`, `docs/`, `specs/`	Transformiert interne Entscheidungen in öffentliche Read-Model-Artefakte	Konsistente Public-Ansicht statt Drift zwischen intern und extern
`base/revisions/SKILL.md`	Revision Packaging + Validation	`public/revisions/`, `specs/`, `docs/`	Packt Zustände als versionierte Revisionen mit Contract-Validierung	Nachvollziehbare Evolutionspunkte und belastbare Rollback-Referenzen
`base/forensic/SKILL.md`	Evidence Chain + Root Cause	`manual/`, `specs/`, `docs/`, `public/`	Stützt GO/BLOCK mit Evidenzklasse statt unbelegter Behauptung	Forensic-Nachweise, überprüfbare Risiken, besserer Audit-Fit
`base/reflection/SKILL.md`	Learning Loop + Retro	`docs/`, `specs/`, `manual/`	Verdichtet Session-Erkenntnisse in wiederverwendbare Regeln	Bessere Folgeentscheidungen und weniger Wiederholfehler
`base/library/SKILL.md`	Knowledge Ingest + Classification	`library/`, `base/library/`, `specs/`, `manual/`	Ordnet importierte Quellen und setzt sie in taxonomische Kontexte	Nutzbares Wissensfundament für Operator, Agenten und Regeln

Propagation A — Manual Skill in den Top-Level-Raum

base/manual/SKILL

manual/ Operate

specs/ Govern

public/ Explain

Propagation B — Forensic + Revisions + Public

forensic Evidence

revisions Package

public Projection

docs Memory

Merksatz für Entwickler: Base-Skills sind die Steuerlogik, Top-Level-Folder sind die Projektionsebene. Jede Skill-Entscheidung muss als Spur in mindestens einem Top-Level-Ordner sichtbar werden, sonst gilt der Schritt als unvollständig.

IIO Architekturbaum — Vollständige SystemstrukturIIO Architecture Tree — Complete System Structure

Grafik 1 — IIO Vollständiger ArchitekturbaumFigure 1 — IIO Complete Architecture Tree

Grafik 2 — Layer-Landkarte: Governance bis PublicFigure 2 — Layer Map: Governance to Public

Grafik 3 — Operator-Kontrollzyklus (OODA-Loop in IIO)Figure 3 — Operator Control Cycle (OODA Loop in IIO)

Grafik 4 — Seed → Node ProjektionsmatrixFigure 4 — Seed → Node Projection Matrix

Grafik 5 — IIO System-Atlas (Orbit-Map)Figure 5 — IIO System Atlas (Orbit Map)

KernschichtCore Layer

KontrollschichtControl Layer

PublikationsschichtPublication Layer

Unsichtbares sichtbarMake the Invisible Visible

Grafik 6 — Wirkungsketten: vom Signal bis zur StoryFigure 6 — Effect Chains: From Signal to Story

Grafik 7 — Subsystem-Inventar: Was steckt alles im IIO-System?Figure 7 — Subsystem Inventory: What is inside the IIO system?

Grafik 8 — Konstellation der KontrollräumeFigure 8 — Constellation of Control Spaces

Premises Explorer

System State

Forensic Explorer

Script Console

Git Control Tower

Public + Docs

Grafik 9 — Blind-Spot-Radar: Wo Story und System auseinanderlaufen könnenFigure 9 — Blind Spot Radar: Where Story and System Can Diverge

Grafik 10 — Die IIO-App-Story in 6 BildernFigure 10 — The IIO App Story in 6 Frames

Grafik 11 — Was dieses System wirklich ist (für Entwickler)Figure 11 — What This System Really Is (for Developers)

1. Was ist der Kern?1. What is the Core?

2. Was ist neu gegenüber normaler Entwicklung?2. What is new compared to normal development?

3. Woraus besteht die Ausführung?3. What is execution composed of?

4. Warum wirkt das für viele neu?4. Why does this feel new to many?

Grafik 12 — Wie Base-Skills mit Top-Level-Foldern verbunden sindFigure 12 — How Base Skills Connect to Top-Level Folders