Model aliases do not establish deployment provenance

General lesson — A recorded model alias is not deployment provenance. Dataset projections often retain prompt.model, timestamps, and prompt/tool digests while dropping the call-level deployment envelope. In that shape, a uniform model alias can prove which name the node snapshot recorded, but cannot prove provider, base URL, release-routing arm, application commit, dependency revision, serving proxy, container image, or exact request bytes. Treat missing projected fields as “not materialized,” not as evidence that the original recorder lacked them.

Applicability and limits: Before calling a replay historical or wire-exact, inventory the exact acquired keys and distinguish per-call evidence from general local source/checkpoint compatibility. A local checkpoint hash matching the model alias and a plausible proxy translator are useful reconstruction inputs, but neither binds historical calls to those bytes or commits.

Evidence/example (2026-09-16): A frozen 198-call contact set had the same recorded Qwen model alias in every node snapshot, matching source digests and one tool-contract digest. Its acquisition rows contained node prompt/turn/state data but no deployment, provider, base URL, commit, image, or request digest. Local application/proxy/checkpoint sources supported a compact candidate mapping and did not contradict it, yet no per-call artifact bound those sources to deployment.