Workflow Artifact

Origin & evolution

The term hardened in continuous-integration practice, where a build produces artifacts (compiled binaries, packaged releases🚢ReleaseProduct SpecificationA shipped version of the productView reference →, test reports) that are stored and versioned separately from the source. Build systems and CI servers treated these outputs as first-class objects with their own retention, naming, and links back to the build number that generated them. The discipline of provenance grew alongside, driven partly by supply-chain security: knowing exactly which run produced a binary, from which inputs, became a requirement rather than a nicety.

As automation spread beyond code compilation into general orchestration, the artifact generalised with it. A workflow that drafts a document, exports a dataset, or files a pull request produces an artifact in the same sense a build does. The constant across both is the link backward. An artifact that cannot name its source run is an orphan, and an orphan output is one nobody can verify or reproduce.

How it works in practice

A weekly-metrics workflow runs every Monday. Run #31 queries the analytics store, renders a PDF dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference →, and writes the file to shared storage. That PDF is a workflow artifact. It carries metadata pointing at run #31, which in turn points at the template and the inputs used. When a stakeholder🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference → questions a figure in week 31's report, the team opens the artifact, follows it to the run, sees the exact query and the data snapshot it read, and settles the question in minutes. The artifact is what made the answer auditable; without the link, the PDF would be a number with no parentage.

Workflow artifact vs. its neighbours

• Workflow run is the execution that produces the artifact. The run is transient, an event with a start and an end; the artifact is the persistent output that remains after the run completes.
• Deliverable is a planned unit of work a team commits to ship. An artifact may fulfil or reference a deliverable, but it is generated by automation, whereas a deliverable is defined by intent and ownership.
• Build artifact🏺Build ArtifactEngineeringA build output (binary, container image)View reference → is the narrower, compilation-specific case: the binary or package a build run emits. A workflow artifact is the general family that build artifacts belong to, covering reports and generated changes as well as compiled output.

In the graph

In the Unified Product Graph, a workflow artifact sits in the automation region as the output layer of automated work. Its origin is fixed by workflow_run_produces_workflow_artifactWorkflow RunproducesWorkflow Artifacthierarchy, the edge that guarantees every artifact knows the run that made it. When the output advances planned work, workflow_artifact_references_deliverableWorkflow ArtifactreferencesDeliverablecross-domain connects it to that deliverable. An autonomous actor that generates output directly is linked through agent_definition_produces_workflow_artifactAgent DefinitionproducesWorkflow Artifactcausal. Modelling the artifact as a distinct entity with a mandatory link to its run is what gives the graph end-to-end provenance, from a file in hand back to the template, the inputs, and the actor behind it.