A repaired identifier can resolve correctly during closure and still send later users to an obsolete remote-sensing landing page. The recurrence may come from the registry, an intermediary cache, a repository redirect or a local client. Closing the original incident does not identify which layer owns a future failure.
This guide explains how to monitor recurrence after closure, collect path-specific cache evidence, and reopen the incident only through declared gates. The objective is not to blame a cache whenever responses differ. It is to preserve enough evidence to separate a stale representation from a newly wrong authoritative target.
The examples use fictional identifiers and networks. Repository operators must follow their registry, security, privacy and change-control requirements. Do not bypass access controls or deliberately poison a public cache to test a theory.
eduKateSG · The Gold Standard · Remote Sensing
Find your next learning step
Follow one identifier from post-closure probes through cache-path evidence, attribution confidence and a governed reopen-or-continue decision.
- ROUTE 1 · Define recurrence — freeze the closed state and observation plan
- ROUTE 2 · Capture paths — record registry, redirect and cache evidence
- ROUTE 3 · Attribute cautiously — separate freshness from authority
- ROUTE 4 · Reopen or contain — use gates and preserve both incidents
- ROUTE 5 · Transfer carefully — limits, questions and evidence routes
Full chapter index · Remote Sensing root guide · Learning that transfers into life · How X Works hub
Chapter contents
Chapters 1–3
Chapters 4–5
Chapters 6–8
Chapters 9–10
CHAPTER 1 OF 12
1. Closure creates a baseline, not immunity
At closure, record the identifier, authoritative registry target, expected redirect chain, landing-page identity markers, observation time, configuration version and cache-expiry assumptions. Future monitoring compares with this state. A green status alone is not a sufficiently rich baseline.
The immediate guide on post-rollback reconciliation, cache-expiry evidence and closure tests establishes that baseline. This article begins after closure and asks what evidence justifies reopening it.
CHAPTER 2 OF 12
2. Define recurrence by identity, not availability
A recurrence occurs when the identifier again reaches the wrong resource identity, an unapproved target or a redirect state excluded by closure. A 200 response for a generic repository homepage can still be a recurrence. A temporary network timeout may be a different incident unless it reveals the same failure mechanism.
Use stable landing-page markers such as collection identifier, product version, sensor, processing level or checksum reference. Avoid brittle text snippets that change with page design. The marker set should distinguish the intended record from a merely healthy page.
CHAPTER 3 OF 12
3. Probe independent paths with comparable requests
Monitor from more than one network, resolver route or cache context when permitted. Keep method, time, headers and redirect-following behaviour comparable. Two browser tabs on the same network are not independent paths simply because they are different windows.
Record the registry API target separately from public resolution. A direct registry read can show current metadata while a public resolver path serves an older response. Conversely, a correct cached redirect can briefly hide a newly wrong registry value.
CHAPTER 4 OF 12
4. Worked example: two failures share one cache path
A fictional DOI should reach collection C4. The registry API and an uncached institutional path both show C4. Two office probes reach C3 with Age values near 1,700 seconds and the same intermediary marker. A mobile-network probe reaches C4 with Age 22 seconds.
The pattern supports an office-path cache hypothesis, not a global registry rollback. The two office observations are correlated because they share the same intermediary. Reopening the original registry incident as if four independent paths failed would overstate the evidence.
| Path | Final identity | Age evidence | Initial interpretation |
|---|---|---|---|
| Registry API | Target for C4 | Not a cached redirect test | Authoritative record appears current |
| Office A | C3 | 1,704 s | Possible shared stale cache |
| Office B | C3 | 1,698 s | Not independent of Office A |
| Mobile network | C4 | 22 s | Separate path resolves correctly |
CHAPTER 5 OF 12
5. Read HTTP cache evidence in context
RFC 9111 defines cache freshness, validation, invalidation and the Age response field. Age estimates time since a response was generated or successfully validated at the origin, as it moves through caches. It is evidence about response handling, not proof of which organisation caused an identity error.
Capture Date, Age, Cache-Control, Expires, validators and the complete redirect chain when available. Header absence is not proof that no cache exists, and identical Age values alone do not prove a common cache. Combine headers with network path and repeated timing.
CHAPTER 6 OF 12
6. Separate authoritative, intermediary and client layers
Start with three hypotheses: the registry target is wrong; an intermediary serves a stale or mis-keyed response; or the client retains local state. Repository redirects add a fourth layer. Test from the authority outward, changing one layer at a time where possible.
Do not use a no-cache request as magical truth. Request directives affect how a cache may respond, but intermediaries and implementations vary. Compare a controlled request with ordinary user behaviour and preserve the exact evidence.
CHAPTER 7 OF 12
7. Use attribution levels rather than certainty theatre
Label attribution as observed, supported or confirmed. Observed means a path produced the wrong identity. Supported means timing, headers or path comparison favour one layer. Confirmed requires direct evidence such as a corrected cache configuration, purge record or registry version that explains the change.
DataCite provenance can show create, update or delete activities, responsible account, time, record version and changed properties for DOI metadata. Its general last-updated timestamp can also change for internal processing such as re-indexing, so that timestamp alone does not prove a metadata edit.
- Preserve the failing response before remediation when safe.
- Read the authoritative record and provenance.
- Repeat from a genuinely separate path.
- Document any purge, expiry or configuration change.
- Verify both target and landing-page identity after action.
CHAPTER 8 OF 12
8. A reopening gate needs recurrence and consequence
Reopen the prior incident when evidence shows the same controlled failure has returned, or when the closed corrective action no longer protects the intended identity. A single unverified report can enter triage without immediately changing the closure state. Severe or widespread wrong-identity resolution may be a hard gate.
The ledger below separates observations from the decision to reopen. The decision owner should record which gate passed, the affected interval and the containment started.
| Gate | Evidence question | Decision effect |
|---|---|---|
| Identity | Did a path reach the wrong resource? | Enter triage |
| Independence | Does recurrence cross separate paths or authority? | Raise confidence and scope |
| Mechanism | Is it the same controlled failure or failed corrective action? | Reopen prior incident |
| Consequence | Are citations or users materially affected? | Set urgency and containment |
CHAPTER 9 OF 12
9. Contain the affected path without rewriting history
If a shared cache path is implicated, notify its operator with a reproducible request, observed headers, expected target and times. Where appropriate, offer a verified alternate access path while preserving the persistent identifier as the canonical citation. Do not silently publish a new identifier to escape a repairable cache problem.
Link the reopened period to the original incident but keep a new event record. Closure was correct for the evidence then; recurrence is a later observation. This avoids changing the original timeline and allows reviewers to measure time between closure and recurrence.
CHAPTER 10 OF 12
10. Close again only after path-specific evidence
A second closure should verify the authoritative record, affected path, at least one independent path, redirect chain and landing-page identity. If the remedy relies on expiry, observe past the relevant freshness window rather than assuming time will cure the state.
Define a shorter heightened-monitoring window after reopening, then return to routine probes when it passes. Repeated closure without understanding the affected path can create a cycle of green spot checks and user failures.
CHAPTER 11 OF 12
11. Limits, misconceptions and changed-context transfer
Caches are not inherently errors; they reduce latency and load when freshness and validation work as intended. A stale response is not automatically malicious or negligent. Evidence should support the named layer and respect provider boundaries.
Transfer check: the repository introduces a content-delivery network that adds another cache. Update the path model, expected headers, expiry assumptions and escalation owner. Do not reuse the old independence claim if every probe now shares the same new edge.
Does a high Age value prove the cache caused the wrong target?
No. Age is useful evidence about response residence or validation, but attribution needs the full redirect chain, authority readback, path comparison and timing. It does not identify an operator by itself.
Should one user report automatically reopen a closed incident?
It should be preserved and triaged promptly. Reopening depends on the declared identity, mechanism and consequence gates, except where a severe hard-stop condition requires immediate action.
CHAPTER 12 OF 12
12. Evidence route and connected reading
RFC 9111 defines HTTP cache operation, freshness, validation, invalidation and cache-related fields. DataCite documents how to retrieve a DOI metadata record and track metadata provenance; it also explains why the general last-updated time does not necessarily mean metadata changed.
Continue through resolver-failure monitoring, identifier-target change control, and the immediate closure-testing guide. The Remote Sensing root connects the wider subject.
Contents · Previous chapter · Return to the Remote Sensing root