sim_run_pipeline
Returns one scenario result per model that a set of stored Bindings (see sim_bind) touches, run as a composed pipeline (each result's contention split into contended, waitingForWork and neverFired exactly as sim_scenario's is), with the assumptions the composition makes, inTransit (per delayed binding, the source's flow its delay carried past the horizon) and, when the set holds a loop, the loop's reading (loop, pipeline-loop-v1: verdict, claim, components with sweepsNeeded and sweepsRun, sweepsRun, residual). Costs 1 compute token per model run, charged up front, before any model is read, for the most runs the set can take — one per model outside a loop, and a loop's models times the most sweeps it can take — and not refunded when a loop settles in fewer. Defaults: hours 8, seed 1, realizations 0 (one SSA trajectory per model; set it, e.g. 16 as sim_scenario does, since bindings and loops couple means). Caps: hours up to 10000, realizations up to 200, as sim_scenario. Each model runs through its own ordinary scenario in topological order, an output port's trajectory resampled into the target's input-transition schedule, one seed and horizon shared by every model (the discipline sim_compare enforces within one model). A declared conversion is applied exactly as declared: the resampled rate is multiplied by any numeric transform, then by the convert factor. A binding with a delay drives its target that many hours later; before then the target runs on its own declared rate. A loop between models runs only when some binding on it declares a delay. It is solved by sweeps, each running every member once with one delayed binding (cut) driven by the previous sweep, until a sweep reproduces the previous one's schedules bit for bit: verdict fixed-point, whose claim (also assumptions' first line) is that this is the unique fixed point of the coupling over 0 to hours at the seed, followed by its four limits — each model was driven by the other's mean across realizations (mean-field: for joint dynamics build one net with sim_extend), each delay is declared, not measured, before its delay a target ran on its declared rate, and nothing is claimed past the horizon (a fixed point can be a loop that grows; read the series). Verdict stopped means a run hit the step budget or token cap (from sweep 2 on, typically a loop whose gain is above 1, which grows every sweep; in sweep 1, before any feedback has gone round the loop, the model itself at these hours and realizations) and not-settled is a defect to report; neither carries steps, and models after the loop are not run. Refused before anything is charged or read, each refusal naming the value and the bound: more than 64 binding ids; realizations or hours out of range (the text sim_scenario gives); and the set-level refusals, whose tool error starts with its code — a loop with no delayed binding (closes-loop), two bindings into one input (port-taken), more than one binding into a model (segment-cap: each becomes a schedule of up to 61 segments, and a scenario holds at most 100), a loop of more than 4 models (loop-too-large), a loop whose total delay does not exceed one resample interval (hours/60) per binding (loop-lag), one needing more than 24 sweeps (loop-horizon), loops needing more than 48 model runs together (run-cap); loop-lag and loop-horizon name the delay that would run at these hours and the most hours that run at this delay, and sim_system's view of a system holding the loop reports that most as maxHours. Refused after the charge (which pays for reading the models) and before anything runs: any binding that fails the check sim_bind applies (binds-port-v1; v2 for a unit conversion; v3 for a delay; a binding recorded before a check may be refused here by the same text), and a delayed binding whose target declares so many schedule segments before the delay ends that its schedule would pass the cap at these hours (segment-cap, code first as above). Every result names its seams: no model's own fitness gates cover the join, one unit line per binding (units agree; converted, naming the factor; or unchecked where a port declares no port.unit), and that a binding couples means: a driven model ran on its source's mean, so its std_dev is its own spread given that mean, not the joint system's. A driven model's resampled schedule keeps one random stream per realization across its segments, so splitting a run into segments adds nothing where no rate changes; the resampling itself is a piecewise-constant approximation of the source's mean, which smooths anything shorter than one resample window (hours/60). Public: no sign-in; writes nothing.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | shared seed across every model's run (default 1) | |
| hours | No | horizon in hours, shared across every model in the pipeline (default 8) | |
| bindingIds | Yes | JSON array of binding ids to run together, e.g. ["id1","id2"] — every model these bindings touch is included automatically. | |
| realizations | No | realizations per model (default 0, which the engine runs as a single realization — one SSA trajectory per model, so set it, e.g. 16 as sim_scenario defaults to, when the resampled series should be a mean rather than one draw; max 200) |