How do you reconstruct a past AutoBot approval or refusal today?

[kimjooyoon]

I'm asketeddy, maintainer of the experimental Gooo Go Ports project, and this question was drafted with AI assistance; I haven't deployed AutoBot.

While reading #17229, I wondered how you currently reconstruct the input, applicable policy version and approval or rejection outcome for a past run from session state and chat history.

If you have a recent non-sensitive example from maintaining or running AutoBot, which record was hardest to recover, and what workaround did you use?

[mrveiss]

hey, thanks for starting this thread and sorry for the slow reply. I honestly didn't notice it, I'd kind of written the discussions section off as a ghost town since every comment so far has come in through issues directly. so it's nice to see someone actually using it

on #17229, we're not there yet. the approval itself does survive, the gate row in postgres keeps who decided, when, the risk tier, a payload hash and which workflow step it was. but the run around it doesn't. the session row is a resume blob that expires, the per-turn context (model, authority, whether approval was required) gets rebuilt each turn and never saved, and chat history is a per-session json file you can read but can't really query across sessions

policy version is the hardest one because nothing records it at all. today the best you could do is take the approval row plus the chat file and work out from git history which policy was probably live at that timestamp. that's a guess, not a record

where we want to land is one durable record per run covering who and with what authority, policy context, data touched, model and tool calls, human decisions and the outcome, with the retention class set when the run closes. the bar is that a run can be rebuilt from that record alone without the chat files

I saw you're working on decision receipts on your side, so if you have thoughts on how to tie the policy version to a decision I'd be glad to hear them

[kimjooyoon]

Thanks — I would bind the policy at the decision point, rather than infer it from timestamps.

There is already a useful seam: resolve_action_line resolves the scoped stored line, baseline category and role requirement before calling the pure resolver. Capture the values actually consumed there, including unavailable/defaulted states; rereading settings afterward could record a different policy.

For a first increment, I would retain a versioned policy artifact containing the evaluator identity and decision-affecting rules/configuration, with an explicit serialization and digest. Each durable decision would link that artifact to its run/correlation ID, step/attempt, request snapshot, resolved authority, outcome/reason and any approval ID. A Git SHA helps identify code, but not live configuration. The digest identifies retained bytes; it neither replaces them nor authenticates their producer.

Keep this as immutable decision history alongside the approval lifecycle. Resubmission currently updates context and payload_hash, so one mutable row should not become the only record of earlier proposals. A policy/authority change while paused should create a linked new evaluation under current execution rules; preserve the original human decision separately from the eventual execution result.

A focused acceptance test: decide under A, change live policy to B, remove chat/resume state, then reconstruct the original decision from the durable record and archived A. Missing artifacts must report “historical policy unavailable,” never substitute B.

This reconstructs evidence, not external behavior: retain relevant model/tool observations without rerunning effects. Deterministic replay needs the actual inputs and evaluator; redacted or expired inputs must be marked as limiting replay. Apply access controls and the run's retention class to those artifacts, without copying credentials into audit rows.

Written with AI assistance; I have not deployed AutoBot.