The Authorized Rerun

"Sometimes you genuinely need to buy the same thing twice. That is not a reason to weaken the guarantee that says you can't."

The Hole the Guarantee Leaves

The identity from lesson 2 of this track is airtight: same audio bytes, same provider configuration, one paid call. Ever. Now here is the situation the archive actually produced. A video's transcript is bad — not structurally broken, just wrong in a way a human noticed — and you want fresh evidence. The audio hasn't changed. The configuration hasn't changed. So the content-addressed key hasn't changed either, which means the ledger will find the completed row and hand back the old response forever. The guarantee is working exactly as designed, and it is standing between you and something you legitimately want.

This is the moment where most systems acquire their worst flag. Two wrong fixes present themselves, and both are tempting because both are one line:

Delete the ledger row. Now the key is free, the next attempt pays, done. It also destroys the record that you ever paid the first time — the exact record the reservation ledger exists to keep. You'd be fixing a money problem by deleting your money history.
Add a flag that skips the ledger check. --force-pay, --ignore-cache, something. It works, and it also puts an unguarded paid POST one reflex away from every operator, forever. Track 5 already showed what happens to a flag people reach for when something looks stuck.

Extend the Identity Instead

Recall's answer doesn't touch the guarantee at all. It adds a third component to the identity. The paid-call key is no longer a pair but a triple: the audio chunk hash, the configuration hash, and a rerun_generation integer that starts at zero and only ever increases. The database's uniqueness constraint covers all three.

Read what that buys. Within generation 0 — which is every ordinary transcription the pipeline has ever run — nothing changed. Same bytes and same config still collapse to one key, still find the completed row, still refuse to pay twice. The guarantee is not weakened by a single byte. But a new generation is a genuinely different key, so it finds nothing, reserves honestly, and pays. You didn't create an exception to at-most-once. You created a second lane where at-most-once holds just as strictly.

And because the generation is a stored column rather than a bypassed check, it leaves a trail. The next generation for a video is one above the highest that video has ever used, so the number itself answers "how many times did we deliberately re-buy this?" A skipped check answers nothing — that's the difference between an audit trail and a hole.

Who Is Allowed to Mint One

The dimension is only as safe as the authority that can move it, so minting a generation is deliberately not reachable from anywhere work happens automatically. Not the worker. Not a retry. Not --force, which still leaves the paid key untouched exactly as Track 5 described. The only path is an operator pressing Retranscribe on a specific video in the console, and that action previews before it acts — the preview says spends_scribe_credits in so many words, names the video, and reports which generation is about to be minted.

One authorization covers every audio chunk of that one video, because the counter is tracked per video and stamped into the job. That's the right granularity: a human looked at one video and decided it was worth money, and the machine spends money on exactly that video.

There's a second door in this system that looks similar and isn't, and telling them apart is worth a moment. Resolving an ambiguous submission with an explicit paid-rerun authorization (Track 4, lesson 3) reopens the same ledger row — same key, same generation — because that situation is "I don't know whether I paid." Retranscribe mints a new generation because its situation is "I know I paid, and I want to pay again." Different uncertainties, different doors, and neither one is a flag you'd hit by reflex.

The Follow-Through Nobody Expects

One detail in the preview is worth stealing wholesale. Before it queues anything, Retranscribe checks whether this video's current transcript had already been approved into the knowledge corpus (Track 7) — and if so, it carries that fact into the job as a follow-through. Buying new evidence will produce a new release, which means the approved thing downstream is about to become the wrong thing. The re-purchase remembers to go fix what it invalidated.

That's the general shape: an authorized exception has to chase its own consequences. It's easy to design the door and forget that everything downstream was built on what the door just replaced.

Code

The key gains a third component, not an exception·sql

-- Before: same bytes + same config = one paid call, forever.
--   UNIQUE (chunk_input_sha256, configuration_sha256)

-- After: an explicitly authorized dimension joins the key.
CREATE TABLE provider_submissions (
  submission_id        TEXT PRIMARY KEY,
  chunk_input_sha256   TEXT NOT NULL,
  configuration_sha256 TEXT NOT NULL,
  rerun_generation     INTEGER NOT NULL DEFAULT 0
                         CHECK(rerun_generation >= 0),
  status               TEXT NOT NULL,
  response_json        TEXT,
  UNIQUE (chunk_input_sha256, configuration_sha256, rerun_generation)
);

-- Generation 0 = every ordinary run. at-most-once, unchanged.
-- Generation 1 = a human said "buy this one again", on the record.
-- Within EACH generation the guarantee is exactly as strict.

Minting a generation is an operator act, and it previews first·python

# The ledger lookup is unchanged -- it just carries the third key part.
existing = ledger.find(chunk_hash, config_hash, rerun_generation)
if existing and existing.status == 'completed':
    return existing.response          # no POST, no charge

# A new generation is minted ONLY by the console Retranscribe action.
def preview_retranscribe(video_id):
    return {
        'video_id': video_id,
        'paid_rerun_generation': next_generation(video_id),  # max + 1
        'spends_scribe_credits': True,      # said out loud, before acting
        'lantern_follow_through': current_release_is_approved(video_id),
    }

# NOT reachable from: --force, the worker, any retry path.
# next_generation() is per VIDEO, so one authorization covers
# every chunk of that video -- and nothing else.

Exercise

Find a uniqueness or at-most-once guarantee in your own work — a dedupe key, a unique index, an idempotency key, a 'send only once' rule. Now imagine the day you legitimately need to repeat that operation. What is the current escape hatch: is there a flag that skips the check, or a manual row deletion in a runbook somewhere? Redesign it as an extra component of the key, decide who is allowed to increment it, and name what downstream would be invalidated by the repeat.

Hint

Three questions separate a good escape hatch from a hole. (1) After using it, can you still count how many times it was used, and by whom? If not, it's a bypass. (2) Is the guarantee still fully enforced within each value of the new dimension? It should be — you're adding a lane, not removing a rule. (3) What was derived from the thing you're about to replace, and does the escape hatch know to go fix it?