Evidence query
Select the right subject, control coverage and pin a published evidence release
A forecaster reads evidence through a published project ontology query release. It does not read every workspace record, and its prompt does not create data access. The query resolves active bindings onto accessible endpoints and supplies rows, diagnostics and source snapshot metadata to the model.
Define the subject contract
For an equipment query, define Equipment, its equipmentId property and the measurements it should return. A root identity can match equipmentId to the runtime input subject_ref. If subjectRef is P-101, the query must expect P-101. An entity IRI, source equipment ID and database primary key are different values unless your query explicitly maps them.
The runtime evidence input contains subject_ref, horizon and params. It also spreads top-level parameter values before inserting those reserved fields. An input schema with additionalProperties false must allow every supplied key, including params and a nullable horizon if your runs omit it. Explicit per-step query input cannot override the run's subject_ref, horizon or nested params.
{"subject_ref":"P-101","horizon":"7d","params":{}}Prepare relevant records
A useful failure-risk evidence set might include measurement times, vibration/temperature trends, age, service history, operating load and prior failures. Units, time zone, sampling and equipment identity must be explicit. Two readings can verify a connection; they are not enough to measure a failure model's predictive accuracy.
Use a workspace plugin installation for credentials and a Data Endpoint for the selected target. Create the project's Equipment/property bindings. Validate the query, inspect the subject-specific preview and publish a release. The complete equipment fixture supplies source SQL, Turtle, all bindings and query YAML if you need a test setup from scratch.
Inspect coverage and freshness
The prediction evidence loader requests a bounded result and retains at most 100 rows. Inspect snapshot.hasMore and diagnostics. If the query has its own smaller limit, a bounded query result can still omit relevant history. Reduce evidence deliberately with meaningful filters or aggregates, rather than assuming the first rows represent all observations.
A published query pins logic, not the external database's data. The prediction's evidenceCutoffAt records the invocation cutoff; it does not by itself make every live connector perform an historical as-of read. For historical evaluation, constrain source observations to what was actually available at that cutoff. Records updated after invocation can otherwise leak later knowledge.
Publish and select a release
New forecaster creation pins the query's latest published release. Editing the forecaster preserves its evidence pin unless you explicitly choose latest/a specific published release or change the evidence query. A retired pinned release is unavailable for new evidence execution; re-pin deliberately and verify the new version.
Through MCP, inspect the query release and forecaster records before forecast_run. In the UI inspect Evidence release in the forecaster's detail/edit flow. A connected assistant should report the actual query and release it selected, not invent a query ID.
What to verify before relying on a run
Check the equipment subject matches the evidence rows; observations are in the intended units/window; sources are accessible; missing/conflicting values are visible; and no post-outcome measurements entered a pre-outcome forecast. Retain the query release, forecaster version and actual evidence artifact for later comparison.