Save and reuse scenarios

A scenario declares one situation: its ID, name, task input, and optional checks, rubric, metrics, Tool datasets, or continuing sequence. Keep its authored JSON in the application repository so your coding agent can review changes alongside application code. Saving a scenario retains a project-owned definition. It does not run your application, allocate a Tool instance, or create an assessment.

Save a complete scenario

After selecting a project, save this as shortage.scenario.json:

{
  "id": "stock-shortage",
  "name": "A request exceeds available stock",
  "input": { "requested": 6, "available": 5 },
  "checks": [
    {
      "id": "review",
      "description": "The application requests review instead of approving",
      "path": "/output/decision",
      "comparator": "equals",
      "expected": "review",
      "required": true
    }
  ]
}

firedrill scenarios save shortage.scenario.json \
  --expected-revision new --idempotency-key stock-shortage-v1 --json
firedrill scenarios --q stock-shortage --json

new requires that the ID does not already exist. Save the returned ID and revision. A later change uses the current revision as --expected-revision and a new deliberate idempotency key. A stale revision conflicts instead of overwriting someone else’s work. After an uncertain response, retry the same file, expected revision, and key. Changing content under the same key is not recovery.

Read an exact revision

Set SCENARIO_ID and REVISION to the values returned by save or list:

firedrill scenarios get "$SCENARIO_ID" "$REVISION" --json

The Scenarios view shows the same retained revisions and their execution context. A saved definition with no executions is valid; it is not a passing test.

Reuse it in a recipe

Place the verified scenario object in a recipe’s scenarios array. For a runnable target, use the stock adapter from your first simulation:

{
  "schemaVersion": "2026-10-14",
  "name": "Stock shortage requirement",
  "target": { "kind": "command", "argv": ["node", "stock-adapter.mjs"] },
  "scenarios": [
    {
      "id": "stock-shortage",
      "name": "A request exceeds available stock",
      "input": { "requested": 6, "available": 5 },
      "checks": [
        {
          "id": "review",
          "description": "The application requests review instead of approving",
          "path": "/output/decision",
          "comparator": "equals",
          "expected": "review",
          "required": true
        }
      ]
    }
  ],
  "limits": { "timeoutMs": 10000, "maxRuns": 1, "maxOutputBytes": 4096 }
}

Save this as shortage.recipe.json, then run:

firedrill preview shortage.recipe.json
firedrill simulate shortage.recipe.json

A recipe contains scenario objects, not a live reference that silently follows future edits. Simulations retain their exact submitted definitions. A later run is new execution and may produce different output.

Reuse the right boundary

Matrices vary explicit task input.
Tool datasets version synthetic starting records.
Sequences retain managed state within a run.
Rubrics express meaningful partial credit.
CI executes the same reviewed recipe in your runner.

Do not put secrets or hidden evaluator instructions in task input. The target receives explicit input, configuration, scoped Tool connections, and scenario ID—not the scenario’s checks, rubric, or future control steps.

Get started

Coding agents

Simulations and evidence

Synthetic Tools

Automation

Web app and access

Core concepts

Files and reference

Save and reuse scenarios

Save a complete scenario

Read an exact revision

Reuse it in a recipe

Reuse the right boundary

​Save a complete scenario

​Read an exact revision

​Reuse it in a recipe

​Reuse the right boundary

Save a complete scenario

Read an exact revision

Reuse it in a recipe

Reuse the right boundary