rag-tutor-documentation/02_Arbeitsplan/01 Entscheidungsdokumente/O1 - Entscheidungsvorlage Moodle-Integration - Intern.md

# Entscheidungsvorlage: Integrationsarchitektur gegenüber Moodle (O1)

**Vertraulichkeit:** intern

**Führendes Dokument** – die Fassung für mastersolution wird als gefilterte Teilmenge hieraus abgeleitet.

**Abgeleitetes Dokument:** "O1 - Entscheidungsvorlage Moodle-Integration - Extern" (v0.1, abgeleitet aus diesem Dokument in v0.3). Änderungen werden zuerst hier nachgezogen und anschließend dorthin propagiert, nie umgekehrt; die Versionszuordnung ist bei jeder Propagation hier fortzuschreiben.

**Bezug:** Internes Konzeptdokument v0.5, Abschnitt 4.3 (L4), Abschnitt 7.3, Abschnitt 8.1 (O1, O8)

|                   |                                                                 |
| ----------------- | --------------------------------------------------------------- |
| erstellt durch:   | d-opt GmbH<br>Oberneumarker Str. 59 <br>08496 Neumark (Sachsen) |
| erstellt von:     | Florian Förster                                                 |
| Erstellungsdatum: | 05.08.2026                                                      |
| geändert von:     | Florian Förster                                                 |
| Änderungsdatum:   | 05.08.2026                                                      |
| Dokumentversion:  | V0.3                                                            |

---

## 1. Entscheidungsgegenstand, Tragweite und Zeitpunkt

### 1.1 Gegenstand

Zu entscheiden ist, in welcher Architektur der Sovereign RAG Tutor gegenüber mastersolution ONE (Moodle-Basis) integriert wird. Die Frage wurde im Konzeptdokument als offener Punkt O1 geführt und dort in der Kurzform „Plugin im AI-Subsystem (Moodle 4.5) vs. eigenständiger Dienst" formuliert.

Diese Vorlage erweitert die Fragestellung bewusst. Die Untersuchung des Moodle-AI-Subsystems (Kapitel 2) hat ergeben, dass die binäre Formulierung den tatsächlichen Optionsraum verfehlt: Die relevante Achse ist nicht „innen oder außen", sondern **wie tief die Kopplung reicht und über welche Mechanismen sie hergestellt wird**. Kapitel 5 arbeitet deshalb mit vier Optionen statt zwei.

### 1.2 Tragweite

Die Entscheidung prägt vier Dinge dauerhaft:

1. **Den Auslieferungs- und Update-Weg der gesamten Produktlinie.** Sie bestimmt, ob das Produkt an den Moodle-Releasezyklus gekoppelt ist oder unabhängig davon versioniert werden kann.
2. **Die Betriebsfähigkeit über heterogene Kundenstände hinweg.** mastersolution betreut mehrere Großkunden mit unterschiedlichen Moodle-Versionen und unterschiedlich stark angepassten Installationen.
3. **Den Schutz des geistigen Eigentums.** Moodle-Plugins unterliegen nach verbreiteter Lesart der GPLv3; die Lage des Kerns entscheidet über die Offenlegungspflicht. Die lizenzrechtliche Einordnung im Detail ist im Rahmen der juristischen Begleitung (O3) zu bestätigen.
4. **Die Leistungsabgrenzung zwischen d-opt und mastersolution (O8).** Der technische Schnitt bestimmt maßgeblich den kommerziellen.

Eine spätere Korrektur ist teuer: Sie beträfe nicht ein Subsystem, sondern die Auslieferungsform aller vier Ausbaustufen.

### 1.3 Zeitpunkt

Die Entscheidung ist vor Implementierungsbeginn von Stufe 1 zu treffen. Sie ist Voraussetzung für die Grobplanung Stufe 1 und beeinflusst deren Aufwandsschätzung spürbar in beide Richtungen. Sie ist ebenfalls Voraussetzung für eine belastbare Verhandlung zu O8.

---

## 2. Architektur des Moodle-AI-Subsystems

Dieses Kapitel ist der Faktenteil. Es beschreibt den Stand des Subsystems, wie er sich aus der Moodle-Entwicklerdokumentation und den Release-Informationen bis Version 5.2 ergibt (Quellen in Anhang B).

### 2.1 Die vier Bausteine

Das AI-Subsystem ist kein Funktionsmerkmal, sondern ein Vermittlungsrahmen zwischen Nutzeroberfläche und KI-Dienst. Es besteht aus vier Bausteinen:

```mermaid
flowchart LR
    U[Nutzer]
    P1["Placement<br/>(UI-Plugin)"]
    M["Manager<br/>(Core)"]
    A(["Action<br/>(Core-Klasse)"])
    PR["Provider<br/>(Plugin)"]
    EXT[Externer KI-Dienst]

    U --> P1
    P1 -->|erzeugt| A
    A --> M
    M --> PR
    PR --> EXT
    EXT -.Response.-> PR -.-> M -.-> P1
```

**Placements** sind die Orte, an denen Nutzer mit KI interagieren – die UI-Komponenten samt zugehörigem Arbeitsablauf. Sie sind eigenständige Plugins und implementieren eine oder mehrere Aktionen. Im Core existieren derzeit zwei: der Course Assistant und der HTML-Texteditor.

**Actions** sind die Verben – das, was ein Nutzer mit der KI tun kann. Sie haben keine Oberfläche, sondern sind Klassen mit einer festgelegten Schnittstelle. In Moodle 4.5 waren dies `generate_text`, `generate_image` und `summarise_text`; ab 5.1 kam `explain_text` hinzu.

**Providers** sind die Anbindung an das eigentliche Modell. Sie sind ausdrücklich als dünner Adapter um eine externe API konzipiert: Sie sollen keine Daten speichern und keine eigene Oberfläche mitbringen, abgesehen von ihren Konfigurationsmasken. Im Core enthalten sind OpenAI und Azure, seit Version 5.2 zusätzlich Google Gemini und Amazon Bedrock. Souveräne Anbindungen (Ollama, LocalAI, LiteLLM) stammen aus dem Plugin-Ökosystem, nicht aus dem Core.

**Der Manager** ist der Controller dazwischen und Kern des Entwurfs. Es gilt die Regel, dass Placements keine Provider kennen und Provider keine Placements – der gesamte Verkehr läuft über den Manager, der die Aktion an einen unterstützenden Provider übergibt und jedes Ergebnis protokolliert.

### 2.2 Entwicklungsstand und -tempo

Das Subsystem wurde mit Moodle 4.5 (Oktober 2024) eingeführt und hat sich seither in jedem Release verändert: Erweiterungen in 5.0, in 5.1 die Aktion `explain_text` sowie Schalter auf Kurs- und Aktivitätsebene, in 5.2 (April 2026) die beiden zusätzlichen Provider. Für die Bewertung ist weniger der jeweilige Funktionszuwachs relevant als das Muster: **Das Subsystem ist ein Bewegungsziel im Halbjahrestakt.**

### 2.3 Governance-Eigenschaften

Für unser Regulatorik-Paket (Konzept 5.5, 5.6) sind drei Eigenschaften bemerkenswert, weil wir sie bei einer Entkopplung selbst erbringen müssen:

- **Nutzungsrichtlinie am Ort der Nutzung.** Nutzer müssen vor der ersten Verwendung einer KI-Aktion eine gesonderte AI-User-Policy akzeptieren – getrennt von der Site-Policy, weil die aufkommende Gesetzgebung eine Zustimmung am Nutzungsort nahelegt. Die Zustimmung wird protokolliert.
- **Rechtesteuerung über Capabilities.** Zugriff auf Placements und einzelne Aktionen wird über das Moodle-Rollen- und Rechtemodell gesteuert; seit 5.1 zusätzlich pro Kurs und pro Aktivität durch Lehrende schaltbar.
- **Protokollierung im Manager.** Jeder Aktionsaufruf wird zentral gespeichert.

Diese Bausteine sind qualitativ genau das, was ein AI-Act- und BetrVG-tauglicher Betrieb braucht. Ihre Existenz ist das stärkste Argument _für_ eine Integration ins Subsystem und muss in der Abwägung fair gewichtet werden.

### 2.4 Grenzen des Subsystems bezogen auf unser Vorhaben

Vier Grenzen sind für die Entscheidung ausschlaggebend:

**G1 – Für unsere Kernfunktion existiert kein passender Aktionstyp.** Eine belegte Antwort mit Quellenabschnitt, Video-Timestamp und Modusangabe ist keine Zusammenfassung und keine Texterzeugung. Aktionen sind Core-Klassen mit eigener Antwortklasse und eigenem Datenbankschema; ein neuer Aktionstyp ist damit praktisch ein Core-Beitrag an Moodle HQ, mit deren Releasezyklus und deren Prioritätensetzung. Der pragmatische Ausweg – unsere Antwort in einen bestehenden Aktionstyp pressen – kostet genau die Struktur, die unser Nachvollziehbarkeitsversprechen trägt.

**G2 – Die Provider-Rolle passt nicht zu unserem System.** Ein Provider ist definitionsgemäß ein dünner Adapter ohne eigene Datenhaltung. Der Knowledge Vault, die Graph-Schicht, das Lernermodell und die Evaluationsschicht sind das Gegenteil davon.

**G3 – Das Subsystem kennt keine Mandantenfähigkeit.** Die Konfiguration erfolgt je Moodle-Site. Unser Betreibermodell (Konzept 5.5) setzt Mandantentrennung voraus. Dass diese Lücke real ist, zeigt das Ökosystem: Es existiert ein Drittanbieter-Infrastrukturplugin (`local_ai_manager`), auf dem mehrere Chat-Plugins aufsetzen, gerade weil mandantenfähige KI-Governance im Core fehlt und dort auf absehbare Zeit auch nicht erwartet wird.

**G4 – Das Subsystem ist auf synchrone, kurze Einzelaktionen ausgelegt.** Unsere Batch-Prozesse (Video-Ingestion, Graph-Extraktion mit Belegpflicht) haben ein völlig anderes Laufzeit- und Ressourcenprofil.

---

## 3. Randbedingungen und Annahmen

### 3.1 Aus dem Lösungskonzept

| |Randbedingung|Quelle|
|---|---|---|
|R1|Souveränität: Betrieb On-Premise **und** im deutschen Rechenzentrum muss möglich sein|Konzept 3, 5.5|
|R2|Nachvollziehbarkeit: Belege, Timestamps, Begründungen sind Pflichtbestandteil der Antwort|Konzept 5.6, 6.7|
|R3|Betreibermodell: Mandantenfähigkeit, Rollenteilung mastersolution/Endkunde, Update-Gate|Konzept 5.5|
|R4|Stufenlogik: jede Stufe eigenständig produktiv und verkaufbar|Konzept 5.1|
|R5|GPU-Komponente ab Stufe 2 mit eigenem Sizing- und Betriebsprofil|Konzept 5.1, O2|

### 3.2 Aus der Kundensituation

**R6 – Versionsheterogenität.** mastersolution betreut mehrere Großkunden, die voraussichtlich auf unterschiedlichen Moodle-Versionen betrieben werden. Diese Randbedingung ist eine konservative Setzung und als Annahme A1 (3.4) geführt; dort ist auch die Wirkung einer etwaigen Widerlegung dokumentiert. Änderungen an dieser Einschätzung sind ausschließlich in A1 nachzuziehen.

**R7 – Hoher Anpassungsgrad.** Die Installationen sind je Kunde unterschiedlich stark angepasst, insbesondere im Erscheinungsbild. Jede Lösung, die sich in die Moodle-Oberfläche einwebt, muss über diese Varianz hinweg funktionieren und getestet werden.

**R8 – Datenbankhoheit.** Die Postgres-Datenbank wird von mastersolution verwaltet. Ein direkter Lesezugriff wäre organisatorisch also möglich – technisch koppelt er uns jedoch an ein Schema, das über die Versionsstände variiert (siehe Anhang A, K1).

### 3.3 Aus unserer Position _(Filterung je Punkt – siehe Hinweis am Ende des Abschnitts)_

**R9 – Kompetenzlage.** d-opt verfügt über keine Moodle- und keine nennenswerte PHP-Erfahrung. Ein Aufbau wäre erheblich aufwändig und müsste anschließend über die gesamte Produktlebensdauer gehalten werden – für eine Technologie, die außerhalb dieses Projekts keinen Beitrag zu unserem Portfolio leistet.

**R10 – Lizenzposition.** Eine Offenlegung der Kernlogik unter GPLv3 wird abgelehnt. Ein schmaler, quelloffener Adapter, der eine proprietäre Kernlogik über eine Netzwerkschnittstelle anspricht, ist unproblematisch. Es ist davon auszugehen, dass mastersolution als maßgeblicher Finanzier der Entwicklung dieselbe Position vertritt; dies ist jedoch zu verifizieren und nicht zu unterstellen. Die zugrunde liegende lizenzrechtliche Einordnung (wann eine Moodle-Erweiterung als abgeleitetes Werk gilt) ist juristisch nicht trivial und im Rahmen der juristischen Begleitung (O3) zu bestätigen; die Architekturempfehlung ist so gewählt, dass sie unter jeder Auslegung Bestand hat.

**R11 – Wiederverwendbarkeit.** Das entstehende System soll für uns auch außerhalb dieses Kundenverhältnisses anschlussfähig bleiben. Dieser Punkt wird gegenüber mastersolution **nicht** hervorgehoben. Er ist auch nicht argumentationstragend: Die Empfehlung in Kapitel 6 hält ohne ihn.

_Hinweis zur Ableitung der Kundenfassung – Filterung je Punkt:_

- _R9 (Kompetenzlage) entfällt in expliziter Form. Die sachlich gültige Teilmenge wird über das Argument der kompetenzorientierten Arbeitsteilung (Kapitel 8) transportiert._
- _R10 (Lizenzposition) **wird aufgenommen**, jedoch umformuliert: nicht als unsere Position, sondern als gemeinsames Interesse am Schutz des von mastersolution maßgeblich finanzierten Produktkerns – einschließlich des Hinweises auf die Wettbewerber im Moodle-Ökosystem, die das Konzept ohnehin als Marktdruck beschreibt. Begründung der Aufnahme: Die GPL-Frage betrifft mastersolution unmittelbar; würde sie in der Vorlage fehlen und später von deren Technikern selbst entdeckt, beschädigte das die Vorlage rückwirkend. Unsere eigene Positionierung dazu (Ablehnung der Offenlegung) bleibt intern._
- _R11 (Wiederverwendbarkeit) entfällt vollständig und wird auch nicht angedeutet. Der Punkt ist nicht argumentationstragend._

### 3.4 Annahmen

|Nr.|Annahme|Status|Wirkung bei Widerlegung|
|---|---|---|---|
|A1|Endkunden betreiben unterschiedliche Moodle-Versionen ohne zeitnahes Major-Upgrade|konservativ gesetzt|Bei einheitlichem, aktuellem Stand verlöre B an Nachteil – die Empfehlung bliebe dennoch bestehen (G1, R10)|
|A2|Die native Moodle-App spielt bei Unternehmenskunden eine untergeordnete Rolle|**zu verifizieren**|Bei hoher App-Relevanz verschiebt sich die Bewertung von K3 (Anhang A); betrifft alle Optionen ähnlich|
|A3|mastersolution gewährt Web-Service-Zugriff in ausreichendem Umfang|plausibel|Ohne ausreichenden Zugriff wird K1/K2 zum Engpass; Rückfall auf Export-Wege|
|A4|Ein Mandant entspricht einer Moodle-Instanz|**zu verifizieren**|Multi-Tenant-Instanzen ändern die Berechtigungsarchitektur spürbar und stellen die Governance-Bewertung von Option B (5.3) infrage|

A2 und A4 sind vor Fertigstellung bei mastersolution abzufragen.

---

## 4. Bewertungskriterien

Die Bewertung erfolgt qualitativ und argumentativ. Auf eine gewichtete Nutzwertanalyse wird bewusst verzichtet: Sie würde eine Präzision suggerieren, die bei Kriterien wie „Lizenzrisiko" oder „Kompetenzaufbau" nicht besteht, und die eigentliche Argumentation hinter Zahlen verstecken.

|Nr.|Kriterium|Leitfrage|
|---|---|---|
|B1|Release-Kopplung|Wie stark bindet die Option unsere Auslieferung an den Moodle-Releasezyklus?|
|B2|Update-Weg über heterogene Stände|Wie viele Moodle-Nebenlinien müssen gleichzeitig lauffähig, getestet und gepflegt werden?|
|B3|Mandantenfähigkeit|Trägt die Option das Betreibermodell aus Konzept 5.5?|
|B4|Aufwand und Kompetenzbedarf|Welche Kompetenzen setzt die Option voraus, und wo liegen sie heute?|
|B5|Lizenz und geistiges Eigentum|Welcher Anteil des Systems unterläge einer Offenlegungspflicht?|
|B6|Funktionsdeckung|Lässt sich die Kernfunktion in ihrer geforderten Form überhaupt abbilden?|
|B7|Governance-Wiederverwendung|Wie viel der in 2.3 beschriebenen Ausstattung können wir nutzen statt selbst bauen?|

B6 ist als K.-o.-Kriterium zu behandeln: Eine Option, die die Kernfunktion nur in verstümmelter Form trägt, ist unabhängig von allen anderen Kriterien nicht wählbar. B5 ist unter R10 ebenfalls K.-o.-tauglich.

---

## 5. Optionen und Bewertung

### 5.1 Der Optionsraum

```mermaid
flowchart TD
    A["A – Vollintegration<br/>Kern als Placement im AI-Subsystem"]
    B["B – Geteilte Integration<br/>Externer Kern, Oberfläche als Placement"]
    C["C – Eigenständiger Dienst<br/>Standardbasierte Anbindung (LTI, Web Services)"]
    D["D – Gestufte Integrationstiefe<br/>C als Fundament, native Einbettung als Ausbaupfad"]
    C -.->|Ausbaupfad| D
```

### 5.2 Option A – Vollintegration

Die Kernfunktion wird als Placement-Plugin im AI-Subsystem realisiert; Retrieval, Kontextaufbereitung und Antwortlogik laufen innerhalb der Moodle-Installation, das Sprachmodell wird über einen Provider angebunden.

**Bewertung:** Scheitert an B6 und B5. Die Kernfunktion hat keinen passenden Aktionstyp (G1); ein neuer Typ ist faktisch ein Core-Beitrag. Der Kern läge vollständig im GPL-Bereich (R10). Hinzu kommen B2 (Pflege über alle Kundenstände hinweg), B4 (Kompetenz nicht vorhanden, R9) und B3 (keine Mandantenfähigkeit, G3). Die GPU-Komponente aus Stufe 2 ließe sich ohnehin nicht in eine Moodle-Installation legen (G4, R5) – Option A ist spätestens ab Stufe 2 auch technisch nicht durchhaltbar.

**Ergebnis: ausgeschlossen.**

### 5.3 Option B – Geteilte Integration

Kernlogik und Modell laufen als eigenständiger Dienst; die Nutzeroberfläche wird als Placement-Plugin im AI-Subsystem realisiert, das über einen Provider oder direkt auf unseren Dienst zugreift.

**Bewertung:** B5 und B3 wären lösbar – der Kern bliebe proprietär und mandantenfähig. B7 wäre die Stärke dieser Option: Nutzungsrichtlinie, Capabilities und Protokollierung kämen aus dem Core. Diese Stärke gilt allerdings nur unter Annahme A4 (ein Mandant = eine Moodle-Instanz), denn die Core-Governance ist je Site konfiguriert; bei Multi-Tenant-Instanzen wäre auch sie neu zu bewerten.

Sie scheitert jedoch an der Kombination aus B6, B2 und B4:

- **B6:** Das Antwortformat wird durch die Antwortklassen der Core-Aktionen bestimmt. Belege, Timestamps und Modusanzeige – die Träger unseres Nachvollziehbarkeitsversprechens – müssten in Strukturen gepresst werden, die dafür nicht gedacht sind.
- **B2:** Ein Placement-Plugin muss über alle bei Endkunden vorhandenen Moodle-Nebenlinien lauffähig sein (R6) und über stark angepasste Oberflächen hinweg funktionieren (R7). Das Subsystem selbst ist dabei ein Bewegungsziel im Halbjahrestakt (2.2).
- **B4:** Diese Pflegelast träfe ein Team ohne Moodle- und PHP-Erfahrung (R9).

Die drei Punkte sind einzeln beherrschbar und in Summe nicht. Der Ausschlussgrund ist also nicht die Idee, sondern ihre Betriebsrealität unter unseren Randbedingungen.

**Ergebnis: nicht empfohlen.**

### 5.4 Option C – Eigenständiger Dienst mit standardbasierter Anbindung

Der Sovereign RAG Tutor läuft als eigenständiger, mandantenfähiger Dienst – On-Premise beim Endkunden oder im Rechenzentrum. Die Kopplung an Moodle erfolgt über etablierte Standardmechanismen (Aufruf und Rollenübergabe per LTI 1.3, Inhalts- und Ereigniszugriff über Moodle-Web-Services). Das AI-Subsystem wird nicht genutzt.

**Bewertung:**

- **B1/B2 – die Stärke.** Die Kopplung ruht auf Mechanismen, die seit Moodle 3.8 stabil verfügbar sind. Über die erwartbare Versionsspanne der Endkunden hinweg gilt dasselbe Verfahren. Unsere Auslieferung wird vom Moodle-Releasezyklus entkoppelt.
- **B3 – erfüllt.** Mandantenfähigkeit ist eine Eigenschaft unseres Dienstes, nicht der Moodle-Instanz.
- **B4 – erfüllt.** Der moodleseitige Anteil ist überwiegend Konfiguration, kein Code. Wo Code nötig ist, liegt er bei mastersolution (Kapitel 8).
- **B5 – erfüllt.** Der Kern bleibt proprietär; ein etwaiges schmales Moodle-Artefakt enthält keine Kernlogik.
- **B6 – erfüllt.** Wir bestimmen Antwortformat und Oberfläche vollständig selbst.
- **B7 – die Schwäche.** Nutzungsrichtlinie, Rechtefeinsteuerung und Protokollierung müssen wir selbst erbringen.

**Zur Schwäche B7 im Detail:** Der Aufwand ist real und darf nicht kleingeredet werden; er beginnt zudem früh, denn die Basis-Governance (Zustimmung am Nutzungsort, Aktionsprotokollierung) wird mit dem ersten LLM-Kontakt in Stufe 2 fällig (8.1, 8.3). Er relativiert sich jedoch aus zwei Gründen. Erstens fällt er ohnehin an: Das Betreibermodell (5.5) und das Regulatorik-Paket (Stufe 3) verlangen Mandantentrennung, Begründungsprotokolle und Update-Gates in einer Form, die das Core-Modell nicht liefert. Zweitens ist ein eigenes Modell dem Core-Modell in genau dem Punkt überlegen, auf den es bei uns ankommt – Mandantentrennung –, und es gilt einheitlich über alle Kundenstände hinweg statt in vier Ausprägungen.

**Grenze der Option:** Die Einbettung in die Moodle-Oberfläche bleibt weniger nahtlos als bei B. Der Absprung ins Material (Konzept 6.7: Kernfunktion, kein Nice-to-have) ist über direkte URL-Verweise in die Moodle-Kursstruktur lösbar, erfordert aber sorgfältige Spezifikation. (Bewusst nicht gemeint ist das LTI-Merkmal „Deep Linking" – dieses bezeichnet die Gegenrichtung, das Platzieren von Tool-Inhalten im LMS durch Lehrende.)

**Ergebnis: tragfähig.**

### 5.5 Option D – Gestufte Integrationstiefe

Option C als Fundament, ergänzt um die bewusste Auslegung, dass eine tiefere Einbettung – Block-Plugin, später ggf. ein Placement im AI-Subsystem – als optionaler Ausbaupfad möglich bleibt, ohne die Architektur zu verändern. Voraussetzung ist, dass die Dienstschnittstelle von Beginn an oberflächenneutral geschnitten wird und keine Annahme über den aufrufenden Kanal trifft.

**Bewertung:** Erbt alle Eigenschaften von C. Der Zusatzaufwand beschränkt sich auf Disziplin beim Schnittstellenschnitt, nicht auf zusätzliche Implementierung. Der Gewinn ist strategisch: Die Entscheidung über die Tiefe der Oberflächenintegration muss heute nicht getroffen werden und bleibt für mastersolution offen.

**Ergebnis: empfohlen.**

---

## 6. Richtungsempfehlung

**Empfehlung: Option C, ausgelegt als Option D.**

Der Sovereign RAG Tutor wird als eigenständiger, mandantenfähiger Dienst gebaut und über etablierte Standardmechanismen an mastersolution ONE gekoppelt. Die Dienstschnittstelle wird oberflächenneutral geschnitten, sodass eine tiefere Einbettung später ohne Architekturänderung nachrüstbar ist.

**Die drei tragenden Gründe, in dieser Reihenfolge:**

1. **Funktionsdeckung (B6).** Das AI-Subsystem hat für unsere Kernfunktion keinen passenden Aktionstyp. Eine Integration würde die Struktur kosten, die das Nachvollziehbarkeitsversprechen trägt – also genau das Merkmal, wegen dessen der Kunde das System kauft.
2. **Betriebsrealität über heterogene Kundenstände (B1/B2).** Eine Kopplung an ein Subsystem, das sich halbjährlich verändert, bei Endkunden mit unterschiedlichen Versionsständen und stark angepassten Installationen, erzeugt eine dauerhafte Pflegelast ohne funktionalen Gegenwert.
3. **Kompetenz- und Lizenzlage (B4/B5).** Der moodleseitige Anteil soll dort liegen, wo Moodle-Kompetenz vorhanden ist; der Produktkern soll nicht offenlegungspflichtig werden.

_Hinweis zur Ableitung der Kundenfassung: Dort wird Grund 2 vorangestellt – die Entkopplung vom Moodle-Releasezyklus als Schutz der Investition von mastersolution über heterogene Kundenstände hinweg ist das gegenüber dem Kunden stärkste Argument. Grund 1 folgt an zweiter Stelle. Grund 3 wird aufgeteilt: die Lizenzfrage als eigenständiger dritter Grund im Sinne von R10 (Schutz des finanzierten Produktkerns), die Kompetenzlage nur in Gestalt der Arbeitsteilung aus Kapitel 8. An der Sachlage ändert die Umstellung nichts; sie ist hier dokumentiert, damit zwischen den beiden Fassungen keine stille Abweichung entsteht._

### 6.1 Der bewusst offen gelassene Freiheitsgrad

Die Empfehlung legt **nicht** fest, wie tief die Oberflächenintegration am Ende reicht. Diese Frage bleibt für mastersolution offen und kann nach den Erfahrungen aus Stufe 1 und 2 entschieden werden – zu einem Zeitpunkt, an dem echte Nutzungsdaten vorliegen statt Vermutungen. Die Architektur trägt beide Ausgänge.

Damit ist die Vorlage eine Richtungsvorgabe aus technischer Verantwortung, keine Vorwegnahme einer Produktentscheidung, die mastersolution zusteht.

---

## 7. Verworfene Optionen und ihre Begründung

Dieses Kapitel ist ausdrücklich nicht als Abwertung angelegt. Die Frage „warum nicht ins native Subsystem?" ist berechtigt und wird von mastersolution kommen; die Antwort muss belastbar sein und darf nicht nach Bequemlichkeit klingen.

|Verworfen|Kernbegründung|Nachrangige Gründe|
|---|---|---|
|**A – Kern als Placement**|Kein passender Aktionstyp; Kern wäre offenlegungspflichtig|Pflegelast, Kompetenzbedarf, keine Mandantenfähigkeit, GPU-Profil|
|**B – Oberfläche als Placement**|Antwortformat durch Core-Aktionsklassen bestimmt; Belege/Timestamps nicht sauber abbildbar|Pflege über alle Nebenlinien und angepasste Oberflächen; Kompetenzbedarf|
|**Provider-Plugin als Träger**|Provider ist definitionsgemäß dünner Adapter ohne Datenhaltung; unser System ist das Gegenteil|–|
|**Direkter Datenbankzugriff für Ingestion**|Koppelt an ein Schema, das über die Versionsstände variiert – erzeugt genau das Risiko, das die Architektur vermeiden soll|Wartungslast bei Moodle-Upgrades der Endkunden|

**Wichtige Klarstellung zu A und B:** Beide wären bei einer homogenen, aktuellen Moodle-Landschaft und vorhandener Moodle-Kompetenz ernsthaft erwägenswert – insbesondere B, wegen der Governance-Ausstattung (2.3). Der Ausschluss folgt aus unseren konkreten Randbedingungen, nicht aus einer generellen Schwäche des Subsystems.

---

## 8. Konsequenzen

### 8.1 Je Ausbaustufe

**Stufe 1 (Souveräne Suche).** Berührt das AI-Subsystem konzeptionell gar nicht – es gibt kein Sprachmodell. Zu klären sind hier Inhaltszugriff für die Ingestion und Identitäts-/Berechtigungsübergabe. Beides über Standardmechanismen. Das ist die einfachste Stufe im Sinne dieser Entscheidung und eignet sich als Erprobung des Kopplungsverfahrens.

**Stufe 2 (Nachschlage-Assistent).** Hier fällt die GPU-Komponente an; die Entscheidung bestätigt sich hier selbst, denn eine Modellkomponente mit eigenem Sizing-Profil lässt sich in keiner Moodle-Installation sinnvoll unterbringen. Zugleich wird hier die in 5.4 benannte Schwäche B7 erstmals wirksam: Mit dem ersten LLM-Kontakt der Nutzer braucht der Dienst die **Basis-Governance** – Zustimmung am Ort der Nutzung und Protokollierung der Aktionsaufrufe (die Bausteine aus 2.3, die das Subsystem geliefert hätte). Sie ist Bestandteil von Stufe 2, nicht Vorarbeit für Stufe 3, und fügt sich zeitlich in die ohnehin gegen Ende Stufe 2 beginnende juristische Begleitung.

**Stufe 3 (Kompetenzmodell und Tracking).** Hier wird der Zugriff auf explizite Lernereignisse relevant. Die Basis-Governance aus Stufe 2 wird zur **vollen Regulatorik-Ausstattung** ausgebaut: Begründungsprotokolle, Rechtefeinsteuerung, konfigurierbare Vier-Augen-Freigaben. Diese muss stehen, bevor Stufe 3 produktiv geht, und ist als Teil des Regulatorik-Pakets zu planen, nicht als Zusatz.

**Stufe 4 (Adaptive Didaktik).** Erstmals schreibende Aktionen im LMS (Einschreibung in generierte Lernpfade). Diese sind über Standardmechanismen abzubilden und unterliegen der Freigabelogik aus Konzept 5.3.3 – das System stößt an, entscheidet aber nicht.

### 8.2 Wirkung auf O8 (Leistungsabgrenzung)

Die Empfehlung impliziert eine Arbeitsteilung, die technischen und kommerziellen Schnitt zur Deckung bringt:

- **d-opt** liefert den souveränen Dienst mit allen Komponenten aus Konzept 6.2–6.9.
- **mastersolution** liefert die moodleseitigen Artefakte: LTI-Registrierung, Web-Service-Konfiguration und Rollen, sowie – falls die Oberflächenintegration später vertieft wird – das zugehörige Moodle-Artefakt.

Das ist sachlich begründet: Dort liegt die Moodle- und PHP-Kompetenz, dort liegt die Kenntnis der kundenspezifischen Anpassungen, und dort ist eine GPL-Offenlegung unproblematisch, weil das Artefakt keine Kernlogik enthält.

_Intern:_ Diese Abgrenzung ist zugleich unsere Verhandlungsposition zu O8. Sie hält unseren Leistungsanteil scharf konturiert und vermeidet, dass wir in eine Betriebsverantwortung für fremde Moodle-Installationen hineinwachsen.

### 8.3 Was zusätzlich zu leisten ist

|Leistung|Stufe|Anmerkung|
|---|---|---|
|Basis-Governance: Zustimmung am Nutzungsort, Aktionsprotokollierung|2|Ersatz für die Core-Governance (2.3); mit erstem LLM-Kontakt erforderlich|
|Volle Regulatorik-Ausstattung: Begründungsprotokolle, Rechtefeinsteuerung, Vier-Augen-Freigaben|3|Ausbau der Basis-Governance; Teil des Regulatorik-Pakets|
|Rollen- und Berechtigungsabbildung Moodle → Dienst|1|Standardisierbar als Teil der Mandanten-Einführung|
|Absprungmechanik in Materialien|1|Kernfunktion laut Konzept 6.7; sorgfältig zu spezifizieren|
|Oberflächenneutraler Schnittstellenschnitt|1|Voraussetzung für den Ausbaupfad aus Option D|

---

## 9. Revisionspunkte

Die Entscheidung ist zu überprüfen, wenn eine der folgenden Bedingungen eintritt:

**V1 – Moodle HQ erweitert das Subsystem substanziell.** Kämen chat- oder retrievaltaugliche Aktionstypen _und_ ein Mandantenmodell in den Core, würde ein optionales Placement attraktiv. Die Architektur bliebe gültig, weil der Kern extern liegt – genau dafür ist Option D ausgelegt. Der Ausbaupfad ist dann zu prüfen, nicht die Grundsatzentscheidung.

**V2 – Die Versionslandschaft homogenisiert sich.** Sollte mastersolution eine einheitliche, aktuelle Moodle-Basis über alle Endkunden durchsetzen, entfiele der Nachteil B2. Die Empfehlung bliebe dennoch bestehen, getragen von B6 und B5.

**V3 – Annahme A2 oder A4 erweist sich als falsch.** Hohe Relevanz der nativen Moodle-App oder Multi-Tenant-Moodle-Instanzen erfordern eine erneute Prüfung der Kopplungsmechanismen (Anhang A), nicht der Grundsatzentscheidung.

**V4 – Die Lizenzposition ändert sich.** Sollte mastersolution eine Offenlegung des Kerns wünschen oder fordern, ist die Entscheidung vollständig neu zu führen – dann fiele das Kriterium B5 weg, und Option B rückte in Reichweite.

_Hinweis zur Ableitung der Kundenfassung: V1–V3 werden übernommen; **V4 entfällt dort bewusst**. Begründung: V4 beschreibt das Szenario einer geänderten Offenlegungsposition – eine vertragliche und positionelle Frage, kein technischer Revisionsauslöser wie V1–V3, und in einer Entscheidungsvorlage nicht aktiv als Denkmöglichkeit anzubieten. Sollte mastersolution die Frage von sich aus stellen, gilt die Antwort aus V4._

---

## 10. Eintrag für das Entscheidungsregister

Vorschlag zur Aufnahme in Konzeptdokument 8.2 (_Nummer bei Einpflege gegen den aktuellen Registerstand prüfen_):

|Nr.|Entscheidung|Begründung (Kurzform)|Datum|Abschnitt|
|---|---|---|---|---|
|E-neu|Eigenständiger Dienst mit standardbasierter Moodle-Anbindung; AI-Subsystem nicht genutzt; tiefere Einbettung als offener Ausbaupfad|Kein passender Aktionstyp für die Kernfunktion; Entkopplung vom Moodle-Releasezyklus bei heterogenen Kundenständen; Kompetenz- und Lizenzlage|_Datum der gemeinsamen Entscheidung mit mastersolution, bei Einpflege einzutragen_|Diese Vorlage|

Zugleich ist O1 in 8.1 als geschlossen zu kennzeichnen, mit Verweis auf diese Vorlage und die Revisionspunkte aus Kapitel 9. O8 ist um den Hinweis auf 8.2 dieser Vorlage zu ergänzen.

---

## Anhang A – Kopplungsmatrix (intern)

> **Nicht Bestandteil der Kundenfassung.** Dieser Anhang dokumentiert die technische Detailebene, aus der die Empfehlung abgeleitet ist. Er dient der späteren Spezifikationsarbeit. Die Diskussion mit mastersolution wird bewusst auf Optionsebene geführt.

Die Grundsatzentscheidung zerfällt bei der Spezifikation in fünf getrennt zu beantwortende Kopplungspunkte:

|Nr.|Kopplungspunkt|Ab Stufe|Optionen|Tendenz|
|---|---|---|---|---|
|K1|Inhaltszugriff (Ingestion)|1|Moodle Web Services · direkter Postgres-/Dateizugriff · Export-/Backup-Weg|Web Services; DB-Zugriff verworfen (Schemakopplung, R8)|
|K2|Identität und Berechtigungen|1|LTI 1.3 mit Rollenübergabe · OAuth2-SSO plus Web Services · Kombination|Kombination: LTI für Aufruf und Grobrolle, Web Services für die feingranulare Berechtigungsprüfung|
|K3|Oberfläche|1|External-Tool-Aktivität · Block-Plugin · Placement · eigene Weboberfläche|External Tool als Einstieg; Block/Placement als Ausbaupfad (Option D)|
|K4|Lernereignisse|3|Web Services · Events/Completion-API|Nach Stufe-2-Erfahrung zu entscheiden|
|K5|Schreibende Aktionen|4|Web Services schreibend|Mit Freigabelogik aus Konzept 5.3.3|

**Zu K2 im Detail.** LTI 1.3 samt der Advantage-Dienste ist in Moodle seit Version 3.8 verfügbar; die Rollen- und Einschreibungsinformationen eines Kurses lassen sich darüber abrufen. Das ist der Grund, warum diese Kopplung über die erwartbare Versionsspanne trägt – und warum sie überwiegend Konfiguration statt Code ist. Die Grenze: Das LTI-Rollenvokabular ist grob (Instructor, Learner, …). Unsere Berechtigungsfilterung auf Index-Einheiten-Ebene (Konzept 6.2) braucht mehr Auflösung; deshalb die Kombination mit Web Services.

**Zu K3 im Detail.** Der Absprung in Materialien und Video-Timestamps (Konzept 6.7) ist der kritische Punkt. Er ist über direkte URL-Verweise in die Moodle-Kursstruktur lösbar (Kurs-, Abschnitts- und Aktivitäts-URLs, bei Video ergänzt um Timestamp-Parameter), muss aber gegen die kundenspezifisch angepassten Oberflächen (R7) getestet werden. Terminologische Abgrenzung: LTI Deep Linking bezeichnet die Gegenrichtung – Lehrende platzieren Tool-Inhalte im LMS. Es ist für den Ausbaupfad in K3 relevant (Einbettung unserer Oberfläche als Aktivität), nicht für den Material-Absprung.

**Offene Detailfragen für die Spezifikationsphase:** Verhalten bei Materialänderungen im laufenden Betrieb (Reindizierung, Differenzvorschläge nach Konzept 5.3.2); Umgang mit Kursen, die nach der Indizierung neu berechtigt werden; Latenzbudget der Berechtigungsprüfung pro Suchanfrage.

---

## Anhang B – Quellen

**Moodle-Entwicklerdokumentation (Primärquellen für Kapitel 2):**

- AI Subsystem, Version 4.5: https://moodledev.io/docs/4.5/apis/subsystems/ai — Architektur der vier Bausteine, Aktionsklassen (`generate_text`, `generate_image`, `summarise_text`), AI-User-Policy-Mechanik
- AI Plugins (Provider- und Placement-Typen), Version 5.0: https://moodledev.io/docs/5.0/apis/plugintypes/ai — Core-Provider und Core-Placements, Trennung der Plugintypen
- Provider-Entwicklung, Version 4.5: https://moodledev.io/docs/4.5/apis/plugintypes/ai/provider — „Thin-Wrapper"-Charakter der Provider, keine eigene Datenhaltung
- Placement-Entwicklung, Version 4.5: https://moodledev.io/docs/4.5/apis/plugintypes/ai/placement — Zugriffssteuerung durch Placements, Manager-Workflow

**Moodle-Nutzerdokumentation:**

- AI subsystem (4.5): https://docs.moodle.org/405/en/AI_subsystem — Struktur Placements/Actions/Providers, Administrationszugang
- AI placements (5.1): https://docs.moodle.org/501/en/AI_placements — Summarise/Explain, Kurs- und Aktivitätsschalter, Capabilities
- AI tools (5.2): https://docs.moodle.org/502/en/AI_tools — Aktionsübersicht nach Rollen und Kontext
- New features (5.2): https://docs.moodle.org/502/en/New_features — Gemini- und Bedrock-Provider im Core
- Publish as LTI tool (5.2): https://docs.moodle.org/502/en/Publish_as_LTI_tool — LTI 1.3 / LTI Advantage (AGS, NRPS, Deep Linking)

**Sekundärquellen (Marktbeobachtung, Plugin-Ökosystem):**

- Accipio: „Moodle AI: What it Does, How it Works" — https://www.accipio.com/blog/leveraging-the-power-of-moodle-ai/ — Provider-Landschaft inkl. Ollama/LiteLLM/LocalAI, Manager-Rolle
- AI Tutor Blog: „Best AI Moodle Plugins" — https://ai-tutor.ai/blog/best-ai-moodle-plugins/ — `local_ai_manager` als Mandanten-Infrastruktur, Einschätzung zur Core-Roadmap, App-Limitierungen bei Chat-Plugins
- eLeDia: „New in Moodle 5.2" — https://eledia.de/en/neu-in-moodle-5-2/ — keine strukturellen AI-Änderungen in 5.2 gegenüber 5.0/5.1

_Abrufstand: August 2026. Da sich das Subsystem im Halbjahrestakt verändert, ist der Faktenteil (Kapitel 2) vor jeder Wiedervorlage gegen den dann aktuellen Stand zu prüfen; die Entwicklerdokumentation ist versioniert und erlaubt den Abgleich je Moodle-Version._