Ontologie-ModellOntology Model

Kernkonzepte der IIO-Ontologie: Intelligent Actor, Communication Mode, Composite Actor und Fractal Composition — die drei Refactorings, die falsche Hierarchien eliminieren.

1. Kernthese: Zwei Ontologie-Revolutionen1. Core Thesis: Two Ontology Revolutions

Die IIO-Ontologie basiert auf zwei Fundamentalverschiebungen, die herkömmliche KI/Human-Trennungen auflösen:

❌ Alte Sichtweise

„Agent" und „Human" sind verschiedene Typen. Kollektive (Teams, Orgs) sind eigene Schichten mit eigenen Regeln. Passive Entitäten existieren neben aktiven Akteuren.

✓ IIO-Ontologie

Alle sind Intelligent Actors. Unterschied = Communication Mode, nicht Ontologie. Kollektive sind Composite Actors — gleiche Regeln, fraktal skalierbar.

P-CORE-003: Entity → Actor P-CORE-004: Agent/Human → Comm.Mode P-CORE-005: Composition → Composite Actor P-CORE-006: Communication = Universal Mechanism

2. Refactoring 1: Entity → Actor (P-CORE-003)2. Refactoring 1: Entity → Actor (P-CORE-003)

Vorher

Entity (passiv) und Actor (aktiv) waren separate Kategorien.
Ressourcen = passive Entities. Nur bestimmte Objekte waren „Actors".

Nachher

Alle Wesen und Artefakte sind Actors.
Passiv/aktiv ist eine Role, keine ontologische Kategorie.
Es gibt keine passiven Entities im Space.

KonsequenzConsequence

Statt „ist das eine Ressource oder ein Actor?" fragt man: „Welche Role hat dieser Actor jetzt — aktiv ausführend oder passiv verfügbar?" Damit verschwindet eine ganze Kategorie-Ebene. Das Modell wird einfacher.

Praktische AuswirkungPractical Effect

Altes KonzeptOld Concept	IIO-KonzeptIIO Concept
Passiver Datenspeicher (Entity)	Actor mit Role „data-provider", gegenwärtig ohne Agenda
Source-Code-Datei (Resource)	Actor mit Role „artifact", kann in Stories, TXs referenziert werden
Tool / Service (passive component)	Actor mit Role „service-provider", hat eigene Boundary

3. Refactoring 2: Agent/Human → Intelligent Actor + Communication Mode (P-CORE-004)3. Refactoring 2: Agent/Human → Intelligent Actor + Communication Mode (P-CORE-004)

Die Unterscheidung Human vs. Agent ist keine ontologische Differenz, sondern eine Kommunikationspräferenz. Beide besitzen identische Kernfähigkeiten:

Perception (Kontext-Awareness) Skill Development & Learning Discovery & Adaptation Agency & Intentionality

Communication Modes (die eigentliche Unterscheidung)Communication Modes (the actual distinction)

Machine-Optimized Communication

AGENTS.md als primäre Schnittstelle
Strukturierte Transactions + Logs
Deterministische Pfade
YAML/JSON-Formate bevorzugt
Direkte Tool-Invokation

Narrative-Optimized Communication

README.md als primäre Orientierung
Narrative + heuristische Reasoning
Story-basierte Planung
Freie Prosa + Metaphern
Kontextuelle Interpretation

Ein einzelner Intelligent Actor kann beide Modi gleichzeitig verwenden. Ein Mensch in IIO empfängt AGENTS.md (Regeln) + README.md (Narrativ) und bindet beide zusammen. Ein LLM-Agent ist identisch aufgebaut — nur die primäre Lese-Präferenz verschiebt sich.

Schichtenmodell nach RefactoringLayer Model after Refactoring

# VORHER (implizite Hierarchie):
Agentic Layer → Formal Core → Story → Human Instruction Layer → ...

# NACHHER (Universal Core + Mode):
Agentic/Formal Core (universal, substrate-agnostic)
    ↓
Communication Mode Layer (adaptiert Präsentation)
    ├→ Machine-Optimized  (AGENTS.md, TX, Logs)
    └→ Narrative-Optimized (README.md, Story)
    ↓
Language · Theme · Publishing · Interface · Transaction · State

Keine Hierarchie mehr zwischen Modi. Core ist geteilt, Mode ist Präsentation.

4. Refactoring 3: Composition wird Composite Actor (P-CORE-005)4. Refactoring 3: Composition Becomes Composite Actor (P-CORE-005)

Wenn Intelligent Actors in koordinierter Arbeit mit definierten Roles und Boundary kollaborieren, wird ihre Composition selbst ein Actor. Kein ontologischer Unterschied mehr zwischen Individuum und Kollektiv — beide folgen identischen Regeln.

Individual Actor

Einzelnes intelligentes Wesen (Mensch, LLM, System …)
Tritt Space bei, empfängt Story/State/Work/Interfaces/Roles
Führt Transactions aus, nimmt an Relations teil
Hat persönliche Story + Plan

Composition (der Klebstoff)

Koordinierte Arbeit + Shared Plan
Definierte Roles + Boundary
Intern: identisches Actor/Role/TX-Modell
Preconditions: alle 6 Felder befüllt + Member Stories kompatibel

Composite Actor

Composition + ihre Members zusammen
Nach außen: verhält sich wie ein einzelner Actor
Kann selbst Spaces betreten, Roles übernehmen
TX-Log: Composite Actor primär, Member-Detail sekundär

Composition YAML-StrukturComposition YAML Structure

id: composition@universe_id
actors:
  - role: lead
    actor: actor_id_1
  - role: contributor
    actor: actor_id_2
  - role: observer
    actor: actor_id_3
shared_plan: plan_id
shared_work: [work_id_1, work_id_2]
shared_artifacts: [artifact_id_1]
shared_state: state_id
boundary: composition_boundary_id
internal_relations: [rel_id_1, rel_id_2]
# → wenn alle Felder befüllt + Stories konsistent:
# Composition registriert sich als Composite Actor

5. Fraktale Skalierbarkeit5. Fractal Scalability

Weil Individual- und Composite Actors identischen Regeln folgen, skaliert das Modell ohne neue Architektur:

Level 1: Individual Einzelner Actor (Mensch oder Agent)

Level 2: Small Team Composite Actor aus 2–5 Individuals

Level 3: Org Composite Actor aus Teams (jedes = Composite Actor)

Level 4: Federation Composite Actor aus Orgs (inter-org coordination)

Jede Ebene benutzt identische Spec. Kein „nested logic", kein Sonderfall.

Multi-Role BeispielMulti-Role Example

Eine Person kann gleichzeitig sein — ohne Widerspruch:

KontextContext	Role	Actor-Typ
In Team Alpha	contributor	Individual Actor
Lead von Team Beta	lead	Individual Actor (innerhalb Composite)
Team Beta → Org Gamma	delegate_member	Composite Actor als Member
Eigener privater Workspace	owner	Individual Actor (boundary-less)

Alle diese Kontext-Rollen existieren simultan — IIO löst Konflikte über den Role-Conflict-Check (P-ROLE-003/P-ROLE-004).

6. Communication als universeller Koordinationsmechanismus (P-CORE-006)6. Communication as Universal Coordination Mechanism (P-CORE-006)

Jede Actor-Interaktion ist ein Communication Event. Intra-Space Events werden als Transactions realisiert. Inter-Space Events verwenden Interfaces und Federation Channels.

EbeneLevel	RealisierungImplementation	Format
Intra-Space (innerhalb einer Composition)	Transaction	TX-YAML + Audit-Log
Inter-Space (zwischen Compositions/Nodes)	Interface + Federation Channel	Adapter-Registry (API/Webhook/Sync)
Cross-Org (zwischen Organisationen)	Federated Boundary + Delegate	P-FED-001: mutual consent TX

Der Communication Mode (P-CORE-004) bestimmt das Präsentationsformat — der zugrundeliegende Mechanismus bleibt für alle Actors identisch.

7. Migrationspfad (für bestehende Repos)7. Migration Path (for existing Repos)

Dieses Dokument lesen.
Ersetze „ist das für Agents oder Humans?" → „Welche Communication Modes sind sinnvoll?"
Prüfe AGENTS.md + README.md: Beschreiben sie dieselbe Arbeit in zwei Modi oder verschiedene Arbeit?
- Gleiche Arbeit → konsistent ✓
- Verschiedene Arbeit → Drift (beheben)
Prüfe Schichtenarchitektur: „Human Layer" sollte „Communication Mode" referenzieren — nicht eine separate Strata.
Aktualisiere alle Docs, die „agent vs. human" sagen → „Intelligent Actors mit verschiedenen Interface-Präferenzen".

Relevante Premises: P-CORE-001 P-CORE-002 P-CORE-003 P-CORE-004 P-CORE-005 P-CORE-006 P-ARCH-001 P-ARCH-002