# Berichtsergänzung: Von der Gruppe zur Modellschule

Amasworld · Next Generation · 17. Oktober 2026 · Modell 2.2-behaviour · KI-unterstützter Entwurf zur fachlichen Prüfung

## 1. Fragestellung und Einordnung

Wie verändert sich die Interpretation einer Schulsimulation, wenn nicht nur Mittelwerte, sondern auch Klassen und einzelne Tagesverläufe sichtbar sind? Die neue Version erweitert die bisherige kontrollierte Gruppensimulation um eine reproduzierbare Modellschule. Sie ersetzt keine Untersuchung an einer echten Schule. Die Programmregeln sind bewusst vereinfachte, erfundene Annahmen.

Diese Ergänzung beschreibt die neue Architektur, die nötigen Nachweise und die Grenzen. Der bisherige Bericht bleibt erhalten. Eine persönliche Reflexion und ein Nachweis eigenständiger Schülerarbeit werden hier nicht erfunden.

## 2. Was sich gegenüber Modell 1.1 ändert

Die ursprüngliche Version 1.1-controlled rechnete fiktive Personen und zeigte vor allem tägliche Gruppenmittel. Die unveränderte Referenz bleibt als `legacy-engine.js` erhalten. Modell 2.0-school ergänzt Klassen, fiktive Identitäten, Schulkonfiguration und vollständige Zustandsfolgen ab Tag 0. Dadurch kann derselbe Versuch aus mehreren Perspektiven betrachtet werden: ganze Schule, einzelne Klasse, Verteilung und einzelne Person.

Zusätzliche Einstellungen betreffen Startwertverschiebungen, die Streuung der Ereignis-Stresssensitivität, ein wählbares Ereignisfenster und die betroffenen Klassen. Hausaufgaben, späterer Schulbeginn und Stundenplanwechsel sind neue hypothetische Ereignisse. Solche Regeln benötigen eine neue Modellversion: Es wäre irreführend, sie unter unverändertem Versionsnamen als dieselbe Simulation auszugeben.

## 3. Aufbau der Software

| Bestandteil | Aufgabe | Wichtige Grenze |
|---|---|---|
| legacy-engine.js | Referenzregeln von 1.1-controlled | Nicht verändern; Kompatibilität separat testen |
| school.js | Validierung und reproduzierbare Modellschule | Kein echtes Schülerregister |
| simulation.js | Gepaarte Tageszustände, ein Haupt- und bis zu vier Zusatzereignisse | Dokumentierte Regeln, keine empirische Vorhersage |
| behaviour.js / social.js | Optionale Rückkopplung, Fachzähler und Vortagskontakte | Frei gewählte Koeffizienten; feste Topologie mit veränderlichen Gewichten |
| assistant-schema.js / backend/assistant.js | Geprüfte Sprachvorschläge und getrennte KI-Lesehilfe | Keine generierten Gleichungen, keine Änderung der numerischen Ergebnisse |
| analysis.js | Mittelwerte, Klassen, Histogramme, Perzentile und regelbasierte Erklärung | Auswertung ist keine empirische Bestätigung |
| storage.js | Konfiguration speichern, Dokumente prüfen, neu rechnen und Altformat migrieren | Importierte Ergebniszahlen nicht blind vertrauen |
| app.js / index.html / styles.css | Bedienung und Darstellung | Echte Browserprüfung bleibt nötig |

Der numerische Kern nutzt klassische lokale JavaScript-Dateien ohne Laufzeitbibliotheken und funktioniert offline. Ein optionaler Cloudflare-KI-Adapter arbeitet getrennt und nur nach Zustimmung und Klick. Er verwendet Anbieter-Kontingente; lokale Berechnungen benötigen keine KI-Aufrufe. Best-Effort-Drosselung ist keine globale Kostengarantie. Die Architektur ersetzt weder tatsächliche Browserprüfung noch eine Abrechnungskontrolle; Details stehen im Sicherheitsdokument.

## 4. Warum einzelne Verläufe wichtig sind

Ein Mittelwert fasst viele Personen zusammen. Er kann verdecken, dass dieselbe Regel je nach Startwert unterschiedlich wirkt. Im Prüfungsereignis hängt der zusätzliche Stress beispielsweise von der Organisation ab. Der Leistungsverlauf verwendet wiederum Lernzeit und Konzentration sowie gegebenenfalls einen hohen Stresswert. So können Unterschiede entstehen, ohne dass die Software für jede Person eine eigene „Persönlichkeit“ oder ein Sprachmodell braucht.

Diese Individualität bleibt begrenzt: Namen und Alter wirken nicht auf die Tagesgleichungen; Organisation bleibt konstant. Optional ergänzte Fachzähler, Lernpersistenz, Anpassung und Unterstützung sind synthetische Variablen. Bei aktiviertem Peer-Modell wirken gewichtete Vortagskontakte auf Stress, Motivation und Lernzeit. Die Anordnung des Graphen ist kein Klassenzimmerplan und kein Beleg echter Freundschaften.

## 5. Kontrollierter Vergleich als Kernmethode

Beide Bedingungen beginnen mit denselben Personen. Die täglichen Hintergrundzahlen werden passend verwendet. Der Unterschied Szenario minus Normalfall lässt sich deshalb innerhalb dieses Modells dem veränderten Ereignis zuordnen. Das ist stärker als der Vergleich zweier unabhängig zufällig erzeugter Gruppen, aber noch keine Aussage über reale Kausalität.

Für die technische Prüfung sind insbesondere nötig: gleiche Ergebnisse bei Intensität 0, Gleichheit vor dem Ereignis, Gleichheit nicht betroffener Personen und Übereinstimmung mit der alten Referenz in neutralen kompatiblen Einstellungen. Metadaten wie Klassen und Namen dürfen die Zahlenfolge der alten Initialisierung nicht verschieben.

## 6. Ein reproduzierbarer Auswertungsplan

1. Eine neutrale Schule mit dokumentiertem Schulseed aufbauen und als JSON sichern.
2. Dauer, Versuchsseed, Ereignisfenster, Zielklassen und Intensität festhalten.
3. Normalfall und Szenario rechnen; Schule und Versuchsparameter zusammen exportieren.
4. Am gleichen Tag Schulmittel, Klassendifferenzen, Histogramm und einzelne Profile auswerten.
5. Nur eine Annahme ändern, etwa die Organisationsverschiebung, und den Versuch ausdrücklich neu aufbauen.
6. Beobachtungen als Modellbefunde formulieren. Ohne tatsächlich gerechnete Daten werden hier keine Zahlenbeispiele als Resultat ausgegeben.

Ein anderer Seed untersucht eine andere künstliche Ausgangslage oder einen anderen Hintergrundverlauf. Das ist keine unabhängige Schulstudie. Wiederholbarkeit bedeutet, dass der Rechenweg nachvollziehbar ist; Gültigkeit bedeutet, dass Annahmen und Ergebnisse zur Wirklichkeit passen. Das eine ersetzt das andere nicht.

## 7. Kritische Analyse

Die Skalen und Koeffizienten sind nicht empirisch kalibriert. Eine maximal sechs Stunden große Lernzeitskala ist eine Programmgrenze und kein gesundheits- oder lernwissenschaftlicher Grenzwert. Die Begrenzung auf 0 bis 100 verhindert bestimmte numerische Ausreißer, bestätigt aber nicht die Qualität des Modells. Sättigung an Grenzen kann Unterschiede verdecken.

Die Bezeichnungen „Stresssensitivität“ und „Leistung“ könnten mehr wissenschaftliche Präzision suggerieren, als tatsächlich vorliegt. Deshalb werden sie ausdrücklich als hypothetische Modellgrößen erklärt. Die zusätzlichen Ereignisse dürfen nicht als Nachweis dafür verwendet werden, dass eine bestimmte Schulreform in Wirklichkeit hilft oder schadet.

Datenschutz ist nicht durch lokale Berechnung erledigt: Downloads können weitergegeben werden, lokale Daten verloren gehen und der Hoster verarbeitet Verbindungsdaten. Eine ausdrücklich ausgelöste KI-Anfrage überträgt zusätzlich Anfragetext oder ausgewählte aggregierte Kennzahlen. Ausschließlich fiktive Daten sind zulässig; die Anwendung hat keine Diagnosefunktion.

## 8. Quellen, KI und eigener Beitrag

Die Primärbelege für die Rechenregeln sind die tatsächlich vorliegenden Quellcodedateien; die Formeln und ihre Grenzen stehen in der Modellbeschreibung. Herstellerdokumentationen im Quellenregister belegen nur Bereitstellungswege. Sie dienen nicht als wissenschaftliche Quelle für Schülerverhalten.

Code, Oberfläche und Dokumentationsentwürfe wurden mit KI-Unterstützung erstellt. Es wird weder vollständige unabhängige Schülerautorenschaft noch eine Lehrpersonenfreigabe behauptet. Der Schüler muss tatsächliche eigene Beiträge, Verständnis, übernommene KI-Vorschläge, Kontrolle und erlaubte Nutzung transparent darlegen. Dafür sind eigene Beobachtungen und eine selbst formulierte Reflexion erforderlich; dieser Bericht schreibt keine persönlichen Gefühle oder Lernerlebnisse vor.

## 9. Prüfstand und Ausblick

Die technische Abnahme wird getrennt in FEATURE-STATUS.md und den tatsächlichen Integrationsbelegen dokumentiert. Hier werden keine Testzahlen, Laufzeiten oder Browserfreigaben vorweggenommen. Eine Hostinganleitung ist vorhanden; eine öffentliche Adresse gilt ohne geprüfte echte URL nicht als live.

Seit Modell 2.1-events sind zusätzlich bis zu vier weitere Ereignisse mit eigenen Stärken, Zeitfenstern und Zielklassen möglich. Direkte Ereignisterme werden vor einem einzigen Tagesschritt addiert, nicht als zusätzliche Tage nacheinander ausgeführt. Alle Ereignisse teilen den reservierten Ereigniszufallswert je Person/Tag; unabhängige Ereignisschwankungen werden nicht behauptet. Kanonische Sortierung schützt vor Reihenfolgeeffekten, identische Doppeleinträge werden abgewiesen. Vollständige Einzelereignishistorien werden gegen den bytegleich erhaltenen 2.0-Kern in single-event.js geprüft. Siehe [Kombinationsmodell](EVENT-PLAN.html).

Modell 2.2 ergänzt synchronisierte Vortagskontakte, veränderliche Gewichte, Fachzähler und Verhaltensrückkopplung. Drei neue definierte Ereignisse betreffen strukturierte Übungen, zusätzliche Lernkontrollen und längere Pausen. Textvorschläge benötigen eine menschliche Prüfung; optionale KI-Lesehilfen sind keine weiteren Rechenbefunde. Nicht implementiert sind Populationen über 300, echte Lehrpläne, neue frei generierte Gleichungen oder autonome LLM-Personen. Empirische Gültigkeit, tatsächliche Schulgeräte und menschliche Zugänglichkeitsprüfungen bleiben gesonderte Aufgaben.

## Nachweise und weiterführende Seiten

- [Bedienanleitung](teacher-guide.html)
- [Gleichungen und Modellgrenzen](model.html)
- [Präsentation](presentation-update.html)
- [Quellenregister mit genauer Verwendung](source-register.md)
- [Funktionsstatus und offene Prüfungen](FEATURE-STATUS.md)
- [Bereitstellung und Freigabe](DEPLOYMENT.md)