Provenance

Part of the WebMEM® Protocol
Location: /protocol/provenance/
Status: Current Draft
Last Updated: 2026-08-24

Overview

Provenance is the evidentiary lineage of knowledge represented through the WebMEM Protocol.

It establishes where published knowledge came from, who or what produced it, what source material supports it, whether it was transformed or derived, and what happened between the originating source and the assertion represented within the Semantic Data Template (SDT).

Provenance is not an optional trust enhancement to WebMEM.

It is a structural requirement of the knowledge model.

Without provenance, WebMEM can represent a claim. With provenance, WebMEM can represent the lineage of that claim.

This distinction is fundamental because two assertions with the same subject, predicate, and value may represent materially different knowledge when their origins or derivations differ.

Why Provenance Is Structural

Consider the assertion:

average_monthly_premium = 15.26 USD

Several materially different histories could produce that same assertion.

For example:

Source Authority
→ directly publishes 15.26 USD

or:

Source Authority
→ publishes underlying records
→ Publisher selects applicable records
→ Publisher calculates arithmetic mean
→ 15.26 USD

or:

Source Dataset A
        ↘
         Publisher combines data
        ↗
Source Dataset B
        ↓
Publisher calculates result
        ↓
15.26 USD

The resulting number may be identical.

The knowledge represented by those three cases is not.

In the first case, the source authority published the value directly.

In the second, the publisher derived the value from source records.

In the third, the publisher created a derived assertion using multiple sources.

If provenance is removed, those distinctions collapse.

The value survives. Its evidentiary meaning does not.

Provenance Is Part of Meaning

WebMEM treats provenance as part of the semantic context necessary to interpret knowledge correctly.

Consider the larger knowledge model:

Semantic Concern	Question Answered
Identity	What entity or object does this knowledge describe?
Fragment Class	What kind of knowledge is being represented?
Assertion or Structure	What does the publisher actually state?
Context	Where, when, for whom, or under what conditions does it apply?
Provenance	Where did the knowledge come from, and how did it reach its published form?
Relationships	How does the knowledge connect to other objects?
Resolution	What must be known or traversed before the applicable knowledge can be reached?

Remove identity and the machine may not know what an assertion describes.

Remove context and the machine may not know where or when it applies.

Remove provenance and the machine cannot determine where the assertion came from or what transformation produced it.

In each case, the visible value may remain intact while part of its meaning collapses.

The Provenance Chain

Provenance may be understood as the lineage connecting an originating source to the knowledge represented within an SDT.

A complete lineage may include:

Authority / Creator
        ↓
Source Resource
        ↓
Source Dataset or Record
        ↓
Acquisition
        ↓
Normalization
        ↓
Transformation
        ↓
Derivation
        ↓
Published WebMEM Assertion

Not every assertion requires every stage.

A source-observed assertion may require only a short lineage:

Source Dataset
→ Source Record
→ Published Assertion

A derived assertion may require a longer lineage:

Source Dataset
→ Applicable Records
→ Publisher Transformation
→ Derivation Method
→ Published Derived Assertion

A multi-source assertion may require multiple branches:

Source Dataset A ──┐
                   │
Source Dataset B ──┼──→ Publisher Derivation → Published Assertion
                   │
Source Dataset C ──┘

The purpose of provenance is not to maximize the length of the lineage.

The purpose is to preserve the stages necessary to understand how the published knowledge came to exist in its current form.

Source-Observed Provenance

A source-observed assertion represents knowledge obtained from an identified source without changing its substantive meaning.

For example:

CMS Plan Benefit Package
→ plan:H5521-290-0
→ maximum_out_of_pocket = 4900 USD

The publisher may normalize the representation before publication:

Source:
"$4,900"

Published representation:
value = 4900
datatype = number
unit = USD

The formatting changed.

The substantive assertion did not.

A DataFragment may therefore identify the source dataset and allow multiple source-observed assertions to inherit that provenance when the same lineage genuinely applies to all of them.

The publisher should not represent itself as the originating authority for a source-observed assertion merely because it normalized or serialized the source knowledge through WebMEM.

Normalization

Normalization is a transformation that changes representation without materially changing the substantive meaning of the source knowledge.

Examples may include:

converting formatted currency into a numeric value and explicit unit;
normalizing capitalization;
converting dates into a consistent representation;
mapping a documented source code to its canonical label;
normalizing whitespace or presentation characters;
or mapping a source identifier into the publisher’s canonical identity representation.

For example:

Source value:
"$0.00"

Normalized assertion:
value = 0
unit = USD

Normalization should remain distinguishable from derivation.

If a transformation introduces a new calculation, classification, aggregation, interpretation, or conclusion, it is no longer merely representational normalization.

Derived Provenance

A derived assertion is knowledge produced by applying a calculation, aggregation, classification, transformation, comparison, or other reproducible method to underlying knowledge.

For example:

CMS Landscape Records
        ↓
Filter to applicable county and plan year
        ↓
Identify applicable plan population
        ↓
Extract monthly premiums
        ↓
Calculate arithmetic mean
        ↓
average_monthly_premium = 15.26 USD

In this case, CMS provides the source knowledge.

CMS did not necessarily publish the resulting average.

The publisher produced the derived assertion.

Provenance should preserve that distinction.

A derived assertion should therefore identify or make resolvable:

the source knowledge used as input;
the applicable input population or record set;
the publisher or process responsible for the derivation;
the derivation method;
the temporal, geographic, or other scope applied during derivation;
and the resulting assertion.

A source may be authoritative for the inputs without being the creator of the derived output.

Multi-Source Provenance

Some assertions depend on more than one source.

For example:

CMS Landscape
      │
      ├── plan availability
      │
      └─────────────┐
                    │
                    ▼
              Publisher Derivation
                    │
                    ▼
              market_share = 18.4%
                    ▲
                    │
      ┌─────────────┘
      │
CMS Monthly Enrollment
      │
      └── enrollment

A single generic source reference would not adequately represent this lineage.

Multi-source provenance should preserve:

each material source;
the role each source played in the derivation;
the transformation or calculation connecting the inputs;
and the publisher responsible for producing the resulting assertion.

Composition within one SDT does not make multiple sources equivalent.

One published assertion may have one lineage with multiple evidentiary branches.

Provenance Scope

Provenance may apply at different levels of the WebMEM architecture.

Conceptually:

SDT
│
├── Dataset-Level Context
│
├── Fragment A
│   ├── Shared Provenance
│   │
│   ├── Assertion
│   ├── Assertion
│   └── Assertion
│
└── Fragment B
    ├── Assertion
    │   └── Assertion-Specific Provenance
    │
    └── Assertion

The correct provenance scope is the highest level at which the lineage remains accurate and unambiguous.

If every assertion in a DataFragment originates from the same source dataset under the same applicable conditions, the fragment may establish shared provenance.

If one assertion originates from a different source, that assertion requires more specific provenance.

If an SDT contains fragments based on several datasets, the page-level dataset declaration should not be treated as though it establishes identical source provenance for every fragment.

Provenance Inheritance

WebMEM allows provenance to be inherited when the same lineage genuinely applies to multiple knowledge objects.

For example:

DataFragment
  entity: plan:H5521-290-0
  plan_year: 2026
  provenance: CMS PBP

  monthly_premium = 0 USD
  primary_care_copay = 0 USD
  specialist_copay = 35 USD
  maximum_out_of_pocket = 4900 USD

All four assertions may inherit the fragment-level provenance if they genuinely originate from the same applicable source.

Now consider:

DataFragment
  entity: plan:H5521-290-0
  plan_year: 2026
  provenance: CMS PBP

  monthly_premium = 0 USD

  enrollment = 2136
    provenance: CMS Monthly Enrollment
    enrollment_month: 2026-07

The enrollment assertion must not inherit the PBP provenance.

The more specific provenance overrides the broader fragment context.

Shared provenance may be inherited. Material provenance differences must remain explicit.

Source Creator, Publisher, and Deriving Publisher

Several different actors may participate in the lineage of one WebMEM assertion.

Those roles should not be conflated.

For example:

Centers for Medicare & Medicaid Services
= creator / authority for source dataset

Publisher
= publisher of the page-level WebMEM dataset

Publisher Data Pipeline
= normalization or derivation process

WebMEM
= representation protocol

The creator of the source dataset remains the creator of that source.

The publisher of the WebMEM dataset is responsible for the machine-facing dataset it publishes.

When the publisher calculates a new value from source data, the publisher is responsible for that derivation.

WebMEM does not become the source or authority for an assertion merely because the assertion is represented using the WebMEM Protocol.

Source Authority and Publisher Assertion

Provenance should allow a consuming system to distinguish among statements such as:

CMS published X.

The publisher reproduced X from CMS.

The publisher normalized X from CMS.

The publisher derived X from CMS data.

The publisher derived X from CMS data and another source.

These statements may refer to the same subject and even the same resulting value.

They represent different evidentiary relationships.

A consuming system cannot evaluate those differences if the publisher collapses all of them into:

source = CMS

WebMEM provenance exists to preserve the more accurate lineage.

Temporal Provenance

Time participates in provenance in several distinct ways.

A source may have one publication date, another retrieval date, a different effective period, and a different applicability period.

The WebMEM representation itself may then have its own generation and modification dates.

For example:

Source Published:
2026-08-01

Source Retrieved:
2026-08-05

Applicable Plan Year:
2027

WebMEM Representation Generated:
2026-08-06

WebMEM Representation Modified:
2026-08-10

These dates are not interchangeable.

Temporal Concept	Meaning
Published	When the source or information resource was published.
Retrieved	When the publisher obtained or accessed the source.
Effective	When a policy, rule, value, or other source knowledge becomes effective.
Applicable	The period for which the represented knowledge applies.
Generated	When the publisher created the WebMEM representation or derived output.
Modified	When the published representation was materially changed.

Temporal provenance should preserve whichever distinctions are necessary to determine lineage and applicability correctly.

The newest source is not necessarily the currently applicable source, and the most recently generated representation is not necessarily evidence of a newer underlying fact.

Provenance and MetaFragment

A MetaFragment may describe an information resource or dataset that serves as a source for other WebMEM knowledge.

For example:

MetaFragment
  entity: dataset:cms-pbp-2026
  title: CMS Plan Benefit Package
  creator: CMS
  published: ...
  version: ...
  canonical_resource: ...

DataFragment
  provenance_ref:
    dataset:cms-pbp-2026

The MetaFragment describes the source object.

The provenance relationship establishes that the DataFragment or assertion descends from or is supported by that source.

These are different semantic functions.

MetaFragment answers: What is this source resource?

Provenance answers: How does this published knowledge relate to that source?

Provenance and Dataset JSON-LD

Schema.org Dataset JSON-LD describes the page-level WebMEM dataset.

That dataset may contain knowledge originating from several external sources.

For example:

Dataset JSON-LD
  publisher: Example Publisher
  dataset: County Medicare WebMEM Dataset

        ↓

SDT
├── DataFragment
│   └── provenance: CMS Landscape
│
├── DataFragment
│   └── provenance: CMS Enrollment
│
└── DerivedStatsFragment
    └── provenance:
        CMS Landscape
        + CMS Enrollment
        + Publisher Derivation

The Dataset declaration describes the publisher’s composed machine dataset.

It does not replace the provenance of the knowledge contained within that dataset.

Likewise, identifying the publisher of the WebMEM dataset does not make that publisher the creator of every source represented inside it.

Read Dataset Declaration and SDT Mapping →

Provenance and Facts

Provenance is especially important for factual assertions because factual values often survive extraction more easily than their evidentiary context.

Consider:

maximum_out_of_pocket = 4900 USD

The assertion identifies the value and its meaning, but provenance establishes its evidentiary origin.

For example:

subject: plan:H5521-290-0
predicate: maximum_out_of_pocket
value: 4900
unit: USD
plan_year: 2026
source: CMS Plan Benefit Package
source_record: applicable plan benefit record
derived: false

If the same value were calculated, inferred, copied from a secondary source, or carried forward from a previous year, the visible assertion might still read 4900 USD.

The provenance would be materially different.

This is why factual assertions cannot be understood solely from their subject, predicate, and value.

Provenance distinguishes the history of the assertion from the content of the assertion.

Read Facts and Assertions →

Provenance and Derived Statistics

Derived knowledge places additional requirements on provenance because the published assertion did not necessarily exist in the source material in the form presented by the publisher.

Consider:

zero_premium_percentage = 61.9 percent

A useful provenance chain may need to establish:

Source Dataset
      ↓
Applicable Geography
      ↓
Applicable Plan Year
      ↓
Defined Plan Population
      ↓
Identify Plans with Premium = 0
      ↓
Count Qualifying Plans
      ↓
Divide by Total Applicable Plans
      ↓
61.9 percent

The resulting percentage is publisher-derived knowledge.

The source dataset supports the inputs.

The publisher is responsible for:

selecting the applicable population;
applying the qualifying condition;
performing the calculation;
and publishing the resulting assertion.

A provenance statement that merely identifies the source dataset would omit the derivation that produced the published value.

Derived provenance must preserve both the evidence and the transformation.

Provenance and Relationships

Provenance is itself relational.

It connects a published knowledge object to the sources, processes, and other knowledge objects from which it descends.

Conceptually:

Assertion
→ sourcedFrom
→ Source Record

Derived Assertion
→ derivedFrom
→ Source Dataset

Derived Assertion
→ generatedBy
→ Publisher Process

Fragment
→ supportedBy
→ MetaFragment

Normalized Assertion
→ normalizedFrom
→ Source Value

The exact relationship vocabulary may vary according to the applicable representation, but the semantic distinction among these relationships should remain clear.

For example, derivedFrom communicates something materially different from sourcedFrom.

Relationships allow provenance to represent lineage rather than merely attach a source label to an assertion.

Read the Relationships specification →

Provenance and Resolution

Provenance may itself affect whether knowledge can be resolved safely.

For example, a machine may encounter two assertions about the same subject and predicate:

Assertion A
  plan_year: 2025
  source_version: 2025 CMS PBP
  value: 4200 USD

Assertion B
  plan_year: 2026
  source_version: 2026 CMS PBP
  value: 4900 USD

The machine cannot safely choose between those assertions without resolving the applicable time period.

Likewise, two assertions may originate from sources with different scopes, authorities, publication dates, or methodologies.

A resolution path may therefore include provenance:

Information Need
→ Entity
→ Applicable Time
→ Applicable Source
→ Applicable Assertion

or:

Assertion
→ Provenance
→ Source Version
→ Applicability
→ Resolution

Provenance does not tell the consuming system which source it must prefer.

It provides the lineage necessary for the consuming system to understand what it is comparing.

Read the WebMEM Resolution Model →

Provenance Is Not Citation

A citation and provenance are related but different concepts.

A citation generally identifies a source or resource associated with a statement.

For example:

Source: CMS Plan Benefit Package

Provenance describes the lineage connecting that source to the published knowledge.

For example:

CMS Plan Benefit Package
→ retrieved 2026-08-05
→ applicable plan record selected
→ currency representation normalized
→ published as:
  maximum_out_of_pocket = 4900 USD

For derived knowledge:

CMS Landscape
→ applicable county records
→ filtered to plan year 2026
→ arithmetic mean calculated by publisher
→ published as:
  average_monthly_premium = 15.26 USD

A citation points toward evidence.

Provenance describes the history connecting the evidence to the assertion.

A WebMEM representation may contain both citations and provenance, but a citation alone does not necessarily provide sufficient lineage for the knowledge being represented.

Provenance Is Not Trust Scoring

Provenance does not assign a universal trust score to an assertion, source, publisher, or dataset.

The current WebMEM Protocol does not define:

source authority scores;
publisher trust scores;
retrieval fitness scores;
confidence rankings based solely on provenance;
or universal rules determining which source a consuming system should trust.

Instead, WebMEM exposes the lineage that a consuming system may evaluate.

For example, provenance may allow a machine to distinguish:

Government source
→ directly observed value

from:

Government source
→ publisher calculation
→ derived value

from:

Secondary source
→ publisher interpretation
→ editorial assertion

A consuming system may evaluate those lineages differently.

WebMEM does not prescribe the result of that evaluation.

WebMEM publishes provenance. It does not calculate trust from provenance.

Provenance Is Not Proof of Truth

A complete provenance chain does not prove that an assertion is true.

A source may contain errors.

A publisher may select the wrong record.

A normalization may be incorrect.

A derivation method may be inappropriate.

A calculation may contain an error.

An assertion may be outdated or applied outside its valid scope.

Provenance makes those relationships inspectable.

It does not eliminate the possibility of error.

A consuming system remains free to evaluate:

source authority;
source quality;
methodology;
recency;
corroboration;
internal consistency;
publisher credibility;
and other signals relevant to its determination.

Provenance establishes lineage, not truth by declaration.

Provenance Is Not Dataset Metadata

Dataset metadata describes an information resource.

Provenance describes how knowledge relates to its evidentiary origin.

For example:

MetaFragment
  title: CMS Monthly Enrollment
  creator: CMS
  publication_date: ...
  canonical_resource: ...

describes the source dataset.

By contrast:

DataFragment
  enrollment = 2136
  provenance:
    source: CMS Monthly Enrollment
    applicable_month: 2026-07
    source_record: plan:H5521-290-0

describes the lineage of a particular assertion.

The source description and the assertion lineage complement one another.

They are not interchangeable.

Provenance Is Not Duplication

Preserving provenance does not require repeating a complete source description beside every assertion.

WebMEM separates:

the identity and metadata of the source;
the relationship connecting knowledge to that source;
and assertion-specific lineage when additional detail is necessary.

For example:

MetaFragment
  source_id: dataset:cms-pbp-2026
  title: CMS Plan Benefit Package
  creator: CMS
  ...

DataFragment
  provenance_ref: dataset:cms-pbp-2026

  assertion
  assertion
  assertion
  assertion

This preserves a common source relationship without duplicating the complete source description four times.

If one assertion has a different source or derivation, it can declare more specific provenance.

The architecture therefore favors reference and inheritance over redundant repetition.

Provenance Granularity

Provenance should be represented at the level where meaningful lineage differences occur.

Too little granularity can collapse important distinctions.

Too much granularity can create unnecessary duplication without improving interpretation.

For example:

Fragment-level provenance
→ appropriate when all assertions share the same source and lineage

Assertion-level provenance
→ appropriate when a specific assertion differs in source or derivation

Multi-source provenance
→ appropriate when one assertion depends on several sources

Derivation provenance
→ appropriate when the publisher produces new knowledge from source inputs

The goal is not maximum provenance detail.

The goal is sufficient lineage to understand how the represented knowledge reached its published form.

Minimum Provenance Model

The exact provenance required by a WebMEM representation depends on the knowledge being represented.

At minimum, provenance should make it possible to identify or resolve:

Source: the resource, dataset, record, authority, or other evidentiary basis supporting the knowledge;
Source Creator or Authority: who or what produced the source when that distinction is material;
Lineage Relationship: whether the knowledge was sourced, normalized, derived, combined, interpreted, or otherwise produced from the source;
Temporal Context: relevant publication, retrieval, effective, applicability, generation, or modification dates;
Derivation: the method and responsible publisher or process when the published knowledge is derived;
and Scope: the population, geography, entity set, jurisdiction, or other context used when it materially affects the lineage.

These elements may be represented directly or through references to other WebMEM knowledge objects when the resulting lineage remains explicit and resolvable.

Example: Source-Observed Provenance

A simplified source-observed lineage might be serialized conceptually as:

<template
  data-webmem-fragment
  data-fragment-class="DataFragment"
  data-fragment-id="plan-benefits">

  <section
    data-entity-id="plan:H5521-290-0"
    data-plan-year="2026"
    data-provenance-ref="dataset:cms-pbp-2026">

    <data
      data-field="maximum_out_of_pocket"
      value="4900"
      data-type="number"
      data-unit="USD">
      $4,900
    </data>

  </section>

</template>

The assertion inherits its source relationship from the containing fragment context.

The referenced source may be described elsewhere through a MetaFragment or other applicable provenance structure.

Example: Derived Provenance

A derived assertion requires additional lineage:

<template
  data-webmem-fragment
  data-fragment-class="DerivedStatsFragment"
  data-fragment-id="county-derived-stats">

  <section
    data-entity-id="county:04015"
    data-plan-year="2026"
    data-provenance-ref="dataset:cms-landscape-2026">

    <data
      data-field="average_monthly_plan_premium"
      value="15.26"
      data-type="number"
      data-unit="USD"
      data-derived="true"
      data-method="arithmetic-mean">
      $15.26
    </data>

  </section>

</template>

The serialization identifies the assertion as derived and identifies its method at a simplified level.

A complete implementation may additionally preserve the applicable source population, transformation process, publisher responsible for the derivation, source version, and other lineage necessary to reproduce or evaluate the assertion.

The conceptual requirement is more important than any particular attribute syntax:

The published representation must not imply that the source directly asserted a value that the publisher actually derived.

Provenance Failure Modes

Several common patterns cause provenance to collapse.

Source Flattening

source = CMS

is used for every assertion even when the assertions originate from several CMS datasets or publisher derivations.

Derivation Erasure

A publisher-calculated value is attributed directly to the source dataset without identifying the publisher’s calculation.

Temporal Collapse

Publication date, retrieval date, effective date, applicability period, and generation date are treated as interchangeable.

Publisher/Creator Collapse

The publisher of the WebMEM dataset is represented as though it created the underlying source data, or the source creator is represented as though it published the derived WebMEM dataset.

Inheritance Leakage

An assertion inherits fragment-level provenance even though it originates from a different source.

Citation Substitution

A link to a source is treated as though it completely describes the lineage connecting that source to the published assertion.

Transformation Ambiguity

The representation does not distinguish normalization from calculation, aggregation, classification, interpretation, or another substantive transformation.

These failures may leave the visible values intact while destroying information necessary to understand their evidentiary meaning.

Conformance

A conforming WebMEM representation must preserve provenance sufficient to understand the material lineage of the knowledge it publishes.

Specifically, a conforming implementation must:

identify or reference the source supporting source-dependent knowledge;
distinguish the creator or authority of an external source from the publisher of the WebMEM representation when those entities differ;
distinguish source-observed knowledge from publisher-derived knowledge when derivation materially affects lineage;
identify material transformations or derivations necessary to understand how a published assertion was produced;
preserve multiple material sources when an assertion depends on more than one source;
preserve temporal distinctions necessary to interpret source lineage and applicability correctly;
apply shared provenance only where the same lineage genuinely applies;
override inherited provenance when a more specific knowledge object has materially different lineage;
avoid attributing a publisher-derived assertion directly to an underlying source authority;
and preserve enough provenance relationships for a consuming system to distinguish source, transformation, derivation, and published assertion.

Conformance does not require every assertion to contain a complete independent provenance record.

Provenance may be referenced or inherited where doing so preserves the lineage accurately and unambiguously.

Relationship to WebMEM 1.x

Provenance was a foundational concern in WebMEM 1.x and remains foundational in the current WebMEM Protocol.

Earlier specifications represented provenance primarily through ProvenanceMeta blocks containing fields such as source title, creator, publication date, retrieval date, license, archive location, version, checksum, glossary scope, digest identity, and related metadata.

WebMEM 1.x also associated provenance with trust scoring, semantic digests, fragment-level retrieval, memory fitness, and other mechanisms intended to influence or evaluate machine consumption.

The current protocol preserves the durable concept while clarifying its architectural role.

Provenance is no longer defined primarily as a metadata block or trust-layer feature.

Provenance is the lineage relationship connecting published WebMEM knowledge to the sources, transformations, derivations, and responsible actors through which that knowledge came to exist in its published form.

The current protocol also separates provenance from the trust-scoring and retrieval assumptions of WebMEM 1.x.

WebMEM publishes lineage. It does not assign universal authority, confidence, trust, retrieval, or truth scores based on that lineage.

This allows provenance to remain a durable part of the knowledge architecture independent of how any particular consuming system chooses to evaluate the source or assertion.

The current protocol further clarifies provenance scope and inheritance. Shared provenance may apply across multiple assertions within a fragment when their lineage is genuinely the same, while material differences in source, derivation, transformation, or temporal context must remain explicit.

This preserves the useful provenance model developed in WebMEM 1.x while making lineage, rather than metadata accumulation or trust scoring, the governing concept.

Without provenance, the protocol can preserve the structure of an assertion while losing the history necessary to understand what that assertion actually represents.

Overview

Why Provenance Is Structural

Provenance Is Part of Meaning

The Provenance Chain

Source-Observed Provenance

Normalization

Derived Provenance

Multi-Source Provenance

Provenance Scope

Provenance Inheritance

Source Creator, Publisher, and Deriving Publisher

Source Authority and Publisher Assertion

Temporal Provenance

Provenance and MetaFragment

Provenance and Dataset JSON-LD

Provenance and Facts

Provenance and Derived Statistics

Provenance and Relationships

Provenance and Resolution

Provenance Is Not Citation

Provenance Is Not Trust Scoring

Provenance Is Not Proof of Truth

Provenance Is Not Dataset Metadata

Provenance Is Not Duplication

Provenance Granularity

Minimum Provenance Model

Example: Source-Observed Provenance

Example: Derived Provenance

Provenance Failure Modes

Source Flattening

Derivation Erasure

Temporal Collapse

Publisher/Creator Collapse

Inheritance Leakage

Citation Substitution

Transformation Ambiguity

Conformance

Relationship to WebMEM 1.x

Related Protocol Documents