Belegpakete

Ein Belegpaket ist ein selbstbeschreibendes Verzeichnis statistischer Tabellen, barrierefreier SVG-Abbildungen und einer Ergänzung ausgeschlossener oder zurückgehaltener Zeilen, alles aus einer abgeschlossenen Kampagne abgeleitet und auf eine Belegstufe gefiltert. DispatchAtlas organisiert exportierte Belege in diese gestuften Pakete, sodass jedes Paket nur die Daten offenlegt, die seine Belegstufe erlaubt.

🪜 Paketstufen

Die vier Stufen-Kennungen stammen aus einem festen, öffentlich-sicheren Vokabular. Jede Stufe ist eine ausführbare Offenlegungsrichtlinie, kein redaktionelles Label:

Jedes Paket wird aus demselben stufengefilterten Datensatz erzeugt wie seine Tabellen und Abbildungen, sodass ein Export niedrigerer Stufe keine Mechanismen höherer Stufe, Deployment-Aussagen oder zurückgehaltene Zeilen zutage fördern kann. Der Filter schlägt schließend fehl: statt zu lecken, löst ein Export, der einen Mechanismus späterer Stufe unter einer niedrigeren Stufe offenlegen würde, einen Fehler aus. Von einer Richtlinie verbotene Zeilen werden ausgeschlossen und mit der Begründung in ein ergänzendes Ausschlussmanifest geschrieben.

📁 Paketinhalt

Ein Paket enthält:

• statistische Tabellen (Solver-Zusammenfassungen, paarweise Vergleiche, Rangfolgen, Benchmark-Abdeckung, infeasible Zeilen),
• barrierefreie SVG-Abbildungen mit einem Abbildungsmanifest, das Rolle, Provenienz und Barrierefreiheitshinweis jeder Abbildung festhält,
• eine Ergänzung, die ausgeschlossene oder zurückgehaltene Zeilen und jede zu den Einschränkungen geroutete Methode festhält,
• bundle.json, das Manifest, das jede generierte Datei listet und die kanonische Manifest-Nutzlast hasht.

Siehe Analyse-Exporte für das vollständige Paketlayout und die statistischen Methoden hinter jeder Tabelle und Abbildung.

⚙️ Wie Pakete erzeugt werden

Eine Kampagne exportiert über den Export-Befehl ein Paket pro Stufe:

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

Das Paket landet in evidence-bundles/{campaign_id}-{tier}/ unter dem Ziel-Arbeitsbereich — der Kurationsschicht des Experimente-Arbeitsbereichs. Im großen Maßstab baut tools/build_campaign_evidence.py Kandidaten-Benchmark-Kataloge, führt die konfigurierten Kampagnen aus, führt die Analyse durch und schreibt die Pakete für jede Stufe plus einen Portal-Datensatz aus einer aufgezeichneten Konfiguration:

uv run python tools/build_campaign_evidence.py `
  --output-root .\experiments `
  --problem-count-per-profile 30 `
  --stochastic-seeds 10 `
  --campaign-suffix local

Der Builder gibt den Phasenfortschritt für Katalogmaterialisierung, Kampagnenplanung, Ausführung, Analyse, Paketexport und Berichtschreiben an stderr aus und schreibt generierte Belege absichtlich außerhalb der Git-verfolgten Quellbäume.

✅ Wie Pakete verifiziert werden

• Manifest-Hashing. bundle.json listet jede generierte Datei und hasht die kanonische Manifest-Nutzlast, sodass der Inhalt eines Pakets gegen sein eigenes Manifest prüfbar ist.
• Determinismus. Den gleichen Export gegen die gleichen Eingaben erneut auszuführen erzeugt die gleichen JSON-, Tabellen- und Abbildungs-Nutzlasten.
• Ableitung, keine Autorität. Ein Paket wird stets aus den Datensätzen auf Laufebene in der Reproduzierbarkeitsschicht abgeleitet — nie eine unabhängige Wahrheitsquelle — und diese Datensätze sind selbst inhaltsgehasht und über die Kampagnen-Engine per Replay verifizierbar.
• Gegatete Promotion. Pakete erreichen öffentliche Oberflächen nur durch die in Release-Bereitschaft beschriebenen Release- und Offenlegungstore.

Die Belegstufen bilden sich auf das Vokabular des ACM Artifact Review and Badging, Version 1.1 (2020), ab, gelesen neben der Stochastische-Optimierung-Anleitung von López-Ibáñez, Branke und Paquete (2021). Jedes Stufenpaket mit seinem inhaltsgehashten bundle.json und Abbildungsmanifest ist bereit für das Artifacts Evaluated — Functional-Abzeichen; ein über das öffentliche Portal publiziertes Paket ist bereit für Artifacts Available; ein Vollkampagnen-Paket, dessen Reproduzierbarkeitsmanifest die Seeds, die Umgebung, den Laufboden sowie die Budget- und Tuning-Parität festnagelt, ist bereit für Results Reproduced. Results Replicated verlangt eine unabhängige Implementierung, allein aus den schriftlichen Methodenbeschreibungen erstellt, die keine Plattform über sich selbst gewähren kann — hier festgehalten, damit die Abbildung ehrlich bleibt.

🌐 Was das Portal konsumiert

Das Ergebnisportal konsumiert den Portal-Datensatz, den derselbe Exportpfad erzeugt (portal-results.json plus einen CSV-Index) — durchsuchbare Tags, Offenlegungslabels, Zielwerte, Lauf-ids und hash-verknüpfte Kampagnen-Metadaten — von tools/build_site_assets.py in statische Website-Assets gerendert. Das Portal liest nie den Experimente-Arbeitsbereich und führt keine Kampagnen aus; es präsentiert nur committete, nach Offenlegung gefilterte Exporte.