31. Simulation

In plain words: Design rule 31: What-if simulation

Designed 5 min read 18 glossary terms 15 connected pages
The short version written for the Snayu team

Defines the What-if Simulator (Shadow): exploring alternative branches against a pinned starting point, with separate roles proposing (Dancer) and reviewing (Hunter) branches, while the target owner decides any real change.

Why read it: Read this before building experimentation or branch-and-compare features.
  1. 1Simulation never changes live state; promotion is a separate, explicit owner decision.
  2. 2Branch generation and review are kept separate, with budgets and stopping conditions.
  3. 3No branch has to win; unknown or contradictory results stay recorded as such.

Designed No simulation store, workflow or provider is built yet.

Words on this page, decoded click one for its card

The original text Underlined words open their plain-English card.

Context

Shadow explores bounded alternatives against a pinned base and retains the evidence and outcome of each branch. Candidate generation, independent review, and promotion need separate owners: Dancer proposes alternatives; Hunter reviews them; the target owner decides whether a proposed change may affect the system.

Decision

ShadowWhat-if Simulator owns the experiment: its simulation IntentRequest, branch lineage, assumptions and unknowns, separation of expansion from review, budgets and stopping conditions, evidence/artifact references, eligibility packages, and cleanup eligibility/receipts. Scheduling, unsafe execution, capability selection, readiness, truth, Persona, consent, live mutation, Memory curation, and training remain outside that office. SpellweaverWorkflow Engine, execution, DispatcherTraffic Controller, OrchestratorStage Manager, DriftEvaluator, MirrorPersona Keeper, HitLApproval Step, ArchiveLong-term Memory, and SoulforgeModel Trainer keep those responsibilities.

A game engine simulating physics, navigation, actors, and gameplay inside an exact local project is Foundry execution, not a ShadowWhat-if Simulator branch. ShadowWhat-if Simulator may compare separate project candidates under pinned bases, but it neither becomes the engine world nor owns the selected game's scene, rules, playtest, or build.

Delivery boundary

ShadowWhat-if Simulator is Designed. No simulation RuneService Config File or schema, PatternWorkflow, branch store, search provider, workspace manager, TombSandbox, Reaper, Vision contract, evaluation integration, or promotion path ships. State of Work owns delivery.

Records and branch law

An immutable Simulation IntentRequest names owner, purpose, exact base state, permitted effects, budgets, stop conditions, and promotion class. It creates stable Branches, each recording parent, generating InvocationJob Request, assumptions, required/observed state, unknowns, resource owner, and status. Observations name exact command/tool/predicate, environment, inputs, outputs, artifacts, and error class. A Vision packages one candidate revision, lineage, checks, measurements, uncertainty, hazards, and proposed effect; a Promotion Request adds target, validation, rollback, authority class, and expiry. A Cleanup Receipt records resources, retained evidence, teardown, residue, and terminal state.

Repository, fixture, world, and artifact bases are exact revisions, never “latest.” Branches are either text-only idea branches, isolated material branches, or a promotion candidate packaged as a complete Vision. The latter is not selected, true, or authorized. Branch status is explicit:

open | blocked | failed | ineligible | candidate | retained | reaped | cleanup_incomplete

No branch need win. Exhaustion, contradictory requirements, unavailable state, and UNKNOWN are truthful outcomes.

Open, judge, prune

An experiment may use enumeration, debate, best-of-N, beam/tree search, human candidates, or another provider; no heuristic is constitutional. Dancer receives the common IntentRequest and one declared Lens, then proposes alternatives with provenance, assumptions, required state, and unknowns. It cannot see siblings before the join, rank them, or promote them. Hunter separately reviews a named candidate, returning challenges, evidence requests, boundary findings, withhold recommendations, and uncertainty without inventing a preferred replacement. A join can cluster or deduplicate only while preserving original lineage.

Before material spend, deterministic predicates may make a branch ineligible; witnessed policy violations may block it. Missing evidence is unknown and may justify one bounded inquiry naming question, access, budget, and stop condition; it ends resolved, refuted, or unknown and may not widen itself. Model hesitation proves nothing. DriftEvaluator evaluates reviewer Posture against matched solvable controls. The Dual-Gate combines deterministic checks with attributed, calibrated qualitative judgment before eligibility; no score, confidence, or surviving cheap branch selects reality.

Versioned exploration strategy

A Simulation IntentRequest may pin an executable exploration strategy by revision and digest, with its input/output contract and implementation closure. Given the observations disclosed so far, eligible branches and remaining budget, it proposes where to continue, a bounded batch of attempts, or a stop. Its decisions retain the evidence available at that point. Branch eligibility, independent Hunter review and promotion keep their existing owners; the strategy cannot widen authority, resource ceilings or sibling visibility.

The strategy remains fixed throughout one admitted experiment. A proposed successor is candidate material evaluated by DriftEvaluator and admitted by the receiving owner for later work. Changes to the score or implementation follow Workflow revision law; no strategy update patches a live RunJob Record. SpellweaverWorkflow Engine coordinates the admitted attempts, DispatcherTraffic Controller selects capability, and OrchestratorStage Manager owns physical readiness and resource conflicts.

Retained branch histories may support historical exploration replay. The replay snapshot pins parentage, source revisions, disclosed observations, recorded costs, terminal states and missing continuations. It preserves unsuccessful branches within the admitted retention scope. Search over those records produces a candidate strategy and bounded evidence; fresh trials establish how it behaves beyond the recorded history. This optional mechanism needs no change to model weights and grants no training admission.

Material containment and budgets

A material branch receives an isolated workspace through a replaceable provider. Jujutsu can provide tracked change identity, not an execution sandbox. Its contract pins base and owned paths, mounts/processes/ports/services/network/secrets/effects, evidence locations, leases, reset/snapshot, expiry, teardown, and state-change verification. Effectful tests use an admitted execution boundary: directory deletion cannot end processes, revoke credentials, close ports, undo remote calls, or restore shared state. The designed TombSandbox proves none of this today.

Intent bounds branch/depth count, tokens, wall time, spend, disk, artifacts, concurrent execution, and review rounds; children consume their parent's reserved envelope. SpellweaverWorkflow Engine coordinates fan-out, join, cancellation, and termination; DispatcherTraffic Controller chooses capability; OrchestratorStage Manager manages readiness and lease conflict; Workers run jobs. Exhaustion cancels or marks incomplete, then cleans up—it never selects a winner.

Evaluation, reaping, and collapse

An Observation proves only its named predicate. A unit test cannot establish architectural fit, a commit cannot establish shared-state isolation, and a model judge cannot establish an effect. ShadowWhat-if Simulator sends exact branches, environments, observations, and artifacts to versioned DriftEvaluator Trial SuitesApp Bundles, keeping deterministic receipts distinct from verdicts. MirrorPersona Keeper may supply Persona-congruence criteria but cannot privately select a Persona. A score is a scoped, versioned, attributable evaluation signal: it may guide pruning, priority, or convergence inside the experiment, but proves and authorizes nothing.

The Branch Reaper

Only after retention settles may Reaper act: commit terminal state; retain required inputs, observations, artifacts, findings, and errors; enumerate jobs, leases, processes, services, ports, and credentials; have workspace/execution owners tear down; reconcile external/shared residue; and write the Cleanup Receipt. TTL is not proof of safe deletion; hold, lease, pending promotion, required evidence, or unknown ownership postpones it. Failure retains its witnessed boundary; neither traces nor success/failure pairs become KarmaLessons Learned or training examples automatically. Jujutsu cleanup verifies descendants and retained references because abandonment can rewrite revision relationships.

ShadowWhat-if Simulator emits only a Promotion Request:

Vision → target owner revalidates current state and evidence → rollback/snapshot preparation
→ Ward and HitL/preauthorization decide the exact effect → owner applies and verifies → receipt

The target rechecks base, preconditions, policy, authority, and rollback against current reality. Historical success or preauthorization outside an eligible class cannot merge, publish, purchase, deploy, restore, or otherwise cross the boundary. Archive separately admits memory; SoulforgeModel Trainer separately admits training. This is the Demarcation Law: SpellweaverWorkflow Engine coordinates live InvocationsJob Requests; ShadowWhat-if Simulator produces candidate realities.

Consequences

Accepted

Candidate worlds carry lineage, budgets, evidence, adversarial review, honest pruning, and cleanup without collapsing experimentation into authority or live effect.

Cost

Search and review consume finite resources, isolation/teardown are difficult, bias can converge on the wrong candidate, and some experiments end without a promotable answer.

Acceptance evidence

ShadowWhat-if Simulator remains Designed until one bounded PatternWorkflow proves independent Dancer branches, separate Hunter review, base pinning, material ownership, deterministic observations, DriftEvaluator evaluation, budget cancellation, inert Promotion Request, current-state revalidation, and a Cleanup Receipt including incomplete teardown. State of WorkWhat Actually Works records that transition.