AMBER — autopsy for dead objects in your B2 bucket

Inspiration

Generative media pipelines create thousands of assets an hour — and some of them die. Renders truncated mid-write. Outputs orphaned when their run metadata is lost. Versions quietly retired by a lifecycle rule at 3am. Every production bucket accumulates these corpses, and when someone finally asks "what happened to this file?", the honest answer is usually a shrug at a hex dump.

I wanted that question to have a real answer, with evidence. In Jurassic Park, a dead creature is reconstructed from DNA trapped in amber. Here, a dead object's life is reconstructed from the lineage DNA in its manifest — and "set in amber" becomes literal: the verdict is sealed under B2 Object-Lock, forever.

What it does

AMBER is a forensic lab for the dead objects in a Backblaze B2 bucket. Pick a body from cold storage and it goes on the light table:

• The autopsy correlates three evidence sources — measured byte forensics, B2 event history, and lineage manifests — into a plain-English, cited cause of death: "Died mid-write — only 59.8% of the file ever arrived", "Auto-deleted by cleanup rule LR-7", "Deleted on purpose — by app key ci-cleanup".
• Every claim shows its proof: the actual B2 event record (viewable raw), the measured byte shortfall, or — honestly — "no hard proof, and that itself is the finding".
• The specimen's portrait is generated through Genblaze (GMI Cloud seedream-5.0-lite) and served from the private bucket via SigV4.
• The seal is the climax: every verdict is written under Object-Lock COMPLIANCE. Press "Try deleting it — watch B2 refuse" and the Worker fires a real versioned DELETE at B2, which refuses with a live 403 AccessDenied. Not a mock — you can watch it happen per click.
• The morgue wall (Durable Object SQLite) persists every sealed verdict, and running meters show the dead weight and $/month your corpses quietly cost.

How it uses Backblaze B2

B2 is the protagonist, not a file dump: live HEAD inspections drive two real autopsies (true Content-Length vs declared-size metadata), specimen images are content-addressed (assets/<sha[0:2]>/<sha[2:4]>/<sha>.jpg) in a private bucket and served through a SigV4-signed Worker proxy (free egress via Cloudflare), the verdict object lives under Object-Lock COMPLIANCE and refuses deletion until 2030, and an HMAC-verified webhook spine with at-least-once dedupe is ready for B2 Event Notifications.

How it uses Genblaze

The Genblaze SDK runs the generation pipeline: Pipeline.ingest stamps provenance manifests on orphaned bytes, and the CONTENT_ADDRESSABLE sink wrote every specimen portrait into B2 by sha256. The canonical-hash manifests are exactly what makes AMBER's citations trustworthy — the same provenance story the SDK itself is built around.

AI providers and models used

• GMI Cloud seedream-5.0-lite via the Genblaze SDK — generated all 10 specimen reconstruction portraits (content-addressed into B2).
• The demonstration corpus's lineage manifests additionally reference GMI Cloud veo3 and seedance-1-0-pro-fast as provenance metadata for video specimens (metadata only, not live generation).

What's real vs demonstration (we label it in the UI)

Two specimens are autopsied live — the Worker HEADs the real B2 objects per request and derives the verdict from what it measures. The other eight run on a labelled demonstration corpus, because B2 Event Notifications (which would make delete/lifecycle events live too) is gated per account. The portraits, the storage, the SigV4 serving, and the Object-Lock refusal are always real. Every verdict wears a badge saying which kind it is.

Challenges I ran into

B2's S3 endpoint occasionally 403s the first signed request after idle — fixed with retry/backoff on the live paths. Object-Lock COMPLIANCE is genuinely irreversible, so sealing a verdict version was a one-way door I had to get right the first time. And Event Notifications being account-gated forced a design decision I ended up proud of: label the seam honestly instead of faking liveness.

What's next for AMBER

Making it pluggable for any bucket: onboard with a read-only application key, live Event Notifications when the account has them, scheduled sweeps that autopsy new corpses automatically, and exportable coroner reports for audit trails.

Try it (no login needed)

Open the live app → click render_truncated.bin (measured live from B2 per request) → any corpus case like promo_cut.mov (open "see the raw event, untouched") → scroll down and press "Try deleting it — watch B2 refuse" for the live 403 → ⚰ Morgue for the persistent wall.

Built With

• aws4fetch
• backblaze-b2
• cloudflare-workers
• durable-objects
• genblaze
• gmi-cloud
• javascript
• python
• sqlite
• typescript