W3C PROV for LLM Context Provenance: A Testable Profile

Executive Summary

W3C PROV for LLM context provenance is useful only after an application profile removes freedoms that are harmless in a general provenance model but fatal to independent reconstruction. PROV defines an entity as a thing with fixed aspects and distinguishes activities and responsible agents around it ^[1]. Those concepts can describe an answer, its claim, a retrieved source snapshot, the extraction or generation step, and the accountable system or person. They do not, by themselves, require the source version, quoted span, content digest, observation time, or reason a field is unknown.

The proposed answer-evidence profile therefore makes those reconstruction facts mandatory. A conforming export must let a second implementation recover six things without access to the producing system: the answer and atomic claim, the exact source state, the supporting span, the transformations and retrievals, the responsible agents, and the times at which the source was observed and each artifact was generated. Identifiers are already required for PROV entities, activities, and agents, while activity times are optional ^[2]. This profile deliberately strengthens the time requirement and uses a named PROV bundle to identify who asserted the lineage. Exact resource versions and uniform timestamp precision are established interchange practices ^{[3] [4]}.

Conformance requires more than parsing. The fixture must survive two independent processing paths, preserve typed relations, timestamp precision, source fixity, and unknown reasons, and respond correctly to source-revision, alternate-representation, and changed-attribution mutations. Reconstruction completeness is reported as recovered required facts divided by required fixture facts, with every omission named. The score is a profile metric, not a W3C metric. This distinction matters because the 2013 PROV implementation report used 280 constraint tests ^[5]. Independent conformance guidance cautions that execution ordering can be necessary for perfect reproducibility ^[6].

Evidence from current language-model research reinforces the separation between lineage and answer quality. MatPROV reports 2,367 procedures from 1,568 papers, yet explicitly notes that automated extraction can omit information ^[7]. ALCE found incomplete citation support 50% of the time, while TREC separately evaluates support, fluency, retrieval, and nugget coverage ^{[8] [9]}. Attributable to Identified Sources says source quality needs a complementary method ^[10]. A valid PROV graph can support traceability, but it cannot establish truth, authority, permission, or legal sufficiency.

Introduction and Background

An answer citation is a pointer. Lineage is a path through source states and transformations. Provenance is a structured account of the entities, activities, and agents involved in producing an artifact. Explanation concerns why a model produced an output, which may require evidence about model behavior that a lineage graph does not contain. Treating these terms as synonyms produces exports that look documented but cannot be replayed or challenged.

The practical question for an enterprise information architect is narrow: can another system receive an export and reconstruct the claim, exact source state, transformation, responsible identity, and observation time? This is the reconstruction test. It evaluates the contract visible at the boundary, not prompts, queues, retrieval architecture, or model internals. It also avoids equating a familiar URL with a preserved source. DataCite recommends a new Digital Object Identifier for a major version and a relation to the previous version ^[3]; Zenodo similarly recommends citing a version-specific DOI when exact recovery matters ^[11]. Crossref uses controlled relationship terms to connect versions and derivations rather than relying on free text ^[12].

W3C's core PROV recommendations provide generation, usage, derivation, attribution, association, revision, and alternate-representation concepts. PROV is therefore a strong interchange foundation. It is not an LLM answer schema, and it does not select a JSON serialization or prescribe evidence-span fields. FAIR guidance independently calls for data and metadata to carry detailed provenance ^[13].

For a system of record, the boundary guarantee is the relevant comparison. Reliable Context states that exported values carry source, excerpt, locator, and dates, and that past record states can be reproduced. Those are observable export properties that this profile can test. They do not reveal or imply how the product is built.

In practical terms, a W3C PROV profile for AI makes AI context lineage explicit but does not automatically make all answers true. Reproducible LLM answers additionally require recoverable inputs, stable identities, typed transformations, and declared unknowns. Using PROV-O for generative AI supplies a graph vocabulary; the application profile supplies the obligations that make an exported graph reconstructable.

Key Changes

From citation presence to exact source state

The first change is from asking whether an answer has a citation to asking whether the cited evidence can be recovered exactly. A URL alone may resolve to a different representation tomorrow. The profile therefore models a logical source, a dated source snapshot, and a quoted evidence span as distinct entities. The snapshot is a specialization of the logical source. PROV says a specialization shares the general entity's aspects while adding more specific ones ^[1].

Fixity and identity serve different purposes. A persistent identifier locates a named version; a digest detects byte change. The Library of Congress PREMIS dictionary defines fixity as evidence that a digital object did not change between two times ^[14]. NIST likewise describes message digests as a way to detect later changes ^[15]. Software Heritage identifiers bind software objects to cryptographic hashes of their properties ^[16]. Neither a digest nor an identifier proves the source is accurate. Together with the observation time and locator, they make the referenced state testable.

The minimum source-state export therefore includes:

• Logical source identifier: a stable Internationalized Resource Identifier or equivalent scoped identifier.
• Snapshot identifier: a distinct identifier for the observed representation.
• Version locator: a version-specific DOI, revision identifier, archive locator, or declared absence.
• Observation time: the time the producing system obtained the representation.
• Media type and language: sufficient interpretation context for the retained bytes or text.
• Content digest: algorithm identifier plus digest value, not an unlabeled hash.
• Evidence span: verbatim text plus page, section, byte, character, or selector coordinates.
• Access outcome: found, not found, blocked, or not applicable, always with a reason.

From a flat citation to typed derivation

The second change is to represent the production path. In PROV, generation and usage connect activities to produced and consumed entities, while derivation relates a resulting entity to an input ^[1]. An LLM context export can use these relations without claiming that derivation proves semantic support. Attribution research similarly treats source corroboration as a separate judgment ^[10].

The profile distinguishes at least four activities:

• Observation: acquires the identified source snapshot at a recorded time.
• Retrieval: selects a snapshot or passage for a particular answer run.
• Extraction: converts the evidence span into a normalized claim.
• Generation: uses claims or passages to produce the answer artifact.

These activities must not be collapsed when separate events are observable. A system may omit an activity it genuinely cannot observe, but it must emit an unknown reason rather than fabricate a node or silently leave a field empty. This makes epistemic absence machine-readable.

From provenance content to accountable assertion

The third change records who asserted the lineage. PROV attribution ascribes an entity to an agent, while association can express activity responsibility ^[1]. The export should identify the software service, configured model release when known, organization, and human reviewer when one participated. It should not imply that a model itself bears organizational accountability. Human attribution studies used five annotators per example, evidence that support judgments can require multiple reviewers ^[10].

A named bundle contains the lineage statements. A second bundle-level assertion identifies the exporting agent, profile version, creation time, and validation report. This is provenance of provenance: the consumer can distinguish what happened from who made the claim about what happened. A malicious or mistaken exporter can still assert false lineage. PROV-N explicitly warns that untrusted documents may mislead consumers ^[2].

The Answer-Evidence Application Profile

W3C's Profiles Vocabulary defines a profile as a specification that constrains, extends, combines, or guides the use of other specifications ^[17]. The rules below are therefore this report's proposed LLM Answer Evidence Profile 1.0, not requirements of PROV-DM. Its versioned identifier follows the same general approach as current RO-Crate profile guidance ^[18].

Table 1 maps the fields that a receiver needs to reconstruct an answer. “Required” means required by this profile, even where base PROV permits omission. Explicit occurrence constraints are established application-profile practice ^[19].

The table makes two design decisions explicit. First, a claim is an entity, not merely a string property on the answer, so that multiple answers can derive from or revise it. Second, an evidence span is separate from the source snapshot, so the export can distinguish source fixity from the precise support selected within it. Dublin Core application-profile guidance recognizes explicit occurrence constraints for repeatability ^[19]. That discipline is necessary here because an unconstrained graph can be valid PROV and still fail reconstruction.

Relation choices

The profile uses relations narrowly:

• wasDerivedFrom: the claim derives from an evidence span, and the answer derives from one or more claims.
• wasGeneratedBy: every snapshot, claim, answer, and lineage bundle identifies its producing activity.
• used: observation, extraction, and generation activities identify their input entities.
• wasAttributedTo: the bundle and answer identify their accountable exporting or publishing agent.
• wasAssociatedWith: each observable activity identifies the responsible system or person.
• specializationOf: a dated snapshot specializes the logical source.
• wasRevisionOf: a new claim or answer state revises an earlier state when the same artifact is intentionally updated.
• alternateOf: two representations present aspects of the same thing without asserting that either revises the other.

PROV defines alternates as presenting aspects of the same thing, and revision as a subtype of derivation whose result is a revised version ^[1]. Exporters should not use these relations interchangeably.

Implementation Considerations and Process Changes

The profile is serialization-neutral at the conceptual layer. PROV-O, PROV-XML, and PROV-N provide different encodings of the model, while JSON-LD 1.1 has its own processing specification. The dedicated PROV-JSONLD document is a 25 August 2024 Member Submission, not a W3C Recommendation ^[20]. A contract may select it, but must accurately state that status. It should separately identify the canonical JSON procedure, such as the deterministic property ordering specified by RFC 8785, and state whether a digest covers HTTP representation data or content ^{[21] [22]}.

Table 2 is a minimal worked graph. Identifiers are illustrative, while the relation pattern is normative PROV vocabulary constrained by the proposed profile.

This graph is intentionally small. It does not expose prompts, private context, or implementation topology. It establishes what an independent receiver needs to connect evidence to a claim and a claim to an answer. Where disclosure policy blocks a value, the export preserves the node and relation shape while declaring the restriction and reason. That is more informative than removing the edge, which would make “not observed,” “not retained,” and “not permitted” indistinguishable.

Serialization and fixity decisions

Implementers should publish the following choices with the profile:

• Canonical form: state whether digests cover source bytes, normalized text, a canonical JSON form, or a canonical RDF dataset.
• JSON canonicalization: RFC 8785 constrains input and deterministically sorts object properties ^[21].
• RDF canonicalization: name the algorithm and whether comparison targets graph isomorphism or lexical identity.
• HTTP digest semantics: distinguish representation data from content because RFC 9530 defines separate fields ^[22].
• Timestamp lexical form: specify timezone, fractional-second precision, and normalization. RFC 3339 lexical ordering assumes uniform fractional-second digits ^[4].
• Profile versioning: use a versioned profile identifier. RO-Crate guidance recommends a major.minor version in the profile URI ^[18].
• Identifier persistence: if software is evidence, a Software Heritage identifier uses strong cryptographic hashes over object properties ^[16].

These details are not cosmetic. Python prov documentation notes that an original non-whole-minute timezone offset is not preserved through a serialization round trip ^[23]. A round trip can retain the instant while losing lexical identity. The conformance report must state which identity notion it tests.

Conformance and Reconstruction Testing

The conformance suite should contain a public fixture, expected normalized graph, mutation set, and machine-readable results. SHACL, the Shapes Constraint Language, is suitable for cardinality and datatype checks on PROV-O exports, provided the profile states its supported feature subset. PROV constraint validation remains a separate layer, covering uniqueness, event ordering, impossibility, and type constraints ^[24]. Round-trip results must also disclose known lexical losses such as changed timezone offsets ^[23]. Exact reproducibility may additionally depend on capturing execution order ^[6].

The test sequence is:

1. Parse: load the canonical fixture in serializer A and serializer B.
2. Validate base PROV: check each graph against PROV constraints applicable to its representation.
3. Validate profile: apply cardinality, datatype, identifier, and time-order rules.
4. Round trip: serialize A to B's format and back, then compare normalized graphs.
5. Reconstruct: recover every required fixture fact using only the exported package.
6. Mutate: change one source version, alternate representation, attribution, timestamp precision, or unknown reason at a time.
7. Detect: require the expected graph difference and validation outcome for every mutation.
8. Report: publish tool versions, profile version, fixtures, differences, and unresolved identifiers.

Table 3 is the conformance matrix to publish for two independent paths. The cells state acceptance criteria, not unmeasured product results.

The interpretation must remain field-level. A single pass percentage can conceal loss of attribution while preserving less consequential labels. PROV equivalence can be tested at the normalized graph layer, but the answer-evidence profile additionally requires semantic identity for its extension fields. RFC 3339 warns that lexical timestamp ordering depends on uniform fractional-second precision ^[4].

Mutation expectations

• Source revision: create a new snapshot and connect it with wasRevisionOf; the earlier claim remains reproducible.
• Alternate representation: connect HTML and PDF snapshots with alternateOf; do not infer byte identity.
• Changed attribution: replace the asserting agent; normalized graphs must differ even if evidence is unchanged.
• Changed span: preserve source snapshot but update the span entity and all downstream derivations.
• Timestamp truncation: fail precision preservation even when the instant remains comparable.
• Blocked locator: retain the entity and change access status plus reason; do not erase the claim silently.
• Unknown digest algorithm: fail fixity validation because the digest cannot be interpreted.
• Orphan claim: fail reconstruction when a supported claim lacks a path to an evidence span.

Data Analysis and Evidence

The quantitative core of this proposal is reconstruction completeness:

completeness = recovered required facts / required facts in the fixture

If a fixture contains 48 required facts and a receiver recovers 46, completeness is 95.8%. This is a labeled hypothetical calculation, not a measured implementation result. The report must also name the two missing facts. Field-weighted variants may be published, but the unweighted fraction remains necessary so weights cannot hide omissions.

Existing evidence shows why syntactic success is insufficient. A PROV document can satisfy base constraints while omitting the source snapshot, evidence span, or asserting identity required by this profile. Similarly, ALCE observed that correctness and citation quality plateaued at different context counts ^[25]. One successful validation result should not be generalized to another evaluation dimension.

MatPROV offers a recent, bounded reuse case. Its evaluation sampled 30 papers containing 44 procedures and used expert-created PROV-JSONLD ground truth ^[7]. Its best one-shot example improved structural F1 by 6.4% and parametric F1 by 7.6% over zero-shot prompting ^[7]. The paper also omits agent nodes because experimenters or institutions are treated as implicit ^[7]. It therefore demonstrates useful PROV-shaped extraction, but not conformance to this profile's accountable-agent requirement.

Citation research measures other constructs. ALCE separates fluency, correctness, and citation quality ^[8] and uses a natural-language inference model to test whether citations entail statements ^[25]. It found correctness plateaued at one passage and citation quality at three in one experiment ^[25]. TREC's 2024 RAG Track separately evaluated nugget coverage, citation support, fluency, and retrieval ^[9]. These studies support a multidimensional report, not a claim that provenance completeness measures answer truth.

Case Studies and Real-World Examples

MatPROV as a bounded reuse case

MatPROV used prompts designed for compliance with a PROV-JSONLD schema ^[7]. Its graph starts from entity, activity, and agent node types, although the published extraction omits agents ^[7]. For an answer-evidence export, that omission becomes a declared conformance failure rather than an implicit modeling choice. The example is valuable precisely because it exposes the difference between reusing PROV-DM concepts and satisfying a particular application profile.

Attribution benchmarks as complementary evidence

Attributable to Identified Sources defines attribution as corroboration by an identified source ^[10]. Its human evaluation used five annotators per example, reflecting difficult judgment boundaries ^[10]. MIRAGE further distinguishes plausible self-citation from faithful reflection of which context a model used ^[26]. Provenance and attribution should therefore be evaluated side by side: one tests reconstructable lineage, the other tests whether evidence actually supports output text. Source quality remains a complementary evaluation rather than an implication of attribution ^[10].

Microsoft Research's FakeWiki benchmark adds a different layer, training-data attribution. It contains 3,537 fabricated Wikipedia-style articles with controlled provenance ^[27]. Its reported supervised model raised mean Recall@10 from 35.0 to 52.2 relative to the strongest retrieval baseline ^[27]. This measures recovery of known training provenance, not the answer-evidence contract defined here.

Implications and Future Directions

An enterprise interchange decision should begin with the reconstruction test, not with a preferred graph technology. A passing exporter publishes its profile version, fixture, validators, two-path matrix, and every missing field. A passing importer reconstructs the same required facts and preserves the intended relation types. A system that produces valid PROV but cannot recover the observed source state should be described accurately as PROV-compatible but nonconforming to this answer-evidence profile.

Four boundaries remain important:

• Truth: lineage says where a claim came from, not whether the claim is correct.
• Authority: attribution names an agent, but does not prove that agent is competent or authorized.
• Permission: a retrievable source and a digest do not establish a right to retain or disclose it.
• Legal sufficiency: technical conformance does not determine whether evidence satisfies a jurisdiction, contract, or proceeding.

FAIR principle R1.2 calls for data and metadata to be associated with detailed provenance ^[13]. That broad objective is compatible with this narrow profile, but it does not replace field-level tests. Likewise, as of September 2026, ISO/IEC FDIS 5181 on data provenance remained in approval rather than publication as an International Standard ^[28]. Implementers should publish exact conformance targets and versions instead of using “standards-based” as an undifferentiated claim.

Future profile revisions should remain additive where possible. New evidence-selector types, canonicalization algorithms, or agent roles can be introduced without weakening the six reconstruction facts. Crossref's controlled relationship vocabulary illustrates why typed version and derivation links are preferable to free text ^[12]. Every revision should ship with migrations, old and new fixtures, and explicit expected graph differences.

Frequently Asked Questions (FAQs)

Is W3C PROV an LLM data provenance standard?

No. PROV is a general provenance family. It supplies concepts and relations that an LLM context provenance profile can constrain. The proposed answer-evidence profile adds mandatory source-state, span, digest, time, unknown-reason, and conformance rules that PROV-DM does not mandate.

Is a citation enough for LLM answer traceability?

No. A citation may identify a page without preserving the observed version, selected span, transformation, or asserting identity. Traceability requires a typed path from answer to claim to evidence span to source snapshot, plus responsible agents and times.

Does PROV-O require JSON-LD?

No. PROV-O is an OWL 2 representation of PROV and can use multiple RDF serializations. JSON-LD can be selected by an application contract, but PROV-DM does not mandate it. The publication status of the selected PROV-JSONLD mapping should be stated precisely. Thus, PROV-O for generative AI is a modeling choice, not a mandated wire format.

How should an organization audit LLM context?

It should test an exported fixture through two independent processing paths, validate base PROV and profile constraints, reconstruct all required facts without producer access, mutate one fact at a time, and publish field-level differences. The audit should report completeness and omissions, not only a pass percentage. An observable export guarantee can be checked against the source, excerpt, locator, and dates actually delivered.

Does provenance explain why the model produced an answer?

Not necessarily. Provenance can record context supplied and transformations observed. Behavioral explanation may require model-specific causal evidence. A 2026 metric audit distinguishes provenance or topicality, generated-answer attribution, and fact-check entailment as separate constructs ^[29].

What must a conformance publication contain?

At minimum: the versioned profile, canonical fixture, expected normalized graph, shape or schema rules, serializer and validator versions, mutation fixtures, complete results, reconstruction numerator and denominator, and a list of each unresolved or lost field.

Conclusion

W3C PROV provides the right conceptual vocabulary for LLM context provenance, but independent reconstruction requires a stricter application profile. The decisive export contains identifiable answer and claim entities, an exact source snapshot and supporting span, typed observation and transformation activities, responsible agents, observation and generation times, and a named bundle whose own attribution is explicit.

Conformance then becomes observable. Two implementations parse the same fixture, exchange it through different serializations, compare normalized graphs, reconstruct every required fact, and detect controlled mutations. The reported completeness fraction is useful only alongside the identity of every missing field. Base PROV validity, profile validity, round-trip preservation, and evidential support are separate results. MatPROV's own warning that automated extraction can omit information illustrates why the missing-field list matters ^[7].

This separation is the central design rule. PROV can make a chain of custody interoperable. Content digests can expose change ^[15]. Persistent identifiers can name versions ^[11]. Attribution evaluations can test support. None of them alone establishes truth, authority, permission, explanation, or legal sufficiency. An export contract is defensible when it states exactly which of these questions it answers, publishes the fixture and profile version, and lets an independent system reproduce the answer-evidence path without privileged access to the producer.