The Outbox

"You already paid for this response. Losing it means buying it again. So save it before you do anything else."

The Last Gap: Paid, But Can't Report It

Walk the happy path to its final step. The executor reserved, submitted, and got a good response back from the provider. The money is spent, and — this is the point — the result is now genuinely valuable, because it cost money to obtain. Its next job is to hand that result to the control plane for durable acceptance. And right there is the last gap: what if the control plane is briefly unreachable at that exact moment? A network blip, a control-plane restart, a moment of Wi-Fi. The executor is holding a paid-for response it can't deliver.

If the executor were to drop that response — crash, give up, move on — the result would be gone, and the only way to get it back would be to pay for it again. That's the exact failure the whole track has been guarding against, reappearing at the finish line. The reservation ledger protected the spend; now something has to protect the response you already bought.

Save It Locally Before You Acknowledge

Recall's answer is the outbox. The instant a successful provider response arrives, the executor atomically writes it to a local outbox file — before it tries to acknowledge completion to the control plane. Only after that local copy is safely on disk does it attempt to report. Now the ordering guarantees survivability:

Control plane unreachable? The paid response is safe in the outbox. When connectivity returns, the executor replays it — no second purchase.
Executor crashes after paying but before reporting? On restart, the outbox still holds the response, ready to submit.
Control plane confirms it has durably recorded the response in its ledger? Only then does the executor delete the outbox copy — the value is safe elsewhere, so the local copy is no longer needed.

This is the store-and-forward pattern, and it's the mirror image of the reservation. The reservation records intent before spending; the outbox preserves the result after spending. Together they bracket the paid call so that no crash, on either side of it, ever forces you to pay twice.

The Shape of Never Paying Twice

Step back and see the whole track as one mechanism. A reservation makes the spend visible before it happens. A content-addressed identity makes the same purchase recognizable so it's bought once. The ambiguous state and the no-retry rule refuse to guess where guessing spends money. And the outbox guarantees that a response you already paid for is never lost to a transient outage. Each piece closes one crash window; together they turn 'pay once' from a hope into an invariant the machine enforces. That is what it means to treat money as a first-class concern in a system's design.

Code

Save the paid response to the outbox before acknowledging·python

response = provider.transcribe(chunk)   # money already spent

# 1. Protect the paid result LOCALLY first — atomic write.
outbox.save_atomic(submission_id, response)

# 2. Only now try to hand it to the control plane.
try:
    control_plane.complete(submission_id, response)
except Unreachable:
    pass  # fine: the outbox holds it; replay later, no re-purchase

# On reconnect / restart: replay anything still in the outbox.
for pending in outbox.list():
    control_plane.complete(pending.id, pending.response)

# Control plane confirms it's durable in the ledger -> now delete.
outbox.remove(submission_id)

Exercise

Find a place in your own work where you obtain something expensive or hard-to-reproduce and then immediately try to send it somewhere (save to a DB, POST to a service, enqueue it). Ask: if that send fails, is the expensive result lost? Design an outbox: write the result to durable local storage first, attempt delivery, replay on failure, and delete the local copy only after the destination confirms receipt. Note what re-cost you just eliminated.

Hint

The vulnerable shape is 'compute/buy the expensive thing, then send it, and if the send fails, it's gone.' Insert a durable local hop: persist the result before the send, so a failed delivery becomes a replay instead of a re-purchase. Delete the local copy only on confirmed receipt — that confirmation is what tells you the value is safe elsewhere.