# Phase 6 — relabel API execution and wave scheduling ## Goal Execute Phase 5 batch artifacts against the configured LLM provider, schedule them in parallel waves against a shared pre-wave queue snapshot, and persist execution outcomes for later evaluation without applying names yet. ## Script `scripts/execute-relabel-batches.js` ## Shared terms - a **batch** is one model request containing one or more work items - a **wave** is a set of batches executed in parallel against the same queue snapshot and reconciled only after execution and retries for that wave finish ## Inputs - `runs//queue.sqlite` - Phase 5 batch-ready request artifacts - provider and model configuration - wave concurrency configuration - transport retry and rate-limit configuration ## Execution rules - Phase 6 owns outbound API execution; Phase 5 stops at persisted batch artifacts and queue state - execute batches in waves so all batches in one wave see the same pre-wave queue snapshot - restrict each wave to one model/config in MVP - support multiple concurrent batch requests within a wave, subject to configurable concurrency and provider rate limits - retries for transport or provider failures should occur before the wave is closed, within configured retry limits - transport and provider failures must be tracked separately from semantic naming failures ## Outputs - persisted wave execution metadata - persisted batch transport outcomes and retry records - `runs//batches//request.json` - `runs//batches//response.json` - updated artifact references in `runs//queue.sqlite` ## Verification - confirm waves execute batches in parallel against one pre-wave snapshot - confirm one wave uses one model/config in MVP - confirm request and response artifacts are persisted for each executed batch - confirm transport failures and semantic failures are recorded separately - confirm retry handling completes before wave reconciliation closes