Runs and evidence

What it is

A run is one execution of a committed workflow version, preserved whole: what ran, what it produced, what failed, and what you decided about it. Evidence is the proof chain behind any output — source records, transformations, and steps, linked all the way through.

What it holds

• Impact first: what changed, what was produced, what needs a human. Mechanics (timelines, node states) exist for investigation, not orientation.
• Narrative: what the system believes happened, in order — compare against expectation before trusting.
• Evidence links: every output traceable to its inputs. If a number cannot be traced, treat the output as unfinished no matter how plausible.
• Freshness: when inputs synced and whether anything upstream changed since. Stale inputs produce stale-looking outputs honestly labeled.
• Diagnostics: failures classified by kind — permissions, unreachable source, bad shape, policy block, transient fault. The kind decides the fix.

How it relates

• Runs execute workflow versions — history, branches, and compare exist so reruns start from known states.
• Evidence chains run through sources (sync state), ontology (provenance), and predictions (drivers) alike.
• Your review decision — approve, retry, correct — becomes feedback that teaches future runs.

What this means for you

• Read impact, then narrative, then evidence — in that order.
• Retry transients; correct structurals at their layer; never silently rerun what you do not understand.
• No finished run left undecided: reviewed runs are training data, unreviewed ones are debt.

Image: run anatomy — impact, narrative, evidence chain, freshness, diagnostics — labeled in reading order.

Next

• Read one: Read your first run.
• Daily practice: Runs.