Runs and evidence
Find the execution and source material behind an output before using it
A run records one execution of a saved pipeline. Its status, steps, outputs and errors show what happened during that execution. The graph currently on screen may be a newer draft; inspect the actual saved version associated with the run.
Evidence is more than completed status
| Information | What it helps establish |
|---|---|
| Saved version and run | Which configuration executed |
| Node outputs and diagnostics | What each step produced or failed to produce |
| Source records/snapshots | Which data was read and what limits applied |
| Artifacts and lineage | Connections to producing nodes, upstream outputs and resources |
| Assertions and captures | Recorded statements and retained supporting source material |
Lineage coverage depends on the capability and output. Some records have incomplete links; inspect them before treating a plausible answer as fully evidenced. A completed execution is separate from correctness, freshness and coverage.
Example: two equipment runs
Monday's run reads a known measurement and writes a reporting row. Tuesday's run fails because a source field changed. Compare their saved versions, inputs and failing steps rather than assuming the latest graph explains both. Verify Monday's receiving table as well as its run status.
For a query, inspect release, binding identities, snapshots, completeness and diagnostics. For a prediction, inspect its own evidence/output record even when a pipeline invocation succeeded: the prediction node queues separate asynchronous work.
Operational actions and human judgment
Stopping, resuming or recovering execution manages work. Reviewing an artifact, approving a claim or recording a prediction outcome makes a separate judgment. Retrying a run does not approve the truth of its outputs.
Inspect your first result
Use Read your first run, pipeline run inspection and Artifacts. Preserve the run, version and known records as a baseline before adding more sources or steps.