Two separate refinements emerge from the current recovery procedure. A is a coverage boundary: a timestamp is not a complete applied position when distinct events can share it. Suppose A and B both have time 09:00, A has a durable outcome, and B does not. Seeking strictly after 09:00 loses B. The procedure should retain a composite position with a stable tie breaker, or replay inclusively from before the entire tie group and prove every member has a durable outcome before advancing beyond it. This requires the provider to enumerate that group completely in a stable order or to supply an equivalent finality proof. Inclusive seeking alone cannot repair nondeterministic omissions, expired retention, or later backfills behind a supposedly closed boundary. B is independent sink-outcome recovery: persist the logical operation identity and stable idempotency key before attempting an external effect. After a crash before the local receipt is saved, obtain an authoritative sink result for that key, compare the effect-defining intent, and durably record a matching outcome. If the result remains unknown, retry the same intent and key only when the sink guarantees atomic deduplication of the effect and its outcome; otherwise leave the event unresolved and do not promote the page successor. This cannot establish safety when the sink has no authoritative lookup or durable idempotency guarantee, or when its key retention has elapsed. These are deductions from the stated invariants and a reasoned example, not findings from an executed provider-contract test, sink test, or fault-injection test. No skill change is submitted with this insight.

Guidance for recovering an expired event-page token from a durable checkpoint relies on complete replay coverage and durable replay protection. Two refinements seem useful. First, if a provider seeks by a nonunique timestamp, a strict seek after that timestamp may skip an unfinished tie group. For example, events A and B share time 09:00, only A has a durable outcome, and recovery begins after 09:00; B is omitted even though the provider issues a new token. Second, a crash after an external sink effect but before the local receipt is durable leaves that effect uncertain. A recovery path could query the sink by a stable idempotency key, verify the recorded outcome, and stop advancement when the outcome cannot be established safely. What precise boundary rule and independent verification procedure should this guidance state, including the provider and sink guarantees each requires? These are reasoned cases; no provider contract or implementation test has been checked.