Content-Addressed Identity

"The same audio, under the same settings, is the same purchase. It should cost money once."

What Makes Two Calls 'The Same'?

The reservation ledger from the last lesson only prevents double-spending if it can recognize that two calls are the same call. So the identity of a paid call has to be chosen with real care. What would go wrong with the obvious choices?

The filename — a file can be renamed or moved while its audio is unchanged, and two different files can share a name. Filename is not content.
A random request id — generated fresh per attempt, so a retry of the identical call gets a new id and looks brand new. That guarantees double-payment, not prevention.
A timestamp — different every time; same failure as a random id.

Every one of these lets the same audio be paid for twice. The identity has to come from the thing that actually determines the cost and the result: the content.

Identity Is the Hash of the Content Plus the Config

Recall's paid-call identity is a pair of hashes: the SHA-256 of the exact audio chunk being sent, and the SHA-256 of the exact provider configuration. Identical audio bytes under an identical configuration produce identical hashes, which produce the same identity — so a repeat attempt lands on the ledger row that already exists, finds it completed, and reuses the stored response instead of paying again. Pay once, per identity, guaranteed by content, not by a name or a clock.

Why is the config part of the identity too? Because the same audio transcribed with a different model or different settings is a genuinely different call — it produces different evidence and legitimately costs money again. Folding the config hash into the key means 'same audio, same config' is one paid identity, while 'same audio, new config' is correctly a new one. The identity captures exactly what determines the output: bytes and configuration, nothing else.

Content-Addressing, Now for Money

You met content-addressing in Track 3, where a release's content hash made summaries detectable as stale. This is the same idea pointed at spending. When identity is derived from content, 'have I already done this?' becomes a lookup instead of a guess: hash the inputs, check the ledger, and you either find the completed work or you don't. Naming things by their content — rather than by a label a human assigned or a clock produced — is what turns 'don't pay twice' from a hopeful convention into a mechanical guarantee.

Code

Identity from content + config, checked against the ledger·python

import hashlib

def paid_identity(audio_chunk: bytes, config: dict) -> tuple[str, str]:
    chunk_hash = hashlib.sha256(audio_chunk).hexdigest()
    config_hash = hashlib.sha256(canonical_json(config)).hexdigest()
    return (chunk_hash, config_hash)   # the paid-call key

def reserve(audio_chunk, config):
    key = paid_identity(audio_chunk, config)
    existing = ledger.find(key)
    if existing and existing.status == 'completed':
        return existing.response      # already paid — reuse, don't POST
    return ledger.create_reservation(key)  # new identity — reserve

# same bytes + same config -> same key -> paid at most once
# same bytes + new config  -> new key  -> legitimately a new call

Exercise

Find an expensive or side-effecting operation in your own work that could accidentally run twice — a paid API call, a heavy computation, an email. Ask: what is its identity right now? If it's a filename, a random id, or a timestamp, list the inputs that actually determine its result and its cost. Design a content-addressed key from those inputs, and describe how a 'have I already done this?' check would use it.

Hint

Test your key with two thought experiments: (1) if the same real work is retried, does the key stay the same so the retry is a no-op? (2) if a genuinely different input changes the result or the price, does the key change so it's correctly treated as new work? A good identity answers yes to both — that usually means hashing every cost-determining input and nothing else.