Create a run manifest¶

Create a run manifest that selects suites, a player roster, runtime capacity, and resume behaviour. Finish with a passing doctor report and generated experiment specifications.

Before you begin¶

You need:

• a checked installation and completed quickstart;
• each required player and provider;
• the manual profile and rule seed selected by each suite, compiled as described in Prepare manuals; and
• enough player processes and game rooms for the selected suite protocols.

List the available names before editing:

gptnt list suites
gptnt list players

list players prints player profiles and provider profiles in separate groups.

Copy the template¶

Run this command from the repository root:

cp runs/_template.yaml runs/my-run.yaml

Edit the copy. This complete manifest uses one custom player through a provider override and one included player:

spec_version: 2

suites:
  - single-pairwise-sync # (1)!

rooms: 1

players:
  - player: my-model # (2)!
    provider: my-provider # (3)!
  - player: test-expert

source: local
observability: limited

The run-manifest reference gives every field, default, and constraint.

Set runtime capacity¶

rooms is the number of game-service processes. Each player entry's count is the number of player-service processes created from that profile. It defaults to 1.

Capacity depends on the selected suite protocols. A two-role experiment needs concurrent Defuser and Expert services. A solo protocol needs one player. Self-play still needs separate service processes for concurrent roles. Use count to supply the concurrency you intend; doctor reports the declared roster and generated appearances.

On Linux, displays assigns rooms to X display numbers in round-robin order. Omit it to preserve the ambient DISPLAY value.

Add anchors or more attempts when required¶

with_best_expert and with_best_defuser pairings read their fixed player configuration names from anchors. An anchor used by the selected suites must also have a roster entry so the run starts its player service.

anchors:
  best_expert: test-expert

attempts_per_mission controls generation depth for each mission and pairing. It defaults to 1 and does not form part of suite identity.

Validate the manifest¶

Run the full check:

gptnt doctor runs/my-run.yaml

Doctor validates the YAML and composes each player and provider pair. It checks the run roster against the selected suites and reports resume state before checking local infrastructure.

Use installation and doctor troubleshooting for a manifest or roster failure. Use provider troubleshooting for a failed model row.

Generate the specifications¶

gptnt generate runs/my-run.yaml

The command writes one JSON file per attempt under output/experiment_specs/my-run/. Regenerating replaces that directory's previous JSON spec set while preserving files with other extensions.

gptnt run does not regenerate specifications. Regenerate them after changing the manifest or a selected configuration that affects the experiments. Continue with Run interactive experiments.