GOLD STANDARD · REMOTE SENSING · HOW X WORKS
Restore only the archive capability that the repair and retest actually support—and preserve the lineage of every readiness version
After an archive capability is downgraded, repair is only the first step. Restoration evidence must show that the affected dependency works again and that downstream claims remain valid. Partial revalidation can avoid waste when dependencies are mapped well, while readiness-version lineage lets future users see which collection, environment and benchmarks supported each capability state.
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.
Define restoration evidence
Plan partial revalidation
Maintain version lineage
Transfer and qualify
Use FAQs, sources and connected routes
CHAPTER 1 OF 12 · DEFINE RESTORATION
1. Repair completion is not capability restoration
Replacing a corrupt file, rebuilding a container or renewing a licence changes the archive state. Restoration requires evidence that the change resolves the failure and that the promised user task works again.
Name the suspended capability, affected objects, repair authority, new versions, verification method, operator and benchmark. Without that chain, a repair ticket cannot support a readiness claim.
CHAPTER 2 OF 12 · DEFINE RESTORATION
2. Match evidence to the capability that failed
Fixity restoration needs trusted source comparison and new checks. Inventory restoration needs manifest reconciliation and identifier resolution. Executability needs a clean environment. Scientific reproducibility needs benchmark outputs, tolerances and domain edge cases.
Do not substitute one layer for another. Matching hashes cannot prove an analysis is interpretable, while a successful plot cannot prove every archived object is intact.
CHAPTER 3 OF 12 · PLAN REVALIDATION
3. Map the dependency cone before choosing the test scope
A changed calibration table may affect products, notebooks and benchmarks that consume it; a documentation edit may affect only cold-start usability. Build a dependency cone from the repaired object to every capability claim.
| Repair | Direct dependency | Downstream claim | Minimum retest |
|---|---|---|---|
| Corrupt raw object | Manifest and replica | Fixity and restoration | Trusted replacement plus full object check |
| Base image rebuild | Runtime and packages | Executability | Clean build and representative runs |
| Calibration-table correction | Processing products | Scientific reproduction | Affected scenes and threshold edges |
| Licence renewal | Data access path | Future-user reproducibility | Independent authorised access |
| Landing-page repair | Discovery and instructions | Usability | Cold-start operator task |
If the dependency cone is unknown, widen the drill or keep the higher capability suspended.
CHAPTER 4 OF 12 · PLAN REVALIDATION
4. Use unchanged controls to detect accidental spread
A partial retest should include at least one unaffected control pathway. It can reveal that a repair changed a shared environment, manifest or comparison tool beyond the expected cone.
Record the tested and deliberately untested scope. “Revalidated” without exclusions invites users to infer a full drill.
CHAPTER 5 OF 12 · WORK THE RESTORATION
5. Work a partial revalidation after a base-image rebuild
A remote-sensing archive lost its pinned runtime base image. A documented recipe builds a successor image with a new digest. Twelve benchmark scenes exist, but only four exercise the changed native library while all share the packaging layer.
| Test | Result | Readiness effect |
|---|---|---|
| Clean rebuild | Recipe resolves and digest is recorded | Executable candidate created |
| Four dependency-sensitive scenes | Outputs within declared tolerances | Changed path supported |
| One unaffected control scene | Matches prior version | No obvious shared regression |
| Cold-start operator | Runs without maintainer help | Documentation and access supported |
| Eight untested scenes | Dependency map shows no changed library use | Remain covered with explicit rationale |
| Lineage record | Old and new environments linked | New readiness version published |
If the control scene failed, the team would expand the cone and withhold restoration until the shared change was understood.
CHAPTER 6 OF 12 · VERSION LINEAGE
6. Create a readiness version for every material state change
A readiness version should identify collection manifest, environment, documentation, access conditions, benchmark set, capability matrix, exclusions and effective dates. Link it to the prior version and the event that caused the change.
Keep downgrade and restoration as separate states. Collapsing them into a final green record erases the period when users needed a warning.
CHAPTER 7 OF 12 · VERSION LINEAGE
7. Propagate the version to products and citations
Derived products should reference the readiness and processing versions that support them. When a restored capability creates different outputs, users need a migration note, not just a replaced archive badge.
Preserve old citations where possible and state whether products remain comparable, require reprocessing or are superseded. Lineage is a user decision aid, not internal bookkeeping.
CHAPTER 8 OF 12 · TRANSFER THE METHOD
8. Changed-context transfer: field campaigns and institutional repositories
A field campaign may restore a notebook environment and three calibration panels; an institutional repository may restore a storage replica and thousands of identifiers. Both can map dependency cones and publish capability-specific lineage.
Their test scale differs. Transfer the restoration evidence chain, not a fixed sampling percentage or benchmark count.
CHAPTER 9 OF 12 · QUALIFY THE RESULT
9. Validate the comparison tool as well as the archive
A revalidation can pass falsely if the comparator, tolerance file or expected output is wrong. Version comparison tools and include known-difference controls where consequence warrants it.
For numerical products, distinguish bitwise identity, numerical equivalence and scientific equivalence. Each supports a different claim.
CHAPTER 10 OF 12 · QUALIFY THE RESULT
10. Limits and common misconceptions
Partial revalidation does not prove untouched dependencies are healthy forever. A new version number does not create provenance unless its inputs and relations are recorded. Restoration of access does not restore legal permission for every user.
Do not delete failed outputs or overwrite expected benchmarks. Preserve them as evidence of the transition and state why the new comparison is justified.
CHAPTER 11 OF 12 · CHECK AND CONTINUE
11. Questions readers often ask
When is a full drill safer than partial revalidation?
Use a full drill when the dependency map is weak, the repair changes shared infrastructure, the consequence is high or prior failures suggest hidden coupling.
Can lower capabilities be restored before scientific reproducibility?
Yes. Fixity, inventory or executability can be re-earned while scientific comparison remains suspended. Publish the matrix rather than one all-or-nothing label.
CHAPTER 12 OF 12 · CHECK AND CONTINUE
12. Evidence, connected routes and the next check
Library of Congress data-integrity guidance describes repair, fixity manifests, routine review and auditable logs. The NDSA Levels of Digital Preservation provides versioned assessment resources across storage, integrity, control, metadata and content. NASA guidance on long-term active archives distinguishes the capabilities needed for reproducible scientific holdings.
Continue through readiness revalidation and downgrade triggers, failure taxonomies and repair evidence, and amendment propagation and citation-version governance. The next check is to draw the dependency cone from one repaired object to every capability claim.