Provenance
Provenance in LunarTrace answers one question: which exact bytes went into a result, and was that known at the time? It does not answer whether the bytes are current, whether they may be redistributed, or whether the result is scientifically admitted. This page separates those questions.
Source witness
Section titled “Source witness”The frozen lunartrace.source_witness/v0 manifest is research/sources/pgda78-site01.manifest.json,
identified as pgda78-site01. It records the PGDA product and landing page, the source citations, the
native grid semantics and the named input roles. Each frozen entry records its file name, role, byte count,
SHA-256 digest and CAS location. Downloaded entries also keep the request URL and any HTTP metadata that
was available.
The Site01 method inputs are the slope raster, the slope_rms raster and the ROI shapefile sidecars.
The witness also records the README and other Site01 products. The manifest has its own SHA-256 identity,
which the execution receipt records.
Content-addressed store
Section titled “Content-addressed store”The content-addressed store (CAS) holds the source bytes outside Git. A role manifest states which bytes
are intended for a task. The CAS makes each blob retrievable by its digest. The store is taken from --store, or from LUNARTRACE_SOURCE_STORE when --store is not
given. There is no built-in host default; the location for the local dev host is set in
Taskfile.yml only.
The CAS is currently a single local copy. That is a custody risk: a digest detects changed bytes, but it cannot recover lost bytes. Keep an authorised replica if the study must be repeated later.
Hash gates
Section titled “Hash gates”STUDY execution applies these gates in order:
- The manifest must have the status
SOURCE_FROZEN. - Every role in the manifest is resolved from the CAS. Not only the two rasters are checked; the README and surface products are verified too.
- Each blob is re-hashed and must match its recorded SHA-256. A mismatch stops the run. No substitute bytes are fetched.
- The method reads the verified inputs. The receipt then records the manifest digest, the input hashes, the result digest, the code state and the environment.
Missing data is not zero. A missing blob or a changed blob is an error. The snippet test that exercises the quickstart skips only the real-source section when blobs are absent. A present but altered blob fails hash verification.
The run_paths function applies the same idea more narrowly: it checks the three hashes that the caller
supplies, for the slope, slope-RMS and ROI inputs, and nothing else.
Execution receipt
Section titled “Execution receipt”receipt.json is an execution_receipt/v0 record. It names the method and implementation, the witness and
manifest digests, the input hashes, the result digest, the git HEAD and dirty state, the environment, the
lock hash and the execution times. Its status is METHOD_EXECUTED.
Three limits apply:
- The receipt records one execution. It is not a signature, and it is not independently authenticated.
- Its bytes change from run to run because the timestamps and environment change. The
result.jsonbytes do not change for the same inputs. - A receipt does not establish numeric reproduction, scientific admission or source rights.
The distinction that matters: the deterministic result is the scientific output, the receipt records one run, and the standing is a separate label that a person or a caller chooses on the basis of evidence.
Frozen is not current
Section titled “Frozen is not current”SOURCE_FROZEN means the manifest fixes one set of bytes for replay. It does not mean that PGDA still
serves those bytes, that the URL is unchanged or that the upstream product is current. A changed upstream
file is a new witness, not an in-place update. The fetch timestamps, ETags and Last-Modified values record
the fetch; they are not a live currentness check.
Use these labels precisely:
- Frozen and hash-verified: the bytes match the witness. This supports replay of that snapshot only.
- Stale: the snapshot may be older than the present upstream data. A later fetch may produce a different witness, and no silent refresh happens.
- Unknown: no check has resolved the status. Do not present an unobserved currentness check as either current or changed.
The currentness decision is an open residual in the project’s gap register.
Source rights and citation
Section titled “Source rights and citation”The source rights are UNVERIFIED. The U.S. Government origin of the PGDA product is not confirmation that it may be redistributed. Source bytes stay in the private CAS, outside Git, and must not be redistributed, nor may derived data be published on the basis of this documentation.
The witness cites two upstream publications:
- Barker et al. (2021), Improved LOLA elevation maps for south pole landing sites: Error estimates and their impact on illumination conditions, Planetary and Space Science 203, 105119, doi:10.1016/j.pss.2020.105119.
- Mazarico et al. (2011), Illumination conditions of the lunar polar regions using LOLA topography, doi:10.1016/j.icarus.2010.10.030.
These are upstream publication DOIs. They are not LunarTrace software or result DOIs. The bibliographic metadata was checked against Crossref on 2026-10-10. That check confirms the metadata only, not the findings of the cited papers.
Historical observation evidence is separate
Section titled “Historical observation evidence is separate”The historical MoonTrace ODE Probe R1 findings are frozen aggregate reports. The original run directories were not found, and the observation and pair rows that generated those reports are unavailable. Later browse image refetches are reference-only and not co-registered. A candidate frontier is not scientific equivalence or change detection, and a search miss does not establish that no post-event observation exists.
LROC, ODE, ALE and CSM source-boundary work is planned or experimental. It is not a current R2 capability. The R2 method does not perform live discovery or observation pairing, and the R2 receipt does not upgrade the historical evidence.
Checklist before sharing any output
Section titled “Checklist before sharing any output”- Is every input hash in the receipt the same as the manifest’s recorded hash?
- Is the standing label the one the evidence supports, and no higher?
- Are the outputs and the source bytes kept local and private?
- Are the claims about area, uncertainty or admission absent?
See also: Method, Limitations and the CLI reference.