internes Konzept - Abbildungen hinzugefügt, Abschnitt über Zusammenwirkung der einzelnen Komponenten mit beispielhaften Prozessen

01_Konzeption/02-1 Sovereign RAG Tutor – Internes Konzeptdokument.md

@@ -1,6 +1,6 @@
 # Sovereign RAG Tutor – Internes Konzeptdokument
 
-**Status:** Entwurf v0.2 · **Stand:** Juli 2026 · **Vertraulichkeit:** intern **Führendes Dokument** – das Kundendokument wird als gefilterte Teilmenge hieraus abgeleitet.
+**Status:** Entwurf v0.3 · **Stand:** Juli 2026 · **Vertraulichkeit:** intern **Führendes Dokument** – das Kundendokument wird als gefilterte Teilmenge hieraus abgeleitet.
 
 ---
 
@@ -112,6 +112,15 @@ Die Zerlegung in sechs Komponenten entlang der klassischen ITS-Architektur (Doma
 
 Das Lösungskonzept ordnet die Funktionalität in vier aufeinander aufbauende Stufen. Drei Eigenschaften machen dieses Modell tragfähig: Komplexität und Risiko steigen monoton – die frühen Stufen sind mit der vorhandenen Teamkompetenz sofort machbar, die schwierigen Teile kommen, wenn das Fundament trägt. Jede Stufe ist eigenständig produktiv nutzbar und verkaufbar und erfüllt bereits Kernanforderungen. Und jede Stufe erzeugt Daten und Erkenntnisse für die nächste – die Suchlogs aus Stufe 1 zeigen, was Nutzer tatsächlich fragen, was die Graph-Modellierung in Stufe 3 informiert.
 
+```mermaid
+flowchart TD
+    S1["Stufe 1: Souveräne Suche<br/>Hybrides Retrieval, Berechtigungsfilter, Quellen,<br/>Video-Pipeline (parallel), Evaluationsframework"]
+    S2["Stufe 2: Nachschlage-Assistent<br/>Souveränes LLM, Grounded Q&A, Timestamps<br/>+ vorgezogen: Graph-Pilot, juristische Begleitung"]
+    S3["Stufe 3: Kompetenzmodell und Tracking<br/>Wissensgraph, Redaktionsworkflow,<br/>regelbasiertes Tracking, Regulatorik-Paket"]
+    S4["Stufe 4: Adaptive Didaktik<br/>Fragengenerierung → Lernpfade → Coaching"]
+    S1 --> S2 --> S3 --> S4
+```
+
 #### Stufe 1: Souveräne Suche
 
 Das produktionsreife Modul aus dem vorhandenen PoC: hybrides Retrieval (BM25 + Embedding-Modelle, Score-Fusion z. B. über Reciprocal Rank Fusion), Cross-Encoder-Reranking als Präzisionsstufe, Berechtigungsfilterung als Kernfeature von Anfang an – jedes Suchergebnis wird vor Anzeige gegen die Nutzerrolle geprüft. Ergebnisdarstellung mit Quellenangabe und direktem Absprung ins Dokument. Bestandteil der Stufe ist das Evaluationsframework (Goldstandard-Testset, nDCG/MRR, Latenzmessung), denn das Vertrauensziel ist ohne Messung nicht erreichbar; dasselbe Framework wird später zum Update-Gate (5.5).
@@ -179,12 +188,42 @@ Der Wissensgraph besteht aus zwei Bausteinen. **Knoten** sind Kompetenzen bzw. W
 
 **Kanten** sind typisierte Beziehungen. Im Sinne der Pragmatik-Anforderung sind genau drei Typen vorgesehen, die alle Szenarien des Brainstormings tragen: _setzt-voraus_ (Kompetenz → Kompetenz; treibt Backlinks, Feedforwards und Lernpfad-Sequenzierung), _wird-vermittelt-durch_ (Kompetenz → Materialabschnitt: Video-Segment, HTML-Kapitel) und _wird-geprüft-durch_ (Kompetenz → Quizfrage; die Kante, über die das Tracking weiß, welche falsche Antwort welche Kompetenz betrifft). Weitere Beziehungstypen (z. B. Ähnlichkeit) sind bewusst zurückgestellt.
 
+Zur Veranschaulichung ein Miniaturbeispiel (Domäne Druckprüfung) mit allen drei Kantentypen:
+
+```mermaid
+flowchart TD
+    H[Hydraulik-Grundlagen]
+    M[Messtechnik]
+    D[Druckmessung durchführen]
+    F[Fehlerdiagnose Druckabfall]
+    MAT1[/"Video H-03, Segment 02:10–04:35"/]
+    Q1[/"Quizfragen 12–15"/]
+
+    H -->|setzt-voraus| D
+    M -->|setzt-voraus| D
+    D -->|setzt-voraus| F
+    MAT1 -.wird-vermittelt-durch.-> D
+    Q1 -.wird-geprüft-durch.-> D
+```
+
 Die Speicherung ist unkritisch (Graphdatenbank oder relational); das Neue ist nicht die Haltung der Daten, sondern ihre Erstellung.
 
 #### 5.3.2 Der teilautomatisierte Workflow
 
 Kerngedanke: Das LLM verwandelt Erstellungsarbeit in Prüfarbeit. Der Mensch erschafft den Graphen nicht, er begutachtet Vorschläge. Die Pipeline umfasst fünf Schritte:
 
+```mermaid
+flowchart TD
+    MAT[Materialbestand im Knowledge Vault]
+    EX["(1) LLM-Extraktion<br/>Kandidaten mit Belegpflicht"]
+    KON["(2) Konsolidierung<br/>Dubletten, Terminologie"]
+    REV["(3) Fachliche Prüfung durch Experten<br/>annehmen / bearbeiten / ablehnen"]
+    FREI["(4) Freigabe<br/>versionierter Graph aktiv"]
+    MAT --> EX --> KON --> REV --> FREI
+    FREI -. "(5) Materialänderung: Differenzvorschlag" .-> EX
+    style REV stroke-width:3px
+```
+
 **1. Extraktion mit Belegpflicht.** Das souveräne LLM aus Stufe 2 (keine neue Infrastruktur) analysiert die Materialien und schlägt Kompetenz-Kandidaten samt Beziehungen vor. Designregel: Jeder Vorschlag muss mit einem Textbeleg verankert sein – der konkreten Stelle im Dokument oder Transkript, aus der er stammt. Vorschläge ohne Beleg werden verworfen, bevor ein Mensch sie sieht. Das unterdrückt Halluzinationen strukturell (das Modell kann keine Kompetenz erfinden, die nirgends im Material steht) und beschleunigt die Prüfung (der Experte liest den Beleg neben dem Vorschlag, statt selbst zu suchen). Es ist dasselbe Grounding-Prinzip wie beim Nachschlage-Assistenten, nach innen gewendet.
 
 **2. Konsolidierung.** Dasselbe Konzept erscheint über Dokumente hinweg unter verschiedenen Namen ("Manometer ablesen" / "Druckanzeige prüfen"). Über Embedding-Ähnlichkeit (Stufe-1-Kompetenz) werden Kandidaten geclustert und Zusammenführungen vorgeschlagen. Ohne diesen Schritt erstickt der Graph an Dubletten und das Tracking führt dieselbe Kompetenz mehrfach.
@@ -312,35 +351,74 @@ Dieser Abschnitt löst Lücke L3. Leitprinzip: Jede Stufe hat eigene, zu ihr pas
 
 Kapitel 5 beantwortet "was bauen wir wann"; dieses Kapitel beantwortet "woraus besteht das System". Aus dieser Sicht werden später die Pflichtenhefte je Subsystem geschnitten. Die sechs Komponenten des Ursprungsentwurfs werden übernommen und um zwei ergänzt, die sich aus der Lückenanalyse ergeben. Englische Eigennamen werden beibehalten (Begründung im Entscheidungsregister E15); der Fließtext bleibt deutsch.
 
-### 6.1 Sovereign Knowledge Vault (Wissensablage und -vernetzung)
+### 6.1 Zusammenwirken der Komponenten
+
+Die folgende Übersicht zeigt die Komponenten und ihre wesentlichen Datenflüsse; die Schnittstellen werden anschließend an drei repräsentativen Abläufen konkretisiert, die zusammen nahezu alle Kanten abdecken.
+
+```mermaid
+flowchart LR
+    UI[Adaptive Interface]
+    CRM[Context & Role Manager]
+    ORC[Pedagogical Orchestrator]
+    VAULT[Sovereign Knowledge Vault]
+    CORE[Sovereign Reasoning Core]
+    CLE[Cognitive Learner Engine]
+    WB[Curation & Review Workbench]
+    EVAL[Evaluation & Telemetry Framework]
+    LMS[(LMS / mastersolution ONE)]
+
+    UI --> CRM
+    CRM --> LMS
+    UI --> ORC
+    ORC --> CLE
+    ORC --> VAULT
+    VAULT --> CORE
+    CORE --> UI
+    CLE --> LMS
+    CORE -.Graph-Vorschläge.-> WB
+    WB -.Freigabe.-> VAULT
+    EVAL -.misst querschneidend.-> VAULT
+    EVAL -.-> CORE
+    EVAL -.-> CLE
+```
+
+**Ablauf A – Nachschlage-Anfrage (ab Stufe 2):** Der Nutzer stellt im Adaptive Interface eine freie Frage. Der Context & Role Manager identifiziert ihn gegen das LMS und liefert Rolle, Berechtigungen und – im Kurskontext – Modus-Policy und Bestehensstatus. Die Anfrage geht mit diesen Filterkriterien an den Knowledge Vault (hybrides Retrieval, Reranking; Inhaltsklassifikation und Berechtigungen wirken hier als harte Filter). Die Fundstellen gehen an den Reasoning Core, der eine grounded Antwort mit Quellenangaben und Video-Timestamps synthetisiert oder eine explizite Fehlanzeige zurückgibt. Das Interface stellt die Antwort mit Modus-Kennzeichnung dar. In Stufe 1 endet derselbe Ablauf vor dem Reasoning Core: Das Interface zeigt die gefilterten Fundstellen direkt. Das Evaluation Framework protokolliert Metriken (Latenz, Null-Treffer, Feedback) ohne Personenbezug.
+
+**Ablauf B – gecoachte Frage im Kurs (Stufe 4):** Gleiche Identifikation über den Context & Role Manager; die Policy ergibt Coaching-Modus. Die Anfrage geht nun nicht direkt ins Retrieval, sondern an den Pedagogical Orchestrator. Dieser holt von der Cognitive Learner Engine den Kompetenzstand, führt gegen die Graph-Schicht des Vault die Gap-Analyse durch und entscheidet die didaktische Reaktion (direkter Hinweis, Backlink, sokratische Gegenfrage). Erst dann instruiert er den Reasoning Core mit didaktischem Prompt und abgerufenen Fakten. Antwortet der Nutzer auf eine Quizfrage, meldet das Interface das Lernereignis über den Context & Role Manager an die Learner Engine, die den Kompetenzstand aktualisiert und ggf. eine Empfehlung samt gespeicherter Begründung (Regel + Datengrundlage) erzeugt.
+
+**Ablauf C – Redaktion und Hintergrundprozesse (Batch, ab Stufe 2/3):** Neues oder geändertes Material durchläuft die Ingestion des Vault (Chunking, Transkription, Embedding). Der Reasoning Core extrahiert im Batch-Betrieb Graph-Kandidaten mit Belegen; die Workbench legt sie dem Fachexperten priorisiert vor. Freigegebene Änderungen gehen als neue Graph-Version in den Vault. Modell-Updates laufen über das Evaluation Framework als Gate: Erst nach regressionsfreiem Lauf gegen das Mandanten-Goldstandard-Testset wird umgeschaltet. Sämtliche Batch-Lasten sind vom interaktiven Pfad (Abläufe A/B) getrennt.
+
+Zwei Strukturprinzipien werden an den Abläufen sichtbar: Der Orchestrator liegt nur im Kurs-/Coaching-Pfad – der Nachschlage-Pfad umgeht ihn bewusst, was die Latenz niedrig und die Stufen 1–2 unabhängig von Stufe-3/4-Komponenten hält. Und der Context & Role Manager ist der einzige Berührungspunkt zum LMS – alle anderen Komponenten kennen weder Identitäten noch Berechtigungsquellen, was die Moodle-Integrationsfrage (O1) auf eine Komponente isoliert.
+
+### 6.2 Sovereign Knowledge Vault (Wissensablage und -vernetzung)
 
 **Zweck:** Ingestion, Indizierung und logische Vernetzung aller Kursmaterialien. **Stufen:** 1 (Vektor-Index + BM25, Text-Ingestion, Video-Pipeline mit zeitgestempelten Transkript-Segmenten, Inhaltsklassifikation "nur im Kurskontext"), 2 (Einbettung der Timestamps in Antworten, optional Keyframe-Analyse), 3 (Graph-Schicht mit den drei Kantentypen). **Änderungen gegenüber Ursprungsentwurf:** Die Graph-Schicht ist nachgelagert statt konstitutiv; die Vault startet als reines Retrieval-System. Die Inhaltsklassifikation ist neu (Leakage-Pfad, 5.2). **Spezifikationshinweise:** Chunking-Strategie pro Materialtyp definieren (HTML-Abschnitte, Transkript-Segmente, Quizfragen als eigene Einheiten). Berechtigungs- und Klassifikationsattribute gehören an jede Index-Einheit, nicht an Dokumente als Ganzes – sonst sind abschnittsgenaue Filterung und Kurskontext-Sperren nicht umsetzbar. Index-Neubau als unterbrechungsfreier Parallelprozess (Update-Gate, 5.5.3). Fachvokabular-Verwaltung pro Mandant für die ASR-Korrektur.
 
-### 6.2 Context & Role Manager (Identität, Berechtigungen, Aktionen)
+### 6.3 Context & Role Manager (Identität, Berechtigungen, Aktionen)
 
 **Zweck:** Identifikation des Nutzers, Verifikation von Rolle und Berechtigungen in Echtzeit, Anwendung als zwingende Filterkriterien auf alle Abfragen; ab Stufe 4 Auslösen autorisierter Aktionen im LMS (z. B. Einschreibung in generierte Lernpfade). **Stufen:** 1 (lesender Berechtigungsfilter), 3 (Zugriff auf explizite Lernereignisse aus dem LMS), 4 (Aktionen). **Änderungen:** Telemetrie-Umfang drastisch reduziert (P3): nur explizite Lernereignisse, keine Verhaltensdaten. **Spezifikationshinweise:** Anbindung an mastersolution ONE (Moodle) klären – hängt an der offenen Moodle-Integrationsfrage (O1). Statusabfrage "Kurs bestanden" für die Modus-Policy (5.2) gehört hierher. Rollenmodell muss die Autoren-Rolle (Workbench, Policies) und die Fachexperten-Rolle (Graph-Review) umfassen, nicht nur Lernende und Vorgesetzte.
 
-### 6.3 Sovereign Reasoning Core (Sprachmodell)
+### 6.4 Sovereign Reasoning Core (Sprachmodell)
 
 **Zweck:** Lokal oder in isolierter, zertifizierter Umgebung gehostetes LLM; synthetisiert Antworten streng auf Basis bereitgestellter Fakten (Grounded Generation); ab Stufe 3 zusätzlich Extraktionsaufgaben (Graph-Kandidaten mit Belegpflicht), ab Stufe 4 didaktisch instruierte Generierung (sokratische Prompts, Fragengenerierung). **Stufen:** 2 (Q&A), 3 (Extraktion), 4 (Didaktik). **Änderungen:** Explizite Festlegung: kein Training/Feintuning auf Mandantendaten (5.5.1). Abstinenz-Verhalten ("keine Antwort im Material") ist Pflichtverhalten und wird getestet (5.6). **Spezifikationshinweise:** Modellauswahl und Quantisierungsstrategie in Stufe-2-Erprobung; Ergebnis sind die Sizing-Profile (O2). Prompt-Templates versionieren – sie sind Verhaltensbestandteil und gehören unter das Update-Gate wie Modellgewichte. Trennung interaktiver Inferenz von Batch-Extraktion (5.5.4).
 
-### 6.4 Cognitive Learner Engine (Lernstandsmodell)
+### 6.5 Cognitive Learner Engine (Lernstandsmodell)
 
 **Zweck:** Führt den Kompetenzstand pro Nutzer auf Basis expliziter Lernereignisse; wertet Regeln aus, die Empfehlungen begründen. **Stufen:** 3 (regelbasiert), 4 (optional BKT). **Änderungen:** Grundlegende Neuausrichtung gegenüber dem Ursprungsentwurf: regelbasiert statt DKT (P2, K4); Eingangsdaten minimiert (P3); jede Empfehlung speichert Regel und Datengrundlage (Begründungskonzept). **Spezifikationshinweise:** Regelwerk als konfigurierbare Vorlagen ausliefern (Betreibermodell: Regelvorlagen sind produktseitig, Parametrisierung mandantenspezifisch). Validitätsmessung (Vorhersage vs. Prüfungsergebnis, aggregiert) von Beginn an einbauen. BKT-Erweiterung so vorsehen, dass sie dieselbe Begründungsschnittstelle bedient ("Mastery-Wahrscheinlichkeit 0,4, weil …") – sonst bricht die Nachvollziehbarkeit beim Ausbau.
 
-### 6.5 Pedagogical Orchestrator (didaktische Steuerung)
+### 6.6 Pedagogical Orchestrator (didaktische Steuerung)
 
 **Zweck:** Entscheidet auf Basis von Lernstand, Graph und Policy, wie das System reagiert: direkte Antwort, Backlink, Feedforward, sokratische Gegenfrage, Lernpfad-Vorschlag. **Stufen:** 3 (Regeln für Backlinks/Feedforwards), 4 (Lernpfadgenerierung, Sokratik, Modus-Policies). **Änderungen:** Kein Reinforcement Learning (K1, P2); regelbasierte Entscheidungslogik. Die Modus-Policy-Hierarchie (5.2) liegt hier. Sokratik ist auf den Coaching-Modus beschränkt statt systemweit erzwungen (K3). **Spezifikationshinweise:** Gap-Analyse (nötige Voraussetzungen laut Graph vs. Lernermodell) als eigenständiger, testbarer Baustein. Lernpfadgenerierung muss Berechtigungen filternd berücksichtigen und darf Freigabeprozesse nur anstoßen, nie selbst entscheiden (P1). Formulierungs-Templates für Backlinks/Feedforwards mit dem Kunden abstimmen – Tonalität ist Produktentscheidung.
 
-### 6.6 Adaptive Interface (Nutzerschnittstelle)
+### 6.7 Adaptive Interface (Nutzerschnittstelle)
 
 **Zweck:** Sucheingabe und -ergebnisse, Chat mit Quellen und Video-Timestamps, Modus-Anzeige und -Schalter, Fortschritts- und Begründungsanzeige, eingebettete Quiz-Snippets. **Stufen:** 1 (Suche), 2 (Chat), 3 (Fortschritt, Begründungen), 4 (Coaching-Dialog, Modus-Schalter). **Änderungen:** Modus-Transparenz als Pflichtmerkmal (5.2); Antwortformat ab Stufe 2 vorbereitet für zweiten Antwortstil. **Spezifikationshinweise:** Absprung in Materialien (Dokumentabschnitt, Video-Timestamp) ist Kernfunktion, kein Nice-to-have – sie trägt die Nachvollziehbarkeit. Begründungsanzeige für Empfehlungen ("weil …") gehört in die Standardansicht, nicht in ein Detail-Popup. Barrierefreiheit früh einplanen (Kundenprodukt didab zeigt die Relevanz der Zielgruppe im Portfolio).
 
-### 6.7 Curation & Review Workbench (neu: Redaktionswerkzeug)
+### 6.8 Curation & Review Workbench (neu: Redaktionswerkzeug)
 
 **Zweck:** Arbeitsumgebung für Fachexperten des Endkunden: Prüfung der Graph-Vorschläge (annehmen/bearbeiten/ablehnen mit Beleganzeige), Priorisierung nach Konfidenz und Wirkung, Strukturprüfungs-Hinweise, Differenzvorschläge bei Materialänderungen, Versionierung und Freigabe; in Stufe 4 zusätzlich Review generierter Prüfungsfragen. **Stufen:** 2 (Pilot), 3 (produktiv), 4 (Fragen-Review). **Begründung als eigene Komponente:** Ergebnis von L1. Die Workbench ist Produktbestandteil mit Benutzbarkeitsanspruch für Nicht-Techniker – kein internes Hilfsskript. Sie ist der Ort, an dem die menschliche Aufsicht (P1, 5.3.3) konkret stattfindet, und erzeugt nebenbei die Governance-Protokolle. **Spezifikationshinweise:** Die Prüfeffizienz entscheidet über die Akzeptanz des gesamten Graph-Ansatzes; UX-Aufwand hier nicht unterschätzen. Batch-Aktionen (mehrere Vorschläge eines Clusters gemeinsam behandeln) von Beginn an. Vier-Augen-Freigabe als konfigurierbare Option für regulierte Endkunden.
 
-### 6.8 Evaluation & Telemetry Framework (neu: Qualitätssicherung)
+### 6.9 Evaluation & Telemetry Framework (neu: Qualitätssicherung)
 
 **Zweck:** Goldstandard-Verwaltung je Mandant, Metrik-Berechnung (5.6), Update-Gate-Ausführung (5.5.3), Abstinenz- und Groundedness-Testsets, aggregierte Wirkungsmetriken ohne Personenbezug, Opt-in-Exportpakete. **Stufen:** 1 (Retrieval-Metriken, Gate), 2 (Groundedness, Abstinenz), 3 (Tracking-Validität), 4 (Wirkungsmetriken gegen Baseline). **Begründung als eigene Komponente:** Ergebnis von L3 und tragende Säule des Betreibermodells – ohne dieses Framework gibt es weder das Vertrauensziel noch sichere Updates noch den Nutzennachweis. Es querschneidet alle anderen Komponenten und verdient deshalb ein eigenes Pflichtenheft. **Spezifikationshinweise:** Muss offline lauffähig sein (Offline-Update-Pakete). Die Aggregations-Leitplanke technisch erzwingen: Auswertungsschicht ohne Personenbezüge für Wirkungsmetriken. Baseline-Erhebung als geführter Einführungsprozess, nicht als Freitext-Fragebogen.
 
@@ -362,7 +440,7 @@ Die vier Stufen (5.1) werden sequenziell beauftragt und abgenommen; innerhalb de
 
 ### 7.2 Unmittelbar nächste Schritte
 
-Erstens: Ableitung des Kundendokuments aus diesem Dokument (Gliederung parallel zu Kapiteln 2, 3, 5, 7; Umformulierung und Filterung gemäß Kapitel 1). Zweitens: Entscheidungsvorlage zur Moodle-Integrationsfrage (O1) erarbeiten – sie ist vor Implementierungsbeginn von Stufe 1 zu treffen, weil sie Deployment und Update-Weg der gesamten Produktlinie prägt. Drittens: Grobplanung Stufe 1 (Aufwände, Team, Meilensteine) auf Basis der Komponentensicht 6.1, 6.2, 6.6, 6.8.
+Erstens: Ableitung des Kundendokuments aus diesem Dokument (Gliederung parallel zu Kapiteln 2, 3, 5, 7; Umformulierung und Filterung gemäß Kapitel 1). Zweitens: Entscheidungsvorlage zur Moodle-Integrationsfrage (O1) erarbeiten – sie ist vor Implementierungsbeginn von Stufe 1 zu treffen, weil sie Deployment und Update-Weg der gesamten Produktlinie prägt. Drittens: Grobplanung Stufe 1 (Aufwände, Team, Meilensteine) auf Basis der Komponentensicht 6.2, 6.3, 6.7, 6.9.
 
 ---
 
@@ -403,7 +481,7 @@ Erstens: Ableitung des Kundendokuments aus diesem Dokument (Gliederung parallel
 |E16|Evaluationsframework als Update-Gate je Mandant; versionierte Releases mit Rollback|Modellwechsel ändern Verhalten; mandantenspezifische Regression möglich|5.5.3|
 |E17|Empfehlung statt Entscheidung als Auslieferungszustand; Automatik nur als Kundenkonfiguration|Art. 22 DSGVO; menschliche Aufsicht AI Act|5.4 P1|
 |E18|Wirkungsmetriken nur aggregiert; technisch erzwungen|Trennung Produktqualität/Leistungskontrolle; Mitbestimmung|5.6|
-|E19|Zwei neue Komponenten: Curation & Review Workbench, Evaluation & Telemetry Framework|Ergebnis der Lücken L1/L3; beide pflichtenheft-würdig|6.7/6.8|
+|E19|Zwei neue Komponenten: Curation & Review Workbench, Evaluation & Telemetry Framework|Ergebnis der Lücken L1/L3; beide pflichtenheft-würdig|6.8/6.9|
 |E20|Internes Dokument als führendes Dokument; Kundendokument als abgeleitete Teilmenge|Drift-Vermeidung; Spezifikationsbasis braucht volle Tiefe|1|
 
 ---