GenLineage

Every generation has a history. Genlineage records each output as an immutable, content addressed commit containing both the asset and the complete recipe that produced it, evaluates it through an agentic evaluator, connects it in a remix DAG, and ships it with a signed provenance manifest, so every asset can be traced back to its origin.

B2 and Genblaze usage

Backblaze B2 is where every asset produced by the pipeline is stored. Assets are organized in an immutable, content addressed structure: assets/sha256/<hash>.<ext> for the original output, derivatives/<hash>/thumb.webp for previews, and a matching provenance/<hash>/ folder containing the asset's manifests and evaluation log.

Because every object is stored by its hash, a remix that reuses an unchanged step does not regenerate or upload the asset again. Instead, it simply references the existing object already stored in Backblaze B2. This allows the remix DAG to grow through deduplication instead of creating duplicate assets.

In production, the API does not proxy asset files. Instead, it returns presigned Backblaze B2 URLs directly. During development, the same folder structure is mirrored on the local filesystem as a fallback.

Genblaze is the verification layer built on top of that storage.

Every commit generates two manifests. The first is Genlineage's own signed recipe, which records the provider, model, prompt, parameters, seed, parent commits, and evaluation scores. The second is a Genblaze manifest created with genblaze core, which produces a canonical SHA 256 based Run, Step, and Asset record using schema version 1.5, signed with the same ed25519 key.

To verify an asset, Genlineage recreates the canonical hash from the manifest and compares it with the recorded value. If either the asset or its recorded lineage has been changed in any way, the hashes no longer match. That result is shown directly in the commit inspector as a pass or fail signature check.

When a step is reused through deduplication, Genlineage keeps the manifest from the original commit instead of generating a new one. This keeps the provenance trail accurate even as the remix DAG grows.

Providers and models used

I built Genlineage around a five phase agentic pipeline: plan, generate, evaluate, retry, commit, rather than a single generation call.

A brief goes through an LLM planning pass using Gemini, which expands it into a complete generation pipeline: storyboard frames, animated shots, voiceover, music bed, grain pass, and the final cut. Every output is scored by an evaluator model against that step's requirements before it can be committed. If the score is below the threshold, the step is retried using the evaluator's feedback, or it fails over to the next provider in that modality.

The providers and models used for each modality are:

  • Images: fal.ai FLUX Pro → Replicate SDXL → Google Gemini (gemini 2.5 flash image)
  • Video: Google Veo 3.1 Lite through OpenRouter → fal.ai Kling v2 → fal.ai Hailuo → Replicate Stable Video Diffusion, which animates the storyboard frame it came from in the remix DAG
  • Voice: ElevenLabs (eleven multilingual v2) → Gemini TTS → fal.ai TTS
  • Music: fal.ai MusicGen
  • Final cut: an ffmpeg compositor that joins the generated shots with crossfades, fades in and out of black, adds the voiceover over a ducked and looped music bed, blends a grain pass on top, and records which commits were used to create the final output.

Every generation route also has a deterministic mock fallback.

Mock provider

The mock provider is a production safety net, it's actually not just a development tool.

If every provider in a modality fails because of exhausted credits, an outage, or rate limits, Genlineage does not stop the pipeline. Instead, it falls back to a deterministic mock generator. The output is clearly marked in the remix DAG and commit inspector as mock (live providers unavailable), so it is never presented as coming from a real provider. This allows the pipeline to finish successfully instead of failing because one provider is unavailable.

The same mock provider also made it possible to build and test the entire five phase pipeline without using live APIs during development. It generates deterministic seeded outputs with no API costs, no network dependency, and repeatable results, making it possible to test the evaluator, retry logic, deduplication, and the overall pipeline independently of any provider.

What it does

You give Genlineage a brief, such as "create a teaser for a coffee brand," and it plans the entire workflow: storyboard frames, animated shots, voiceover, background music, a grain pass, and the final video, while streaming every step live to the browser as a growing DAG.

Each step is generated, evaluated by AI against its own requirements, retried with feedback if it doesn't meet the quality threshold, and only then committed. Every commit is content addressed by hash, digitally signed, and added to an append only project history.

When you remix an existing project, unchanged assets are reused instead of being generated again, allowing the DAG to grow without repeating work or storage. Every commit also includes two provenance manifests: my own Ed25519 signed recipe and a Genblaze provenance record. Both can be independently verified, allowing anyone to confirm that an asset has not been modified since it was created.

How I built it

I built Genlineage with a FastAPI backend and a Next.js/React frontend, using React Flow to render the live DAG.

Generation runs through provider chains for each media type using fal.ai, Replicate, ElevenLabs, Gemini, and Veo 3.1 through OpenRouter. Each provider has automatic failover, and if every live provider for a media type is unavailable, Genlineage falls back to a deterministic mock generator so the pipeline completes instead of failing.

Backblaze B2 stores every generated asset in a content addressed structure, while SQLAlchemy manages the database using PostgreSQL in production and SQLite for local development. If the database is ever lost, it can be rebuilt from the append only project history and the signed provenance manifests.

Authentication uses secure sessions with bcrypt, email verification through Resend, Google OAuth for sign in, and Flutterwave for subscription billing (currently on testmode). All plan limits and permissions are enforced on the server, so they cannot be bypassed by modifying the client.

How GenLineage will help

GenLineage can really help businesses, marketers, and content creators who want to create advertising videos for their products or services. Instead of only generating a final video, it lets users keep the assets created during the process.

One feature I really like is that users can choose to save the individual storyboard frames or the generated shots, not just the final video. Those assets can later be reused, remixed, or edited without having to generate everything again.

Another feature that actually sets GenLineage apart is users can choose the voice and background music they want in their videos. It also shows the estimated cost of every generation, helping users understand how much each output costs.

What I learnt

This project really opened my eyes to how really complex AI media generation pipelines are. I learnt how to connect different AI providers into one workflow, build automatic failover between providers, implement content addressed storage and provenance tracking, and design a system that can retry failed generations while keeping a complete history of every asset.

Challenges I faced

One of the biggest challenges I faced was funding the AI providers. Building an application like GenLineage requires using several paid AI services, and I couldn't afford enough API credits.

For example, fal.ai is fully integrated into GenLineage, but it currently falls back to the mock provider because I don't have API credits. Google Gemini is also integrated, but since I'm using the free plan, I regularly hit its API limits, causing it to fall back to the mock provider as well. Replicate is also connected, but I was only able to add about $1 in credits, so my testing there was very limited.

Building GenLineage has been an incredible learning experience for me. While there is still more to build, I'm proud of how far the project has come. I look forward to continuing to improve it.

Built With

Share this project:

Updates