Lots de preuves

Un lot de preuves est un répertoire auto-descriptif de tableaux statistiques, de figures SVG accessibles et d'un supplément de lignes exclues ou retenues, le tout dérivé d'une campagne terminée et filtré à un niveau de preuve. DispatchAtlas organise les preuves exportées en ces lots par niveaux afin que chaque lot n'expose que les données que son niveau de preuve permet.

🪜 Niveaux de lot

Les quatre identifiants de niveau proviennent d'un vocabulaire fixe sûr pour le public. Chaque niveau est une politique de divulgation exécutable, pas une étiquette éditoriale :

Chaque lot est généré à partir du même jeu de données filtré par niveau que ses tableaux et figures, donc un export de niveau inférieur ne peut pas faire apparaître des mécanismes de niveau supérieur, des affirmations de déploiement ou des lignes retenues. Le filtre échoue en position fermée : plutôt que de fuiter, un export qui exposerait un mécanisme de niveau ultérieur sous un niveau inférieur soulève une erreur. Les lignes qu'une politique interdit sont exclues et écrites dans un manifeste d'exclusions supplémentaire avec le motif.

📁 Contenu du lot

Un lot contient :

• des tableaux statistiques (résumés de solveurs, comparaisons par paires, classements, couverture de benchmarks, lignes infaisables),
• des figures SVG accessibles avec un manifeste de figures enregistrant le rôle, la provenance et la note d'accessibilité de chaque figure,
• un supplément qui enregistre les lignes exclues ou retenues et toute méthode routée vers les limitations,
• bundle.json, le manifeste qui liste chaque fichier généré et hache la charge utile canonique du manifeste.

Voir exports d'analyse pour la disposition complète du lot et les méthodes statistiques derrière chaque tableau et figure.

⚙️ Comment les lots sont produits

Une campagne exporte vers un lot par niveau via la commande d'export :

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

Le lot atterrit dans evidence-bundles/{campaign_id}-{tier}/ sous l'espace de travail cible — la couche de curation de l' espace de travail des expériences. À grande échelle, tools/build_campaign_evidence.py construit des catalogues de benchmarks candidats, exécute les campagnes configurées, effectue l'analyse et écrit les lots pour chaque niveau plus un jeu de données du portail à partir d'une configuration enregistrée :

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

Le constructeur émet la progression des phases vers stderr pour la matérialisation du catalogue, la planification de la campagne, l'exécution, l'analyse, l'export du lot et l'écriture du rapport, et écrit intentionnellement les preuves générées hors des arborescences de source suivies par Git.

✅ Comment les lots sont vérifiés

• Hachage du manifeste. bundle.json liste chaque fichier généré et hache la charge utile canonique du manifeste, de sorte que le contenu d'un lot est vérifiable face à son propre manifeste.
• Déterminisme. Réexécuter le même export face aux mêmes entrées produit les mêmes charges utiles JSON, de tableau et de figure.
• Dérivation, pas autorité. Un lot est toujours dérivé des enregistrements au niveau exécution dans la couche de reproductibilité — jamais une source de vérité indépendante — et ces enregistrements sont eux-mêmes hachés par contenu et vérifiables par rejeu via le moteur de campagnes.
• Promotion sous porte. Les lots atteignent les surfaces publiques uniquement à travers les portes de version et de divulgation décrites dans préparation de version.

Les paliers de preuves se projettent sur le vocabulaire ACM Artifact Review and Badging, version 1.1 (2020), lu de concert avec les recommandations d'optimisation stochastique de López-Ibáñez, Branke et Paquete (2021). Tout lot de palier avec son bundle.json haché par contenu et son manifeste de figures est prêt pour le badge Artifacts Evaluated — Functional ; un lot publié via le portail public est prêt pour Artifacts Available ; un lot de campagne complète dont le manifeste de reproductibilité épingle les graines, l'environnement, le plancher d'exécutions et la parité de budget et de réglage est prêt pour Results Reproduced. Results Replicated exige une implémentation indépendante bâtie à partir des seules descriptions écrites de la méthode, ce qu'aucune plateforme ne peut s'accorder à elle-même — indiqué ici pour que la projection reste honnête.

🌐 Ce que le portail consomme

Le portail des résultats consomme le jeu de données du portail que la même voie d'export produit (portal-results.json plus un index CSV) — étiquettes cherchables, étiquettes de divulgation, valeurs d'objectif, ids d'exécution et métadonnées de campagne liées par hachage — rendus en actifs statiques du site par tools/build_site_assets.py. Le portail ne lit jamais l'espace de travail des expériences ni n'exécute de campagnes ; il présente uniquement des exports validés et filtrés par divulgation.