Skip to content
Merulan

Simulations

Simulations freeze an approved release and sealed inputs into a Run whose state, output, and lineage remain inspectable.

Simulations run approved releases against sealed inputs in Analysis. Each Run keeps the release, inputs, and settings it used, so you can trace the result back to those facts.

Ownership

A Simulation Run owns its state and output references. Start resolves the approved release alias once. The Run keeps that package, configuration, sealed input, and effective settings. A later alias change does not alter an accepted Run.

In the Console, Analysis › Simulations opens /labs/simulations, and its Runs list remains at /labs/simulations/runs. Analysis supplies the navigation path. The Simulation service keeps the Run, its state, and its output.

Laboratory can use a Simulation as an Experiment subject. The Experiment owns the study's composition. The Simulation still owns its Run and ending. A Comparison reads that evidence through its retained links.

States

A Simulation Run begins requested. It can wait for capacity before it prepares inputs and runs. Success, failure, and cancellation are terminal. A blocked Run is a stop with a recorded reason. It can recover through a separate path.

Cancelling while inputs are prepared or work is running requests a stop. The Run can finish before that request wins. Read the final state to learn whether the Run stopped or finished.

Boundaries

A Simulation Run uses sealed inputs and bounded settings. The caller cannot choose an arbitrary executor or supply an output path. A result is evidence, not a production writeback. Changing live Records needs a separate authorized action.

Output and trace publication also have separate states. A committed output does not prove that every trace is published. An output read can withhold evidence when the caller's current access no longer permits disclosure.

Failures

A Simulation start can be refused by access, quota, or input checks. A blocked Run records the condition that stopped progress. A failed Run records an execution failure. A cancelled Run records a stop. None supplies successful output.

Trace delivery can remain pending or enter quarantine even when output exists. Read the trace state as its own evidence. An unavailable read does not establish either a pending trace or a completed Run.

Recovery

A Simulation recovery begins with the Run read. Keep its exact identity, reason, and frozen inputs. Repair the cause before deciding whether more work is needed. A terminal Run does not resume. A blocked Run needs its runtime recovery path. The Console does not offer a resume control.

For an uncertain start, the start identity contract defines unchanged request replay. Operate simulations follows state, cancellation, and output through readback.

Export and delegation

Simulations run an approved release against a sealed input and publish the output. Merulan retains the sealed input and the approved release. It also retains the Run, its output, and how it ended. Simulation compute may run outside Merulan. Merulan refuses an output that does not match its Workspace, schema, marks, or source. An exported package can repeat a Simulation, but its outputs return through the same publication check.

  • Models explains reviewed Model releases.
  • Experiments and evaluations explains how retained Simulation evidence supports a study.
  • The API guide explains access for the documented Simulation start and read contracts.