One shared line reaches both routes; Genblaze records the run, B2 re-hashes 6/6 objects, and 0 remain stale.
Ending B rebuilt, Ending A preserved byte-for-byte, 4 B2 assets reused, and 0 unnecessary AI requests.
One B2 preview is missing, so Ending B is blocked, Ending A stays verified, and publication stops.
4 assets rebuilt, 2 preserved, 6/6 B2 objects verified, both routes safe, and 0 stale media.

Branchline

Change one scene. Rebuild only what it affects. Publish no stale branches.

Changing a script does not change the media already built from it.

For visual-novel, interactive-comic, and branching-game teams, one shared edit can leave voice, captions, previews, and endings out of sync. Rebuilding everything wastes generation. Reusing files blindly risks publishing a broken story.

Branchline is a release compiler for branching generated media. It traces each change through the dependency graph, computes the smallest valid rebuild, asks for approval, runs affected generation through Genblaze, verifies the finished release objects in Backblaze B2, and blocks any route it cannot prove safe.

The result is visible and measurable:

Correct rebuild: 4 assets rebuilt, 2 preserved, 6/6 B2 objects verified, 2/2 routes safe, 0 stale
Correct reuse: 2 rebuilt, 4 verified B2 objects reused, Ending A byte-identical, 0 unnecessary generation requests
Correct refusal: 5 objects verified, 1 missing, Ending B blocked, Ending A independently verified

Most tools stop after generation. Branchline handles what comes next: release integrity.

Inspiration

Generated-media tools are very good at creating a new asset. They are much less useful when an existing project changes.

A creator should not have to choose between regenerating an entire story or trusting that every old file is still valid. The system should know:

What must change
What can stay
What must never ship

That became the core design of Branchline.

What it does

Branchline follows a controlled release loop:

Change → Diagnose → Plan → Approve → Generate or Reuse → Verify → Publish or Block

When a source scene changes, Branchline:

compares the new source state with the previous release;
traces every affected downstream asset and reachable route;
creates the smallest rebuild plan;
waits for human approval before generation;
rebuilds affected media through Genblaze;
reuses only objects already verified in Backblaze B2;
remotely checks the canonical B2 objects and release manifest;
publishes only when every required route passes.

Branchline does not merely report a problem. It changes the release state, verifies the result, and records why publication was allowed or stopped.

Three demo workflows

1. Shared dialogue revision

A shared line changes from:

“The last train leaves at seven.”

to:

“The last train leaves at eight.”

Branchline traces that edit to the voice, caption, and both route previews.

Result: 4 rebuilt · 2 preserved · 6/6 B2 objects verified · 2/2 routes safe · 0 stale.

2. Selective visual revision

Only Ending B’s visual changes.

Branchline rebuilds the two affected files, reuses four verified B2 objects, and preserves Ending A byte-for-byte.

Result: 2 rebuilt · 4 reused · 0 unnecessary generation requests · 6/6 verified.

3. Publication safety failure

Ending B is pointed to a missing B2 preview.

Branchline verifies five objects, rejects one, blocks the dependent Ending B, preserves the independently safe Ending A, and stops the complete release.

Result: 5 verified · 1 missing · unsafe route blocked · no stale branches published.

How it works

Source change
    ↓
Dependency graph
    ↓
Minimal rebuild plan
    ↓
Human approval
    ↓
Genblaze generation or verified reuse
    ↓
Backblaze B2 objects + release manifest
    ↓
Remote SHA-256 and route verification
    ↓
Publish safe routes or block affected routes

This is closer to an incremental software build than a one-off media generator. A source edit invalidates only its downstream dependencies. Verified objects remain reusable. Missing or mismatched objects cannot pass the release guard.

Why Genblaze is essential

Branchline uses genblaze-core[audio] and genblaze-s3 as the generated-media execution and provenance layer.

Genblaze is responsible for:

running the media-generation pipeline;
recording the provider, model, prompt, parameters, and outputs;
producing canonical generation manifests;
preserving parent/child release lineage;
distinguishing new generation from verified reuse;
writing generated outputs through the B2 storage integration.

The demo’s generated voice path uses Google Gemini TTS with gemini-2.5-flash-preview-tts and the Kore voice.

Without Genblaze, Branchline would lose the reproducible generation run and lineage required to explain where each generated release object came from.

Why Backblaze B2 is essential

Backblaze B2 is the release source of truth, not a passive upload bucket.

Branchline uses B2 for:

content-addressed generated media;
canonical release manifests and provenance;
verified reuse across releases;
short-lived signed playback URLs;
remote SHA-256 object verification;
missing-object detection;
durable release and audit records.

The publication decision depends on what Branchline can verify in B2. A local preview cannot override a missing or mismatched release object.

Without B2, Branchline could not prove that the media being published matches the verified release.

Engineering challenges

Selective invalidation across shared routes

A shared scene can affect multiple endings, while route-specific media should remain untouched. The dependency graph had to calculate the exact rebuild set instead of treating the story as one flat bundle.

Verifying the real release, not a local result

A successful generation call does not prove that the stored release object is correct. Branchline retrieves the canonical B2 objects and independently verifies their bytes before publication.

Safe partial failure

A missing Ending B object should not erase a healthy Ending A. Branchline isolates the failed dependency, keeps the independent route verified, and blocks the full release without pretending the candidate is safe.

Auditable generation lineage

Generation evidence needed to survive across releases. Branchline records the Genblaze run, parent release, stored lineage, B2 release record, and remote verification result as one inspectable proof chain.

Accomplishments

Built a complete change-to-publication workflow rather than a generation-only demo
Made Genblaze and Backblaze B2 load-bearing parts of the main product action
Implemented correct rebuilding, correct reuse, and correct refusal as separate working scenarios
Verified B2 objects remotely instead of trusting local output
Preserved unaffected routes during a release failure
Added public, no-login deployment and signed media playback
Passed 234 automated tests across the release engine, integrations, evidence, and interface
Created all demo story, artwork, audio, and interface assets specifically for this project

What we learned

The safest action is not always generation.

A reliable generated-media system must know when to rebuild, when to preserve, and when to refuse publication. Provenance becomes valuable only when it is tied to a real release decision. Storage becomes valuable when it can prove the bytes that users will actually receive.

The strongest result in Branchline is not a newly generated file. It is a release that can explain exactly why every route is safe—or why one was blocked.

What’s next

support larger story graphs, additional locales, and more media types;
connect the release guard to CI and pull-request workflows;
add team approvals, notifications, and searchable release history;
expand Genblaze providers for image, dubbing, and video pipelines;
apply the same dependency-aware release model to localized campaigns, interactive education, and other multi-version media systems.