Evidence
Backblaze B2 layout
B2 is not where finished files are dropped at the end. It is where every stage reads from and writes to, which is what makes a run reconstructable after the fact.
What is stored
A single twelve-second run produces 60 job-scoped objects:
Inputs
Source master, the immutable job request, authorization evidence.
Intermediates
Transcript, quality decisions, per-segment translations, every speech attempt, captions.
Outputs
Localized audio, the final render, disclosure records, status events, checkpoints, canonical manifests.
Why storage rather than a database
Three properties fall out of it:
- Resumability. A worker that dies mid-run loses nothing. The next claim reads the last checkpoint and continues.
- Auditability. Records are append-only. A superseded translation is still there next to the one that replaced it.
- Independence. The evidence outlives the process that made it. Nothing important lives only in a running service's memory.
This is why retries are cheap
Because completed attempts are already durable, an approved correction reuses every finished stage and only regenerates the segment that failed.
How the application reads it
The browser never talks to B2. Requests go through a server-only bridge, and the media proxies accept a fixed set of kinds or an exact opaque job handle.
source · final · captions · speech
No arbitrary keys
There is no route that takes a B2 key from the client and fetches it.
Attempting one — /api/media?kind=../../private — returns
unsupported_verified_media_kind before any storage call is made.
Hash verification
The application re-checks stored media hashes before describing bytes as verified. A manifest asserting a hash is not treated as sufficient on its own; the object is hashed and compared.
The example run's final MP4:
369f3eea954c2bba91bd7a65cade78a86a9f9e1050cf915702e9a2da2e3917fe
Browsing it
The B2 assets page lists the highlighted objects for the example run with their kinds, sizes and full keys.