Flow Atlas

Die acht registrierten Flows des IIO-Systems — von der Entstehung einer Story bis zur Realität, inklusive Import, Publishing, Service, Contract, Agent-Arbeit, Coding und Federation.

Grundprinzip aller FlowsCore Principle of All Flows

Jeder IIO-Flow ist eine geordnete Sequenz von State-Übergängen. Kein Flow darf Schritte überspringen, ohne einen Transaction-Record zu hinterlassen.

Story → Plan → Work → Artifact → State → Evidence → Reality

Dieses 7-Glieder-Modell ist der kanonische Kern aus dem Space-Kernel. Jeder registrierte Flow ist eine Spezialisierung dieser universellen Sequenz für einen spezifischen Operationstyp.

P-STORY-001 P-TXN-001 P-EXEC-001 8 registrierte Flows

Übersicht: Alle FlowsOverview: All Flows

story-to-reality

Der Basisflow — Kernsequenz für alle anderen Flows.

Story→ Plan→ Work→ Artifact→ State→ Evidence

import-flow

Überführung von Legacy-Daten in govarniertes IIO-Format.

Legacy→ Staging→ Classify→ Normalize→ Relations→ State

publishing-flow

Interne Artefakte zu öffentlichen Outputs mit Kanal-Trennung.

Internal→ Theme/Lang→ Approval→ Public

service-flow

Anfragen, Incidents und Changes von Eingang bis Abschluss.

Request→ Assign→ Execute→ Evidence→ Closure

contract-flow

Vertragsprozess von Entwurf bis Verlängerungsplanung.

Draft→ Review→ Approval→ Signature→ Record→ Renewal

agent-workflow

Agentische Aktionen unter Human-in-the-Loop-Kontrolle.

Prompt→ Context→ Proposal→ Validate→ HITL→ State

coding-flow

Software-Entwicklung von Spec bis Release.

Spec→ Plan→ Branch→ Code→ Tests→ Review→ Merge→ Release

federation-flow

Grenzüberschreitende Kooperation zwischen Nodes.

Local State→ Boundary Check→ Bridge/Fed→ Remote Ref

1 · story-to-reality — Basisflow1 · story-to-reality — Base Flow

Der universelle Basisflow. Alle anderen Flows sind Spezialisierungen. Jede State-verändernde Aktion im IIO-System muss auf dieses Schema abbildbar sein.

Story→ Plan→ Work→ Artifact→ State→ Evidence

#	SchrittStep	Was passiertWhat Happens	Gate / SchichtGate / Layer
1	Story	Absicht formulieren: Wofür? Wer? Welches Ziel? Story muss konsistent und widerspruchsfrei sein.	Story
2	Plan	Story in konkrete, prüfbare Schritte übersetzen. Plan ist deterministisch — gleicher Input → gleicher Plan.	Story Role
3	Work	Ausführung nach Plan. Jede Abweichung vom Plan ist eine neue Transaction mit Begründung.	Role Skill
4	Artifact	Ergebnis der Arbeit — Datei, Record, Entscheidung, Code. Artefakt liegt im richtigen Node (Placement Rule Q1).	Boundary
5	State	System-State wird aktualisiert. State-Änderung = Transaction-Record. Kein Hidden State.	Transaction
6	Evidence	Nachweis, dass Story erreicht wurde. Auditierbar, reproduzierbar, unveränderlich archiviert.	Audit

P-STORY-001 P-STORY-002 P-TXN-001 P-TXN-006

2 · import-flow — Legacy-Überführung2 · import-flow — Legacy Migration

Überführt Legacy-Daten aus externen Quellen in governance-konformes IIO-Format. Kein Legacy-Artefakt darf direkt in produktive Strukturen übernommen werden — immer durch Staging und Classify.

Legacy Source→ Staging→ Classification→ Normalized→ Relations→ State

#	SchrittStep	Was passiertWhat Happens	Gate / SchichtGate / Layer
1	Legacy Source	Quelle identifizieren und isolieren. Keine direkten Schreibzugriffe aus Legacy. Placement Q4 prüfen.	Boundary
2	Staging	Artefakt in `imported/` ablegen, unveränderlich. Quellvermerk, Timestamp, Herkunfts-Actor.	Transaction
3	Classification	Regelbasierte Klassifikation (No-AI möglich): owned / referenced / generated / sensitive / contract-relevant.	Skill Role
4	Normalized	Artefakt in IIO-Zielformat überführen. Transformation ist Transaction-Record mit before/after State.	Transaction
5	Relations	Verbindungen zu anderen Nodes, Repos und Actors anlegen. `relations.yaml` aktualisieren.	Composition
6	State	Import-Abschluss als Transaction festhalten. Status: `imported`. Audit-Trail vollständig.	Audit

P-MIG-001 P-ROOT-001 P-TXN-002 P-NOAI-001

3 · publishing-flow — Publikation3 · publishing-flow — Publication

Steuert den Weg vom internen Artefakt zum öffentlichen Output. Kanal-Trennung (AGT/DE/EN) ist strukturelle Pflicht — kein Mixed-Language-Artefakt darf publiziert werden.

Internal Artifact→ Theme / Language→ Approval→ Public Output

#	SchrittStep	Was passiertWhat Happens	Gate / SchichtGate / Layer
1	Internal Artifact	Quell-Artefakt ist vollständig, in Kanal deklariert (AGT/DE/EN), kein Plaintext-Sensitive.	Boundary
2	Theme / Language	Kanal-Template anwenden. Sprach-Check: kein Mixed-Language. Theme-Klasse aus Registry.	Boundary Skill
3	Approval	Named Reviewer prüft. Kein Self-Approve. GO/BLOCK festhalten als Transaction.	Role Transaction
4	Public Output	Artefakt in `public/` ablegen oder deployen. Versionsnummer + Timestamp. Unveränderlich nach Publish.	Audit

P-LANG-001 P-LANG-002 P-LANG-003 P-ROLE-004 P-TXN-006

Technische Tiefenstruktur dieses Flows: publishing-pipeline.html — 4 Streams (content / assets / theme / routing_seo), 6 Theme-ETL-Stages, HITL Publication Gate, alle Scripts und Theme-Familien im Detail. · Transformer-Referenz (alle Processors, Input/Output-Streams): theme-transformer-reference.html · Language-Kanal-Policy: language-publishing.html

4 · service-flow — Service & Incidents4 · service-flow — Service & Incidents

Verarbeitet Requests, Incidents und Changes von Eingang bis zum dokumentierten Abschluss. Jeder Service-Event ist eine Transaction — kein Verbal-Commitment ohne Record.

Request / Incident / Change→ Assignment→ Execution→ Evidence→ Closure

#	SchrittStep	Was passiertWhat Happens	Gate / SchichtGate / Layer
1	Request / Incident / Change	Ticket anlegen mit Typ, Priorität, Actor-ID, Kontext. Kein informelles Handeln ohne Record.	Story
2	Assignment	Role-basierte Zuweisung. Actor hat nötige Skill-Evidenz. Kompositions-Membership prüfen.	Role Composition
3	Execution	Bearbeitung nach Plan. Jede Abweichung = neue Teilaktion mit Begründung. LLM-Unterstützung erlaubt.	Skill
4	Evidence	Nachweis der Lösung: Logs, Screenshots, veränderte Dateien. Reproduzierbar und datiert.	Transaction
5	Closure	Ticket schließen, State updaten, Learnings klassifizieren (local-only / seed-relevant).	Audit

P-TXN-001 P-ROLE-001 P-SKILL-002 P-LEARN-001

5 · contract-flow — Verträge5 · contract-flow — Contracts

Verwaltet den vollständigen Vertrags-Lebenszyklus. Contracts sind besonders geschützte Artefakte: Signature-Schritt erfordert Owner-Gate, Record ist unveränderlich.

Draft→ Review→ Approval→ Signature→ Record→ Renewal

#	SchrittStep	Was passiertWhat Happens	Gate / SchichtGate / Layer
1	Draft	Entwurf mit Actor-ID, Scope, Laufzeit. Kanal AGT (intern). Keine Veröffentlichung vor Approval.	Story
2	Review	Fachlicher Review (nicht-selbst-genehmigend). Legal/HR-Impact aus Placement Q7 prüfen.	Role
3	Approval	Owner-Gate: Named Owner muss GO geben. BLOCK wenn Scope unklar oder Conflict-of-Interest.	Role Transaction
4	Signature	Verbindliche Unterzeichnung. State wechselt zu `active`. Höchste Risiko-Klasse — Owner-Gate Pflicht.	Boundary
5	Record	Unterzeichnetes Artefakt in `archive/`. Unveränderlich. Querverweis in Registry.	Audit
6	Renewal	Ablaufdatum im Kalender, automatische Reminder. Erneuerung startet neuen contract-flow-Zyklus.	Story

P-TXN-002 P-TXN-006 P-SAFE-002 P-ROLE-004 P-ROOT-001

6 · agent-workflow — Agentische Aktionen6 · agent-workflow — Agentic Actions

Der Steuerungsflow für alle KI-Agentenaktionen. Kein Agent darf State verändern ohne Human-in-the-Loop-Gate. LLM-Vorschläge sind immer Proposal — nie direkte Execution ohne Validation.

Prompt→ Context→ Action Proposal→ Validation→ Human Review (HITL)→ State Change

#	SchrittStep	Was passiertWhat Happens	Gate / SchichtGate / Layer
1	Prompt	Task an Agent übergeben. Scope klar definiert. Actor-ID und Role-Binding vorhanden.	Story
2	Context	Agent lädt relevanten Kontext. Nur erlaubte Quellen. Kein versteckter State. Fail-closed bei fehlendem Kontext.	Boundary
3	Action Proposal	Agent formuliert konkreten Aktionsvorschlag — kein direktes Handeln. Vorschlag ist deterministisch dokumentiert.	Skill
4	Validation	Automatische Premises-Prüfung: Scope-Grenzen, Placement-Regeln, Permissions. GO/BLOCK/ESCALATE.	Transaction
5	Human Review (HITL)	Nur bei GO: Mensch bestätigt oder modifiziert. Kein Auto-Approve für State-ändernde Aktionen.	Role Boundary
6	State Change	Nach HITL-Freigabe: Aktion ausführen. Transaction-Record mit Agent-ID + Human-Approver. Audit-Trail vollständig.	Audit

P-EXEC-001 P-EXEC-002 P-SAFE-002 P-NOAI-001 P-TXN-007

7 · coding-flow — Software-Entwicklung7 · coding-flow — Software Development

Steuert den Software-Entwicklungszyklus von der Spezifikation bis zum Release. Jede Phase ist eine Transaction — Branch-Wechsel, Merges und Releases hinterlassen Audit-Records.

Spec→ Plan→ Branch→ Code→ Tests→ Review→ Merge→ Release

#	SchrittStep	Was passiertWhat Happens	Gate / SchichtGate / Layer
1	Spec	Anforderung als Story formuliert. Scope, Akzeptanzkriterien, Layer-Impact sind definiert.	Story
2	Plan	Technischer Plan: Schritte, Dateien, Dependencies. Premises-Impact vorab geprüft.	Role Skill
3	Branch	Git-Branch mit klarer Naming-Konvention. Branch ist Isolation-Boundary für In-Progress-Arbeit.	Boundary
4	Code	Implementierung nach Spec. Agent-Support erlaubt; Proposals durch Coding-HITL-Gate.	Skill
5	Tests	Automatisierte + manuelle Tests. Test-Ergebnisse sind Evidence-Artefakte.	Transaction
6	Review	Peer-Review (nicht self-approve). Reviewer ist nicht der gleiche Actor wie Author (P-ROLE-004).	Role
7	Merge	Merge nach GO. BLOCK wenn Tests fehlen oder Reviewer fehlend. Merge = Transaction-Record.	Transaction
8	Release	Versionierte Veröffentlichung mit Changelog. Owner-Gate bei produktionskritischen Changes.	Audit

P-ROLE-004 P-SKILL-002 P-TXN-001 P-TXN-006 P-SAFE-002

8 · federation-flow — Cross-Node-Kooperation8 · federation-flow — Cross-Node Cooperation

Ermöglicht kontrollierte Zusammenarbeit zwischen unabhängigen Nodes unter Wahrung der Boundary-Regeln. Mutual Consent und Scope-Immutability sind Pflicht — keine implizite Cross-Node-Verbindung.

Local State→ Boundary Check→ Bridge / Federation→ Remote Reference / Sync

#	SchrittStep	Was passiertWhat Happens	Gate / SchichtGate / Layer
1	Local State	Node-Zustand vollständig dokumentiert, alle Artefakte platziert. Kein partielle State-Sync.	Story
2	Boundary Check	Boundary-Typ prüfen (internal/semi-permeable/federated). RG-003: Mutual Consent und Scope-Deklaration.	Boundary
3	Bridge / Federation	Federation-Artefakt anlegen: beide Nodes gelistet, Scope unveränderlich, TTL-Review-Gate (24h). Human-Reviewer Pflicht.	Composition Transaction
4	Remote Reference / Sync	Nur Referenz-Links oder explizit genehmigte Sync-Artefakte. Keine Ownership-Übertragung ohne neuen contract-flow.	Audit

P-COMP-001 P-BOUND-004 P-BOUND-005 P-TXN-004

Flow-Übersicht: Layer-BeteiligungFlow Overview: Layer Participation

Flow	Story	Role	Composition	Skill	Boundary	Transaction	Audit
story-to-reality	●●●	●●	●	●●	●	●●●	●●●
import-flow	●	●	●●	●●	●●●	●●●	●●
publishing-flow	●	●●	—	●●	●●●	●●	●●●
service-flow	●●	●●●	●●	●●	—	●●●	●●
contract-flow	●●	●●●	—	—	●●	●●●	●●●
agent-workflow	●●	●●	—	●●●	●●●	●●	●●●
coding-flow	●●	●●●	—	●●●	●●	●●●	●●
federation-flow	●●	●	●●●	—	●●●	●●●	●●

●●● = primär aktiv | ●● = beteiligt | ● = marginally | — = nicht direkt aktiv

QuellenSources

iio/base/agentic-organization/flows/flow-registry.yaml — Registrierte Flow-IDs
iio/base/agentic-organization/flows/{flow-name}/flow.yaml — Kanonische Schritt-Beschreibungen
iio/base/agentic-organization/flows/README.md — Grundprinzip und Platzierungsregeln