Multi-step chains
Run explicit stages and validate the selected final output
A chain executes ordered stages within one prediction. Each stage has an identifier; its output is retained for subsequent model prompts and the execution trace. The final object must satisfy the forecaster's output schema. A chain is not a training pipeline or a Data Pipeline graph.
Two-stage equipment assessment
This example first assesses evidence quality, then produces probability/confidence/rationale for an unplanned mechanical failure causing at least one hour downtime within the run's window. You need an active forecaster with that output schema, probabilityPath $.probability, a published equipment evidence query and matching input. Forecasting and model execution must be configured.
{
"mode": "chain",
"steps": [
{
"id": "assess",
"kind": "llm",
"prompt": "Assess the evidence for {{subject_ref}} during {{horizon}}. Identify measurement age and missing history. Evidence: {{evidence_json}}",
"outputSchema": {
"type": "object",
"properties": {
"assessment": {
"type": "string"
}
},
"required": [
"assessment"
]
}
},
{
"id": "forecast",
"kind": "llm",
"prompt": "Estimate the probability of unplanned mechanical failure causing at least one hour downtime for {{subject_ref}} over {{horizon}}. Use the evidence and prior assessment, disclose uncertainty, and match the configured final output schema. Evidence: {{evidence_json}} Prior steps: {{steps_json}}",
"final": true
}
],
"budget": {
"maxDurationMs": 120000,
"maxTotalTokens": 30000,
"maxExternalCalls": 0
}
}This complete executionConfig replaces the forecaster's execution configuration. In the forecaster Edit page, enter it in Execution config and save a new version. Through MCP use forecaster_update with forecasterId, executionConfig and a unique idempotencyKey. The in-app creation assistant starts with a simple single-call draft; advanced stages are configured after creation.
What stage kinds do
| Kind | Current execution behavior |
|---|---|
| llm, model, aggregate | Structured model calls; aggregate is not a deterministic database aggregation operator |
| ontology_query | Executes the same pinned evidence query with explicit input overrides for non-reserved inputs |
| http, http_model | Calls a configured, permitted HTTPS external endpoint |
| plugin_tool | Calls an allowlisted runtime tool plugin |
A chain query stage stores its result as a stage output. It does not automatically replace the seed evidence used by later prompts. Include steps_json or an appropriate explicit value reference to use that result.
Passing results
Step prompts may use subject_ref, horizon, params_json, evidence_json, output_schema_json, steps_json and trace_json. The main forecaster prompt still uses only its base variable contract.
External bodies/parameters support $evidence, $outputs and $step.STEP_ID as whole value references. The current resolver returns the whole selected stage output; do not assume $step.assess.assessment traverses a nested field. Those references are not arbitrary code or a query language.
Final selection and inspection
Mark the intended final model step final true. If no marked stage supplies a final object, the runtime uses the last stage's object output and validates it. All stages continue executing in sequence; final is a selection marker, not an early-stop instruction.
Run a single known equipment subject first. Inspect seed evidence, stage trace, prompts, final schema, token usage and failure diagnostics. A stage named assess does not prove its interpretation is correct; check measurements against the retained evidence.