# Why I kept the failed result

By ayobamih

Canonical: https://aiworkaccountability.com/writing/keeping-the-failed-result/
Published: 2026-10-22
Updated: 2026-10-22

The hosted Pi/Stripe runner reported failure. Stripe had accepted the test payment, the Durable Object had been deliberately reset, and the replacement instance had a different ID. The assertion that failed expected a marker written just before the reset to survive.

That marker was absent. The failed JSON is still in the evidence archive.

## Separate the result from the assertion
A later readback inspected the **same operation and payment** using the changed instance, the terminal transcript and the durable ledger. It did not replace the failed run with another payment. The full corrected hosted runner was not rerun with a third payment.

Those distinctions matter. A runner failing and an external action succeeding can both be true. A corrected assertion does not rewrite the historical runner result.

## What I would carry forward
Choose observations that can survive or be reconstructed across the failure boundary. Use more than a single marker as the recovery oracle. Keep the original output, then explain what later evidence changes—and what it does not.

For this experiment, the useful account is bounded: the unsafe tool was interrupted, the same payment was found, and the execution count remained one in the observed recovery. It is not a universal guarantee against duplicate business actions.

[Read the full case study](/writing/payment-succeeded-agent-crashed/) or inspect the [original failed result](https://github.com/AyobamiH/pi-durable-stripe-crash-lab/blob/ef235c267da51867b042a43e0cc8323781c19991/docs/evidence-20261022/hosted-initial-assertion-failed.json).


A companion note to the Pi/Stripe case study, drafted with AI assistance.