What is the campaign table of contents?

It is the list of every section the campaign page is showing right now, in the order it appears: the outcome card, the INSTRUCTION.md, the agent activity, the trials, the selected task's trace and its folds, the workload and reproducibility analyses, and the campaign data exports. Click a row and the page scrolls to that section, opening it if it was folded.

The list follows the page. A section that is not rendered for this campaign, a trace before a task is selected, results before a run has ended, is not listed, so the rows are also a summary of what this campaign has produced so far.

What is your campaign prompt?

It is the INSTRUCTION.md you write, the sentence the whole system is built to act on. A campaign turns it into an evaluation that did not exist before: a pack of tasks, each one an environment the agent works in, an instruction it must follow, and a verifier that decides whether an attempt earned its reward. The setter policy reads this prompt and authors those tasks iteration by iteration; the solver policy is then measured against them.

What comes back is a solve rate per task, measured over independent attempts. Tasks the solver always passes teach nothing, tasks it never passes teach nothing, and the band between them is the frontier, the training signal that is hard to obtain any other way.

The clearest INSTRUCTION.md inputs describe the kind of work, what a good task looks like, what the agent must produce, and how success should be judged. The task pack and its solve rates are the asset the campaign produces.

What is your campaign history?

It is every campaign this account has launched, newest first, and each row is one complete self-play loop: a prompt, the task pack the setter authored from it, and the solve rates the solver was measured at. The row shows the goal, the status (building, completed, failed, or stopped), the accepted-over-generated progress, and when it last changed.

Selecting a row opens that campaign's summary, its task history, and the evidence behind every task. Fork on a row submits the same prompt as a fresh campaign with a clean evaluation, which is how a prompt that worked is run again or refined. Campaigns are independent of one another, so nothing in one loop leaks into the statistics of the next.

What are the example campaigns?

They are campaigns Vmax ran and certified, listed for every account to read. Each one is a real finished loop with its task pack, its trials, and its environment files, so the whole product can be understood from a result before anything is spent on a run of your own.

They are read only: there is no Stop, and the settings panel shows the request they were launched with but cannot change it. Fork is live, and it opens the composer with the example's prompt, which is the shortest path to a first campaign that is known to work.

What is the campaign agent activity?

It is the audit trail of the run, and it is what makes every number on this page defensible. Each row is one event the campaign agent recorded while it ran the loop: building the task setting from the prompt, launching setter trials to author tasks, validating them, dispatching solver rollouts into sandboxes, and folding verifier scores back into the evaluation. Oldest first, most recent last.

When a solve rate needs explaining, this log is the explanation, step by step. When a run fails, the error row is the worker's own account of the fault, which is where a diagnosis starts.

What is your campaign summary?

It is the evaluation in four numbers. Generated tasks is how many evaluation items the setter authored across every iteration. Measured tasks is the subset the verifier scored; anything the validator rejected never became an item and is not counted. Solver rollouts is the total number of scored attempts, the sample size behind every rate shown.

Solve rate is the fraction of those attempts that passed. Near one, the pack is too easy to learn from; near zero, too hard. The band between is the frontier, the place where a training signal exists, and finding it automatically is the point of self-play.

A spinner marks a statistic still accumulating from the trial stream, so an incomplete number is shown as incomplete.

What is your campaign task history?

It is one card per evaluation item in the selected campaign. A task is three things at once: the instruction the agent reads, the environment it works in, and the verifier that decides its reward. The setter authored it, the validator accepted it, and the solver was measured on it.

Every campaign is an independent self-play loop, so a task belongs to exactly one campaign and this list shows the selected campaign only. The campaign list on the left switches campaigns, and the Atlas gathers every task across all of them.

Each card shows the task id, the setter iteration that produced it, why the validator accepted or rejected it, and the solver's success ratio over its scored rollouts. Selecting a card opens the evidence in the content well: the instruction, the environment files, and every trial with its command log.

What is this task's evidence?

It is the record behind one evaluation item, the point where the system stops being a claim. A task has three parts worth understanding: the instruction the agent is given, the verifier that decides its reward, and the environment it was built in, meaning the image, the files, and the dependencies the agent could reach. All three are on this page.

Around the task run several trials, and the tabs organise them. The setter trial authored the task. The validator checked it against the campaign's acceptance criteria before it counted. The solver trials are the independent attempts that are scored, each one a sample of the solve rate. When the campaign uses one, an LLM judge reads the attempt as part of the reward.

The tab counts are the trials recorded so far; a running campaign fills them in as the stream lands, so setter evidence can exist before any solver rollout does. Every step is toned by its outcome.

What is the task instruction?

It is the INSTRUCTION.md the setter generates for Vmax's system, the exact text the agent is handed, and the most important artefact on the page. The campaign prompt described the kind of task wanted; the setter turned that into this one concrete problem statement, and every solver rollout below is an independent attempt at exactly these words. The verifier grades against this instruction and nothing else.

That is why it sits above the trials rather than inside them. An ambiguous instruction cannot be rescued by solver capability, and a sharp one makes every number beneath it meaningful. The export controls beside it hand over the whole task in Markdown, JSON, or CSV.

What are the task files?

They are the environment, and they carry as much weight as the instruction. A task is not only a question; it is a place the agent works. The runtime image fixes the operating system and the interpreter, these files fix what is on disk, and the dependencies declared in them fix what the agent can import or call. Together they are the third part of a task, beside the instruction and the verifier.

The verifier script is among them, so this fold is also where reward is decided in plain sight: what is checked, what counts as a pass, and what prints to stdout and stderr on failure. The solver cannot see the verifier; a reader can, and that asymmetry is what keeps the evaluation honest.

What is the stored evidence?

It is the terminal record of this task's trials, read back from Campaign's own database rather than from the live stream: for the setter trial that authored the task and the evaluation trial that measured it, every stored descendant, each with its agent trajectory turn by turn, its events, its command log, and the files it produced. It is the deepest record the product keeps, and it is what an auditor would ask for.

Every read is checked against the stored length and digest, and a record that fails that check is refused whole rather than shown in part, so anything on this fold is exactly what the worker wrote. The trajectory is shown as the JSON the worker stored, and each trial's trajectory, events, and logs download as their own files. A file listed without its body is fetched on request, so a large or binary artefact costs nothing until it is wanted.

What is the campaign data?

It is everything the Campaign API answered for this campaign, as files: the immutable record, the compact task rows with both trial ids, every worker event with its whole payload, the trial snapshots and the log rows this page retained, and the inventory of stored evidence once the run has ended. The page draws a projection of those answers; the files are the answers themselves.

They exist so nothing the API provides is locked inside this interface. A payload the activity log shortens, a log row past the retained window, a field no surface draws: all of it is in these files, in the shape the API sent it, ready for a notebook or a second opinion.

What is the certified task pack?

It is the task setting the campaign agent built from your INSTRUCTION.md and then proved in the certification trial before any iteration was paid for: the code the setter runs inside, the environment it builds tasks in, and the verifier contract, stored with the digest the record names as its SHA-256. Every task in this campaign came out of it.

The files are read back from stored evidence, so they are the pack as certified, not a draft. When a task pack reads wrong, this is where the translation from your brief to executable code can be checked. A pack that certified is also the one thing a new campaign can restart from without authoring again.

What are the setter and solver trials?

A single task is produced and measured by several trials, and the distinction matters. The setter trial authored the task: it read the prompt, wrote the instruction, built the environment, and shipped a verifier. The validator trial checked that task against the campaign's acceptance criteria, so a task whose verifier passes an empty answer never became an evaluation item. The solver trials are the attempts that are scored, each an independent rollout whose pass or fail is one sample of the solve rate. When the campaign calls for it, an LLM judge reads the attempt and contributes to the reward, which is how properties a script cannot check are graded.

These tabs switch between the setter's record and the solver's record for this task. The setter shows how the task came to exist; the solver shows how it was met. Both are timelines of commands with their outcomes, and both are exportable.

What are campaign trials?

They are the trials of this campaign that no task owns: the certification trial that proved the task pack before any task was authored, a setter trial whose task has not landed yet, and any trial the stream carried whose parent is unknown. A task's own setter and solver trials are not here; they live in that task's trace, under the task card that names them.

While a campaign builds and no task exists yet, this is the only evidence the trial stream has produced, so it is the place to watch. Each rollout is the same timeline of commands with their outcomes as a task rollout, and each trial moves out of this list the moment a task claims it as its evaluation root.

What is the campaign INSTRUCTION.md?

It is the brief the setter was given, exactly as it was submitted in the composer, and it is the one input a campaign has: the domain, what a good task looks like, the deliverable a solver must produce, how it is verified, and what to reject. Every task in this campaign descends from it, so when a task pack reads wrong, this is the first place to look.

It is not the same file as a task's instruction. This is the campaign-level INSTRUCTION.md you wrote; each task the setter authors carries its own instruction.md, the problem statement a solver reads, shown in that task's trace. A campaign is immutable, so this text cannot be edited here. Fork reopens the composer with it and the same settings, which is how a sharper brief becomes the next campaign.

What is the task matrix?

Each row is a campaign and each column is a setter iteration, the generation round that produced the task. A cell counts the tasks that campaign generated in that iteration and is shaded by their solve rate, so a dark cell is a batch the solver mostly failed and a pale one a batch it mostly passed; an empty cell means no task landed in that round.

Read a row left to right to watch a campaign's difficulty move as self-play iterates, and read a column to compare campaigns at the same round. Iteration is a generation-context input, not an execution barrier, so the columns are a timeline of authorship, not of running. Click a cell to open its tasks.

What is the workload analysis?

It is how the difficulty of the generated tasks moved across the campaign's iterations, which is the clearest picture of whether self-play did its job. Each setter round conditions on the solve rates the previous round measured, so a working campaign shifts task mass out of the always-pass and never-pass bands and into the frontier between them.

The analysis is read from the measured tasks only. A task the validator rejected never had solver rollouts, so it cannot contribute a solve rate and is not part of the workload; the campaign summary counts those separately. What remains is the evaluation the campaign actually produced, described by where its difficulty landed.

What is the generated task difficulty mix?

It is one bar that sorts every measured task by how the solver fared on it. A task the solver passed on every rollout is too easy to learn from; a task it never passed is too hard; a task it passed on some rollouts and failed on others sits in the frontier band, and that band is the training signal the campaign exists to find.

The bar normalises the three counts into shares of one hundred percent, so campaigns of different sizes compare directly. A bar that is almost entirely one colour is a finding in itself: uniformly easy means the prompt set the bar too low, uniformly hard means the solver is not yet capable of the domain, and a wide middle band means the setter found the solver's edge.

What is reproducibility?

It is the record needed to run this campaign again and expect the same workload: the trial settings the request was launched with, exactly as the worker read them, and the campaign agent's activity log, every event in the order it happened. An evaluation that cannot be reproduced is an anecdote, and these two folds are what make this one a result.

The trial configuration table is the settings panel as it stood at submission, including the setter and solver budgets and the runtime image every task environment was built on. The activity log is the same audit trail the build console shows while a campaign runs, kept here so the finished result carries its own provenance. Fork reuses the same prompt; the table is where the matching settings are read.

What is the trial configuration?

It is the request this campaign was launched with, read back from the campaign record rather than from the settings panel, so it is what the worker actually ran and not what a form remembers. A campaign is immutable once created, which is why these values can be trusted as the provenance of every number above them.

The rows cover the method and the sandbox the deployment provides, the runtime image every task environment was built on, whether a sandbox could reach the network, the size of the pack, the setter rounds that produced it, the attempts scored per task, how many sandboxes ran at once, and the compute timeout that bounded the run. For the setter and the solver it lists the CPUs, the memory, and the sampling temperature, the three budgets that most change what a task looks like and how an attempt behaves. The full set of per-agent limits is in the settings panel for this campaign.

The export beside the heading hands the table over as Markdown, JSON, or CSV, and Fork submits the same prompt again with these same settings, which is the shortest path to a second run that is comparable to this one.

What does a complete campaign mean?

The self-play loop ran every iteration it was asked for and ended on its own, so this page is a finished evaluation rather than a snapshot of one. Every task below was authored by the setter, accepted by the validator, and scored over the number of solver rollouts requested, and nothing here is still moving.

The numbers are the asset. Where the solve rates landed says how hard the pack is for this solver, and the tasks the solver sometimes passed and sometimes failed are the frontier the campaign was launched to find. Fork submits the same INSTRUCTION.md as a fresh campaign, and a new INSTRUCTION.md input is how a pack that landed too easy or too hard is moved toward that band.

What is the task setting implementation?

It is the code the campaign agent wrote from your INSTRUCTION.md before any task existed: the task setting, a small package that tells the setter how to build a task, what an environment for it contains, and how a verifier decides a reward. The setter runs inside it on every iteration, so this is where your INSTRUCTION.md became executable.

The files are listed so the translation can be checked. If the campaign produces tasks that miss the point, the fault is usually visible here, in what the agent understood the domain and the bar to be, and a sharper INSTRUCTION.md is the fix.

What is a smoke trial?

It is the first pass through the task setting, run before the real loop starts: one setter attempt authors a single task, one solver rollout attempts it, and the verifier scores the result. Its purpose is to prove the pipeline end to end, not to measure anything.

A smoke task that fails stops the build before any iteration is paid for. A smoke task that passes is kept as evidence that the setting works, and the campaign then begins its iterations in earnest; it is not counted toward the evaluation.

Why did this campaign stop early?

A campaign runs its self-play loop on a worker outside this interface, inside a sandboxed compute environment. If that process exited, exceeded its compute timeout, or lost its sandbox, the campaign is recorded as failed, and everything gathered before that point, every rollout the verifier scored, is preserved.

There is deliberately no resume. A loop continued after a break would bias the solve rates it was measuring, and an honest partial evaluation is worth more than a biased complete one. Fork submits the same prompt as a fresh campaign with new identifiers and a clean evaluation, and the error row in the activity log names the fault.

Why was this campaign cancelled?

It was stopped on request. The worker cancelled the setter and solver trials that were still running, recorded any unfinished samples as unmeasured so they can never be mistaken for scored results, and kept every rollout the verifier had already graded.

A stopped loop is not resumed, for the same reason a failed one is not: continuing it would bias the statistics it was measuring. Fork submits the same prompt as a new campaign with a clean evaluation.

What are the campaign settings?

They are the run-level parameters, and they are also the design of the evaluation itself. The rows in green are the ones set on nearly every campaign: how large the task pack is, how many setter rounds produce it, how many attempts stand behind each solve rate, and how long the whole run may take before it is cut off. The rest describe the deployment and rarely move.

What are the setter settings?

They are the limits for the setter, the side of self-play that manufactures the evaluation. Each setter trial authors a task inside its own sandbox under these budgets, so they bound how much work a task, its environment, and its verifier may take to construct. The two in green are the ones that shape the pack: how long a trial may run, and how widely it samples.

What are the solver settings?

They are the limits for the solver, the side of self-play being evaluated, and they decide what the evaluation measures. Each solver rollout is one sandboxed attempt at a task under these budgets, scored by the verifier when it finishes or when the timeout expires. The two in green are the ones that change what a solve rate means: how long an attempt may take, and how stochastic it is.

What is the Atlas?

It is every task from every campaign in one place, for the questions that are rarely about one campaign. The API has no cross-campaign index, so this view reads one campaign at a time and merges what comes back, owned campaigns first and the read-only examples after.

List is the sortable record, one row per task, naming the campaign it belongs to. Atlas is the same set drawn as a map: one cell per task, grouped by campaign, shaded by how often the solver passed it. A pack that is uniformly easy or uniformly impossible reads at a glance.

Selecting a task opens its campaign and lands on that task's evidence, so the map is also the navigation. A task still belongs to exactly one campaign; this view only gathers them.

What is the Atlas summary?

It is the total across every campaign this account can read, the portfolio view rather than the selected campaign. Campaigns counts how many have been read so far, since each campaign's task list is a separate request and the API keeps no cross-campaign index.

Tasks is every generated evaluation item, Measured the subset the verifier scored, Rejected the ones the validator threw out, Solver rollouts the total scored attempts behind them, and Solve rate the fraction of those attempts that passed. Together they say how much evaluation exists and how hard it is. A task still belongs to exactly one campaign; this is only the sum.