Dara

The control plane for AI media: govern spend before generation, preserve every attempt in B2, and verify every delivered asset.

Comment

Inspiration

Generative media has moved from experimentation into production faster than the controls around it.

A creative team can generate thousands of images, videos, and voice assets across several providers—but later struggle to answer basic questions about any one file:

Which model and parameters created it?

How much did it really cost, including failed attempts?

Was the provider call approved before money was spent?

Was the final asset reviewed or revised?

Can somebody verify that the delivered file is the one recorded by the production system?

The generation itself is no longer the hardest part. Governing the work, accounting for it, and preserving trustworthy evidence are.

That is why we built Dara.

What it does

Dara is a control plane for governed AI media production. It combines four capabilities that normally live in disconnected systems:

Govern

Before contacting a provider, Dara calculates a worst-case reservation using the active model registry and evaluates it against a typed project policy.

Policies can restrict providers, models, modalities, dimensions, duration, retry counts, QA requirements, per-run cost, and daily spend. A blocked run records the complete decision but makes zero provider calls and spends nothing.

Policy is enforced again before every provider step, after visual QA, and before publication.

Generate

Dara orchestrates still-image, motion, voice, and regeneration pipelines through Genblaze.

A production workflow can expand a prompt, generate media, perform structured visual QA, revise a failed attempt, fall back across models or providers, publish the approved result, and stream every step to the browser.

Failed attempts and discarded outputs remain part of the record instead of disappearing when a later attempt succeeds.

Verify

Every approved asset carries Genblaze provenance and is connected to a trusted record in Backblaze B2.

Dara’s public verifier extracts and validates an embedded manifest when present, computes the uploaded file’s SHA-256 fingerprint, resolves the trusted B2 record, and compares the uploaded bytes with the exact published-file hash.

A changed file produces a visible trusted mismatch. Unknown files are reported as unknown rather than being treated as valid or invalid without evidence.

Account

Dara maintains an immutable accounting ledger containing provider, model, project, attempt, outcome, latency, known or estimated cost, policy decisions, and approval status.

The Ledger screen shows total spend, spend prevented before provider calls, cost per approved asset, reliability, and breakdowns by project, model, and month.

Failed work is included because a failed provider request may still cost money.

How we built it

Dara has two application services and one durable storage layer:

A Next.js and TypeScript web application provides Studio, Runs, Assets, Policies, Ledger, sharing, and public verification.

A FastAPI control plane runs the policy engine and Genblaze pipelines.

A single Backblaze B2 bucket stores all durable application state.

OpenAI is the primary generation provider. Replicate provides a genuinely provider-diverse image fallback through its official FLUX route.

Studio streams pipeline events using Server-Sent Events. Provider credentials and the internal API token remain on the server and are never exposed to the browser.

Live generation requires two explicit confirmations, is controlled by per-run and daily spend caps, and can be disabled independently with a server-side kill switch.

How Backblaze B2 is used

Backblaze B2 is Dara’s entire persistence layer—not merely a destination for generated files. There is no application database.

The production bucket stores:

dara/live/runs/{tenant}/{date}/{run_id}/ dara/assets/{aa}/{bb}/{source_sha}.ext dara/published/{aa}/{bb}/{published_sha}.ext dara/share-assets/{token}/{asset_id}.ext dara/manifests/{run_id}.json dara/index/sha/{sha}.json dara/ledger/{table}/year=YYYY/month=MM/*.parquet dara/state/{jobs,live-runs,assets,policies,projects,shares}/

Dara deliberately preserves two immutable versions of an asset:

The original provider output, addressed by the source SHA-256 recorded in the Genblaze manifest.

The exact published derivative delivered to the client, addressed by its own whole-file SHA-256.

This distinction matters because embedding provenance changes a file’s bytes. Dara never overwrites the source object or pretends that the pre-embed source hash should match the finished derivative.

Small B2 index objects allow the verifier to resolve either trusted hash without guessing filenames or object extensions.

For analytics, Genblaze’s ParquetSink writes completed telemetry into a local per-job staging directory. Dara uploads each completed table as a new immutable, year-and-month-partitioned Parquet object in B2.

DuckDB then uses httpfs and B2’s S3-compatible endpoint to query those remote Parquet partitions directly. The ledger is not copied into another analytics database.

Jobs are also written to B2 on every state transition. If the process restarts, Dara reconciles orphaned work, releases safe reservations, and reconstructs committed daily spend from durable records.

How Genblaze is used

Genblaze is Dara’s execution and provenance spine, not a thin wrapper around one model call.

Dara uses:

Multi-step Pipeline graphs for still, motion, voice, and regeneration

input_from fan-in for generated visuals, narration, and FFmpeg composition

fallback_models for same-provider and cross-provider recovery

AgentLoop for structured visual QA, prompt revision, and capped retries

parent_run_id for retry and regeneration lineage

ObjectStorageSink for B2-bound media and manifests

ParquetSink for run, step, asset, and cost telemetry

Manifest embedding, extraction, and canonical verification

EmbedPolicy pointer mode for disclosure-safe shared assets

A customised ModelRegistry for pre-flight pricing

astream() for Studio’s live event stream

abatch_run() for bounded concurrent voice generation

LoggingTracer for structured execution evidence

FFmpegCompositor for deterministic media fan-in

Dara adds a trusted published_sha256 record in B2 so it can verify the exact delivered derivative while preserving Genblaze’s correct binding to the original source bytes.

Challenges we faced

Verifying a file after embedding provenance

Embedding a manifest changes the media file, which means the provider output and delivered derivative cannot honestly share one hash.

We solved this by preserving both immutable byte roles in B2 and indexing both SHA-256 values.

Preserving failed fallback attempts

Genblaze executes fallback models correctly, but a successful fallback does not retain every failed primary attempt in the final manifest.

That is insufficient for cost accounting because a failed call may still be billable. Dara maintains a separate append-only attempt ledger and filed a reproducible upstream report.

Separating estimated and settled cost

The GPT Image connector currently does not retain all provider-reported usage information. Dara therefore distinguishes known, estimated, and unknown cost instead of presenting every figure as settled fact.

Running application state on object storage

B2 does not provide database transactions or atomic compare-and-swap. Dara uses one writer per job, per-tenant admission locks, conservative reservations, and startup reconciliation.

The current deployment is deliberately single-instance. A horizontally scaled version would require durable transactional coordination.

Keeping the public product honest

Early versions used deterministic fixtures to make development repeatable. We kept those fixtures exclusively in automated tests and removed every replay or fixture fallback from the public product.

Studio, Runs, Assets, Policies, and Ledger now read live API and B2 records. If production data is unavailable, the interface fails closed and says so.

What we learned

We learned that provenance and authenticity are related but different.

A self-consistent manifest proves that its own declared structure is intact. Strong verification requires comparing the submitted bytes against a separately trusted record. In Dara, that trust boundary is the production B2 bucket.

We also learned that governance cannot be added only after generation. The most valuable policy decision happens before the first provider call, while later checks are still necessary before retries and publication.

Finally, we learned that object storage can serve as both the operational system of record and the analytics layer. Immutable Parquet in B2, queried directly with DuckDB, makes the storage and accounting architecture one coherent system.

Accomplishments

Dara’s production evidence set contains 20 real client-project records:

12 approved assets

Three zero-cost expensive-video policy blocks

Three paid visual-QA rejections

Two OpenAI-to-Replicate recoveries

Production image, motion, and voice workflows

Eight trusted-manifest GPT Image samples

Eleven production speech samples

Eight visual-QA evaluations

The active records account for $0.723650 in provider spend and $4.800000 prevented before provider execution.

We also submitted three reproduced Genblaze SDK reports during development:

Pointer-mode output paths can reference nonexistent files

Successful fallback can erase the failed primary attempt

GPT Image response usage is not retained by DalleProvider

What’s next

The next version of Dara would add:

C2PA or external signing for verification beyond the organisation’s B2 trust boundary

Webhook and CI/CD integrations that can block publishing automatically

Durable multi-instance coordination and tenant identity

Broader cross-provider fallback for motion and speech

Additional enterprise policy and reporting integrations

Dara’s goal is simple: make AI media generation governable before spend, accountable after execution, and verifiable after delivery.

Built With

Share this project:

Updates