Воспроизводимые кампании

Рабочее пространство experiments/ хранит всё, что производит кампания, и всё, что нужно для её воспроизведения. Разделение строгое: рецепты отслеживаются, выходные данные локальны. Конфигурации кампаний и скрипты-исполнители живут в контроле версий; каждый тяжёлый вывод — сгенерированные бенчмарки, записи прогонов, логи, контрольные точки, пакеты доказательств и снимок окружения — остаётся на машине, которая его произвела, и регенерируется по требованию из рецепта.

🗂️ Компоновка

Выходные каталоги существуют локально и автоматически воссоздаются исполнителем кампании при отсутствии; ничто под ними никогда не индексируется для коммита.

🧱 Два слоя, один источник истины

1. Слой воспроизводимости (гранулярный). Каждый прогон — это одна запись JSON в results/{campaign_id}/{solver_id}/{benchmark_id}/run_{idx}.json. Сам путь — индекс: кампания, затем решатель, затем бенчмарк, затем повтор — так что любой срез доказательств адресуем без базы данных. Записи несут первоклассные поля времени, сходимости, решения и усилия решателя; ничто аналитическое не прячется в свободных заметках.
2. Слой курирования (по уровням). evidence-bundles/{campaign_id}-{tier}/ хранит разбитые по уровням раскрытия экспорты, производные от записей прогонов. Идентификаторы уровней происходят из фиксированного безопасного для публики словаря — core, speed, quality, platform — и пакет всегда производен от записей уровня прогонов, никогда не независимый источник истины.

🔁 Контракт воспроизводимости

• Каждая кампания объявляет одно мастер-зерно; зерно каждого прогона выводится детерминированно из него и позиции прогона — та же конфигурация, те же зёрна, те же записи, бит в бит.
• .checkpoints/{campaign_id}.json записывает хеш конфигурации. Неизменная конфигурация возобновляется с контрольной точки и пропускает завершённые прогоны; любое изменение конфигурации полностью делает контрольную точку недействительной.
• ENVIRONMENT.md снимает хост, операционную систему, Python и коммит репозитория во время выполнения, так что каждый результат прослеживается до точного кода и машины, которые его произвели.
• Логи — только-добавление на каждое выполнение.

Эти практики — зерно на прогон, захват конфигурации и окружения, чтобы результат можно было регенерировать из его рецепта — следуют признанным стандартам документирования и воспроизведения вычислительных экспериментов (ACM Artifact Review and Badging, Version 1.1, 2020; Gundersen & Kjensmo 2018).

Манифест воспроизводимости также обосновывает нижнюю границу в 30 прогонов производным утверждением о мощности: на этой границе, при двустороннем уровне 0,05 и мощности 0,80, парный дизайн обнаруживает стандартизованные эффекты около 0,523 или больше при приближении Уилкоксона с поправкой на ARE (Noether 1987; методология: Campelo and Takahashi 2019). Предложение пересчитывается из границы во время рендеринга, так что оно никогда не может разойтись с границей, которую обосновывает. Рядом с ним следуют два дополнительных дескриптора протокола: запись масштабирования бюджета, фиксирующая, как бюджет оценивания растёт с размером экземпляра (масштабируемый по размеру протокол Vallada, Ruiz and Framiñan 2015, записываемый манифестом честного сравнения лаборатории как масштабируемое по оцениванию правило или как фиксированное для кампании), и запись паритета настройки, несущая равный бюджет настройки на алгоритм, который объявляет каждая сравнительная кампания (LaTorre, Molina, Osaba, Poyatos, Del Ser and Herrera 2021); необъявленный паритет честно рендерится как необъявленный.

🏃 Как кампания записывает в рабочее пространство

1. Создайте или скорректируйте конфигурацию кампании под configs/ (smoke-pilot.json — отслеживаемая отправная точка).

2. Запустите её через исполнитель кампании — программно, как в учебных руководствах, через отслеживаемый скрипт-рецепт (uv run python experiments/scripts/run_smoke_pilot.py), или через интерфейс командной строки:

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

3. Исполнитель валидирует конфигурацию в детерминированный план, записывает results/{campaign_id}/plan.json и environment.json, затем сохраняет одну запись с хешем содержимого на каждый завершённый прогон плюс любые неудачные попытки.

4. Инспектируйте записи прогонов под results/ и возобновляйте, повторяйте или перезапускайте из той же конфигурации. Повторный запуск той же конфигурации воспроизводит те же записи бит в бит; изменённая конфигурация делает контрольную точку недействительной, а не переиспользует её молча.

Страница движка кампаний полностью документирует валидацию, бюджеты сухого прогона, режимы выполнения, повторы, возобновление и проверку повтором.

📦 От записей прогонов к пакетам доказательств

Путь экспорта превращает завершённый каталог кампании в курируемый пакет под 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 ведёт тот же путь на масштабе, строя каталоги бенчмарков, кампании, анализы и пакеты для каждого уровня из одной записанной конфигурации. Страница пакеты доказательств описывает уровни; экспорты анализа описывает статистическое содержимое.

🔒 Безопасная для публики граница

Публичные страницы никогда не читают это рабочее пространство напрямую: сайт документации и портал результатов потребляют только зафиксированные, отфильтрованные по раскрытию экспорты, произведённые из курируемого слоя. Частные программные журналы в рабочем пространстве игнорируются контролем версий и никогда не достигают публичной поверхности.