# Epistemics — Limits of Drift

## 1. Die falsche Prämisse — Wann ein hoher Drift-Score besser ist als ein niedriger

Drift setzt implizit voraus: *Kohärenz ist ein Proxy für Qualität*. Die Scoring-Formel belohnt Einheitlichkeit, bestraft Varianz. Aber Kohärenz ist keine hinreichende Bedingung für Richtigkeit — und unter bestimmten Bedingungen ist sie sogar ein Feind des Fortschritts.

**Szenario 1: Architektur-Transition unter Last.**
Ein Team migriert ein Django-Monolith in eine modulare Service-Architektur. In Phase 2 von 4 existieren zwangsläufig *zwei* Error-Handling-Muster (das alte synchrone und das neue async-basierte), *zwei* Datenzugriffsmuster (ORM-direkt und Repository-Pattern), *zwei* Import-Topologien. PFS, MDS und AVS werden feuern. Der Composite Score steigt. Aber dieser hohe Score *ist* der Beweis, dass die Migration stattfindet. Ein niedriger Score in dieser Phase würde bedeuten: niemand hat angefangen. Der temporäre Kohärenzverlust ist ein notwendiges Artefakt strukturellen Lernens — das System befindet sich in einem Zwischenzustand, der nicht auf den Zielzustand zurückprojiziert werden kann. Wer jetzt den Score senkt, stoppt die Migration.

**Szenario 2: Deliberate Polymorphismus als Designentscheidung.**
Ein System wie ein Codec-Framework (vgl. httpx's `DeflateDecoder`/`GZipDecoder`) oder ein Plugin-System *muss* strukturell ähnliche, aber nicht identische Implementierungen enthalten. MDS erkennt die Duplikation korrekt — aber die Duplikation *ist* die Architektur. Das gleiche gilt für Strategy-Patterns, Visitor-Implementierungen und explizit gewollte Adapter-Hierarchien. Hier ist der hohe Score ein Zeichen, dass das System *richtig gebaut* ist: die Interface-Konformität erzeugt die strukturelle Ähnlichkeit, die Drift als Anomalie wertet. Der Score bestraft hier das Richtige.

**Das epistemische Problem:** Drift kann zwischen *ungewollter Inkohärenz* (Copy-Paste-Drift) und *gewollter Varianz* (Migration) bzw. *gewollter Ähnlichkeit* (Polymorphismus) nicht unterscheiden, weil beide AST-strukturell identisch aussehen. Der Score misst Entropie, nicht Intention. Das ist kein Bug — es ist eine Grenze des Repräsentationsmodells.

---

## 2. Der blinde Fleck — Konsistente Falschheit

Die gefährlichste Erosion tritt auf, wenn die gesamte Codebase *einheitlich* das Falsche tut. Beispiele:

- Jedes Modul validiert Permissions korrekt — aber gegen das falsche Permission-Modell (RBAC implementiert, ABAC wäre nötig).
- Alle 18 API-Endpoints verwenden dasselbe Error-Handling-Pattern — aber das Pattern schluckt kritische Fehlerklassen.
- Der Datenzugriff ist konsistent normalisiert — aber die Normalisierung erzeugt N+1-Query-Explosionen in jedem einzelnen Modul.

Das hypothetische Signal wäre ein **Semantic Misalignment Signal (SMA)**: die Divergenz zwischen *was der Code tut* und *was der Code tun sollte*, gemessen an einer externen Spezifikation oder einem formalen Invariantenmodell.

**Warum es deterministisch nicht implementierbar ist:**

Das Problem ist nicht technisch, sondern ontologisch. Um SMA zu berechnen, bräuchte Drift Zugang zu:

1. **Einer formalen Intention** — was das System tun *soll*. Diese existiert in den meisten Projekten nicht als maschinenlesbare Spezifikation. Sie existiert als implizites Wissen in Köpfen, in Slack-Konversationen, in vergessenen Design-Docs. Kein AST enthält diese Information.

2. **Einer Bewertungsfunktion für semantische Korrektheit** — die nicht *syntaktisch* (Pattern-Match) sondern *semantisch* (Bedeutungsmatch) operiert. Deterministisch geht das nur gegen eine formale Spezifikation (Design-by-Contract, Property-Based Typing, algebraische Effektsysteme). Sobald die Spezifikation informell ist, wird die Bewertung probabilistisch — und damit nicht-deterministisch.

3. **Einem Weltmodell** — um zu wissen, dass "Permission-Check gegen RBAC" falsch ist, muss man wissen, dass das System ABAC braucht. Dieses Wissen liegt außerhalb des Codes.

Ein LLM *kann* hier Heuristiken liefern ("Das sieht aus wie ein RBAC-Pattern in einem Multi-Tenant-System — ist ABAC beabsichtigt?"), aber es kann keine deterministische Aussage treffen. Die epistemische Grenze ist: **Syntax ist beobachtbar, Semantik nicht. Kohärenz ist messbar, Korrektheit nicht.** Drift operiert in der beobachtbaren Domäne und kann die nicht-beobachtbare Domäne per Definition nicht erreichen — es sei denn, es gibt eine externe Spezifikation her, gegen die deterministisch geprüft werden kann. Aber dann wäre Drift kein statischer Analyzer mehr, sondern ein formaler Verifier.

---

## 3. Das Mess-Paradoxon — Was der Django-6.0-Drop über die Natur des Scores aussagt

Die Fakten aus STUDY.md: Django hält 10 Jahre lang einen Score von 0.553–0.563 (σ=0.004). Dann fällt 6.0 auf 0.547 (Δ=-0.016) — ausgelöst durch 116 Deprecation-Removal-Commits, die Legacy-Kompatibilitätsschichten entfernen.

**Was das über die Natur des Scores aussagt:**

Der Score ist kein Qualitätsmaß — er ist ein **Entropiemaß**. Er misst die strukturelle Varianz in einer Codebase zu einem Zeitpunkt. Das hat eine wichtige Konsequenz: *Der Score kann nicht zwischen Komplexität, die gebraucht wird, und Komplexität, die weggehört, unterscheiden.* Er misst beides als dasselbe Signal. Django's Legacy-Schichten waren einmal sinnvoll (Rückwärtskompatibilität). Dass der Score sinkt, wenn sie entfernt werden, zeigt: der Score belohnt Reduktion, nicht Richtigkeit. Er wäre auch gesunken, wenn man *produktive* Code-Teile gelöscht hätte.

**Der perverse Anreiz in KI-gestützten Teams:**

Wenn ein Team auf den Drift-Score als KPI optimiert, entsteht folgendes Goodhart-Szenario:

1. **Deletion-Bias:** Der schnellste Weg, den Score zu senken, ist Code löschen. Ein KI-Agent, der Drift-Scores optimiert, wird Module mit hohem Fragmentierungs-Score bevorzugt eliminieren — nicht refactoren, sondern entfernen. Das senkt PFS, MDS und potentially EDS gleichzeitig. Die Frage "Brauchen wir das?" wird ersetzt durch "Senkt das den Score?".

2. **Uniformity-Bias:** Anstatt das richtige Pattern für einen neuen Use-Case zu wählen, wird das *häufigste* bestehende Pattern kopiert — weil es die Fragmentierung nicht erhöht. Das erzeugt eine Monokultur, die gegen PFS optimiert ist, aber gegen Wandlungsfähigkeit.

3. **Refactoring-Vermeidung:** Tiefe Refactorings (z.B. ein Error-Handling-Pattern zu vereinheitlichen) erzeugen *während* des Refactorings einen Score-Anstieg (zwei Patterns koexistieren). In einem Team, das den Score täglich trackt, wird das Refactoring abgebrochen, bevor es abgeschlossen ist — weil es kurzfristig "schlimmer" aussieht.

4. **Sophistication Ceiling:** Komplexe, aber korrekte Architekturen (Event-Sourcing, CQRS, Port/Adapter) erzeugen *mehr* Signale als einfache MVC-Strukturen — mehr Module, mehr Import-Kanten, mehr Pattern-Varianz zwischen Command- und Query-Seite. Das Team wird sich für die einfachere Architektur entscheiden, nicht weil sie besser ist, sondern weil sie leiser ist.

**Die Konsequenz:** Der Score ist nur als **Delta über Zeit** interpretierbar (wie STUDY.md selbst sagt), aber das Team muss die *Richtung* des Delta qualitativ bewerten können. Ein Score-Anstieg während eines bewussten Refactorings ist ein anderes Signal als ein Score-Anstieg durch achtloses Copy-Paste. Drift liefert das Thermometer — aber es kann nicht sagen, ob Fieber eine Krankheit oder eine Immunreaktion ist.

---

## 4. Die Grenze des Deterministischen — Wo das Prinzip aufhört, ein Vorteil zu sein

Das Determinismus-Prinzip (ADR-001) ist die epistemische Kernentscheidung von Drift: gleicher Input → gleiches Ergebnis. Das garantiert Reproduzierbarkeit, Auditierbarkeit, CI-Fähigkeit. Es ist ein *enormer* Vorteil — bis zu folgendem Punkt:

**Die exakte Grenze liegt dort, wo die Drift-Klasse nicht mehr strukturell, sondern semantisch ist.**

Drift kann derzeit erkennen:
- Syntaktische Drift (PFS, MDS) — Pattern haben sich vervielfacht ✓
- Topologische Drift (AVS, SMS) — Import-Graph hat sich deformiert ✓
- Temporale Drift (TVS) — Churn-Profil hat sich verändert ✓
- Dokumentations-Drift (DIA) — Code und Docs divergieren ✓

Was Drift *prinzipiell nicht sehen kann* mit rein deterministischer Analyse:

1. **Idiomatic Drift** — Code, der syntaktisch korrekt aber idiomatisch fremd ist. Ein KI-generiertes Python-Modul, das Java-Patterns verwendet (Getter/Setter statt Properties, Abstract-Factory statt Module-Level-Functions), ist AST-valide und import-valide. Es erzeugt keine Fragmentierung (es ist in sich konsistent). Aber es ist *fremd* im Kontext der umgebenden Codebase. Um das zu erkennen, bräuchte man ein *statistisches Modell der Codebase-Idiome* — das ist deterministisch berechenbar (Frequenzverteilung von AST-Patterns), aber Drift tut es nicht, weil es ein trainiertes Baseline-Modell erfordern würde.

2. **Intention Drift** — Der Punkt aus Frage 2. Deterministisch nicht zugänglich.

3. **Emergent Coupling** — Zwei Module, die nie imports teilen, aber immer zusammen geändert werden (hidden logical coupling). TVS sieht den Churn, aber nicht die *Ko-Änderung*. Um das deterministisch zu erkennen, bräuchte man eine Ko-Änderungs-Matrix aus dem Git-Log — das *ist* deterministisch und implementierbar (und STUDY.md §12.6 zeigt, dass "Hidden Coupling" als AVS-Pattern bereits existiert). Aber die Erkennung, *warum* die Kopplung besteht und ob sie problematisch ist, erfordert semantisches Verständnis.

   > **Update (v0.8.0):** Das CCC-Signal (Co-Change Coupling) implementiert genau diese Ko-Änderungs-Matrix und erkennt Module, die trotz fehlender Import-Beziehung statistisch signifikant gemeinsam geändert werden. Die hier genannte semantische Grenze bleibt bestehen — CCC erkennt *dass* Kopplung existiert, nicht *warum*.

4. **API-Kontrakt-Drift** — Ein Modul exportiert weiterhin dieselbe Funktion, aber deren *Verhalten* hat sich geändert (schleichend, über viele Commits). Semantic Versioning *sollte* das markieren, tut es aber in der Praxis nicht. Deterministisch erkennbar wäre nur die Signaturänderung — nicht die Verhaltensänderung.

**Der exakte Kipppunkt:** Das Determinismus-Prinzip hört auf, ein Vorteil zu sein, sobald die *relevanteste* Drift-Klasse in einer Codebase nicht mehr strukturell, sondern semantisch ist. In einer Codebase, die überwiegend von KI geschrieben wird, ist strukturelle Kohärenz *leicht herzustellen* — Copilot kann konsistente Patterns produzieren, wenn man es richtig promptet. Die Drift, die dann entsteht, ist nicht: "der Code sieht anders aus". Sondern: "der Code sieht gleich aus, aber tut subtil verschiedene Dinge". Genau diese Klasse ist deterministisch unsichtbar.

Je besser die KI wird, desto weniger syntaktische Drift erzeugt sie — und desto mehr semantische. Drift's Determinismus-Prinzip schützt es vor den Problemen nicht-reproduzierbarer Analyse, aber es macht es blind für genau die Erosionsklasse, die in einer KI-dominierten Zukunft dominieren wird.

---

## 5. Die systemische Empfehlung — Welche Annahme aufbrechen?

Nicht: ein neues Signal. Sondern: eine neue Prämisse.

**Die Annahme, die aufgebrochen werden muss:**

> *Drift misst den Zustand einer Codebase.*

Das ist die zentrale, nicht hinterfragte Prämisse. Alle sieben Signale messen einen *Snapshot*: wie viele Patterns gibt es jetzt? Wie sieht der Import-Graph jetzt aus? Wie hoch ist die Komplexität jetzt? Selbst TVS, das sich temporal gibt, misst letztlich den *aktuellen Churn* — nicht die *Entwicklungstrajektorie* des Systems.

**Was sich ändern müsste:**

Drift müsste aufhören, *Zustände* zu messen, und anfangen, *Prozesse* zu messen. Die relevante Frage in einer Welt mit 80% KI-Code ist nicht: "Wie kohärent ist die Codebase?" — denn die KI kann Kohärenz billiger herstellen als jeder Mensch. Die relevante Frage ist:

**"Versteht irgendein Akteur (Mensch oder Maschine) noch, warum die Codebase so ist, wie sie ist?"**

Das ist eine Frage über *epistemische Integrität*, nicht über strukturelle Kohärenz. Konzeptuell müsste Drift sich von einem **Kohärenzmesser** zu einem **Verständlichkeitsradar** wandeln. Konkret:

1. **Von Pattern-Zählung zu Entscheidungs-Archäologie.** Statt zu zählen, wie viele Error-Handling-Varianten existieren, fragen: Gibt es in der Historie eine *nachvollziehbare Entscheidung*, warum sich das Pattern an welcher Stelle geändert hat? Wenn 80% der Commits KI-generiert sind und keine Commit-Message erklärt, warum Pattern B statt Pattern A gewählt wurde, dann existiert eine *Wissenslücke* — unabhängig davon, ob der Code kohärent ist.

2. **Von Struktur zu Delta-Lesbarkeit.** Der Composite Score sollte nicht messen, wie „aufgeräumt" der Code ist, sondern wie *vorhersagbar* die nächste Änderung für einen neuen Entwickler wäre. Die Frage verschiebt sich von "Ist es konsistent?" zu "Kann jemand, der das System nicht gebaut hat, die nächste richtige Änderung ableiten?" Das ist der eigentliche Erosionsindikator — und er ist in einer KI-dominierten Welt *der einzige, der zählt*, weil die KI selbst jedes Pattern erzeugen kann, aber nicht entscheiden kann, welches in diesem Kontext das richtige wäre.

3. **Von Single-Codebase zu Codebase-als-Konversation.** Wenn 80% des Codes KI-generiert ist, ist die Codebase nicht mehr ein Artefakt menschlicher Entscheidungen, sondern ein *Transkript eines Dialogs* zwischen Mensch und Maschine. Die Erosion liegt dann nicht im Code, sondern im *Verlust des Dialogs* — wenn Prompts verloren gehen, wenn Kontext nicht übertragen wird, wenn das Warum verschwindet. Drift müsste diesen Dialog als Analyseeinheit behandeln, nicht nur den resultierenden Code.

**Die fundamentale Verschiebung:** Von **"Wie sieht der Code aus?"** zu **"Weiß jemand, warum der Code so aussieht?"** — und wenn die Antwort nein ist, das als die eigentliche Erosion benennen. Nicht die syntaktische Varianz ist das Problem der Zukunft. Sondern die *epistemische Leere*, die entsteht, wenn Code schneller erzeugt als verstanden wird.

---

## 6. Taxonomie der gewollten Inkohärenz

**Status:** `[PLANNED]` — Community-Studie S8

EPISTEMICS.md §1 stellt fest: Kohärenz ist nicht identisch mit Qualität. Ein hoher PFS-Score kann *gewollte Varianz* messen — bewussten Polymorphismus, Interface-Segregation, Framework-erzwungene Pattern-Unterschiede.

**Die offene Frage:** Wie groß ist der Anteil architekturisch *gewollter* Varianz an den PFS-Findings in aktiv gewarteten Repos? Und lassen sich aus der Antwort Suppressions-Regeln ableiten, die False Positives reduzieren, ohne reale Inkohärenz zu verbergen?

**Vier Kategorien stehen zur Erprobung:**

- **A — Ungewollte Inkohärenz:** Pattern-Fragmentierung ohne architektonische Begründung.
- **B — Gewollte Varianz:** Bewusster Polymorphismus, Interface-Segregation, Adapter/Strategy-Pattern.
- **C — Migrations-Transit:** Altes und neues Pattern koexistieren während eines geplanten Übergangs.
- **D — Framework-erzwungene Varianz:** Verschiedene Patterns sind Framework-bedingt nötig (z.B. Class-based vs. Function-based Views in Django).

**Methodik:** Cross-Repo-Rating — jeder Rater klassifiziert PFS-Findings aus einem *fremden* Repo, um Rationalisierungs-Bias zu vermeiden. Inter-Rater-Agreement via Cohen's κ, Dissens-Auflösung durch dritten Rater.

**Erwarteter Erkenntnisbeitrag:** Wenn Kategorie B+C+D zusammen ≥20% der Findings ausmachen, sind Suppressions-Heuristiken notwendig. Wenn <10%, ist das PFS-Signal robuster als in §1 befürchtet.

Auswertungs-Script: `scripts/study_rater_agreement.py`. Quantitative Ergebnisse in [STUDY.md §16](STUDY.md).

**Ergebnisse:** *Ausstehend — Community-Beiträge werden gesammelt.*

---

## 7. Dokumentation als Frühindikator für Wartungsschuld

**Status:** `[PLANNED]` — Community-Studie S6

Die These: Day-2-Vernachlässigung manifestiert sich zuerst in der Dokumentation. Wenn ein Team aufhört, Docs zu pflegen, ist das ein Frühindikator dafür, dass auch der Code bald erodiert — eine *dokumentarische Drift*, die der Code-Drift vorausgeht.

**Die offene Frage:** Korreliert das DIA-Signal (Documentation-Implementation Asymmetry) stärker mit der Zeit seit dem letzten Dokumentations-Commit als mit der absoluten Codebasis-Größe?

Falls ja: DIA misst nicht Umfang, sondern *Aufmerksamkeit*. Das wäre eine epistemisch bedeutsame Unterscheidung — der Score wäre dann nicht nur ein Entropie-Maß (vgl. §3), sondern ein Proxy für die kognitive Bindung des Teams an die eigene Codebase.

Falls nein: DIA korreliert primär mit LOC, und der scheinbare Maintenance-Effekt ist ein Größen-Artefakt. Das würde das Signal nicht entwerten, aber seine Interpretation grundlegend verändern.

**Erwarteter Erkenntnisbeitrag:** Klärung der Frage, ob das DIA-Signal Erosion oder Komplexität misst — eine der offenen Fragen aus der Django-Studie (§3).

Quantitative Ergebnisse in [STUDY.md §16.3](STUDY.md). Statistische Auswertung via Steiger's Z-Test für abhängige Korrelationskoeffizienten.

**Ergebnisse:** *Ausstehend — Community-Beiträge werden gesammelt.*
