The strong rivalDistributed tracing and immutable logs may be enough

Existing observability can capture spans, service versions, latency, inputs, outputs and errors. For low-consequence reversible workflows whose main need is debugging, a trace plus controlled logs is proportionate. A second graph can duplicate sensitive data, increase cost and create volume that nobody can query.

Consequential claims and actions need semantic enrichment at selected points, not a duplicate of every event. Add evidence anchors, authority, derivation, claim support, transaction and outcome edges to trace events whose coverage contract requires them. Reuse correlation identifiers and lifecycle systems where possible.

Capture-everything is not the goal. Raw prompts, documents and customer data in a central graph can create a new disclosure path. Store minimised identifiers, hashes, versions, policy results and protected links, leaving payload in governed sources. Access to provenance follows tenant, purpose and sensitivity rules.

The boundary is the reconstruction objective. If the organisation must explain which evidence supported a material claim, prove what a tool changed, identify effects of a corrected fact or let an auditor verify a chain without seeing payload, operational tracing alone needs semantic provenance edges.

Adjacent recordsSix useful mechanisms that should not collapse

A trace can show that a retrieval call executed without showing which span supports a claim. A lineage event can show that table B derives from table A without recording who authorised the use. A signature can protect origin and bytes while the signed source remains wrong. Provenance composes these records without upgrading integrity into truth.

Original constructThe Runtime Provenance Spine

Origin is not correctness. Provenance proves only the claims supported by its captured, verified links. A complete path can show that a wrong source was faithfully transformed and acted upon.

The spine becomes a Claim-Action Evidence Graph. Nodes are typed entities, activities, agents, claims, policies, tools, actions and outcomes. Edges include used, generated, derived-from, attributed-to, supported-by, contradicted-by, authorised-by, transformed-by, acted-on and superseded-by. Edge metadata prevents the graph from becoming a flattened story.

Claim and action granularityBind what matters at the point it changes meaning or state

A paragraph with three material facts needs three claim nodes if different spans support them. Retrieval of a document does not mean that document supports every sentence. Link exact spans and retain a contradiction where a controlled source disagrees. Citation generation is evaluated for correctness and completeness at the claim level.

A derived calculation records each source value and unit, the formula or code version, rounding, deterministic result and review. Citing a narrative page about the method cannot reproduce the number. A tool side effect records the authorised contract, exact inputs, validation, transaction identifier, changed state, response receipt and rollback path.

Summary laundering occurs when untrusted or low-authority text becomes polished and then appears authoritative. Preserve origin and authority through extraction, compression and summarisation. The derived node inherits constraints and can never outrank the source merely because its prose is cleaner.

If a decisive input version is missing, do not invent a citation or substitute the current record. Mark the broken edge and quarantine the material output or action. Historical reconstruction can later repair the chain only from verifiable records, not from the model’s explanation of what it probably used.

Design before deploymentThe provenance coverage contract

Specify claim and action classes that require evidence binding, minimum granularity and anchor quality, mandatory capture points, deterministic identifiers, transformation fields, contradiction and exclusion semantics, retention and access, integrity verification, reconstruction objectives, permissible gaps and correction routes.

Coverage follows consequence and reversibility. A public factual answer may need page citations and a small trace. A calculated eligibility claim needs values, units and code version. An external side effect needs the full inference, authorisation, transaction and outcome chain. A designated irreversible action fails closed if mandatory capture is unavailable.

Balance granularity against sensitive-data and volume cost. Store exact payload only where purpose and access require it. Otherwise record protected source identifiers, typed metadata, hashes and links resolved through authorised views. Sampling can support aggregate monitoring but cannot replace required evidence for an individual consequential action.

Monitor capture success at each mandatory point, orphan edges, clock consistency, version completeness, support accuracy, contradiction retention, transaction receipts, access denials, graph latency and correction propagation. Do not average these into one completeness score that lets strong tracing conceal a missing decisive source.

Integrity is one boundaryAttestation strengthens origin without proving truth

Signed manifests and supply-chain attestations can establish that identified materials passed through named steps and produced a particular artefact. Content provenance manifests can bind assertions to media. These mechanisms strengthen origin and byte integrity when keys, identities and verification are governed.

A correctly signed source can be factually wrong, biased, incomplete, out of date or unauthorised for the purpose. The graph records integrity verification separately from authority, validity, support and decision correctness. A failed signature may quarantine an artefact; a valid signature does not waive review.

Access-limited audit uses scoped metadata, hashes, verification statements and approved views so an auditor can test continuity without seeing every protected value. Graph queries enforce tenant and purpose before traversal. Counts, neighbourhoods and timing can leak sensitive existence, so query results need the same access design as source data.

Clock consistency matters. Trace timestamps, source validity, policy versions and transaction times may use different systems. Preserve ordering evidence and uncertainty rather than inventing a precise chronology. Paper 086’s temporal semantics provide the version basis; provenance links those versions to the executed decision.

Provenance earns its cost during changeUse a correction pulse to find effects

When a source fact is superseded, traverse derived-from, supported-by, used and acted-on edges to locate assertions, prompts, summaries, caches, decisions, tool actions and affected parties. Then apply the consequence policy: invalidate, recompute, replay, review, reverse, notify or remediate.

The earlier graph remains historical evidence of what executed. The corrected version and supersession edge explain what is now known. Revocation ends active reuse without rewriting the old transaction. Each downstream system acknowledges its disposition, and unresolved nodes stay visible.

If provenance capture partially failed under load, mark the gap explicitly. Low-consequence output may continue under a documented degraded mode. Actions designated by the coverage contract fail closed or use a synchronous receipt store. A green service trace cannot hide the absence of a mandatory evidence edge.

The decision provenance receipt is generated from verified graph nodes and edges. Free-text generation may format the explanation, but the identifiers, versions, claims, support, transaction and correction state come from the graph.

Worked runtime chainThree claims, one calculation and one side effect

A service agent asks an assistant whether a disputed charge qualifies for reversal and, if so, to open a remediation case. The response contains three material claims: the transaction amount and date, the applicable policy threshold, and the customer’s current eligibility. It derives a deadline, recommends reversal and calls a case-management tool. The provenance objective is not to preserve every generated token. It is to make each claim, calculation and state change reconstructable under the identity, policy, evidence and versions that actually executed.

Begin with the accountable request

The first spine segment records the human identity, the assistant’s workload identity, delegation scope, assigned case, declared purpose, affected customer, requested decision and request schema version. Authentication alone does not establish authority. The segment links to the entitlement result that permits this agent to retrieve the case evidence, produce decision support and create a remediation case, but not to issue a payment or disclose the record outside the approved service interface.

A deterministic correlation identifier is established before retrieval and propagated through services. It is not a customer identifier and does not contain sensitive payload. Delegation and purpose versions are explicit so an auditor can distinguish the human sponsor’s ordinary role from the narrower authority granted to the assistant for this task. If the identity or case relationship changes during execution, the record shows which decision point re-evaluated access.

Capture policy and source authority before relevance

The policy segment identifies the controlling refund rule, effective version, issuer, scope and permissible automation. The source segment names the transaction record, case history and eligibility source, with stable identifiers, checksums where appropriate, valid and recorded times, and access decisions. Candidate generation runs inside authorised partitions. Excluded evidence is represented by safe reason and partition metadata rather than copied protected content.

The search service records its query version, index version, filters, candidate identifiers and rankings. This does not claim every candidate influenced the answer. Selected-context edges identify the exact spans and structured values passed to inference. One retrieved manual is rejected because it is superseded; the graph records the exclusion and controlling replacement. This distinction prevents a later report from claiming support merely because a source appeared somewhere in retrieval.

Keep transformation activities visible

The transaction amount arrives in minor currency units and is normalised through code version N7. The policy threshold is extracted from a source-anchored assertion produced by parser P3 and reviewed under assertion version A9. A redaction step removes an identifier before the text enters the model. Each activity records inputs, output identifiers, version, time and responsible service. The graph carries derivation rather than storing duplicate payload in every node.

A case summary was produced earlier from customer correspondence. Its node retains the original episode references, transformation version and low authority for operational fact. The model may use it to understand the dispute narrative, but the current eligibility claim must come from the authoritative eligibility service. Polished summary prose therefore cannot silently become the decisive source.

Bind each claim to the evidence it actually uses

Claim one states that the disputed transaction occurred on the recorded date for the recorded amount. It links to exact structured fields and their source version. Claim two states that the amount falls within the active policy threshold. It links to the policy assertion and its exception clause. Claim three states that the customer is eligible at decision time. It links to the current eligibility response and records one older case note as contradictory but non-controlling evidence.

The final paragraph can cite all three sources for presentation, but the receipt is generated from claim-level edges. Tests verify entailment and completeness: the linked span must support the atomic claim, and every material claim must have the required support. A paragraph-level citation cannot conceal that one sentence relies only on model prior knowledge. Contradictions remain queryable rather than being excluded to make the narrative appear certain.

Represent the derived deadline as a calculation

The filing deadline uses transaction date, policy interval, declared timezone and a business-calendar version. The calculation activity records those inputs, units, formula and code checksum, rounding or boundary rule, and deterministic output. A model may explain the calculation, but it does not create the authoritative result. Re-execution with the same versions should reproduce it. A citation to a policy paragraph without the source values and algorithm would be insufficient provenance.

If the calendar is corrected later, the supersession edge reaches the calculation, resulting claim and open case task. The system can recompute the deadline and decide whether the difference requires notice or remediation. The original calculation remains historical evidence of what executed rather than being overwritten by today’s value.

Capture the action at the transaction boundary

The recommendation alone has not changed external state. When the assistant requests case creation, the tool enforcement point records the approved contract version, sanitised inputs, case entitlement, idempotency key and policy decision. The tool returns a transaction identifier, created case identifier, resulting state and receipt. A read-back verifies the state. The rollback or cancellation path and current status are linked to the action.

If the tool times out, absence of a response is not proof that no case was created. The idempotency key and transaction lookup resolve uncertainty before retry. Provenance records the reconciliation outcome. This stops a duplicate side effect and gives incident response a deterministic handle that a language-model transcript cannot supply.

Follow the action to an observed effect

The outcome segment records that the case reached the assigned queue, was acknowledged by an owner and produced the required customer review. It distinguishes delivery from business outcome. The assistant’s successful tool call proves only that a case record was created. It does not prove remediation occurred or that the customer was made whole. Coverage defines which later state is necessary for this decision class.

Feedback is typed. A closed case may indicate process completion, not decision correctness. A customer complaint may reveal harm but is not a universal label. Incident, correction and appeal events connect to the originating claim and action so teams can examine outcomes without treating every downstream signal as ground truth.

Generate the decision receipt from verified graph facts

The receipt lists the request and policy versions, claims and support edges, transformation activities, selected and excluded evidence, calculation, model and template, tool transaction, observed state, reviewer and expiry. It also states gaps at the permitted level. Formatting may use natural language, but identifiers and relations come from graph queries with schema validation. The model cannot add an attractive source that was not part of the path.

Receipt verification re-resolves protected links under the auditor’s entitlement. A service agent may see customer-facing sources, a risk reviewer may see policy and transaction metadata, and a security auditor may verify hashes and capture acknowledgements through an approved view. One receipt can therefore support scoped verification without distributing the most privileged payload to every reader.

Map capture to existing observability

Use the distributed trace as the execution skeleton. Enrich selected spans with typed identifiers or emit linked provenance events at authority, transformation and state-change boundaries. Data lineage supplies job, run and dataset relationships. Source annotation supplies exact spans. Audit services record access and approvals. Attestation verifies selected artefacts. A graph projection composes these records for semantic queries without forcing every system to duplicate full payload.

Schema and identifier governance make composition possible. Define deterministic formats for request, source version, transformation, claim, tool transaction and outcome nodes. Use idempotent event ingestion and record producer version. Late provenance events can attach through stable identifiers. Orphan detection finds events that cannot reach an expected request or action root and routes them for repair.

Minimise sensitive data at capture time

Do not solve auditability by copying prompts and records into a universal log. Classify fields and store only what the coverage objective needs. A source node may contain an opaque controlled identifier, version and sensitivity label; authorised systems resolve payload on demand. Claim text may be represented by a protected node and hash when broad audit needs only continuity and integrity.

Tenant and purpose are enforced during graph traversal, not merely on source access. Neighbour counts, source types, action identifiers and correction paths can reveal protected facts. Query services filter before traversal, return safe absence and log provenance access. Retention varies: tool transactions may follow financial or operational evidence policy, while raw model context may have a shorter permitted life.

Design for capture failure under load

Mandatory events use acknowledged delivery, durable queues or synchronous receipt stores proportionate to the action. The coverage contract names which side effects cannot proceed without confirmed capture. A payment, access grant or destructive change can fail closed or remain in a reversible pending state until its authorisation and transaction edges are durable. Low-consequence generation may continue with a marked provenance gap.

Back-pressure should not trigger silent sampling of consequential paths. Health measures include event loss, acknowledgement latency, queue age, orphan edges and incomplete action receipts by class. Degraded-mode tests deliberately remove the tracing collector, lineage service and graph writer. The expected route is explicit: continue lightly, constrain, quarantine or fail closed according to the contract.

Separate integrity verification from semantic review

A manifest signature can prove that an identified issuer signed these bytes and that they have not changed since. The graph records key identity, verification time, manifest version and result. A separate authority edge determines whether that issuer controls the claim for this decision. Support evaluation tests whether the content entails the claim. Temporal checks determine whether the version was valid. Legal and fairness review remain outside cryptographic integrity.

A negative control uses a signed but factually wrong source. Verification succeeds, and the source remains wrong. The Router must not upgrade the decision because the signature is valid. Another control uses an accurate unsigned draft where policy requires verified issuance; the factual content may be plausible, but the authority gate remains unsatisfied. These tests prevent provenance language from becoming an assurance shortcut.

Evaluate claim support and action reconstruction directly

Create test cases with multi-claim paragraphs, distractor sources, partial support, conflicting versions, transformations that change units, summary laundering and missing decisive inputs. Measure whether each material claim has the correct evidence, whether contradictions and exclusions survive, and whether a verifier can reproduce calculations. Citation style and URL presence are not adequate evaluation targets.

For actions, attempt reconstruction from the receipt: identify principal and delegation, policy result, source versions, model and code, exact tool contract, deterministic inputs, transaction, state change, rollback and outcome. Inject retries, timeouts, partial commits and correction. An action passes only if the graph explains what occurred and supports the required response without depending on hidden reasoning.

Make correction a graph operation

When the eligibility source corrects its earlier value, the source service emits a new version and supersession relation. A dependency query finds claims supported by the old node, outputs containing them, caches that reused them, decisions that relied on them, tool actions they justified and affected customers. The consequence policy assigns invalidation, recomputation, review, reversal, notification or remediation.

Consumers record disposition and completion. Some claims remain historically valid as statements of what the system believed; they stop being current support. An action may be irreversible but still require explanation and remedy. Provenance does not automate the remedy choice by itself. It supplies the affected set and evidence needed for accountable action.

Keep the graph useful through ownership and expiry

Every event class has a producer, schema owner, quality objective, retention rule and correction route. Coverage reviews remove fields nobody uses, add missing edges revealed by incidents and confirm that access policies still match organisational roles. Schema evolution preserves older event interpretations. A graph that accumulates unnamed edge variants becomes harder to trust even if its storage is technically complete.

Expire transient context and protected payload while retaining the minimum authorised receipt or hash needed for the reconstruction purpose. Retire nodes from current queries when sources or policies supersede them. Test deletion and restoration so an old backup cannot reactivate revoked evidence. Provenance has a lifecycle; indefinite graph growth is not evidence quality. Routine graph audits should also confirm that every active action class still reaches its required source, authority, transaction and outcome nodes under current access policy.

Interactive instrumentRuntime Provenance Router

Set consequence, evidence, transformation, tool, capture, correction and access conditions. The Router returns one of exactly five routes with the coverage contract, missing edge, retention and correction action. It does not calculate a provenance-completeness score.

Exactly five outcomesCoverage is an operating route, not a score

Use lightweight source citation and operational tracing

Use for public, low-consequence, reversible answers when verified page pointers and ordinary service tracing meet the reconstruction objective.

Bind each material claim to evidence and transformation

Use for multi-claim analysis, calculations and decision support where exact spans, contradiction and derivation versions must be tested.

Capture the full inference, tool, action and outcome provenance chain

Use when a consequential side effect requires principal, policy, context, tool contract, transaction, changed state, rollback and observed outcome.

Quarantine the output or action until the broken chain is repaired

Use when identity, decisive input, transformation, transaction, capture or access is missing or unsafe under the coverage contract.

Revoke, replay or review downstream effects after correction

Use when supersession reaches dependent claims, actions or affected parties through the graph.

Negative controlsTen tests of semantic continuity

Evidence boundaryStandards supply relationships and records, not decision correctness

W3C PROV supplies entities, activities, agents and relations for generation, use, derivation, attribution, association and delegation. Web Annotation supports precise evidence targets. OpenTelemetry and OpenLineage support execution and data-event interoperability. These foundations can be mapped into the spine without forcing one storage product.

in-toto, SLSA and C2PA provide bounded patterns for verifiable production steps and content manifests. Their guarantees depend on governed identities, keys and verification, and they do not prove factual truth. Citation research treats claim-source attribution as a capability requiring direct evaluation. Dataset and model documentation provide lifecycle context rather than per-decision runtime proof.

NIST sources support provenance, information integrity, audit, access, monitoring and accountability within their scope. EU AI Act documentation, logging, record-keeping, transparency, oversight, monitoring and correction obligations depend on the system, actor, provision and application timeline. This article does not treat the spine as legal compliance by itself.

The Runtime Provenance Spine, Claim-Action Evidence Graph, coverage contract, decision receipt and Router are this article’s synthesis. They prove only what their verified capture and access boundaries support, never truth, legality, fairness or correctness in the abstract.