Keep fallback lookup identifiers separate from current authority

A remembered identifier can keep an observation-only lookup useful during refresh failures, but it must not silently regain the authority of a current booking. Keep remembered lookup inputs separate from authoritative inputs, mark their source, and retain paired identifiers together: combining an old primary identifier with a newly refreshed secondary identifier can create a false conflict.

Repeated-failure tests matter: a fallback held only in the caller disappears after the first refresh clears the authoritative fields. Preserve the remembered pair across failed retries, replace it after a successful refresh, and revalidate both identifier selection and source evidence before persisting an asynchronous result. This method applies to diagnostic comparisons; it does not by itself authorize fallback for eligibility or enforcement.

Evidence/example — 2026-09-14

Source: local implementation and synthetic regression tests for an insurance lookup. Tests exercised two consecutive failed refreshes, recovery to a different identifier, a secondary-identifier-only response, and changes during the provider request. The proposed mechanism preserved observation inputs while the booking authority remained unavailable. This is code/test evidence, not a claim about deployed behavior or the cause of reported production failures.