Foundation: Konzeptionelle Grundlage für AI-gestützte Projektarbeit

Dieses Dokument definiert die gemeinsamen Konzepte, die sich in Profilen (software, research, writing) spezialisieren.

1. Kernkonzepte

Das Modell orientiert sich am hermeneutischen Zirkel: Vorverständnis und Gegenstand verändern sich wechselseitig durch jede Auseinandersetzung. Man beginnt mit einem Vorverständnis (Grounding), richtet sich auf etwas aus (Directive), arbeitet daran (Discourse) — und versteht danach sowohl den Gegenstand als auch die eigenen Voraussetzungen anders. Dieser Zirkel ist kein Kennzeichen eines Fehlers, sondern die Grundstruktur von Erkenntnisgewinn. Die Foundation überträgt dieses Prinzip auf AI-gestützte Projektarbeit.

Ein Circle hat drei substantielle Pole und einen Prozess, der sie verbindet:

        Directive
        (Wohin?)
          ╱╲
         ╱  ╲
        ╱    ╲
       ╱      ╲
Grounding ──── Artifact
(Worauf?)     (Was entsteht?)

Directive — prognostiziert den Zustand des Artifacts nach Abschluss
Grounding — die Basis, auf der Directive formuliert und Artifact entwickelt wird
Artifact — was im Discourse materialisiert wird, orientiert an der Directive, fundiert im Grounding

Coherence ist die Konsistenz zwischen diesen drei Polen. Discourse ist der Prozess, der sich zwischen ihnen bewegt. Rebalance justiert eines der drei nach, wenn Coherence nicht erreicht ist.

1.1 Directive

Prognostiziert den Zustand des Artifacts nach erfolgtem Abschluss.

Eine Directive richtet den Circle auf ein Ziel aus und definiert die Konditionen des Artifacts, mit denen der Circle abgeschlossen wird. Sie kann im Verlauf des Circle revidiert werden.

Directives haben keine inhärente Größe. Was eine Directive von einem Task unterscheidet, ist nicht der Umfang, sondern die Entscheidbarkeit: Erfordert die Arbeit Grounding, das noch nicht existiert? Wenn ja, ist es eine Directive und eröffnet einen Circle. Wenn nein, ist es ein Task und wird innerhalb eines bestehenden Turns ausgeführt. Große Directives erzeugen Sub-Circles durch Rekursion; kleine Directives können in einem einzigen Turn abgeschlossen werden. Beide folgen demselben Prozess.

Profil	Spezialisierung
software	Goal
research	Hypothesis
writing	Thesis

Abschluss: Eine Directive ist erfüllt, wenn Coherence zwischen Directive und Artifact hergestellt ist.

1.2 Grounding

Die Basis, auf der Directive formuliert und Artifact entwickelt wird.

Grounding umfasst alles, was den Circle und das Projekt fundiert: Festlegungen, Vorannahmen, etablierte Konventionen. Grounding akkumuliert sich über Sessions und Circles hinweg.

Grounding ist notwendig provisorisch. Man kann keinen Circle ohne Grounding beginnen — aber das Grounding, mit dem man beginnt, ist das Beste, was man jetzt weiß, nicht die Wahrheit. Jeder Turn kann Grounding revidieren. Das ist kein Defekt, sondern das Prinzip des hermeneutischen Zirkels: Vorverständnis und Gegenstand verändern sich wechselseitig. In Gadamers Terminologie ist Grounding das Vorurteil — die notwendige Voraussetzung, ohne die kein Verstehen beginnen kann, die aber durch das Verstehen selbst transformiert wird.

Profil	Spezialisierung
software	Decisions — kristallisiertes Vorverständnis (z.B. "REST statt GraphQL", weil man ein Vorurteil über die Angemessenheit hat)
research	Pre-understanding — expliziertes Vorverständnis im Sinne Gadamers
writing	Premises — argumentative Voraussetzungen, die sich im Schreibprozess klären

Zwei Schichten: Grounding existiert als aktiver Zustand und als Historie:

Schicht	Inhalt	Zweck
Grounding-Stand	Nur aktuelles Best-of-Knowledge	Wogegen Mensch und AI arbeiten. Sauber, widerspruchsfrei, abgeglichen.
Grounding-Historie	Append-only-Log aller Grounding-Elemente, einschließlich abgelöster	Nachvollziehbarkeit, Rationale, Lernen aus vergangenen Revisionen.

Wenn Grounding revidiert wird, wandert das alte Element in die Historie und das neue nimmt seinen Platz im Stand ein. Der Grounding-Stand darf niemals widersprüchliche Residuen früherer provisorischer Elemente enthalten — er repräsentiert das aktuelle Verständnis des Projekts, nicht seinen gesamten Weg. Die Historie bewahrt den Weg.

Abgleich geschieht an zwei natürlichen Punkten: während eines Rebalance (wenn ein Turn aufdeckt, dass Grounding revidiert werden muss) und bei Session-Ende (wenn Memory aktualisiert wird). An beiden Stellen stellt der Mensch sicher, dass der Grounding-Stand nur das widerspiegelt, was aktuell als zutreffend gilt.

Dynamik: Grounding wird im Circle transformiert — profilspezifisch als neue Decisions (software), verändertes Pre-understanding (research) oder revidierte Premises (writing).

1.3 Coherence

Die Konsistenz zwischen Directive, Grounding und Artifact.

Coherence hat zwei Aspekte:

Aspekt	Bedeutung
Coherence (Status)	Der erreichte Zustand der Konsistenz
Coherence Review	Die Prüfung, ob dieser Zustand erreicht ist

Der Coherence Review prüft alle drei Kanten des Dreiecks:

Kante	Prüffrage
Artifact ↔︎ Grounding	Respektiert das Artifact das bestehende Grounding?
Artifact ↔︎ Directive	Bewegt sich das Artifact auf die Directive zu?
Grounding ↔︎ Directive	Ist das aktuelle Grounding noch angemessen für die Directive?

Die profilspezifische Ausprägung bestimmt, wo der Schwerpunkt liegt:

Profil	Spezialisierung	Typischer Schwerpunkt
software	Architectural Coherence	Artifact ↔︎ Grounding (Respektiert der Code die Decisions?)
research	Epistemic Coherence	Artifact ↔︎ Directive (Ist das Artifact widerspruchsfrei zur Hypothesis?)
writing	Argumentative Coherence	Grounding ↔︎ Directive (Tragen die Premises die Thesis noch?)

Funktion: Coherence ist das Abschlusskriterium eines Circle. Ohne Coherence Review kein verlässlicher Abschluss.

Operationalisierung: Coherence ist primär ein qualitatives Urteil, das der Kompetenz des Human-in-the-Loop obliegt. Der Mensch trägt die Verantwortung für die Bewertung, ob Artifact, Directive und Grounding konsistent sind. AI kann dabei unterstützen:

Rolle	Beitrag zur Coherence-Prüfung
Human	Urteil über Gesamtkohärenz, Validierung gegen implizites Wissen, finale Entscheidung
AI	Systematische Prüfung gegen explizites Grounding, Aufdecken von Widersprüchen, Checklisten-basierte Reviews

Formale Ansätze können ergänzend wirken:

Checklisten-Review: AI prüft Artifact systematisch gegen dokumentiertes Grounding (z.B. "Werden alle dokumentierten Decisions respektiert?")
Divergenz-Analyse: AI vergleicht Artifact-Zustand mit Directive und markiert Abweichungen
Adversarial Review: AI argumentiert bewusst gegen die Coherence-These, um Schwächen aufzudecken

Die Operationalisierung ist profilspezifisch: Architectural Coherence (Software) lässt sich formaler prüfen als Epistemic Coherence (Research), wo das Urteil stärker auf Expertise beruht.

1.4 Memory

Die persistierte Wissensstruktur, die Kontinuität über Sessions und Circles hinweg ermöglicht.

Memory ist das Gedächtnis des Projekts. Es enthält:

Aktive Directives — Was gerade verfolgt wird
Grounding-Stand — Aktuelles Grounding des Projekts
Projekt-Kontext — Architektur, Konventionen, Rahmenbedingungen
Historie — Journal, abgeschlossene Circles, Grounding-Änderungen

Memory ist für Mensch und AI gleichermaßen lesbar und wird bei Session-Start geladen und bei Session-Ende aktualisiert.

Aspekt	Funktion
Für AI	Kontext, der fehlendes Langzeitgedächtnis kompensiert
Für Mensch	Dokumentation, Onboarding, Nachvollziehbarkeit
Für Prozess	Ermöglicht Rebalance über Sessions hinweg

Memory-Management: Das Kontextfenster der AI ist begrenzt. Memory muss daher aktiv verwaltet werden: Was wird geladen, was wird zusammengefasst, was wird archiviert. Ein wachsendes Projekt akkumuliert mehr Grounding, Historie und Kontext, als in ein Kontextfenster passt. Memory-Management entscheidet, welcher Ausschnitt des Gedächtnisses in einer Session verfügbar ist — und beeinflusst damit direkt die Qualität des Discourse.

Ladepriorität: Wenn das Kontextfenster nicht alles fassen kann, in dieser Reihenfolge laden:

Grounding-Stand — ohne aktuelles Grounding kann die AI nicht kohärent arbeiten
Aktive Directives — ohne Directives hat die AI keine Richtung
Projekt-Kontext — Architektur, Konventionen, Rahmenbedingungen, relevant für die aktiven Directives
Jüngste Historie — letzter Journal-Eintrag, jüngste Grounding-Änderungen
Ältere Historie — zusammengefasst, nicht wörtlich

Implementierung: Memory kann verschiedene Formen annehmen (Dateien, Datenbank, Knowledge Graph). In mono: CLAUDE.md + Journal + ADRs.

1.5 Artifact

Was im Discourse materialisiert wird, orientiert an der Directive, fundiert im Grounding.

Ein Artifact ist das, was am Ende eines Circle (oder als Increment einer Session) entsteht. Artifacts werden versioniert, dokumentiert und im Coherence Review gegen Directive und Grounding geprüft.

Profil	Spezialisierung	Beispiele
software	Code Artifact	Funktionierender Code, Tests, Dokumentation
research	Knowledge Artifact	Erkenntnisse, Interpretationen, Publikationen
writing	Text Artifact	Entwürfe, Kapitel, fertige Texte

2. Prozessstruktur

Circle                          Das Ganze: Directive → Closure
│
├── Turn                       Eine Runde: Discourse → Coherence Review → Rebalance
│   ├── Task                   Operative Einheit (Grounding reicht)
│   ├── Task
│   └── Task → Sub-Circle      Eskalation (Grounding reicht nicht)
│
├── Turn
│   └── ...
│
└── Closure

Ebene	Einheit	Gesteuert durch	Abschlusskriterium
Circle	Konvergentes Ganzes	Directive	Coherence über alle drei Kanten
Turn	Eine Umdrehung	Coherence Review	Coherence erreicht oder Rebalance ausgelöst
Task	Operative Arbeit	Bestehendes Grounding	Output erzeugt

Session ist orthogonal: sie ist der zeitliche Rahmen, in dem Turns stattfinden, begrenzt durch Kontextfenster, Zeit und Aufmerksamkeit.

2.1 Circle

Die Gesamtheit der epistemischen Bewegung von Directive zu Closure.

Ein Circle ist nicht eine einzelne Runde, sondern die Gesamtheit des Weges von einer gesetzten Directive bis zur erreichten Closure. Der Name leitet sich vom hermeneutischen Zirkel ab — dem Prinzip, nicht von der Form einer einzelnen Schleife.

Ein Circle enthält Turns: wiederholte Durchläufe von Discourse → Coherence Review → Rebalance → zurück in den Discourse. Jeder Turn verändert das Verständnis von Directive, Grounding oder Artifact. Der Turn ist die Runde; der Circle ist das Ganze.

┌──────────────────────────────────────────────────────────────────┐
│                            CIRCLE                                │
│                                                                  │
│   Directive ───────────────────────────────────────► Closure     │
│                                                                  │
│        │                                                ▲        │
│        ▼                                                │        │
│   ┌─────────┐      ┌─────────┐      ┌─────────────┐     │        │
│   │Grounding│─────►│Discourse│─────►│  Coherence  │─────┘        │
│   │         │      │         │      │   Review    │   (coherent) │
│   └─────────┘      └─────────┘      └──────┬──────┘              │
│        ▲                                   │                     │
│        │           (Rebalance)             │ (nicht coherent)    │
│        └───────────────────────────────────┘                     │
└──────────────────────────────────────────────────────────────────┘

Phasen eines Circle:

Directive setzen — Was soll erreicht/geprüft/dargelegt werden?
Grounding explizieren — Welches Grounding gilt?
Discourse — Intensiver Austausch zwischen Mensch und AI (siehe 2.3)
Coherence Review — Prüfung: Passt Artifact zu Directive und Grounding?
Rebalance — Bei Nicht-Coherence: Gleichgewicht wiederherstellen (siehe unten)
Closure — Coherence erreicht; Artifact fertig

Rebalance:

Die Wiederherstellung des Gleichgewichts zwischen Directive, Grounding und Artifact.

Der Coherence Review kann drei Arten von Diskrepanz aufdecken:

Diskrepanz	Rebalance-Aktion
Artifact entspricht nicht dem Grounding	Zurück in Discourse mit klarerem Grounding
Grounding war unvollständig oder falsch	Grounding erweitern/korrigieren, dann Discourse
Directive war unrealistisch oder unklar	Directive adjustieren, ggf. neuen Circle starten

Rebalance ist keine Niederlage, sondern der normale Modus des Circle. Jeder Turn schärft das Verständnis dessen, was tatsächlich erreicht werden soll und kann.

Bounded Closure:

Nicht jeder Circle endet mit vollständiger Erfüllung der Directive. Ein Circle kann auch in Bounded Closure enden: Die Arbeit hat gezeigt, dass die Directive unter gegebenen Bedingungen nicht (vollständig) erreichbar ist. Die Bounded Closure dokumentiert, was erreicht wurde, was gelernt wurde und welche Bedingungen die vollständige Erfüllung verhindert haben.

Bounded Closure ist ein valides Ergebnis des Circle selbst — das Wissen um strukturelle Grenzen ist ein Artifact. Aber aus der Perspektive des Parent Circle ist es ein Scheitern: Das Child hat nicht geliefert, was der Parent zum Weitermachen braucht. Der Parent muss jetzt ein Rebalance durchführen — einen alternativen Weg finden, eigenes Grounding revidieren oder die eigene Directive anpassen. Das erfordert menschliches Handeln.

Kontext	Bounded Closure bedeutet
Child Circle	Directive nicht erreichbar; Grenzen dokumentiert; Circle endet sauber
Parent Circle	Erwarteter Input fehlt; Rebalance erforderlich; Mensch entscheidet über das weitere Vorgehen
Äußerster Circle	Projekt-Directive nicht erreichbar; Projekt endet

Beispiel: Eine Research-Hypothesis kann sich als nicht falsifizierbar herausstellen (fehlende Daten, strukturelle Anonymisierung). Der Child Circle erreicht Bounded Closure. Der Parent muss jetzt ein Rebalance durchführen: alternative Datenquellen suchen (Grounding revidieren), die Hypothesis einschränken (Directive anpassen) oder die Grenze akzeptieren (Bounded Closure propagiert nach oben).

Rekursion:

Circles können während des Discourse Sub-Circles hervorbringen. Dies geschieht nicht durch Vorausplanung, sondern durch Entdeckung — ein Turn deckt auf, dass ein Teilproblem eigene Directive, eigenes Grounding und eigenes Artifact braucht.

Parent Circle
│
├── Turn 1: Discourse → entdeckt Lücke
│           ↓
│     ┌─ Child Circle (eigene Directive, erbt Parent-Grounding)
│     │   ├── Turn 1 ...
│     │   └── Closure → Child-Artifact
│     └─ Child-Artifact fließt zurück als Grounding oder
│        als Teil des Parent-Artifact
│
├── Turn 2: Discourse mit neuem Grounding
│
└── Closure

Die Beziehung zwischen Parent und Child:

Child-Directive leitet sich aus einer Lücke ab, die ein Turn im Parent aufdeckt
Child-Grounding erbt vom Parent (plus eigene Spezifika)
Child-Artifact fließt bei Closure zurück in den Parent — als neues Grounding oder als Teil des Parent-Artifact
Child-Closure (oder Bounded Closure) ermöglicht dem Parent, weiterzumachen

Die Rekursionstiefe ist nicht vorhersehbar. Man weiß beim Start eines Circle nicht, wie viele Sub-Circles er hervorbringen wird. Das ist kein Planungsversagen — es ist die Natur epistemischer Arbeit in offenem Raum.

Antizipierte Circles:

Die Rekursion beschreibt emergente Sub-Circles: Ein Turn deckt eine Lücke auf, und ein Child-Circle entsteht durch Entdeckung. Aber nicht alle Sub-Circles entstehen so. Projekte haben Richtung — und aus dieser Richtung lassen sich künftige Circles voraussehen, bevor der Discourse sie hervorbringt.

Ein antizipierter Circle hat eine provisorische Directive, aber noch kein eigenes Grounding. Er ist eine Absichtserklärung: "Das wird voraussichtlich ein eigener Circle." Die provisorische Directive wird bei Aktivierung verfeinert; das Grounding entsteht erst dann.

Projekt-Circle (äußerster)
│
├── Circle 1 (abgeschlossen)
│
├── Circle 2 (aktiv — eigene Directive, eigenes Grounding)
│   ├── Turn 1 ...
│   └── Sub-Circle (emergent, entdeckt in Turn 1)
│
├── Circle 3 (antizipiert — provisorische Directive, kein Grounding)
├── Circle 4 (antizipiert — provisorische Directive, kein Grounding)
└── ...

Eigenschaft	Emergenter Sub-Circle	Antizipierter Circle
Entstehung	Entdeckt im Discourse eines Turns	Abgeleitet aus übergeordneter Vision
Directive	Spezifisch, aus konkreter Lücke	Provisorisch, wird bei Aktivierung verfeinert
Grounding	Erbt vom Parent + eigene Spezifika	Noch nicht vorhanden; entsteht bei Aktivierung
Reihenfolge	Nicht planbar	Geordnet nach aktueller Einschätzung, revidierbar

Die Reihenfolge antizipierter Circles ist selbst eine Form von Grounding — sie repräsentiert die aktuelle Einschätzung des Projektwegs. Nach jedem abgeschlossenen Circle kann diese Reihenfolge revidiert werden: Neue Erkenntnisse können Prioritäten verschieben, Circles überflüssig machen oder neue antizipierte Circles hervorbringen. Das ist Rebalance auf Projekt-Ebene.

Verhältnis zur Emergenz: Antizipierte Circles ersetzen emergente Sub-Circles nicht. Beide koexistieren. Ein aktiver Circle kann jederzeit emergente Sub-Circles hervorbringen, unabhängig davon, welche Circles antizipiert sind. Die Antizipation ist Vorverständnis (im Sinne Gadamers), nicht Festlegung — sie orientiert, bindet aber nicht.

Verhältnis zu PDCA und OODA:

Der Circle hat strukturelle Ähnlichkeit mit Plan-Do-Check-Act (Deming) und Observe-Orient-Decide-Act (Boyd). Der Unterschied ist die epistemische Rahmung:

Aspekt	PDCA	Circle
Einheit	Prozessverbesserung	Erkenntnisgewinn
Ziel	Qualitätskontrolle	Coherence zwischen Directive, Grounding, Artifact
Turn	Fehlerkorrektur	Rebalance (Grounding, Directive oder Artifact können sich ändern)
Abschluss	Standard erreicht	Coherence erreicht oder Bounded Closure
Beteiligte	Prozess-Akteure	Mensch und AI als epistemische Teilnehmer

PDCA optimiert einen bekannten Prozess. Der Circle navigiert einen offenen epistemischen Raum, in dem sich die Fragestellung selbst verändern kann (Directive-Revision). Diese Eigenschaft teilt er mit dem hermeneutischen Zirkel, von dem der Name abgeleitet ist: Vorverständnis und Gegenstand verändern sich wechselseitig.

Dauer: Ein Circle kann Minuten (kleine Directive) oder Tage/Wochen (komplexe Directive) dauern.

2.2 Session

Ein zeitlicher Rahmen, kein strukturelles Element des Circle.

Eine Session ist ein begrenzter Arbeitsabschnitt, in dem Fortschritt im Circle erzielt wird. Sessions sind durch Kontextfenster, Zeit und Aufmerksamkeit begrenzt. Sie können an jeder Stelle im Ablauf beginnen und enden — mitten im Turn, mitten im Task, sogar mitten in einem Prompt bei Abbruch oder Timeout.

Circle-Ablauf (kontinuierlich):

  ┌─ Turn 1 ───────┐ ┌─ Turn 2 ────────────────────┐ ┌─ Turn 3 ──────────┐
  │Discourse→Review│ │ Rebalance→Discourse→Review  │ │ Discourse→Review  │
  └────────────────┘ └─────────────────────────────┘ └───────────────────┘
       ┆                       ┆                              ┆
  ─────╂───────────────────────╂──────────────────────────────╂────────►
       ┆    Session 1          ┆       Session 2              ┆  S 3
       ┆                       ┆                              ┆

Session-Grenzen schneiden an beliebiger Stelle. Sie folgen nicht den Turn-Grenzen.

Session-Grenzen sind arbiträre Schnitte durch die konzeptionelle Struktur des Circle. Eine Session „enthält" keine Turns — sie überlappt mit ihnen. Ein Turn kann mehrere Sessions umfassen (Kontextfenster füllt sich mitten im Turn), und eine Session kann mehrere Turns umfassen.

Was eine Session leisten muss:

Phase	Aktivität
Start	Memory laden: aktive Directives, Grounding-Stand, Projekt-Kontext
Arbeit	Dort weitermachen, wo der Circle aufgehört hat
Ende	Memory aktualisieren: Journal-Eintrag, Grounding-Änderungen, Artifacts committen

Der zentrale Kontrakt: Jedes Session-Ende muss Memory in einem Zustand hinterlassen, von dem aus die nächste Session fortsetzen kann. Das macht arbiträre Unterbrechungen überlebbar.

Drei Funktionen:

Kontinuität — Kontext über Unterbrechungen hinweg erhalten, via Memory
Increment — Messbaren Fortschritt im Circle erzielen
Checkpoint — Dokumentierter Stand für Rückkehr

2.3 Discourse

Der kollektive epistemische Prozess zwischen Mensch und AI.

Discourse bezeichnet den intensiven Austausch, in dem Mensch und AI gemeinsam am Artifact arbeiten. Im Gegensatz zu "Work" (zu passiv) oder "Dialogue" (zu harmonisch) betont Discourse:

Kollektiver Erkenntnisprozess — Nicht Auftragsausführung, sondern gemeinsames Erarbeiten
Gegenspieler-Dynamik — AI agiert als eigenständiger Teilnehmer mit eigenen "Positionen"
Intensiver Austausch — Zahlreiche Prompt-Response-Paare
Multi-Agenten-Fähigkeit — Kann mehr als zwei Teilnehmer umfassen

┌─────────────────────────────────────────────────┐
│                   DISCOURSE                     │
│                                                 │
│    Human ◄───────► Agent 1                      │
│      │               │                          │
│      │               ▼                          │
│      └──────────► Agent 2 ◄────► Agent 3        │
│                                                 │
│    Mensch kann mit mehreren Agenten agieren.    │
│    AI kann intern weitere Agenten involvieren.  │
└─────────────────────────────────────────────────┘

Interne Struktur des Discourse:

Der Discourse hat eigene Dynamik mit:

Prompts und Responses — Das sichtbare Ping-Pong
AI-interne Loops — Agent-Ketten, Tool-Nutzung, Reasoning
Emergente Erkenntnisse — Entstehen durch den Austausch, nicht durch Einzelleistung

Events im Discourse:

Während des Discourse entstehen Situationen, die einen Übergang im Circle erfordern. Diese Events sind noch nicht formalisiert — die folgende Taxonomie ist ein Arbeitsstand:

Event	Auslöser	Reaktion
Grounding-Lücke	AI oder Mensch stellt fest, dass Grounding fehlt, das für den Fortschritt nötig ist	Discourse pausiert; Mensch klärt Grounding
Grounding-Konflikt	Neue Erkenntnis widerspricht bestehendem Grounding	Rebalance: Grounding prüfen und ggf. revidieren
Scope-Drift	Arbeit bewegt sich erkennbar von der Directive weg	Mensch entscheidet: Directive anpassen oder Arbeit zurückführen
Confidence-Erosion	AI signalisiert Unsicherheit über den eingeschlagenen Weg	Coherence Review vorziehen, bevor mehr Aufwand in fragliche Richtung fließt
Artifact-Ready	Ein Artifact-Stand ist für Review bereit	Übergang in Coherence Review

Offene Fragen zu Events:

Wie signalisiert die AI Events? (Strukturierte Outputs, Metadaten, natürlichsprachliche Marker?)
Welche Events kann die AI erkennen, welche nur der Mensch?
Kann das Tooling Events erkennen und automatisch Governance triggern? (→ Steering-Problem, Sektion 4)

Der Discourse endet (vorläufig), wenn ein Artifact-Stand für Coherence Review bereit ist.

2.4 Task

Die operative Einheit innerhalb eines Turns.

Ein Task ist eine konkrete Arbeitseinheit, die im Discourse eines Turns anfällt und innerhalb des bestehenden Groundings ausführbar ist. Tasks setzen um, was das Grounding ermöglicht — sie erzeugen keine neuen Grundlagen, sondern arbeiten auf vorhandenen.

Circle
  └── Turn
        ├── Task 1  (Grounding reicht → ausführen)
        ├── Task 2  (Grounding reicht → ausführen)
        └── Task 3  (Grounding reicht nicht → eskaliert zu Sub-Circle)

Abgrenzung Task vs. Circle:

	Task	Circle
Grounding	Vorhandenes Grounding reicht aus	Eigenes Grounding muss entwickelt werden
Directive	Keine eigene; dient der Directive des Circle	Eigene Directive
Artifact	Trägt zum Artifact des Circle bei	Eigenes Artifact, das in den Parent zurückfließt
Coherence	Kein eigener Coherence Review	Eigener Coherence Review
Dauer	Typisch innerhalb eines Turns abschließbar	Kann Turns und Sessions umfassen

Schwellenkriterium: Die Frage, die einen Task von einem Circle trennt, ist: Reicht das vorhandene Grounding, um das Ergebnis vorherzusagen und den Weg dorthin zu bestimmen? Wenn ja → Task. Wenn nein — weil etwas entdeckt, verstanden oder entschieden werden muss — eskaliert der Task zu einem Sub-Circle mit eigener Directive.

Verhältnis zu beyond-agile: Das beyond-agile-Paper argumentiert "Decisions, not tasks" — Tasks sollen nicht die primäre Fortschrittseinheit sein, weil in AI-gestützter Arbeit die Entscheidungen (= Grounding) der Engpass sind. Die Foundation übernimmt diese Position: Grounding ist primär, Tasks sind derivativ. Tasks fließen aus dem Grounding, nicht umgekehrt. Fortschritt wird an Grounding-Zuwachs und Coherence gemessen, nicht an abgehakten Tasks.

3. Die Rolle der AI

AI agiert autonom innerhalb von Grenzen, die den Menschen im Loop halten.

In beiden Ursprungspapieren (beyond-agile, hermeneutic research circle) wird die rein instrumentelle Sicht auf AI zurückgewiesen. Aktuelle AI-Agenten (z.B. Claude Code) agieren innerhalb einer Session mit genuiner Autonomie: Sie analysieren Code, wählen Tools, bauen und nutzen Hilfsmittel, treffen Implementierungsentscheidungen und strukturieren ihre Arbeit selbstständig. Ein AI-Agent handelt — und erzeugt dabei Fakten, die den Projektzustand verändern. Das ist keine Werkzeugnutzung; es ist delegierte Arbeit.

Wo AI autonom ist:

Domäne	AI handelt eigenständig
Implementation	Wählt Code-Struktur, Algorithmen, Patterns, Bibliotheken
Tool-Nutzung	Wählt, kombiniert und baut Tools nach Bedarf
Task-Ausführung	Plant und führt Schritte innerhalb eines Tasks ohne Nachfrage aus
Problemanalyse	Liest Code, identifiziert Probleme, schlägt Lösungen vor

Innerhalb dieser Domänen ist AI ein genuiner Teilnehmer — sie bringt eigenes Grounding mit (Training, Patterns, Konventionen) und trägt Urteil bei, nicht nur Arbeit.

Wo der Mensch die Kontrolle behält:

Die Grenzen sind bewusst gesetzt. Sie existieren, weil die Integrität des Circle von menschlicher Aufsicht an bestimmten Punkten abhängt:

Grenze	Begründung
Directive-Änderungen	Nur der Mensch kann den Zweck des Circle umlenken
Grounding-Revisionen	Die Basis, auf der das Artifact entsteht, zu ändern, erfordert menschliches Urteil
Coherence-Bewertung	Der Mensch trägt die Verantwortung für das finale Qualitätsurteil
Memory-Hoheit	AI schreibt nicht eigenständig in das Memory — sie schlägt vor, der Mensch entscheidet, was persistiert wird

Beratende Rolle zwischen den Grenzen:

AI kann den Circle-Verlauf aktiv beeinflussen, ohne die Grenzen zu überschreiten:

Grounding-Fragen stellen: AI erkennt fehlendes Grounding und eskaliert an den Menschen
Coherence-Bedenken äußern: AI signalisiert, wenn sie Inkonsistenzen zwischen Artifact und Grounding erkennt
Rebalance vorschlagen: AI kann argumentieren, dass eine Directive unrealistisch oder ein Grounding unvollständig ist

Konsequenzen für den Prozess:

Aspekt	Implikation
Dokumentation	AI-Beiträge müssen dokumentiert werden (wer hat was entschieden?)
Review	AI-Output erfordert Coherence Review (nicht nur "funktioniert es?")
Delegation	Explizit festlegen, welche Festlegungen AI eigenständig treffen darf
Grounding teilen	Das Grounding des Projekts muss für AI lesbar im Memory sein

Die Frage, wie AI-Impulse technisch als Events eingebettet werden können, die Governance-Prozesse auslösen, ist das Steering-Problem (Sektion 4).

4. Das Steering-Problem

Wie steuert der Mensch einen Prozess ohne strukturelle Interventionspunkte?

Das Circle-Modell (Sektion 2) setzt voraus, dass Events wie Grounding-Lücken, Confidence-Erosion und Scope-Drift (Sektion 2.3) erkannt und behandelt werden können. Die Grenzen aus Sektion 3 setzen voraus, dass der Mensch eingreifen kann, wenn Directives, Grounding oder Coherence betroffen sind. Beide Voraussetzungen erfordern etwas, das aktuelles Tooling nicht bietet: verlässliche, regelbasierte Interventionspunkte.

Die Lücke im aktuellen Tooling:

Tools wie Claude Code bieten zwei Mechanismen für Mensch-AI-Interaktion:

Mechanismus	Was er leistet	Was er nicht kann
Textuelle Antworten	AI kommuniziert in natürlicher Sprache im Gespräch	Kein strukturiertes Event-Signaling; kritische Momente sind in Prosa eingebettet
Mechanische Hooks	Shell-Befehle, die durch Tool-Aufrufe ausgelöst werden (pre/post)	Keine semantische Awareness; können weder Grounding-Lücken noch Coherence-Bedenken erkennen

Keiner dieser Mechanismen kann die Grenzen durchsetzen, die dieses Modell erfordert. Es gibt keine Möglichkeit, eine Regel wie „pausiere und eskaliere, wenn die AI eine Festlegung treffen will, die bestehendem Grounding widerspricht" zu definieren — weil aktuelles Tooling kein Konzept davon hat, was eine Festlegung ist.

Was nötig ist: ein Orchestration Layer

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   AI Agent      │────►│  Orchestration  │────►│   Human         │
│                 │     │  Layer          │     │   Interface     │
│ Emittiert       │     │                 │     │                 │
│ strukturierte   │     │ Gleicht Events  │     │ Zeigt           │
│ Events mit      │     │ gegen Regeln ab,│     │ Entscheidungs-  │
│ typisierten     │     │ setzt Grenzen   │     │ punkte an,      │
│ Metadaten       │     │ durch           │     │ genehmigt oder  │
│                 │     │                 │     │ lenkt um        │
└─────────────────┘     └─────────────────┘     └─────────────────┘

Das erfordert zwei Dinge, die noch nicht existieren:

1. Eine klare Event-Spezifikation. Die Events aus Sektion 2.3 (Grounding-Lücke, Grounding-Konflikt, Scope-Drift, Confidence-Erosion, Artifact-Ready) müssen als typisierte, maschinenlesbare Signale formalisiert werden — nicht als natürlichsprachliche Hinweise. Jedes Event braucht:

Einen Typ-Identifikator
Ein strukturiertes Payload (welches Grounding, welche Directive, welche Abweichung)
Eine Severity-/Dringlichkeitsklassifikation

2. Erweiterungen des Agent-Toolings. Der AI-Agent muss diese Events als Teil seines Outputs emittieren können, und der Orchestration Layer muss sie abfangen können, bevor die Konversation weiterläuft. Das unterscheidet sich fundamental von aktuellen Hooks (die auf Tool-Aufrufe reagieren) oder textuellen Antworten (die der Mensch manuell parsen muss).

Events, die Governance triggern:

Event	Governance-Aktion
Grounding-Lücke erkannt	Discourse pausieren; an Mensch eskalieren
Grounding-Konflikt erkannt	Discourse pausieren; Mensch gleicht Grounding-Stand ab
Confidence unter Schwellwert	Coherence Review vorziehen
Scope-Drift erkannt	Mensch entscheidet: Directive anpassen oder Arbeit zurückführen
Directive-Revision vorgeschlagen	Revalidierung bestehender Artifacts
Grounding-Änderung vorgeschlagen	Impact-Analyse auf abhängige Artifacts

Status: Dieses Problem ist die kritische Lücke zwischen dem Foundation-Modell und seiner praktischen Anwendung. Das Modell beschreibt, was geschehen soll; das Tooling unterstützt noch nicht, es geschehen zu lassen. Die Lösung erfordert Zusammenarbeit zwischen Methodik (Event-Spezifikation) und Tooling (Agent-Erweiterungen, Orchestration Layer).

5. Begriffsübersicht

Foundation-Begriff	Definition	Software	Research	Writing
Directive	Was den Circle orientiert	Goal	Hypothesis	Thesis
Grounding	Worauf die Arbeit aufbaut	Decisions	Pre-understanding	Premises
Memory	Persistierte Wissensstruktur des Projekts	(gleich)	(gleich)	(gleich)
Discourse	Kollektiver epistemischer Prozess Mensch–AI	(gleich)	(gleich)	(gleich)
Coherence	Konsistenz von Artifact, Directive, Grounding	Architectural	Epistemic	Argumentative
Rebalance	Wiederherstellung des Gleichgewichts	(gleich)	(gleich)	(gleich)
Artifact	Materialisiertes Ergebnis	Code	Knowledge	Text
Circle	Gesamtheit von Directive zu Closure	Goal-Cycle	Hermeneutic Circle	Writing Cycle
Turn	Eine Runde im Circle (Discourse → Review → Rebalance)	(gleich)	(gleich)	(gleich)
Task	Operative Einheit im Turn (Grounding reicht aus)	(gleich)	(gleich)	(gleich)
Session	Technisch-zeitlicher Arbeitsrahmen	(gleich)	(gleich)	(gleich)

6. Verhältnis zu den Ursprungspapieren

Konzept	beyond-agile (Software)	hermeneutic circle (Research)
Directive	"Goals, not stories"	"Hypotheses as organizing structure"
Grounding	"Decisions, not tasks" (Grounding ist primär)	"Vorurteilsstruktur / Pre-understanding"
Memory	"CLAUDE.md-style context files"	"Checkpoint at each level transition"
Discourse	"AI figures out steps, asks for Grounding"	"Horizontverschmelzung / fusion of horizons"
Coherence	"Architectural compliance" (alle drei Kanten)	"Epistemic integrity" (alle drei Kanten)
Circle	"Session-based work" (implizit)	"Hermeneutic circle" (explizit)
Session	"Natural rhythm of work"	"Pass through the circle"
AI-Rolle	"AI handles implementation"	"AI as first-class participant"
Steering	"Tooling gap" (Problem benannt)	"Event-based steering" (Lösung skizziert)

7. Offene Fragen

Zwei-Ebenen-Architektur: Das Research-Paper unterscheidet operativ (Forschungsausführung) und meta (Tool-Entwicklung, Prozessreflexion). Die Praxis zeigt, dass diese Unterscheidung profilübergreifend gilt: mona arbeitete gleichzeitig an Architektur und Implementation, vulkangruppe an Methodik und Forschung, mono selbst wird mit mono entwickelt. Ist "meta" ein eigenes Profil oder ein Modus, der in jedem Profil aktiviert werden kann? Die Antwort hat Konsequenzen für die mono-Architektur: Ein Profil impliziert eigene Directive/Grounding/Coherence-Spezialisierungen; ein Modus wäre ein Overlay über das aktive Profil.
Event-Formalisierung: Die Event-Taxonomie (Sektion 2.3) und das Steering-Problem (Sektion 4) benennen die relevanten Events und die Tooling-Lücke, die ihre Behandlung verhindert. Die offene Arbeit ist die Formalisierung: typisierte Event-Spezifikationen, strukturierte Payloads und der Orchestration Layer, der sie verbindet. Dies ist der kritische Pfad, um das Modell operativ zu machen.
Parallele Circles: Die Rekursion (Sektion 2.1) beschreibt Parent-Child-Beziehungen. Können Circles auch parallel laufen, ohne in Parent-Child-Beziehung zu stehen? Wie beeinflusst ein Circle das Grounding eines anderen? (Praxis: Bei vulkangruppe beeinflussten die Ergebnisse eines Stimmen-Circles die Analyse anderer Stimmen.)
Task-Koordination: Tasks sind als operative Einheit im Turn definiert (Sektion 2.4). Offen ist, wie Tasks innerhalb eines Turns koordiniert werden: Reihenfolge, Abhängigkeiten, Parallelisierung. Ist das ein Implementierungsdetail des Toolings, oder braucht die Foundation dafür konzeptionelle Vorgaben?
Multi-Agenten-Discourse: AI-Agenten spawnen bereits intern Sub-Agenten (Sektion 2.3). Die Prozess-Implikationen sind noch nicht modelliert: Wie wird Grounding zwischen Agenten geteilt? Wie funktioniert Coherence Review, wenn mehrere Agenten zum Artifact beigetragen haben? Wer koordiniert?
Session-Recovery: Sessions können an jeder Stelle abbrechen (Sektion 2.2), auch mitten im Turn oder Task. Das Modell verlangt, dass Memory die Wiederaufnahme ermöglicht, aber die Mechanik der Recovery — was wird zurückgespult, was wird wiederholt, was wird verworfen — ist noch nicht spezifiziert.
Writing-Profil: Das Profil ist konzeptionell angelegt, aber noch nicht erprobt. Spezialisierungen (Thesis/Premises/Argumentative Coherence) müssen durch praktische Erfahrung validiert werden.

Dieses Dokument ist work in progress und wird iterativ verfeinert.