Reproduzierbare Kampagnen

Der experiments/-Arbeitsbereich enthält alles, was eine Kampagne erzeugt, und alles, was zur Reproduktion nötig ist. Die Trennung ist strikt: Rezepte werden verfolgt, Ausgaben sind lokal. Kampagnenkonfigurationen und Runner-Skripte leben in der Versionskontrolle; jede schwere Ausgabe — generierte Benchmarks, Laufdatensätze, Logs, Prüfpunkte, Belegpakete und der Umgebungs-Schnappschuss — bleibt auf der Maschine, die sie erzeugt hat, und wird bei Bedarf aus dem Rezept neu erzeugt.

🗂️ Layout

Ausgabeverzeichnisse existieren lokal und werden vom Kampagnen-Runner automatisch neu erstellt, wenn sie fehlen; nichts unter ihnen wird je zur Übernahme bereit gestellt.

🧱 Zwei Schichten, eine Wahrheitsquelle

1. Reproduzierbarkeitsschicht (granular). Jeder Lauf ist ein JSON-Datensatz unter results/{campaign_id}/{solver_id}/{benchmark_id}/run_{idx}.json. Der Pfad selbst ist der Index — Kampagne, dann Solver, dann Benchmark, dann Replikat — so ist jeder Ausschnitt der Belege ohne Datenbank adressierbar. Datensätze tragen erstklassige Felder für Timing, Konvergenz, Lösung und Solver-Aufwand; nichts Analytisches versteckt sich in freiformigen Notizen.
2. Kurationsschicht (gestuft). evidence-bundles/{campaign_id}-{tier}/ enthält die offenlegungsgestuften Exporte, die aus den Laufdatensätzen abgeleitet sind. Die Stufen-Kennungen stammen aus dem festen, öffentlich-sicheren Vokabular — core, speed, quality, platform — und ein Paket wird stets aus den Datensätzen auf Laufebene abgeleitet, nie eine unabhängige Wahrheitsquelle.

🔁 Reproduzierbarkeitsvertrag

• Jede Kampagne deklariert einen Root-Seed; der Seed jedes Laufs leitet sich deterministisch aus ihm und der Position des Laufs ab — gleiche Konfiguration, gleiche Seeds, gleiche Datensätze, Bit für Bit.
• .checkpoints/{campaign_id}.json erfasst den Konfigurations-Hash. Eine unveränderte Konfiguration setzt vom Prüfpunkt fort und überspringt abgeschlossene Läufe; jede Konfigurationsänderung macht den Prüfpunkt vollständig ungültig.
• ENVIRONMENT.md schnappschießt Host, Betriebssystem, Python und den Repository-Commit zur Ausführungszeit, sodass jedes Ergebnis zum exakten Code und zur Maschine, die es erzeugt haben, rückverfolgbar ist.
• Logs sind je Ausführung nur-anhängend.

Diese Praktiken — Seed pro Lauf, Erfassung von Konfiguration und Umgebung, damit ein Ergebnis aus seinem Rezept neu erzeugt werden kann — folgen anerkannten Standards zur Dokumentation und Reproduktion rechnerischer Experimente (ACM Artifact Review and Badging, Version 1.1, 2020; Gundersen & Kjensmo 2018).

Das Reproduzierbarkeitsmanifest rechtfertigt den 30-Läufe-Boden zudem mit einer abgeleiteten Aussage zur Teststärke: am Boden, bei einem zweiseitigen 0,05-Niveau und 0,80 Teststärke, detektiert das gepaarte Design standardisierte Effekte von etwa 0,523 oder größer unter der ARE-angepassten Wilcoxon-Approximation (Noether 1987; Rahmenwerk: Campelo und Takahashi 2019). Der Satz wird zur Renderzeit aus dem Boden neu berechnet, sodass er nie vom Boden abdriften kann, den er rechtfertigt. Zwei weitere Protokolldeskriptoren reisen daneben: ein Budget-Skalierungseintrag, der aufzeichnet, wie das Auswertungsbudget mit der Instanzgröße wächst (das größenskalierte Protokoll von Vallada, Ruiz und Framiñan 2015, vom Fair-Comparison-Manifest des Labors als auswertungsskalierte Regel oder als kampagnenfest aufgezeichnet), und ein Tuning-Paritäts-Eintrag, der das gleiche Tuning-Budget je Algorithmus trägt, das jede vergleichende Kampagne deklariert (LaTorre, Molina, Osaba, Poyatos, Del Ser und Herrera 2021); eine undeklarierte Parität rendert ehrlich als undeklariert.

🏃 Wie eine Kampagne in den Arbeitsbereich schreibt

1. Erstelle oder passe eine Kampagnenkonfiguration unter configs/ an (smoke-pilot.json ist der verfolgte Ausgangspunkt).

2. Führe sie über den Kampagnen-Runner aus — programmatisch wie in den Tutorials, über ein verfolgtes Rezept-Skript (uv run python experiments/scripts/run_smoke_pilot.py), oder über die Befehlszeilenschnittstelle:

   uv run dispatchatlas-lab run --config experiments/configs/smoke-pilot.json

3. Der Runner validiert die Konfiguration zu einem deterministischen Plan, schreibt results/{campaign_id}/plan.json und environment.json, dann persistiert er einen inhaltsgehashten Datensatz pro abgeschlossenem Lauf plus etwaige fehlgeschlagene Versuche.

4. Inspiziere die Laufdatensätze unter results/ und setze fort, spiele wieder ab oder führe aus derselben Konfiguration erneut aus. Die gleiche Konfiguration erneut auszuführen reproduziert die gleichen Datensätze Bit für Bit; eine geänderte Konfiguration macht den Prüfpunkt ungültig, statt ihn still wiederzuverwenden.

Die Seite der Kampagnen-Engine dokumentiert Validierung, Trockenlauf-Budgets, Ausführungsmodi, Wiederholungen, Fortsetzung und Replay-Verifikation vollständig.

📦 Von Laufdatensätzen zu Belegpaketen

Der Exportpfad verwandelt ein abgeschlossenes Kampagnenverzeichnis in ein kuratiertes Paket unter evidence-bundles/{campaign_id}-{tier}/:

uv run dispatchatlas export `
  --campaign-dir .\experiments\results\smoke-pilot `
  --target-dir .\experiments `
  --authorized-output-root .\experiments `
  --tier core

tools/build_campaign_evidence.py treibt denselben Pfad im großen Maßstab und baut Benchmark-Kataloge, Kampagnen, Analysen und Pakete für jede Stufe aus einer aufgezeichneten Konfiguration. Die Seite Belegpakete beschreibt die Stufen; Analyse-Exporte beschreibt den statistischen Inhalt.

🔒 Öffentlich-sichere Grenze

Öffentliche Seiten lesen diesen Arbeitsbereich nie direkt: die Dokumentations-Website und das Ergebnisportal konsumieren nur committete, nach Offenlegung gefilterte Exporte, die aus der kuratierten Schicht erzeugt wurden. Private Programmaufzeichnungen im Arbeitsbereich werden von der Versionskontrolle ignoriert und erreichen nie eine öffentliche Oberfläche.