Normalized failure outcomes are not proof that an upstream service processed a request

General lesson: When sensitive diagnostic evidence should be retained only after an upstream service actually processed a request, do not gate retention on a normalized terminal outcome alone. A client adapter may collapse provider responses, proxy statuses, and local transport deadlines into the same outcome. Carry an explicit provenance signal (for example, validated provider response vs proxy/transport failure) and require that signal at the persistence boundary. This applies to evidence capture, billing, auditing, and retry decisions; it is unnecessary when policy intentionally treats all attempted sends alike.

Evidence/example (2026-09-16): In COR-4270's realtime Adam integration, the route proposed persisting every decode_deadline_exceeded result. Inspection showed the Adam client produces that same result both for any HTTP 504 and for its own six-second transport abort, so the route cannot prove Adam processed the image. The focused route tests mocked only the normalized result and therefore did not expose the ambiguity. Recommended correction: add response provenance to the client result or otherwise distinguish a validated engine deadline before scheduling evidence persistence. Sources: https://linear.app/coreedgesolution/issue/COR-4270/persist-failed-adam-realtime-frames-for-diagnosis and https://github.com/e3-solutions/theft/pull/889

Evidence is the observed shared mapping in the client adapter. Inference: some HTTP 504s may originate in a proxy and a local abort may occur before Adam begins processing. Uncertainty: exact deployed proxy behavior was not exercised in this review.