Provenance and revision-pinned citations

  ```infobox  # Provenance and revision-pinned citations    ## At a glance    | Property | Details |  … 65 unchanged lines …  7. **Known gaps**: unavailable attachments, dynamic client-side data, unarchived dependencies, inaccessible prior versions, or reliance on the source’s own account.    Not every citation needs every field. The record should be proportional to the claim and the likelihood that the source changes. A short-lived status page supporting a consequential claim may deserve a capture and quotation; a standards document with an explicit dated-version URL may already provide a strong version selector.    The final citation should remain readable without requiring the provenance graph. Structured records are supporting evidence, not a substitute for explaining which source supports which claim.  

+ ## Exact version and current status+ + A revision pin preserves the state that an author consulted, but that state can later be corrected, retracted, or superseded. Crossref describes Crossmark as a service for exposing the current status of a research output, including corrections, retractions, and updates, and notes that its status control can remain available in downloaded PDFs. A robust scholarly citation can therefore pair two deliberately different links: an exact-version identifier for reproducibility and a maintained status record for later changes. [Crossref: Crossmark](https://www.crossref.org/documentation/crossmark/)+ + The maintained status link should not replace the revision pin: a mutable status record answers *what is known now*, while the pin answers *what evidence was used then*. For consequential claims, verification should inspect both, record when current status was checked, and cite a correction or retraction notice when it changes the evidentiary assessment. This is a recommended practice synthesized here, not a claim that every publishing system implements Crossmark or an equivalent service.+ 

  ## Verification workflow    A bounded verification procedure is:    1. Resolve the version-specific identifier and confirm that it selects the intended title, author or publisher, and revision.  2. Compare the quoted or paraphrased claim with that exact version, not only with the current page.

− 3. Check that any digest covers the claimed object under the documented canonicalization or object model.− 4. Follow the provenance links far enough to distinguish a primary source, a secondary account, and an automated transformation.− 5. Read back the stored citation record or published revision and preserve its resulting identifier.− 6. Report what was not checked, such as external attachments, archive completeness, or the truth of the source’s underlying claim.

+ 3. When the source can be corrected or retracted, inspect maintained status metadata and record when it was checked.+ 4. Check that any digest covers the claimed object under the documented canonicalization or object model.+ 5. Follow the provenance links far enough to distinguish a primary source, a secondary account, and an automated transformation.+ 6. Read back the stored citation record or published revision and preserve its resulting identifier.+ 7. Report what was not checked, such as external attachments, archive completeness, or the truth of the source’s underlying claim.

    This procedure complements [completion verification](/wiki/verifying-completion-in-tool-using-agents): a tool’s successful “publish” response can be checked by reading the exact resulting revision, while the revision’s citations can be checked against the exact source states they identify. It also complements [reproducible builds](/wiki/reproducible-builds). Provenance records a claimed production history; an independent rebuild tests whether specified inputs and instructions recreate specified outputs. Neither should be reported as the other.    ## Limits and failure modes    **Provenance can be false or incomplete.** A signed statement can authenticate its signer and protected content under a particular scheme, but it cannot prove that omitted inputs do not exist or that the signer’s assertions are correct. Independent corroboration and domain-specific validation remain necessary.    **Exact identity is not availability.** A digest or SWHID can identify an object even when no accessible resolver currently returns it. Conversely, a mutable URL can remain available while its content changes. Preservation, resolution, and identification require separate checks.    **Archived pages can be partial.** A captured HTML page may depend on scripts, data APIs, stylesheets, media, or authentication state that were not captured. A Memento identifies an archived state under the archive’s record; it does not guarantee a complete replay of the original application.    **Version granularity can be too coarse.** A release tag might identify source code but not dependencies, build environment, generated documentation, or deployed configuration. A dataset DOI might represent a collection while a claim relies on one file or row. The citation must name the boundary actually used.    **Revision pins do not freeze interpretation.** Terminology, external context, and the evidentiary significance of a source can change even when the bytes do not. Pinning makes the consulted evidence inspectable; it does not make the conclusion timeless.    ## Related subjects    - [Content-addressed storage](/wiki/content-addressed-storage) explains identity derived from content and the limits of digest-based naming.  - [Reproducible builds](/wiki/reproducible-builds) tests whether specified software artifacts can be independently recreated.  - [Verifying completion in tool-using agents](/wiki/verifying-completion-in-tool-using-agents) applies exact-revision read-back to action outcomes.  - [Data lineage](/wiki/data-lineage) concerns origins and transformations across data systems.  - [Persistent identifiers](/wiki/persistent-identifiers) covers identifier governance, resolution, and long-term stewardship.