Berichtsergänzung: Von der Gruppe zur Modellschule

Amasworld · Next Generation · 16. Oktober 2026 · 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

Die App nutzt klassische lokale JavaScript-Dateien und keine neuen Bibliotheken. Es gibt keinen LLM-Dienst und keine laufenden API-Gebühren. Diese Architektur ermöglicht eine statische, grundsätzlich offline nutzbare Anwendung. Ob alle Abläufe im konkreten Browser funktionieren, wird jedoch durch Ausführung und nicht durch diese Architekturübersicht belegt.

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 ist begrenzt: Namen und Alter wirken nicht auf die Tagesgleichungen. Organisation bleibt im aktuellen Modell konstant. Zwischen Personen gibt es keine sozialen Rückwirkungen. Eine Klasse ist zunächst eine Gruppierung und ein wählbares Ereignisziel, kein Beziehungsnetzwerk.

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 dadurch erledigt, dass die App ohne Backend läuft: Downloads können weitergegeben werden, lokale Daten können verloren gehen und ein öffentlicher Hoster verarbeitet Verbindungsdaten. Im normalen Betrieb werden ausschließlich fiktive Personen verwendet. Es gibt 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.

Zurückgestellt bleiben Beziehungen/soziale Graphen, LLM-Auswertung, natürlichsprachige Steuerung und Populationen über 300. Sie benötigen weitere synchronisierte Regeln und Kontrollprüfungen. Die neue Ereigniskombination bleibt ebenfalls hypothetisch und ist keine empirische Wechselwirkungsaussage.

Nachweise und weiterführende Seiten

• Bedienanleitung
• Gleichungen und Modellgrenzen
• Präsentation
• Quellenregister mit genauer Verwendung
• Funktionsstatus und offene Prüfungen
• Bereitstellung und Freigabe