Ziel
Frühwarnindikatoren und Systemreaktionen nachvollziehbar untersuchen, ohne jede Analysepipeline von Grund auf neu programmieren zu müssen.

Research software · Open science
Vom reproduzierbaren Analysewerkzeug zur integrierten ECHO-Forschungsumgebung für die Frage, wann komplexe Systeme ihre Fähigkeit zur Selbstkorrektur verlieren.
01 / Jetzt verfügbar
BenchEWS Studio 1.4.0 bündelt Analyse, Parametrisierung und Ergebnisdarstellung in einer grafischen Forschungsumgebung. Die veröffentlichte Zenodo-Fassung enthält Software und Dokumentation; für macOS ist ein installierbares DMG-Paket abrufbar.
Frühwarnindikatoren und Systemreaktionen nachvollziehbar untersuchen, ohne jede Analysepipeline von Grund auf neu programmieren zu müssen.
Ein strukturierter Einstieg in reproduzierbare Experimente, vergleichbare Auswertungen und dokumentierte Forschungsabläufe.
Zwölf funktionale Panels führen von System- und Datenwahl über Analyseparameter bis zu Diagnostik, Visualisierung und Export.
Die Software unterstützt Forschung und Exploration. Ihre Ergebnisse sind indikativ und ersetzen weder domänenspezifische Validierung noch eine sichere Vorhersage von Kipppunkten.
02 / Plattform- und Versionsstatus
Die Bezeichnungen BenchEWS, ECHO und Studio stehen für unterschiedliche Ebenen: Forschungsprogramm, mathematische Architektur und konkrete Software-Implementierung.
| Ebene | Plattform / Stand | Status | Geltungsgrenze |
|---|---|---|---|
| BenchEWS Studio 1.4.0 | macOS auf Apple Silicon (arm64) | VERÖFFENTLICHT | Vom Projektinhaber auf realer Hardware geprüft; keine unabhängige Reproduktion behauptet. |
| Studio 1.4.0 | Windows / Linux | NICHT FREIGEGEBEN | Kein offizielles Paket und kein hardwarevalidierter Plattformstand dieser Version. |
| ECHO Architecture 2.0 | Spezifikation / Entwicklung | IN ENTWICKLUNG | Architekturziel, kein bereits universell validiertes Messinstrument. |
| Studio 3.0 | Forschungsausblick | VORGESCHLAGEN | Keine implementierte oder terminierte Produktversion. |
Echte Ansichten der laufenden Version 1.4.0, entnommen aus dem BenchEWS Studio User Manual Rev. 3. Die Screenshots dokumentieren die Oberfläche; sie sind keine Simulation und kein Design-Mock-up.




03 / Leistungsumfang
BenchEWS Studio verhält sich wie ein wissenschaftliches Instrument: Es verbindet Konfiguration, Ausführung, Ergebnis und Provenienz, statt diese über Skripte, Tabellen und Notebooks zu verstreuen.
Eine Forschungsfrage wird als Objekt angelegt und mit Konfigurationen und Läufen verbunden.
Beobachtungsdaten und Indikatoren werden explizit festgelegt.
Interne Regeln prüfen, ob eine Konfiguration ausgeführt werden darf.
Der Lauf berechnet populationsbezogene Varianz und Lag-1-Autokorrelation.
Ergebnisse, Parameter und Zustandsfolge bleiben nachvollziehbar.
Die wissenschaftliche Deutung bleibt bewusst beim Forschenden.
Ein prüfbares Knowledge Package kann erzeugt und für Zenodo vorbereitet werden.
Die veröffentlichte Fassung berechnet populationsbezogene Varianz und Lag-1-Autokorrelation für univariate Beobachtungszeitreihen. Beide Module tragen den transparenten Status Experimental, weil Messunsicherheit und Kalibrierung noch nicht implementiert sind.
Abgrenzung zu CRTI: CRTI gehört zum wissenschaftlichen BenchEWS-Forschungsprogramm und ist Gegenstand eines revidierten, derzeit bei AIP Advances geprüften Manuskripts. Im veröffentlichten Frozen Kernel von Studio 1.4.0 ist CRTI noch nicht als ausführbares Indikatormodul integriert. Die spätere Softwareintegration wird getrennt als Implementierung, Rechenverifikation und empirische Validierung ausgewiesen.
Eine fest eingebaute synthetische 20-Punkte-Reihe muss 0,8310 für die Varianz und 0,7753 für die Lag-1-Autokorrelation reproduzieren. Damit wird der Kernlauf zu einem konkreten, falsifizierbaren Funktionstest.
Ein deterministischer Zehn-Zustände-Workflow mit Guard-Bedingungen verhindert etwa Ausführung vor Validierung oder Publikation vor Abschluss. Jeder Übergang wird mit Zeit und auslösender Aktion in einem append-only Audit Trail festgehalten.
Eine SQLite-Registry und ein inhaltsadressierter, SHA-256-geprüfter Dateispeicher halten Objekte, Läufe und Artefakte zusammen. Änderungen an gespeicherten Artefakten werden dadurch technisch erkennbar.
04 / Reproduzierbarer Export
Das zentrale Exportobjekt ist ein Knowledge Package im interoperablen RO-Crate-Format. Es bündelt Lauf, Konfiguration, Ergebnisse und maschinenlesbare Provenienz in einem selbstständigen, SHA-256-geprüften Forschungsartefakt.
05 / Oberfläche
Die Oberfläche folgt dem Forschungsprozess und öffnet niemals als leerer Arbeitsraum.
Gemeinsame Sollwerte ausführen und Installation prüfen
Frage, Projektzusammenhang, Daten und Indikatoren festlegen
Zulässigkeit prüfen, Lauf ausführen und Ergebnis kontrollieren
Ergebnisse dokumentieren, ohne automatisches wissenschaftliches Urteil
Knowledge Packages publizieren und Vorarbeiten wiederverwenden
Gespeicherte Objekte und registrierte Module mit Status einsehen
Implementierungsgrenze: Die Version 1.4.0 erzeugt keine Schätzung der Self-Correction Capacity, keine Messunsicherheit und keine automatische wissenschaftliche Interpretation. Diese klare Begrenzung ist Teil des Instrumentenkonzepts.
06 / Geprüfter Entwicklungsstand · Recovery-Baseline 19. August 2026
Version 2.0 entwickelt Studio von einer Analyseoberfläche zu einer nachvollziehbaren Forschungsarchitektur weiter. Die folgende Bestandsaufnahme beruht auf der geprüften Post-WP13-/WP14-Recovery-Baseline. Sie beschreibt einen Entwicklungsstand, keine freigegebene Veröffentlichung und keine architekturweite wissenschaftliche Validierung.
Ein deterministischer, sequenzieller und zyklenfreier DAG-Prozesskern orchestriert abhängige Arbeitsschritte. Ausführung und Objektlebenszyklus bleiben getrennte Zustandsräume.
Append-only Ereignisprotokoll, kanonische Inhaltsidentität und getrennte Ausführungsidentität machen sichtbar, welche Fassung, Eingabe und Prozessausführung ein Ergebnis erzeugt haben.
Deterministische Projektarchive, sichere Round-Trips und die Rekonstruktion von Referenzen aus 1.4.0 sind im unabhängigen Kern geprüft; abhängige Vollintegrationen sind teilweise noch nicht laufzeitgeprüft.
Hypothesen, Evidenz, Anhänge, Gegenbelege, Evaluation und Missingness besitzen getrennte Objekte. Widersprüchliche Evidenz muss sichtbar bleiben; automatische wissenschaftliche Bewertung wird nicht behauptet.
Die geprüfte Registry enthält derzeit drei ausführbare wissenschaftliche Module. „Experimental“ bezeichnet ihren Reifegrad, nicht ihre mathematische Existenz oder Softwareausführbarkeit.
| Modul | Softwarestatus | Wissenschaftlicher Status | Belegte Grenze |
|---|---|---|---|
| Varianz | AUSFÜHRBAR | Experimental | Frozen Legacy Kernel; keine quantifizierte Messunsicherheit oder universelle EWS-Validität. |
| Lag-1-Autokorrelation | AUSFÜHRBAR | Experimental | Frozen Legacy Kernel; keine quantifizierte Messunsicherheit oder universelle EWS-Validität. |
| Skewness | AUSFÜHRBAR | Experimental | Adjustierter Fisher-Pearson-Koeffizient; unabhängig handgerechneter Referenzfall, aber keine universelle Richtungsdeutung. |
| CRTI | NICHT INTEGRIERT | Mathematisch beschrieben / Manuskript unter Prüfung | Noch kein ausführbares 2.0-Modul in der geprüften Baseline; Implementierung und Validierung bleiben getrennte nächste Schritte. |
| Weitere 19 EWS-Kandidaten | NICHT BELEGT | Erst nach Registry- und Quellprüfung auszuweisen | Keine öffentliche Integrationsbehauptung, bevor Namen, Formeln, Bindings, Tests und Status im Quellstand nachgewiesen sind. |
Neue Module registrieren Berechnung, Metadaten und Visualisierung über einen generischen Binding-Vertrag, ohne die gemeinsame Dispatch-Tabelle oder den Frozen Kernel zu verändern.
Version, mathematische Definition, Messgröße, Eingaben, Ausgaben, Provenienz, Unsicherheit und Validierungsnachweis werden pro Modul als strukturierte Metadaten geführt.
Drei Vergleichsfälle prüfen Wrapper-Fidelität, Archiv-Round-Trip und reale Process-Engine-zu-KernelService-Anbindung; ein Live-Vergleich mit dem abhängigen Legacy-Engine-Pfad bleibt offen.
Die 1.4.0-Oberflächenstruktur bleibt erhalten. Neue Informationsdialoge und eine additive Verifikationsaktion erweitern sie, ohne einen dreizehnten Workflow-Bereich einzuführen.
Technik, Ökologie/Klima, Ökonomie, Finanzmärkte, Gesellschaft, Wissenschaft/Forschung und Individuum sind beschrieben. Sechs besitzen noch keine domänenspezifischen Adapter oder Schwellen; „Individuum“ bleibt ausdrücklich eingeschränkt.
D → FCQ → RF(T) → TR → V ↺, Observer-/Goodhart-Kontext, aktive Messung, Viabilität und Epistemic Silence sind wissenschaftliche Architekturbausteine, noch keine ausführbaren Diagnosealgorithmen.
Release-Gate: Erst ein neuer, eindeutig versionierter Quellstand darf diese Liste erweitern. Für jeden weiteren Indikator werden Name, Formel, Inputs, Output, Binding, Rechenverifikation, Unsicherheit, Gültigkeitsbereich und Evidenzquelle einzeln nachgewiesen. Die Zahl der Module ist kein Qualitätsmaß; entscheidend sind Statusklarheit und Falsifizierbarkeit.
07 / Forschungsausblick
Als längerfristige Entwicklungsrichtung soll Version 3.0 die Architektur für kontinuierlichere Datenströme, erweiterbare Mehrdomänenmodelle und vergleichende Szenarien öffnen.
Transparenter Status: Version 3.0 ist ein Forschungs- und Entwicklungsziel, kein bereits implementiertes Produkt und noch kein verbindlich terminiertes Release.
08 / Identität
Dipl.-Ing. Bernd von Mallinckrodt · unabhängiges Forschungsprogramm
Primärquellen / Further reading
Versionierte Primärquellen aus dem BenchEWS-Forschungsprogramm – ausgewählt für den Gegenstand dieses Kapitels.
Softwarepaket, Manual und Scientific Release Companion der veröffentlichten Fassung.
10.5281/zenodo.21807143↗ECHO specificationSemantische und metrologische Referenz für die Weiterentwicklung zu Studio 2.0.
10.5281/zenodo.21917450↗Programme architectureEinordnung der Software in das gesamte offene Forschungsprogramm.
10.5281/zenodo.21398929↗Benchmark foundationWissenschaftliche Grundlage der vergleichenden Benchmark-Infrastruktur.
10.5281/zenodo.21207501↗