How a graph records what happened.

The argument, up front

A graph of bare assertions is untrustworthy the moment it feeds a decision: no one can tell whether a figure came from a system of record or a guess, whether it is current or stale, asserted or inferred, or who is accountable for it. Provenance and workflow modeling turn those unknowns into queryable data. The good news is that one W3C vocabulary — PROV-O — carries most of the weight, and the same three concepts describe a claims-handling process and a nightly data pipeline alike.

This brief connects to three others: it is the queryable form of the lineage the enterprise strategy and the source-mapping strategy call for, and it shares its version-chain machinery with ontology versioning.

“Workflow” means two different things in a knowledge graph, and it helps to name them before modeling either. Both reduce to the same pattern: an activity uses some entities and produces others, run by an agent following a plan.

PROV-O is the W3C Recommendation for provenance on the Web. Learn these dozen terms and you can model most of what an enterprise graph needs.

Retrospective provenance of a claim decision

@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix ex:   <https://example.org/resource/> .

ex:decision-9001 a prov:Entity, claim:Decision ;
    prov:wasGeneratedBy  ex:adjudication-run-42 ;
    prov:wasAttributedTo ex:adjuster-jsmith ;
    prov:wasDerivedFrom  ex:CLM-1001, ex:POL-500 ;                 # lineage
    prov:generatedAtTime "2026-02-01T16:20:00Z"^^xsd:dateTime .

ex:adjudication-run-42 a prov:Activity ;
    prov:used            ex:CLM-1001, ex:POL-500 ;
    prov:startedAtTime   "2026-02-01T16:00:00Z"^^xsd:dateTime ;
    prov:endedAtTime     "2026-02-01T16:20:00Z"^^xsd:dateTime ;
    prov:qualifiedAssociation [
        a prov:Association ;
        prov:agent   ex:adjuster-jsmith ;
        prov:hadRole ex:AdjudicatorRole ;
        prov:hadPlan ex:adjudication-plan-v3 ] .                   # the plan it followed

ex:adjuster-jsmith a prov:Person, prov:Agent .

Provenance has two tenses, and a mature graph models both. Confusing them — describing a process definition as if it were an execution — is the most common workflow-modeling mistake.

The processes the business runs are first-class graph content. Three complementary patterns capture them; most domains use all three together.

• Event-based — the lifecycle. Model each significant occurrence as a timestamped event — opened, closed, reopened, cancelled — each with an OWL-Time instant or interval. The ordered event stream is the workflow history.
• State-based — the current status. Derive the present state from the latest event rather than storing a mutable flag, so status is always explainable by the events behind it — “the current status is whatever the most recent lifecycle event set it to.”
• Activity-based — the accountable process. When you need to know who did what, using what, lift the step to a prov:Activity with an agent, inputs and outputs. An adjudication or an underwriting review is both a domain step and a provenance activity.

Every step that builds the graph — extraction, a mapping run, entity resolution, a reasoning pass, a materialization — is a prov:Activity that consumes inputs and generates graph data. Recording those runs answers the questions auditors and engineers ask most.

A mapping run, recorded against the graph it produced

@prefix prov: <http://www.w3.org/ns/prov#> .

# the triples this run produced live in their own named graph...
ex:graph/policy-src1 {
    ex:POL-500 a policy:Policy ; policy:policyNumber "POL-500" .
}
# ...and the named graph carries the provenance of the run
ex:graph/policy-src1
    prov:wasGeneratedBy ex:mapping-run-2026-05-01 .

ex:mapping-run-2026-05-01 a prov:Activity ;
    prov:used              ex:policy-extract-2026-05-01 ;
    prov:wasAssociatedWith ex:mapping-engine ;
    prov:endedAtTime       "2026-05-01T02:14:00Z"^^xsd:dateTime ;
    prov:qualifiedAssociation [
        a prov:Association ;
        prov:agent   ex:mapping-engine ;
        prov:hadPlan <https://example.org/mapping/policy/2.1.0> ] .  # the pinned mapping version

ex:mapping-engine a prov:SoftwareAgent .

Provenance can hang at four levels of granularity. Finer is more precise and more expensive; pick the coarsest level that answers your questions.

Workflow and provenance modeling forces a distinction that flat data hides: an assertion has more than one time, and conflating them corrupts audit and history.

Provenance and workflow modeling are not documentation for its own sake — they exist to answer questions the business cannot otherwise ask of the graph.

• Use PROV-O as the backbone, and extend narrowly: P-Plan for process definitions, PAV / Dublin Core for authoring metadata, your domain events for the business lifecycle. Don’t invent a bespoke provenance model.
• Make named graphs the default carrier of provenance; drop to statement-level (RDF 1.2 triple terms) only where a single fact truly needs its own metadata.
• Emit provenance automatically. Pipelines should produce their PROV as a byproduct of running — hand-authored provenance is never complete and never trusted.
• Separate provenance from base data in its own graphs. It can dwarf the facts it describes; partition it so it stays queryable without bloating everyday queries.
• Let competency questions set the grain. Capture the provenance your lineage, trust and audit questions actually require — no finer. Regulated domains earn fine-grained capture; others do not.
• Relate domain events to their activities, so one traversal crosses from “what happened” to “who is accountable and how it was produced.”