Run predictions

A Prediction node invokes a project forecaster for a subject and horizon. The forecaster obtains evidence from its pinned published query release; adding a source edge does not by itself replace that evidence query. This example predicts for a single known subject so you can inspect the entire result.

What you need

You need a Semogram account with workspace membership, a project in that workspace and permission to create and run pipelines. Reading or writing also requires access to the selected endpoints and external systems. Creating a pipeline does not grant those permissions.

Forecasting must be enabled and the model runtime configured. You need a project ontology with queryable evidence for a real subject, a published evidence-query release and an active forecaster. This is an existing-evidence scenario, not a claim that a model can make a meaningful business prediction from two unrelated rows. The prerequisites and authoring steps are stated below.

Prepare evidence and a forecaster

1. In project Ontology → Queries, author a query selecting the evidence for your test subject, with the subject parameter required by that definition. Inspect its read bindings and execute it for that subject. Validate and publish a release.
2. In the project forecaster creation flow, choose that Evidence release and define a name/slug, prediction kind, prompt template, input/output schemas and model. Use a bounded single_call execution configuration. The evidence query's parameter/schema must match the selected subject and params.
3. Save/publish the forecaster. Inspect the immutable forecaster version and pinned evidence release. Keep its actual UUID; changing a query release later does not silently update that pin.
4. Establish an expected review question, such as whether the response cites the known evidence and follows the output schema. Do not invent a target probability as the fixture's “correct” answer.

For example, a forecaster named demo-order-assessment can produce a scenario assessment for an actual order subject with an output schema containing assessment (string) and confidence (number). Use a prompt that requests evidence-backed assessment and identifies missing evidence. A schema and name alone do not create the underlying ontology/query. The forecast reference provides optional contract detail.

Prepare a relevant ingress path

Studio requires an ingress node and connected execution path. Use a source endpoint that contains the known subject’s supporting records, and verify its selected target and record bounds. For a database test, install Postgres read through workspace Plugins → Explore, fill Host, Port, Database, User, protected Password and Ssl; then create an Ingress endpoint with the actual evidence table/query target and Stream/Query contract the capability supports. Verify that fixture relates to the selected subject and published query. A source edge establishes the pipeline dependency; the forecaster still reads its pinned evidence query.

Create Ingress → Prediction, choosing Full load/parser for structured fixture records. Connect a declared collection output to the prediction's input port and configure the existing forecaster as below. Do not use unrelated orders as fake predictive evidence.

Configure the node

In Studio, ask the assistant to prepare a prediction node using that existing forecaster and subject. Set a future horizon end appropriate to the task; the date below is illustrative and must be replaced before it expires.

Prepare a pipeline prediction using the existing demo-order-assessment forecaster for our known test order subject. Use the exact subject reference expected by its published query, a reviewable horizon end and matching query parameters. Show the pinned forecaster and evidence release before saving. Do not create substitute evidence.

{
  "forecasterId": "<FORECASTER_UUID>",
  "subjectRef": "<ACTUAL_SUBJECT_REFERENCE>",
  "horizon": "next review window",
  "horizonEndsAt": "2027-01-01T00:00:00Z",
  "params": {}
}

Validate, save, run and inspect

Validate, save a version and run once. The prediction step queues a separate job and returns predictionId with nonBlocking: true; the pipeline does not wait for its result. Inspect that prediction’s own completion/failure state before reading its output. Inspect the stored prediction: subject, horizon, forecaster version, query release, evidence cutoff/snapshots, output, warnings, usage and model details. Check that the selected evidence actually belongs to the subject. An execution success is not a measurement of predictive accuracy.

Current v1 execution requires a literal subject string or literal expression; a field-derived subject is rejected. This node queues one configured subject, not a per-row forecast loop. For repeated named subjects, use the supported forecaster/watchlist workflow separately.

Record an observed outcome at the appropriate evaluation time using the forecaster’s outcome policy. Unknown/unresolved is not the same as “did not occur.” Compare predictions against real outcomes before operational reliance; evaluation does not automatically retrain the model.