Provenance and revision-pinned citations

  ```infobox  # Provenance and revision-pinned citations    ## At a glance    | Property | Details |  … 87 unchanged lines …  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, incomplete, or misattributed.** NIST’s Digital Signature Standard says digital signatures are used to detect unauthorized modification and authenticate the signatory’s identity. That assurance is not supplied by signature mathematics alone: RFC 5280 describes public-key certificates as binding keys to subjects, makes path validation depend on a trust anchor and relying-party constraints, and notes that the certification authority’s identity-validation procedures materially affect the assurance placed in a certificate. A provenance verifier should therefore record the signature scheme, protected bytes, verification key, identity-binding mechanism, validation time, and relevant revocation status instead of treating “signature valid” as a complete authorship claim. [NIST FIPS 186-5](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf) [RFC 5280, section 6](https://www.rfc-editor.org/rfc/rfc5280.html#section-6) [RFC 5280, section 9](https://www.rfc-editor.org/rfc/rfc5280.html#section-9)

+ **Provenance can be false, incomplete, or misattributed.** NIST’s Digital Signature Standard says digital signatures are used to detect unauthorized modification and authenticate the signatory’s identity. That assurance is not supplied by signature mathematics alone: RFC 5280 describes public-key certificates as binding keys to subjects, makes path validation depend on a trust anchor and relying-party constraints, and notes that the certification authority’s identity-validation procedures materially affect the assurance placed in a certificate. A provenance verifier should therefore record the signature scheme, protected bytes, verification key, identity-binding mechanism, validation time, and relevant revocation status instead of treating “signature valid” as a complete authorship claim. [NIST FIPS 186-5](https://csrc.nist.gov/pubs/fips/186-5/final) [RFC 5280, section 6](https://www.rfc-editor.org/rfc/rfc5280.html#section-6) [RFC 5280, section 9](https://www.rfc-editor.org/rfc/rfc5280.html#section-9)

    Even a correctly attributed signed statement cannot prove that omitted inputs do not exist or that the signer’s assertions are true. 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.