Get Receipt

"Show me how you got that" -- E2's own acceptance bar. Returns the exact recipe/series_versions/result this receipt was written with, PLUS replay: a fresh re-run of the same recipe, hash-compared against the stored result -- OI's own pure, DB-free replay_receipt() (receipt_hash.py, #449) does the comparison and, on a mismatch, explains which tracked series_versions entry changed. result itself is always the ORIGINALLY STORED answer (never swapped for the fresh re-run's own result, even on a mismatch) -- a receipt's job is to say what was actually served.

REPLAY NEVER RECORDS A NEW RECEIPT as a side effect of checking one (R2C review of #452, non-blocking item (c)) -- _chat_check_comparability(..., record= False) is the non-recording variant built specifically for this call site.

REPLAY NEVER BLOCKS THE RAW READ (same "secondary concern never breaks the real response" discipline _record_receipt() itself already follows) -- any failure (an unknown/future query_kind this function doesn't know how to re-invoke, a transient DB error during the fresh re-run) degrades replay to None rather than 500ing a request whose whole point is "show me what was already recorded".

facts_drift/method_drift (#802, panel finding 5, migration 098): additive to replay above, not a replacement. replay['explanation'] can only ever INFER "the method may have changed" from the ABSENCE of a data explanation; facts_drift is a direct field-by-field diff of the actual facts dict evidence_verdict.evaluate() decided from (stored at write time vs. freshly recomputed here), and method_drift directly compares this receipt's own pinned deploy_commit against the CURRENT one -- real, nameable signals rather than an inference. Both None when the receipt predates migration 098 (never captured facts/method at write time) -- that is NOT the same as "no drift", so this never fabricates a clean bill of health for a receipt that simply has no baseline to diff against.