Provenant-Git for Generative Media

Provenant is a version-control system for AI-generated media built on top of Genblaze and Backblaze B2. Every generation is an immutable, content-addressed, hash-verified "commit."

Comment

Inspiration

Modern generative AI workflows are chaotic. Creators regenerate and tweak prompts dozens of times, losing track of earlier versions, costs, and the relationship between an original asset and its refinements. There's no equivalent of git log for a chain of AI-generated images, videos, or audio. We wanted to bring the discipline of version control — commits, lineage, forks, rollbacks — to generative media, so every asset a creator produces is traceable, auditable, and never truly lost.

What it does

Provenant treats every AI generation as an immutable commit: a record with the prompt, provider, model, cost, and a cryptographically verifiable manifest. Creators can:

  • Commit a new generation (image, video, or audio) from a prompt
  • Refine an existing asset, preserving a parent-run pointer so the full lineage is never lost
  • Fork a project to explore a new direction while keeping cryptographic lineage back to the original checkpoint
  • Verify integrity by re-hashing local assets and comparing them against the canonical manifest stored in Backblaze B2
  • Roll back the project head to any previous commit instantly

Every commit's manifest and media asset are stored in Backblaze B2 under a clear hierarchical layout (runs/<project>/<run_id>/...), so the full history of a project's media generation lives durably in object storage, not just a local database.

How we built it

The backend is built on FastAPI, orchestrating generation through the official Genblaze SDK family — genblaze-core, genblaze-s3, genblaze-gmicloud, and genblaze-elevenlabs. Each commit is built using Genblaze's public StepBuilder and RunBuilder APIs, which produce a SHA-256-verified canonical manifest via Manifest.from_run(). Assets and manifests are pushed to a Backblaze B2 bucket through genblaze-s3's S3StorageBackend, using a hierarchical key strategy so lineage is reconstructable directly from the storage layout — not just our app's database. Image generation runs through Google's Gemini API, with GMI Cloud integrated as an additional provider option for image and video generation.

Challenges we ran into

  • Respecting the SDK's public contract: early on, we found ourselves reaching into a private, underscore-prefixed Genblaze attribute (_parent_run_id) to link refined commits to their parent, because our refine endpoint only has a parent run ID string at request time, not a live PipelineResult object. We caught this in review and switched to Genblaze's documented "manual builds" pattern (RunBuilder(...).parent(run_id)), which does the same job through the public API — and we verified with a grep pass that no private-attribute access remains anywhere in the codebase.
  • Credential hygiene under time pressure: we discovered a live B2 application key had leaked into project files. We treated this as non-negotiable even close to deadline — rotated the key in the B2 console, generated a new one, and re-verified the full commit → B2 upload → manifest-fetch flow end-to-end with the new credentials before considering it resolved.
  • Proving lineage, not just claiming it: rather than trusting our own API's response, we insisted on fetching the manifest.json directly from B2 (independent of our app) to confirm parent_run_id was genuinely present in the stored artifact itself.

Accomplishments that we're proud of

  • A refine/fork/rollback flow where lineage is provably intact — checked not just through our app, but by pulling the manifest straight out of B2 and confirming the parent pointer matches.
  • Clean adherence to Genblaze's public SDK surface after catching and fixing an internal-API dependency before it could break silently.
  • Taking security seriously under deadline pressure: full credential rotation, verified with live before/after tests, not just a doc edit.

What we learned

That verifying your own claims is as important as building the feature. Several times during development, something that looked complete on the surface (a key removed from a README, a "supported model" listed in an enum) turned out to still need real end-to-end proof — a live API call, a raw manifest fetch, a hardcoded value we hadn't actually wired up. That discipline of demanding raw evidence over narrated summaries shaped how we shipped the whole project.

What's next for Provenant — Git for Generative Media

  • Extend true multimodal reference-image support to newer Gemini model variants (currently our image pipeline is wired to Gemini 2.5 Flash; broader model support is in progress)
  • Wire up a fully working audio pipeline through ElevenLabs TTS (currently integrated at the SDK level, with real audio generation still being finished)
  • Move Backblaze B2 Object Lock from commit-level metadata into enforced, audit-grade retention at the storage layer, for true compliance-grade immutability
  • A visual "commit graph" UI so creators can see branches and lineage the way they'd see a git history
  • Team/multi-user support so provenance tracking works across a whole creative team, not just a single creator

Built With

Share this project:

Updates

Submission history