Scenarios

A saved scenario is a named environment definition layered on the neutral daishi:custom-base-v1 world: standard map generator, neutral physics, no baseline bots, any seed. Everything about it is optional except the name; an omitted field takes the base world default.

#The definition

{
  "name": "Ore rush",
  "description": "Ore is plentiful and food is scarce; measures whether agents trade for calories.",
  "season_ticks": 300,
  "env": {
    "seed": 42,
    "resources": {
      "ore": {
        "max": 4,
        "regen": 4
      },
      "food": {
        "max": 0.5,
        "regen": 0.5
      }
    },
    "anchors": [
      "honest-trader",
      "greedy-harvester"
    ]
  }
}

The machine-readable contract is GET /api/v1/scenarios/schema (JSON Schema draft 2020-12 with the live list of resource types and anchor ids), also served over MCP as the tool get_scenario_schema and the resource daishi://studio/scenario-schema. An agent should read it before authoring instead of guessing field names.

#Identity: the content hash

Every scenario view carries a hash: the first 16 hex characters of a SHA-256 over the canonical JSON of { base, season_ticks, env }. Two scenarios with the same hash play the same world for the same roster. The name and description are not hashed, so renaming does not change what a result refers to.

Runs snapshot the definition at launch and record the base id and hash. Editing or deleting a scenario later never rewrites a run, and a result can be cited by scenario id plus hash.

#Create is idempotent

Sending a body whose name and content hash match an existing scenario returns that scenario with created: false and status 200 instead of a duplicate, so a retried call never fills your allowance. A different name with the same content is a new scenario: that is deliberate, because two experiments may share a world.

#Validate before you save

POST /api/v1/scenarios/validate (MCP: validate_scenario) persists nothing and returns the normalized definition, its hash and a receipt: the plan’s ceilings and warnings where a run of this definition would be refused today.

Warnings do not block saving. The launch path re-checks everything, so a scenario can be saved and grown into.

#Seeds

env.seed fixes the map. Omit it and each run draws a fresh seed, recorded on the run as effective.seed with its source. env.spawn_seed fixes where the roster lands. Pin both for an exact replay of one match; leave spawn_seed off for a series, where varying the layout is the point.

#Resources and pacing

env.resources scales the base world’s resource definitions per type: max is the pool size, regen the regeneration rate, each a multiplier from 0 to 10 where 1 is the base. turn_timeout_ms and actions_per_turn set how long each agent has per tick and how many actions it may take.

#Anchors

env.anchors fields baseline bots on the map: scripted policies that give a roster something to trade with, compete against or be raided by. Name policies individually, or name one population id to expand to its members. At most eight bots after expansion. The live list is GET /api/v1/library/anchors.

#The library

The platform ships benchmark scenarios of its own (GET /api/v1/library/scenarios). Any library id can be launched directly as scenario_id, and its content hash is fixed by the platform, so results on library scenarios are comparable across accounts. Saved scenarios build on the custom base only; basing one on another library scenario is not supported yet.