Skip to content
Merulan

Operate simulations

Start a Simulation with sealed inputs, read its live state and output, and confirm cancellation or recovery from the retained Run.

Use this guide when you run a Simulation with Labs & Modeling. As an operator, check its state and output before using the result or starting more work.

Before you start

The Simulation needs an approved release alias, a sealed input snapshot, and rights to start and read its Run. Confirm the input belongs to the intended study. Simulations explains the fixed inputs and settings behind a result. A Sandbox scenario needs its exact revision. A remembered alias is not proof of its current release, so inspect the approved release before starting.

Start the Run

In the Console at /labs/simulations, check the displayed approved release alias. Enter the sealed input snapshot and choose Start simulation. Keep the returned Run id. The Console reads the Run's current state after start. The accepted response alone only proves the request was stored.

For an API caller, use the start contract and a stable request key. Keep the exact request for replay if the response is uncertain. The API guide owns access and call syntax.

Read state and output

Read the Simulation with its Run id. Check whether it is waiting, preparing, running, blocked, or terminal. In the Console, choose View output for that Run. Inspect the output state, release and input lineage, and recorded compute. Use available output only when its lineage matches the intended study. Withheld or unavailable output is not an empty successful result.

Checkpoints

The Simulation Run must retain the intended input and the release resolved at start. A later release change cannot change those pins. Check the current Run state each time you inspect progress. If you choose Cancel run, keep reading until the owner reports an ending. The state cancel_requested is not terminal. Success or failure can win the race with the stop request.

Success

The Simulation Run reports success and its output read reports available evidence with the expected lineage. Retain the Run and output reference for the study. Read trace state separately when the review needs a trace. Available output does not imply a published trace. If the goal was cancellation, confirm cancelled and keep that outcome. A cancellation refusal does not change the Run's state.

When it fails

A Simulation failure needs the current state and reason. Use the exact Run for investigation rather than inferring a result from the list's age.

REQUEST_IDENTITY_INTENT_CONFLICT

The key already names a different request. Replay the unchanged original request to recover it. Use another key only for intended new work.

QUOTA_DENIED

The request exceeds an admission quota. Resolve the quota condition before another start. Check whether an earlier request already has a Run.

GOVERNANCE_DENIED

Current policy refuses the action or disclosure. Resolve that policy condition before repeating the same action. A known Run id does not grant access.

Recovery

A Simulation start with an uncertain response needs unchanged keyed replay, then Run readback. A failed or cancelled Run stays terminal. Repair its cause before starting different work. A blocked Run keeps its reason and needs the runtime owner's recovery path. The Console has no resume control, and cancel on a blocked Run is a no-op.

For an active Run, cancellation requests a stop or stops work that has not begun. Read the actual ending. Keep any failed or cancelled evidence in the study. For withheld output, restore the required access. Do not rerun to bypass the refusal.

Next steps