A second incident closure is not a return to innocence. It means the team has repaired a recurrence, tested the resolver path and assembled stronger closure evidence. The next risk is subtler: restoring ordinary traffic too quickly and removing the quarantine before the repaired path has survived realistic freshness, deployment and cache cycles.
This guide treats reintegration as an experiment. Traffic returns in stages, identity and provenance are checked at the point of use, alternate paths remain available, and quarantine is retired only when explicit gates are met. The method applies to remote-sensing imagery, catalogues, tiles, derived products and APIs whose meaning depends on both data identity and delivery behavior.
The practical lesson is that a correct registry entry does not prove correct delivery. Monitoring must follow the actual resolver, redirect, cache and representation path that a user or downstream system experiences.
A practical orientation
Keep four layers visible: the intended dataset identity, the metadata or registry record, the network delivery path and the bytes or representation received. A reintegration test should connect all four, because a stale cache can serve the wrong object while the registry looks perfect.
Use this guide after reopened-incident containment and second closure. It provides a staged test, a worked cache example, retirement gates, transfer to content negotiation and explicit limits.
- Define the post-closure state — for incident owners planning heightened monitoring.
- Design path-reintegration tests — for delivery and platform teams.
- Follow the worked cache example — for headers, identity and freshness checks.
- Apply retirement gates — for the quarantine decision.
- Transfer to APIs — for negotiated representations.
Chapter contents
Open a route that matches the decision in front of you, or read straight through. Each route returns to the same evidence chain.
Start with the operating question
Build the evidence chain
Design reintegration as staged exposure
Work the example
Stress-test the decision
Set quarantine-retirement gates
1. Define what second closure did and did not prove
Second closure should prove that the recurrence was contained, the diagnosed mechanism was repaired, affected products were assessed and the tested path returned correct evidence under the closure conditions. It does not prove that every geography, cache, client or future deployment will behave identically.
Record the repaired components, tested paths, data identities, cache states, deployment versions and time window. These become the post-closure envelope. Monitoring asks whether live behavior remains inside it as ordinary variation returns.
- Dataset and derived-product identifiers.
- Resolver, redirect, CDN, origin and client paths tested.
- Expected freshness and validator behavior.
- Known untested paths or representations.
- Rollback owner, trigger and retained quarantine route.
2. Monitor identity, freshness, path and consequence
Identity checks ask whether the response is the intended product, version, spatial-temporal extent and processing level. Freshness checks ask whether cache and validation behavior match policy. Path checks confirm where the response actually travelled. Consequence checks assess whether downstream maps, measurements or decisions are affected.
A simple uptime probe is insufficient. It can report success while an old tile, redirected object or mismatched representation is served. Use semantic checks on representative products and compare the public path with a controlled origin or quarantine reference.
| Layer | Evidence | Failure it can reveal |
|---|---|---|
| Identity | Identifier, checksum, extent, processing version | Wrong or substituted product |
| Freshness | Age, Date, ETag, Last-Modified, validation outcome | Stale or incorrectly reused response |
| Path | DNS/resolver, redirects, cache status, origin trace | Unexpected intermediary or route |
| Consequence | Rendered map, sample value, downstream job | Operational impact despite technically valid response |
3. Design reintegration as staged exposure
Begin with a canary path or small share of representative traffic. Keep the quarantine route available and compare responses. Expand only after the canary survives the relevant cache, deployment and update cycles. A single successful request tests reachability, not stability.
Choose cases that cover the failure mechanism: recently updated objects, long-lived objects, redirects, alternate formats, different regions and clients. The purpose is not maximum request volume; it is coverage of meaningful path states.
4. Test the path the user actually follows
Capture the full redirect chain and final representation. Record status codes, validators, cache-control fields, response age and a content identity check. Where an intermediary adds headers, treat them as supporting evidence rather than universal truth; behavior differs across providers.
Repeat tests from the networks or environments that experienced the incident. Origin-only tests can verify the source while missing a resolver or cache problem. Conversely, a public-path failure with a correct origin narrows the repair towards delivery rather than the scientific data product.
5. Define an observation window by mechanisms, not habit
The monitoring window should include the events that could recreate the failure: a cache expiry, revalidation, product update, configuration deployment, regional propagation or scheduled catalogue refresh. “Seven days” is useful only if it covers those mechanisms.
State which events occurred during the window. If no product changed and no cache expired, an apparently calm week provides weak evidence about reintegration. Extend heightened monitoring until the relevant cycles have been observed or deliberately exercised.
6. Worked example: retiring an office-path quarantine
A remote-sensing catalogue is correct at origin, but an office network previously received a stale redirect through a shared cache. After the second repair, the team keeps that resolver path quarantined and runs a canary. Across four cycles it requests an unchanged product, an updated product, a redirect target and an expired cached response.
For each cycle, the final URL and dataset identifier match; the updated product changes ETag as expected; Age resets after validation; and the redirect chain no longer points to the retired object. The team also forces one rollback drill. This is stronger evidence than four repeated requests to the same warm object.
| Cycle | Deliberate condition | Evidence required |
|---|---|---|
| 1 | Warm unchanged object | Correct identity; allowed cache reuse |
| 2 | Product update | New validator and correct processing version |
| 3 | Redirected catalogue route | Expected chain and final target |
| 4 | Expired object / revalidation | Fresh validation; no retired object served |
| Drill | Simulated recurrence | Quarantine or rollback route restores safe delivery |
7. Respond to failed reintegration without losing evidence
If a canary fails, stop expansion and preserve the response, headers, path trace, client conditions and intended identity. Reapply quarantine for the affected path rather than flushing every system reflexively. Broad destructive changes can erase the evidence needed to locate the fault.
Classify whether the failure is the old mechanism, a repair side effect or a new incident. A familiar symptom does not prove the same cause. Keep the second-closure record intact and open a linked event when the evidence warrants it.
8. Set quarantine-retirement gates
Retirement means the ordinary path becomes primary and the exceptional quarantine control is removed or archived. Require correct identity and freshness across the relevant cycles, successful staged exposure, no unexplained path divergence, intact provenance, active monitoring and a rehearsed rollback.
Every gate needs an owner and evidence location. Avoid a vote based on general confidence. If one untested representation remains material, retire quarantine only for the verified scope or keep a targeted restriction.
- Representative identities and versions verified.
- Freshness and revalidation behavior observed.
- Redirect and resolver paths match the intended design.
- Canary expanded without unexplained failures.
- Rollback or rapid re-quarantine tested.
- Residual untested scope named and governed.
9. Retire the control without deleting the capability
Remove the quarantine from routine traffic, but preserve its configuration, decision record and activation procedure where practical. A dormant recovery path should have an owner and periodic test; otherwise it becomes theatre that cannot be used in the next incident.
Update runbooks, monitoring scope and product provenance links. The closure trail should show when quarantine began, why it remained after second closure, which evidence allowed retirement and what observation would reopen the decision.
10. Know the limits of delivery evidence
Correct delivery does not prove scientific fitness. A byte-identical product can still be inappropriate for a new land-cover question, resolution need or atmospheric condition. Keep scientific validation and delivery-path assurance connected but distinct.
Likewise, HTTP metadata is evidence about representation transfer and cache behavior, not a universal provenance system. Use persistent identifiers, product metadata and controlled records to establish dataset lineage.
11. Common questions after a second closure
Teams often ask whether one clean request is enough, whether purging every cache is safest, or whether registry correctness settles the matter. The consistent answer is to test the mechanism: observe meaningful cycles, preserve evidence and verify the delivered object at the point of use.
How many clean cycles are enough to retire quarantine?
There is no universal count. The window must cover the mechanisms that could recreate the failure, such as update, expiry, revalidation, redirect and deployment. Four identical requests in one state may provide less evidence than two deliberately different cycles.
Should quarantine be deleted after retirement?
Ordinary routing can be restored, but the recovery capability and record should usually be preserved, owned and tested. Delete only when a governed replacement makes it obsolete and recovery remains credible.
12. Changed-context transfer, evidence check and sources
Transfer the method to an API that negotiates JSON, GeoTIFF metadata or language-specific responses. Include the request headers and Vary behavior in the identity of the test. A cache can be fresh yet serve the wrong negotiated representation if its cache key is incomplete. Reintegration must therefore sample the meaningful request variants.
RFC 9111: HTTP Caching defines cache behavior, freshness, validation and fields such as Age. RFC 9110: HTTP Semantics defines representation, validators and content negotiation. DataCite’s guidance on tracking provenance describes relation types for connecting versions and sources. Together they support the delivery and provenance checks used here; local incident evidence still determines the retirement gate.
Continue through the Gold Standard ecosystem
Return to the Remote Sensing subject root, the Gold Standard of Education parent, or the How X Works hub.
Immediate predecessor: reopened-incident containment and second-closure evidence · Prerequisite: delivery-path verification and rollback · Remote Sensing root
These routes are grouped by learning purpose: prerequisite model, immediate predecessor, and the wider transfer framework. They are not substitutes for the evidence and limits stated in this guide.