GOLD STANDARD · REMOTE SENSING · HOW X WORKS
Reconcile archive readiness, product versions and citations before asking users to migrate from a superseded capability
A restored archive can acquire a new readiness version while derived products, papers, notebooks and catalogues still cite older states. Reconciliation maps those states without rewriting history. Citation migration then tells users which identifier and version to use for new work while preserving the record of old work. A superseded-capability notice explains what changed, which tasks are affected and whether older outputs remain reproducible, comparable or safe to use.
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.
Reconcile lineage states
Plan citation migration
Publish transition notices
Transfer and qualify
Use FAQs, sources and connected routes
CHAPTER 1 OF 12 · RECONCILE LINEAGE
1. Readiness, processing and citation versions answer different questions
A readiness version records which archive capabilities were demonstrated. A processing version identifies the algorithm, calibration and environment that produced data. A citation version or DOI helps readers identify the collection used. These identifiers may change together, but they should not be treated as interchangeable.
Create a reconciliation event when one layer changes without the others. Name the old and new states, effective dates, relation type and affected user tasks.
CHAPTER 2 OF 12 · RECONCILE LINEAGE
2. Represent version relations explicitly
Use relations such as previous version, new version, derived from, compatible with, requires reprocessing and supersedes. Preserve stable identifiers where policy allows and attach version-specific descriptions rather than silently replacing the object behind a citation.
| Relation | User meaning | Required note |
|---|---|---|
| IsNewVersionOf | A later maintained state exists | What changed and effective date |
| IsPreviousVersionOf | This state has a successor | Where to migrate |
| DerivedFrom | Product depends on named inputs | Input and processing versions |
| ComparableWith | Defined comparison remains valid | Variables, regions and tolerances |
| RequiresReprocessing | Old output should be regenerated | Trigger and migration path |
| Supersedes capability | A task is no longer supported here | Replacement or limitation |
Where comparability is conditional, encode the condition in visible documentation rather than reducing it to a yes/no badge.
CHAPTER 3 OF 12 · PLAN MIGRATION
3. Inventory citations and consumers before changing guidance
Search collection metadata, landing pages, notebooks, benchmark manifests, derived products, APIs, teaching materials and recent publications. Classify each consumer by whether the old citation remains historically correct, needs a version note or should migrate for future work.
Do not edit published papers to pretend they used a later collection. Preserve the original citation and add a linked correction or migration note only when appropriate.
CHAPTER 4 OF 12 · PLAN MIGRATION
4. Give old and new citations distinct jobs
The old citation identifies what earlier work actually used. The new citation identifies the recommended state for new work. A migration guide should state whether results are bitwise identical, numerically comparable within a tolerance, scientifically comparable for named variables or not comparable.
Keep a machine-readable relation and a short human example. Users often reach a collection through copied citations rather than the current catalogue.
CHAPTER 5 OF 12 · WORK THE RECONCILIATION
5. Work a collection restoration and citation migration
Collection 4.1 loses executable readiness after its pinned environment disappears. A restored environment and calibration correction produce readiness version R4 and processing version 4.2. Collection 4.0 remains widely cited, while 4.1 products can be reproduced only under the restored environment.
| Consumer | Observed state | Migration decision | Notice |
|---|---|---|---|
| Published 4.0 paper | Correct historic citation | Keep 4.0 citation | Link successor for new work |
| Active 4.1 notebook | Runs under restored environment | Pin R4 and 4.1 inputs | State environment requirement |
| New product pipeline | Uses corrected calibration | Move to 4.2 | Reprocess baseline |
| Benchmark catalogue | Mixes 4.1 and 4.2 outputs | Split records by version | Do not pool silently |
| Teaching example | Claims latest collection | Update to 4.2 | Retain archive screenshot date |
| API client | Requests unversioned latest | May change outputs | Require explicit version |
The team preserves old citations, makes new-work guidance unambiguous and prevents an unversioned API call from quietly changing a result.
CHAPTER 6 OF 12 · PUBLISH THE NOTICE
6. Write a superseded-capability notice around user decisions
Name the capability, affected collection and versions, change date, reason, tasks affected, tasks unaffected, replacement path, comparability statement, citation guidance and contact or issue route supported by the archive.
Lead with what users should do. Internal ticket numbers and infrastructure details can support the notice without replacing a clear migration instruction.
CHAPTER 7 OF 12 · PUBLISH THE NOTICE
7. Keep notices resolvable after the transition window
A notice should remain reachable from old landing pages, identifiers and manifests after routine support ends. Record the final migration window, archive location and the evidence needed to reproduce the superseded state.
When a capability is withdrawn without replacement, say so directly and explain which historical claims remain supported.
CHAPTER 8 OF 12 · TRANSFER THE METHOD
8. Changed-context transfer: land products and emergency maps
A land-cover time series may need a version bridge across algorithm changes. An emergency map may be superseded quickly because the event state changes. Both need preserved provenance and user-facing version relations.
Their migration windows differ. Transfer reconciliation and notice fields, not the same retention period or comparability claim.
CHAPTER 9 OF 12 · QUALIFY THE RESULT
9. Test migration instructions with an independent user
Ask a user who did not perform the restoration to locate the old record, identify the recommended successor, reproduce one supported output and cite the correct state. Record where the instructions or identifiers fail.
A catalogue can be internally consistent yet unusable if old links do not resolve or a citation example omits the version.
CHAPTER 10 OF 12 · QUALIFY THE RESULT
10. Limits and common misconceptions
A new DOI does not prove a scientific change; a stable DOI does not prove the underlying processing is unchanged. Superseded does not mean historically invalid. Reproducible does not necessarily mean comparable for every variable.
Do not redirect every old identifier to a new landing page without preserving the old version context. Do not call a collection “latest” inside archival evidence that needs a stable meaning.
CHAPTER 11 OF 12 · CHECK AND CONTINUE
11. Questions readers often ask
Should every processing version receive a new DOI?
Follow the repository and identifier policy. Whatever the identifier choice, make the processing version and relation to prior states explicit and citable.
When may an old citation remain unchanged?
When it accurately identifies the data actually used. Add migration guidance for new work without rewriting the historical record.
CHAPTER 12 OF 12 · CHECK AND CONTINUE
12. Evidence, connected routes and the next check
NASA Earthdata guidance on collection citations maps citation fields, including dataset version. NASA Earthdata guidance on associated DOIs defines relations such as previous version and new version. NASA Earthdata version-description guidance explains how to record what separates a current dataset version from its predecessor.
Continue through capability restoration and readiness-version lineage, archive readiness revalidation and downgrade triggers, and amendment propagation and citation-version governance. The next check is to trace one old citation to the exact archive and processing state it names.