After a parser repair, do not request every old URL again. Replay only a retained snapshot when retention, the separate replay purpose, and recorded context are all explicitly allowed. For expired or missing input, request anew only when a current task is still needed and current permission is explicitly allowed. Everything else stays on hold.
This guide is for the owner of an authorized recurring data workflow whose parser changed after records were produced. Its job is to correct clearly labelled historical output without turning a repair into unbounded recollection. It does not grant access, extend a retention period, prove a source is current, or diagnose a proxy. An API, licensed export, source correction, or manual review may be the better route.
Start with two different products: a correction and an observation
A local replay reads the exact retained input under the new parser and writes a historical correction. Preserve the original observation time, source/context version, snapshot identifier, parser versions and correction time. It may fix what was extracted from that old input; it cannot claim what the source says now.
A recollection creates a new observation at a new time. It must meet current source permission, task scope, rate and retention rules, and it should not silently overwrite the old result. Keep both records linked. HTTP describes representations and cache controls, but an HTTP freshness rule does not itself authorize a business workflow to retain, reuse, or newly request source material.
| What is available? | Safe action | What the resulting value means |
|---|---|---|
| Retained snapshot; retention and replay permission both allowed; context complete | Replay locally; keep the original result and write a labelled correction. | Corrected historical interpretation of that snapshot, not a current observation. |
| Expired or deleted input; current task remains needed; current-request permission explicitly allowed | Add one current request to the recollection set. | New observation with a new timestamp, not rebuilt history. |
| Retained bytes with missing, unknown, or denied replay permission; retention disallowed; or context incomplete | HOLD. Do not use a copy, log fragment, or memory as a substitute, and do not automatically convert it into a new request. | No repaired value. |
| Expired/missing input but current permission is unknown or denied, or the task is no longer useful | HOLD; obtain a decision or close the record. | No request and no inferred result. |
Build the minimum recollection set, not a repair queue
First freeze the affected parser version and define the affected extraction path. A changed selector is not proof that every stored record is wrong. Classify each record once using an audit row: record ID | parser/version | input state | retention basis | replay permission | context completeness | original observation time | current need | current-request permission | disposition | owner.
- Exclude unaffected records. A record outside the changed parsing path is
SKIP; do not refresh it merely because the release happened. - Replay eligible retained inputs locally. Eligibility needs all four: bytes are still retained under the approved rule, retention is permitted, the separate replay/correction purpose is explicitly permitted, and captured context can identify the representation well enough. Missing language, market, account scope, response timestamp, source version, or parser provenance can make a snapshot inadequate.
- Hold retained inputs with an unresolved replay boundary. Missing, unknown, or denied replay permission; a retention dispute; or incomplete evidence cannot automatically turn retained bytes into a network request. Expired or deleted input is different: it cannot be replayed, but it may be evaluated for a separately allowed current observation.
- Admit a fresh request only for an outstanding current decision. It needs a named owner, explicit current permission and applicable limits. Add its record ID once; a second request is not justified by the parser fix alone.
- Publish two ledgers. Historical corrections and new observations must have separate timestamps, denominators and downstream labels. A current report should not substitute a new value for a historical-period record.
Formally, the minimal recollection set is the records where affected AND input_is_expired_or_missing AND current_needed AND current_request_permission_explicitly_allowed. A retained-but-not-replayable input is not silently treated as “missing”; it holds until its replay/retention boundary is resolved. All other affected records resolve to local replay or hold. This is a policy gate under those explicit assumptions, not an estimate of source change or a cache hit rate.
Worked synthetic example
The six records below are invented teaching inputs. They do not represent customer data, stored pages, access rights, IPHTML behavior, or a recommended retention duration.
| Record | Parser path | Input and permission state | Decision | Reason |
|---|---|---|---|---|
| A | Affected | Retained; retention and replay allowed; complete context | REPLAY_LOCAL | Correct the old output, retaining its original observation time. |
| B | Affected | Snapshot expired; current task needed; current permission allowed | RECOLLECT | Expiry blocks replay, but explicitly allowed current work produces a new observation. |
| C | Affected | Input missing; current task needed; permission allowed | RECOLLECT | One eligible new observation belongs in the minimum set. |
| D | Affected | Input missing; current task needed; permission unknown | HOLD | Do not infer permission from an old workflow. |
| E | Unaffected | Retained input available | SKIP | The parser repair does not touch this path. |
| F | Affected | Retained; replay permission unknown; current request otherwise allowed | HOLD | Do not convert unresolved replay permission into a new request. |
The answer is two current requests: B and C. A is repaired without network activity. D is absent because current permission is unknown; F is absent because its retained input's replay boundary is unresolved. B and C create new observations, never reconstructed history.
Run the offline decision fixture
Download the parser-repair fixture and run it with Python 3.9 or later. It uses only the standard library, has no configuration, makes no network requests, and never changes a collection system.
python3 parser-repair-replay-plan.pyIts meaningful assertions show that A is a historical local replay; B and C are the two synthetic recollections; an expired snapshot never replays; unknown current permission never admits a request; and unknown replay permission on retained bytes remains held even if a current request would otherwise be allowed. Counterexamples reject an invalid permission value, unapproved retention, and unknown replay permission. The fixture trusts its supplied policy fields; it cannot inspect an actual contract, source, snapshot, or parser.
Controls that keep the correction honest
- Keep immutable references to old output and input disposition; do not edit a report in place without a correction record.
- Record why a replay is allowed and when its input must be deleted.
no-storeor a source-specific rule is a stop condition, not a convenient exception. - Test the repaired parser against representative retained fixtures before accepting a correction. A parse success alone does not prove field semantics; use the field-quality guide for field contracts and quarantine.
- Keep request reduction separate. The duplicate-request guide governs shareable retrieval and freshness, not whether a historical parsing defect warrants a new observation.
- When a reported panel has a corrected historical value, preserve its coverage/provenance label; the regional-coverage guide explains why a later observation cannot silently fill an old reporting window.
- Route unresolved permission, retention, or possibly duplicated side effects to the owner. An incident backlog can have different safety gates; see the incident runbook.
If a genuinely authorized current observation remains after this triage and requires an appropriate rotating network context, review IPHTML’s rotating proxy information. For a scoped discussion, contact IPHTML with the authorized source, current-decision deadline, context dimensions, retention boundary and stop conditions—never credentials, raw snapshots, or personal data. Existing APIs, licensed feeds, exports, or direct approved access remain preferable when they meet the task.
Sources checked November 9, 2026: RFC 9110 for HTTP representations and request semantics; RFC 9111 for cache storage, freshness, validation and no-store; and the NIST Privacy Framework for privacy-risk management context. These sources do not authorize collection, prescribe a retention period, validate this fixture, or establish demand, product performance, paid conversion, or retention.