Run the lattice
A published scenario, a published ruleset, a seed. You submit orders — or let the scenario's scripted commanders act — and every decision comes back sealed into a hash chain: what was chosen, from which options, in whose words, what it changed, and what the world did about it. Same scenario version, ruleset version, seed and orders reproduce the same trace, decision for decision.
No member data is in scope: a run reads a published scenario, mutates an in-memory world and writes the decision ledger. Member libraries, notes and identity readings are never touched by this surface.
The catalogue
Every scenario is authored and versioned by the Board, and pinned onto every run that executes it.
Charge! — Honor Games
A short two-a-side probe: one striker and one guard per side, four turns. Deliberately the smallest encounter the ruleset seats, so a first run costs almost nothing and the full trace fits on one screen.
The encounter
- ▸Probe the opposing line without committing anything
- ▸Read a complete sealed trace end to end in one sitting
The seating · Red vs Blue
Both sides run the aggressive baseline here: press the weakest living enemy, brace below a third strength. A first order of your own is usually enough to see the difference in the trace.
Muse Wars — Prime Factions
Three Prime Factions seated at once — Order, Chaos and Spark — across eight turns. The encounter ends when one side is left standing or the turns run out, so it shows how a multi-sided seating resolves when the sides are not balanced.
The encounter
- ▸Resolve a three-sided seating where no pair is allied
- ▸See whether a smaller faction survives by being ignored or is picked off first
The seating · Order vs Chaos vs Spark
Order seats a defensive doctrine and braces early; Chaos and Spark both press. With three sides in play, a unit's weakest living enemy is often on the side it just traded with — which is the behaviour this seating is meant to expose.
Command & Conquer — Tiberium Timeline
A two-sided holding action over a corridor crossing: two Nod elements against a GDI line of three. Nod presses from the start; GDI braces. The encounter is small enough to compute by hand from the published roster, which is what makes a trace from it checkable.
The encounter
- ▸Hold or break the corridor crossing across six turns
- ▸Observe how a two-unit screen trades against a three-unit line
- ▸Compare a lab's own orders against the scripted baseline in the same seating
The seating · Nod vs GDI
The scripted baseline: Nod units push the weakest living enemy while above a third strength; GDI units brace below a third strength and otherwise strike the heaviest threat.
The published ruleset · sandbox-1
Small, fully stated and deterministic. Nothing about an encounter is hidden from the caller.
damage = max(1, round(attack × roll × support) − round(defense × 0.5)), where roll is uniform in [0.90, 1.10] drawn from the seed and support is 1.25 when an allied unit supported the attacker that turn; a defending target halves the result.
Units act in the order the scenario seats them. Support resolves before attacks, stance before damage, and recovery last.
experience = +2 for each decision that dealt damage; a unit whose hit points reach 0 is destroyed and acts no further.
Scenario version + ruleset version + seed + orders pin the run. Re-submitting the same four inputs reproduces the same trace, and each decision carries the hash of the one before it.
A run touches only the units the Board authored in the scenario. No member library, note, identity reading or private record is in scope at any point.
Call it from a lab
The sandbox is an endpoint, not a screen: submit orders as JSON, receive the sealed trace back. A Sigil is your credential — the institution's licence must be live, and the Sigil must hold the orchestration domain or be an experimental (research) Sigil, which is the trial path.
https://muse-wars-1c4ede90.base44.app/functions/labSandbox
Every call carries x-api-key: mw_… (a Sigil minted by the Board). The catalogue is open; running, reading your runs and verifying a trace are not.
curl -s https://muse-wars-1c4ede90.base44.app/functions/labSandbox \
-H "x-api-key: $MUSE_WARS_SIGIL" \
-H "content-type: application/json" \
-d '{"action":"run","scenario_key":"tiberium_corridor_standoff","seed":"paper-1"}'The published catalogue and the ruleset it resolves against.
{ "action": "scenarios" }Resolve a scenario, seal every decision, and return the trace with its integrity verdict.
{
"action": "run",
"scenario_key": "tiberium_corridor_standoff",
"seed": "paper-1",
"turns": 6,
"orders": [
{ "turn": 0, "actor": "nod_1", "action": "attack", "target": "gdi_1",
"rationale": "Cut the heaviest opposing unit before it can trade.",
"expected_outcome": "The enemy line loses its strongest hitter early.",
"confidence": 70 }
]
}The runs that Sigil has made, newest first.
{ "action": "runs" }One run's decisions, re-verified live against the hash chain.
{ "action": "trace", "run_key": "lab:<scenario>:<run id>" }Ruleset sandbox-1 · turns ≤ 12 · units ≤ 8 · orders ≤ 60 · every key-mode call is written to the API chronicle and charged against the licence's term.