Evidence Provenance Graph: How to Trace Automated Decisions

An evidence provenance graph is a directed record of how a piece of evidence, or an automated decision, came to exist: which sources fed it, which activities transformed it, which agents (human, model or software) acted, and how each link supports or contradicts the conclusion. For a regulated financial services firm, its job is practical: when an examiner asks "why did this system do that, and who was watching?", the graph answers with traceable, verifiable records instead of reconstructed recollection.

The term sits between two better-known ideas. A provenance graph records lineage. An evidence graph records reasoning. An evidence provenance graph joins them, so that every claim in an audit file can be walked back to the entities, activities and reviewers behind it.

TL;DR

• An evidence provenance graph combines lineage (what produced what) with support and challenge relations (what backs or contradicts a conclusion), so a decision can be traced end to end.
• The W3C provenance model of entities, activities and agents is the common foundation; evidence-specific extensions add claims, findings and defeasible assertions.
• To be auditable, nodes need stable identifiers, timestamps, model or agent versions, inputs, human review outcomes and integrity protection such as cryptographic signing.
• A graph proves what was recorded and that it was not altered. It does not prove the underlying decision was correct.
• For AI agents, the graph can be built from metadata alone, which keeps customer data out of the governance layer.

Table of Contents

• What an evidence provenance graph is
• What the graph must record to trace an automated decision
• How provenance records become a graph
• What makes the evidence auditable
• Using the graph to demonstrate oversight
• What a graph can and cannot prove
• How we approach it
• See the graph for your own agents
• FAQ
• Sources

What an evidence provenance graph is

The foundation is the W3C provenance model. It defines three core concepts: entities (things, such as a dataset or a report), activities (what happens to entities over time) and agents (the people, organizations or software responsible). The International Virtual Observatory Alliance adapted these concepts to judge data quality, reliability and trustworthiness in its provenance data model, and the W3C's own PROV-O ontology describes provenance as information used to form assessments about quality, reliability or trustworthiness.

That gives you lineage. It does not, on its own, tell you whether a conclusion is well supported. Evidence-oriented extensions fill the gap. The EVI ontology, for example, extends PROV-O with support and challenge relations in directed acyclic evidence graphs, and treats findings as defeasible assertions: claims that stay open to revision when new evidence arrives. Timothy Clark of the University of Virginia argues in a 2021 paper on evidence graphs that computational results should be handled this way, with formal graphs that let support and challenge propagate through arbitrarily deep networks.

Provenance graph, evidence graph, evidence provenance graph

A useful working definition: an evidence provenance graph is a provenance graph in which the nodes at the end of each chain are claims or decisions that someone must be able to defend.

What the graph must record to trace an automated decision

A graph is only as useful as the fields behind its nodes. Three bodies of 2026 material point to a consistent minimum.

First, a non-normative February 2026 submission to the SEC defines Agent Decision and Execution Logs as immutable, timestamped event logs that allow decision-to-execution chains to be reconstructed. It also proposes examiner-facing audit trails comparable to the supervision of a human trader, mapping strategy actions back to their underlying logic and signal sources.

Second, an SEC-filed paper on expert oversight argues that evidence provenance graphs should capture the agent or model version, retrieval sets, human reviewer interventions, and an explicit justification of how sources support or contradict specific propositions.

Third, the Decision Provenance Standard (v1.2) requires decision records to be persistent, findable artifacts carrying a stable identifier, an accountable owner, the decision statement, rationale, inputs, assumptions and success criteria.

Putting these together, a defensible node and edge model has these elements:

1. Stable identifier. Every decision, input and evidence item can be cited without ambiguity.
2. Accountable owner. A named role, not a team alias, answers for the decision.
3. Actor identity and version. Which agent, model or workflow acted, and in which version.
4. Inputs and retrieval sets. What the system was given or looked up, referenced rather than copied where the content is sensitive.
5. Timestamps and ordering. Enough to reconstruct the sequence from trigger to execution.
6. Human review events. Who looked, when, and with what outcome.
7. Support and challenge links. Which sources back the conclusion and which contradict it.
8. Integrity protection. A mechanism that makes later alteration detectable.

Modeling human oversight as events

Oversight that exists only in a policy document leaves no trace in the graph. The expert-oversight proposal cited above recommends recording human judgment as a persistent, machine-native, state-changing event linked to the evidence graph. It describes four operationally meaningful review outcomes: confirmed, corrected, disputed or escalated, and blocked.

That vocabulary is worth borrowing even if you adopt no other part of the proposal. A reviewer who "confirmed" a decision and one who "blocked" it create different downstream edges, and an examiner can count both. Our guide to designing an AI decision appeals process shows how disputed and escalated outcomes connect to customer-facing remedies.

The same discipline applies to the technical events around a decision. For a worked view of the metadata and review events needed to reconstruct AI decisions in banking, see this piece on AI in banking fraud detection.

How provenance records become a graph

Collection and linking are separate problems. Collection decides what gets observed. Linking decides how observations become edges.

Collection: where the records come from

Provenance data can be captured from application logs, workflow engines, identity providers, model registries and review tools. The trade-off is intrusiveness. Instrumenting every agent and pipeline gives rich detail but changes production systems and often pulls in customer data. Reading metadata from the systems that already govern identity and access gives less detail per decision but a complete inventory, and it does so without touching the content of any customer record. Our article on AI governance without PII explains what oversight can be proven from metadata alone.

Linking: from events to edges

Linking relies on identifiers that persist across systems: an agent identity, a decision ID, a model version tag. Where those identifiers are missing, the graph fills with orphan nodes, and an examiner sees gaps. A practical sequence for building the graph:

1. Inventory the agents, models and automations that can influence a decision.
2. Assign each a stable identity and an accountable owner.
3. Define the decision types that matter and the evidence each must carry.
4. Capture events as they happen, with timestamps and version references.
5. Link events to decisions and decisions to sources using explicit relations (used, generated, attributed to, supported by, challenged by).
6. Seal the result so that tampering is detectable.

The design of controls that make the middle steps repeatable is covered in building deterministic controls for AI, and the pre-execution side in decision pipeline evidence.

What makes the evidence auditable

An auditor does not ask whether the graph is elegant. The auditor asks whether it can be checked independently. Four properties carry most of the weight.

• Completeness. The graph covers every in-scope agent and decision type, and shows where coverage ends.
• Integrity. Records are tamper-evident. Cryptographic hashing or signing lets a third party confirm that nothing changed after sealing.
• Determinism. The same inputs yield the same classification and the same evidence output, so a result can be reproduced on request.
• Portability. The evidence can be handed over and verified without access to the live system.

The open Agent Evidence specification describes this packaging idea: evidence packs as portable containers for evidence graphs, including claim maps, source maps, provenance chains and verification results, intended for audit, compliance and incident response.

Research on generative AI points to a related direction. A paper on compliance-by-construction describes argument graphs that link evidence to formal arguments, so auditors can traverse provenance relations and reconstruct how a decision was reached. The same work describes accountability that links AI-generated nodes to models, prompts and human reviewers through PROV relations.

Using the graph to demonstrate oversight

Regulated firms rarely need a graph for its own sake. They need it to answer five recurring supervisory questions.

Our four-function governance framework places evidence generation inside the design of the controls rather than at the end of the audit cycle. For sector detail, the articles on credit decisioning audits and market surveillance governance show how the same graph structure adapts to different decision types, and the third-party AI audit plan covers vendor-supplied models whose internals you cannot inspect.

For teams sequencing the work, a phased 90 to 180 day AI governance framework is one way to connect provenance records to human oversight and accountability.

US guidance to watch

The US has no single rule that prescribes an evidence provenance graph, so firms assemble the expectation from several directions. The SEC-facing materials above are proposals and submissions, not binding rules, and should be read as signals about where examiner expectations may go. On the standards side, NIST's work on evaluation probes for agentic AI accumulates machine-readable audit trails that verify whether agent decisions are factually grounded against trusted document corpora. Its April 2026 methodology assesses citation quality along three dimensions: faithfulness (guarding against hallucination), completeness (guarding against cherry-picking) and sufficiency (guarding against overreaching).

Those three dimensions translate directly into graph checks: does every cited source exist, are contradicting sources recorded alongside supporting ones, and do the cited sources actually carry the conclusion drawn from them.

Firms operating in both the US and the EU or UK should map each obligation to its jurisdiction rather than assume one evidence file satisfies all. Frameworks such as EU AI Act Article 26, FCA SYSC and Consumer Duty are jurisdiction-specific, and a graph that carries framework tags on each control lets one record serve several regimes.

What a graph can and cannot prove

This is the section teams skip and examiners do not.

It can prove that a record existed at a point in time, that it is unchanged since sealing, that an identified actor was linked to an action, and that a review event occurred. It can show coverage and expose where coverage stops.

It cannot prove that the underlying decision was right, that a cited source was true, or that an unrecorded event did not happen. Integrity is a statement about the record, not the world. This is consistent with the defeasible-assertion view in the EVI work: findings remain open to challenge, and a signed graph preserves the challenge history rather than ending it.

Three practical consequences follow.

1. Scope statements matter. State which agents, decisions and time periods the graph covers, and which it does not.
2. Capture gaps are findings. An agent with no owner or no review events should appear as a visible gap, not be silently omitted.
3. Pair the graph with testing. Provenance shows what happened. Validation and outcome monitoring show whether it was good.

How we approach it

We build evidence provenance on a simple premise: governance evidence should not require access to the data it governs. A graph assembled from metadata alone, such as OAuth grants, agent identities, ownership and review events, can show an auditor what exists, who is accountable and where risk concentrates, while touching no customer data.

Two properties decide whether that evidence survives scrutiny. The first is determinism: each risk classification and evidence item should be reproducible and cited to public regulatory and industry sources. The second is verifiability: we sign evidence packs with HMAC-SHA256 so that firms, auditors and regulators can check integrity offline, without trusting our platform at the moment of inspection.

Agentless integration is what makes this deployable in regulated environments. Nothing is inserted into production systems, so the governance layer does not become a new risk surface. Our view is that firms which can produce a sealed, traceable graph on demand will spend their examination time on substance rather than on reconstructing the past.

Eleye

See the graph for your own agents

AETHER Pulse builds an inventory and identity graph of your AI agents from OAuth metadata, maps risk concentration including financial blast-radius exposure, and generates provenance-tracked, signed evidence packs on demand. Plan details are on our pricing page, which covers the Design Partner and Production plans and the Article 26 readiness audit, and the main site lists the Free, Pro and Enterprise plans.

If you are scoping a first evidence graph, start with the inventory: it is the node set every other edge depends on.

FAQ

Is an evidence provenance graph the same as an audit log?

No. An audit log is a chronological list of events. An evidence provenance graph links those events to decisions, sources, actors and reviews through typed relations, so a reader can follow a conclusion back to its basis. Logs are often the raw material the graph is built from.

Does the graph need to contain customer data?

Not necessarily. It can reference inputs by identifier, version or hash instead of copying content, and it can be assembled largely from metadata about agents, identities and review events. That keeps the governance record out of the scope of the data it describes.

How does a graph show that humans oversaw an automated decision?

By recording review as an event with an identified reviewer, a timestamp and an outcome, such as confirmed, corrected, disputed or escalated, or blocked. Those events attach to the decision node, so an examiner can see the review rather than rely on a policy statement.

Can a signed graph prove the decision was correct?

No. Signing shows the record was not altered after it was sealed. Correctness depends on the model, the inputs and the judgment applied, which need separate validation and monitoring.

Sources

• IVOA Provenance Data Model Version 1.0
• PROV-O: The PROV Ontology
• EVI: Evidence Graph Ontology
• Evidence Graphs: Supporting Transparent and FAIR Computation
• Sovereign Bills and Private Credit Tokenization with Agentic AI (SEC submission, February 2026)
• Frame Infrastructure for AI, Vol. 3: Expert Oversight
• The Decision Provenance Standard v1.2
• Agent Evidence specification
• Compliance-by-Construction Argument Graphs
• Building Evaluation Probes into Agentic AI, NIST

Recommended

• Decision Pipeline Evidence for Finance: Prove Intent Before Execution
• AI Policy to Evidence Mapping for Regulated Firms
• Audit Sampling for AI Decisions: A Defensible Approach
• Map NIST to Evidence: Regulator Ready AI Reports for Compliance