GOLD STANDARD · REMOTE SENSING · HOW X WORKS
Prove a retired Earth-observation workflow can still be reconstructed by checking bytes, dependencies and the restoration path
An archive is not reproducible merely because files still exist. Fixity shows whether stored bytes changed; dependency escrow preserves the software, configurations and rights information needed to interpret them; a reproducibility drill tests whether an independent reader can rebuild a declared result.
This guide connects the Gold Standard of Remote Sensing, Gold Standard of Education, and How X Works hub.
Chapter contents and reading routes
Choose the route closest to your present task. Every teaching chapter remains expanded, so the article also reads naturally from start to finish.
Separate preservation layers
Build the audit package
Run and govern drills
Transfer and qualify
Use FAQs, sources and connected routes
CHAPTER 1 OF 12 · SEPARATE THE LAYERS
1. Fixity, readability and scientific reproducibility are different claims
Fixity asks whether a digital object matches its recorded checksum. Readability asks whether formats and labels can still be interpreted. Scientific reproducibility asks whether the documented inputs and process recreate a result within a declared bitwise, numerical or scientific tolerance.
A perfect checksum cannot supply a missing calibration table. A runnable container cannot prove that its source granules are the cited versions. Audit each layer separately and link their evidence.
CHAPTER 2 OF 12 · SEPARATE THE LAYERS
2. Define the preservation object before hashing it
Name the files and relationships that form the object: source granules, quality masks, ancillary fields, coefficients, code, configuration, environment description, documentation, validation scenes and expected outputs. Give each a stable identifier and version.
Use file-level hashes plus an aggregate manifest so missing, extra and reordered components are visible. Store the manifest and audit logs in controlled inventory systems; do not keep the only checksum beside the only copy it is meant to verify.
CHAPTER 3 OF 12 · BUILD THE PACKAGE
3. Design fixity audits by risk and storage tier
Generate fixity as early as ingest and verify it after transfer, replication and storage migration. Online collections may support frequent complete checks; high-latency archives may require a risk-based sample between periodic complete reviews.
| Audit event | Minimum comparison | Evidence retained |
|---|---|---|
| Ingest | Producer or transfer checksum | Receipt, hash algorithm, time and result |
| Replication | Source manifest versus new copy | Object and aggregate results |
| Routine review | Stored bytes versus approved manifest | Coverage, failures and repairs |
| Storage migration | Old and new inventories plus hashes | Completeness and chain of custody |
| Restoration drill | Restored objects and expected outputs | Environment, interventions and tolerances |
A failed check starts an incident, not an automatic overwrite. Quarantine the object, compare replicas and provenance, identify the trustworthy copy, repair under change control and retain the original failure evidence.
CHAPTER 4 OF 12 · BUILD THE PACKAGE
4. Escrow dependencies without pretending everything can be redistributed
Preserve source or executable code where rights permit, immutable environment specifications, package locks, build instructions, base-image identifiers, calibration and ancillary data, licences, interface contracts and a contact or succession plan.
Do not escrow live credentials or silently copy restricted software. Record lawful access requirements and a replacement or emulation path. When exact dependencies cannot be preserved, state the loss and the highest reproducibility level still supported.
CHAPTER 5 OF 12 · WORK THE AUDIT
5. Work a retired bridge archive across three storage tiers
A retired harmonisation bridge has 50 TB of source scenes, a 2 GB container, coefficient tables and 24 benchmark outputs. Online manifests cover every file; a second geographic copy is near-line; cold storage holds a third copy. The annual drill selects scenes by sensor, season and known edge conditions.
| Check | Result | Response |
|---|---|---|
| Online full fixity | Two granules mismatch | Quarantine and compare replicas |
| Near-line sample | Both granules correct | Restore verified copies; retain incident log |
| Dependency build | Base image unavailable | Build from pinned packages; update escrow recipe |
| Benchmark rerun | 23 within tolerance; one aerosol edge fails | Trace ancillary-version omission |
| Independent rerun | Passes after manifest repair | Approve archive with documented change |
The archive was bit-preserved except for two repaired files, yet the larger reproducibility failure was a missing ancillary version. The drill tested the chain rather than equating storage health with scientific reconstruction.
CHAPTER 6 OF 12 · RUN THE DRILL
6. Use an independent operator and a clean environment
Give the operator the same landing documentation a future user would receive. Start from a clean account and machine, resolve identifiers, obtain permitted dependencies, build the environment, run benchmark cases and compare outputs.
Log every undocumented intervention, expired link, unavailable licence, ambiguous command and tolerance decision. A maintainer who supplies missing knowledge from memory can make an incomplete archive appear healthy.
CHAPTER 7 OF 12 · RUN THE DRILL
7. Close findings with preservation changes and another test
Classify findings as bit-integrity, inventory, dependency, documentation, scientific-comparison or access failures. Give each an owner and repair evidence. Update manifests only through versioned change control so a new checksum does not conceal an unexplained mutation.
Repeat the affected part of the drill after repair and after major storage or software migration. Preserve the old manifest, incident and reason for the new approved state.
CHAPTER 8 OF 12 · TRANSFER THE METHOD
8. Changed-context transfer: satellite archive and field drone campaign
A mission archive may hold petabytes with formal replicas and designated preservation content. A field drone programme may retain raw images, calibration panels, flight logs, firmware and one analysis environment.
Both need defined preservation objects, fixity and restoration tests. Their storage tiers, access rights and sampling frequencies differ. Transfer the layered audit, not the infrastructure scale.
CHAPTER 9 OF 12 · QUALIFY THE RESULT
9. Test scientific tolerances as well as bytes
Bitwise equality may be possible for archived outputs but not for every recomputation across hardware or numerical libraries. Define expected checksums where exactness is required, and numerical or domain-specific tolerances where legitimate variation exists.
Include edge scenes, quality flags and failure cases. A global mean agreement can hide changed masks, geolocation shifts or threshold crossings that matter to downstream products.
CHAPTER 10 OF 12 · QUALIFY THE RESULT
10. Limits and common misconceptions
Checksums detect change but do not explain which copy is correct. Redundancy helps only when replicas are independent enough and their custody is documented. A container captures many dependencies, not external services, licences or undocumented inputs.
One successful drill does not guarantee indefinite reproducibility. Obsolescence and access conditions evolve. The archive remains credible because evidence is renewed, failures are visible and claims are bounded.
CHAPTER 11 OF 12 · CHECK AND CONTINUE
11. Questions readers often ask
Must every object receive a full fixity check every year?
Not always. Choose a documented schedule using storage behaviour, replication, consequence and audit capability. Some tiers may use representative checks between complete reviews, but coverage and residual risk must remain explicit.
Is a software container enough for dependency escrow?
No. Preserve its immutable identity, build recipe, configuration, inputs, ancillary versions, licences and expected outputs. Test it in a clean environment so hidden services and local assumptions become visible.
CHAPTER 12 OF 12 · CHECK AND CONTINUE
12. Evidence, connected routes and the next check
Library of Congress data-integrity guidance explains early fixity, file and aggregate manifests, routine review and auditable logs. NASA guidance on long-term active archives separates uncorrupted bits, discoverability, readability, understandability, usability and reproducibility. NASA Planetary Data System preservation policies include checksum, integrity, retention, backup and recovery requirements.
Continue through bridge retirement and archive reproducibility, bridge-version governance and lineage, and reprocessing impact triage and user migration. The next check is to hand one benchmark restoration to someone who did not build the archive.