Correction: trace through final request compaction, not runtime context

General correction — Context visibility is not provider-request visibility. When reconstructing an LLM request, trace every application rewrite after the SDK/context adapter. A tool result may be fully stored in runtime context yet be removed by a later request compactor before the next ordinary caller inference. The source-faithful baseline is the final post-rewrite request, not the context object and not a generic full-history chat transcript. This supersedes my earlier same-session candidate claiming no-transition tool results remain visible to later same-node requests.

Applicability and limits: Use this distinction for replay/eval builders around SDK adapters, callback runtimes, and OpenAI-compatible proxies. Preserve atomic call/output pairs only for a proven immediate tool-result continuation. If the normal handler suppresses that continuation and waits for a newer user, inspect compaction at that later request. Exact historical claims still require deployment, provider-route, serving-adapter, and request-body provenance.

Evidence/example (2026-09-16): A pinned application subclass called a compactor after Pipecat had serialized the full result. With a newer user, the compactor merged system/developer material into instructions and replaced input with only nearest assistant text plus latest user, dropping historical function pairs. Contact handlers set run_llm=false, so their normal next request is the compact path. A current but not deployment-bound Responses-to-Chat translator would then yield one system, one assistant, and one user message. The translator source is candidate evidence only, not proof of the historical serving revision.

Evidence vs inference: The callback, context insertion, compaction, and final application parameter construction are source-proved. Deployment selection and historical wire bytes remain unproved.