SereneSet Spark

Generate, refine, and prove every campaign asset.

Comment

SereneSet Spark

Generate, refine, and prove every campaign asset.

Inspiration

Generative AI has made the first draft dramatically faster, but it has also created a new operational problem.

Marketing teams can generate an image or video in seconds, yet the surrounding workflow is still fragmented. Campaign briefs live in documents, brand assets live in shared drives, prompts disappear into chat histories, generated files are downloaded with unclear names, feedback happens elsewhere, and nobody can confidently explain how the final version was produced.

The tools were solving the blank canvas, but not the campaign.

I built SereneSet Spark to explore a more useful question:

What would generative media look like if generation, brand context, refinement, review, provenance, and durable storage were designed as one workflow?

The result is a campaign asset workspace where every generated output remains connected to its purpose, source material, previous versions, model configuration, and final export.

What SereneSet Spark Does

SereneSet Spark helps marketing teams turn a campaign brief and reusable brand assets into structured image and video campaign packs.

Each campaign has its own workspace and URL. Inside it, a team can:

  1. Define the product, audience, tone, channels, and campaign brief.
  2. Upload reusable logos, product images, guidelines, and creative references.
  3. Attach selected brand assets to the campaign with explicit roles.
  4. Generate images from text, uploaded references, and campaign context.
  5. Generate videos from text or an approved source image.
  6. Refine an image using its latest generated version as the next input.
  7. Submit explicitly supported video-to-video refinements.
  8. Review assets and mark them as draft, in review, approved, or rejected.
  9. Compare the latest output with previous versions.
  10. Inspect prompts, providers, models, source inputs, manifests, hashes, and storage lineage.
  11. Export the campaign’s media, brand inputs, provenance records, and metadata sidecars as a portable pack.

The core workflow is:

[ \text{Brief} + \text{Brand Context} + \text{Source Media} \rightarrow \text{Generated Version} + \text{Provenance} \rightarrow \text{Reviewable Campaign Pack} ]

How I Built It

SereneSet Spark uses a production-oriented architecture rather than treating generation as a single API call.

Application layer

The frontend is a responsive React and TypeScript workspace. Campaigns, generation controls, review queues, version previews, and provenance inspectors are organized into independently scrollable work panes.

The backend is built with FastAPI and PostgreSQL. Its relational model separates:

  • Campaigns
  • Campaign assets
  • Asset versions
  • Immutable generation inputs
  • Reusable brand assets
  • Campaign-to-brand-asset attachments
  • Review state
  • Long-running generation jobs
  • Worker heartbeats

Alembic manages database migrations, while Pydantic schemas protect the API boundaries.

Generative media layer

Genblaze orchestrates the media pipeline and connects SereneSet Spark to GMI Cloud models.

The current workflows include:

  • Image generation and refinement with seedream-5.0-lite
  • Text-to-video and image-to-video generation
  • Capability-gated video-to-video refinement with wan2.7-videoedit

Image generation can accept multiple reference images with explicit roles. Refinement automatically snapshots the latest successful version as a new source input rather than mutating the earlier version.

Video generation is handled asynchronously. The API validates and queues the request, while a PostgreSQL-backed worker claims the job, refreshes its heartbeat, signs the required B2 input only for the active attempt, runs the Genblaze pipeline, streams the resulting artifact into durable storage, and finalizes the version metadata.

Storage layer

Backblaze B2 is not simply a backup destination at the end of the workflow. It is part of the application’s data model.

B2 stores:

  • Uploaded reference images and videos
  • Reusable brand assets
  • Immutable generation input snapshots
  • Generated image artifacts
  • Large generated video artifacts
  • Genblaze manifests
  • Version metadata sidecars
  • Provenance records
  • Export-pack inputs

Objects use stable campaign, asset, and version-scoped keys. PostgreSQL stores relationships, review state, jobs, and durable B2 keys, while the media itself remains in object storage.

Private artifacts are served through short-lived signed download URLs. Temporary URLs are never treated as provenance identifiers; the stored B2 key remains the durable reference.

Every completed generation records the provider, model, prompt, source version, input roles, SHA-256 values, manifest state, and artifact flow. The UI can therefore show the complete path from provider output to the campaign’s B2 artifact and metadata sidecar.

The Most Difficult Challenges

Ensuring the model actually received its inputs

One of the hardest bugs looked successful from the application’s perspective: reference files were uploaded and recorded, but the generated result suggested that the provider had never received them.

I traced the media across every boundary: multipart request, validation, B2 upload, signed input URL, Genblaze external input mapping, and provider payload.

The fix was not only to route the input correctly. I also extended provenance to record which parameter carried the media and whether context assets were routed to the provider or retained only as provenance. The application can now distinguish between “input stored” and “input actually sent.”

Supporting video without blocking the API

Video jobs can take several minutes and produce large artifacts. Running that work inside a normal request would make the API fragile and difficult to deploy.

I introduced a durable PostgreSQL-backed worker with job claiming, progress updates, retries, cancellation, duplicate-paid-job prevention, and heartbeat-based readiness checks. Generated videos are streamed into B2 instead of being loaded fully into application memory.

The frontend polls shared job state and automatically refreshes the completed asset, so the generated video appears without requiring a page reload.

Handling changing provider capabilities honestly

Video models do not share one universal contract. Duration, resolution, source-image, and source-video parameters vary between models, and an apparently available model may not support the intended operation.

I added an explicit capability registry and a read-only model-contract checker. Unsupported combinations fail before a paid job is queued. Video-to-video is operationally gated, and the system never silently converts a video into one frame or submits a source that the model would ignore.

This made the workflow less magical, but significantly more trustworthy.

Preserving provenance across generation, storage, and export

A provider URL is temporary, while an audit trail must remain useful after that URL expires.

SereneSet Spark records immutable B2 keys, hashes, source-version identifiers, provider job information, generation parameters, and manifest verification results. Export packs include the real generated artifacts together with their metadata sidecars and input lineage.

The challenge was making provenance useful to a marketer without hiding the technical evidence. The preview inspector therefore provides a concise overview alongside a deeper storage and generation lineage view.

What I Learned

The most important lesson was that a production generative-media application is primarily a data lifecycle, not a prompt box.

The difficult work happens between the model calls:

  • Validating media before paying for generation
  • Preserving immutable inputs
  • Routing the correct files into provider-specific parameters
  • Tracking long-running operations reliably
  • Moving large outputs without exhausting memory
  • Separating temporary access URLs from durable identifiers
  • Making provenance understandable
  • Packaging the result for downstream use

I also learned how naturally PostgreSQL and B2 complement each other. PostgreSQL provides transactional workflow state and relationships, while B2 provides durable, scalable storage for the media and evidence attached to that workflow.

Genblaze made it possible to treat generation as an orchestrated pipeline rather than hard-coding the entire application around one model call.

Production Readiness

SereneSet Spark is deployed as separate production processes:

  • A public React frontend
  • A FastAPI application service
  • A PostgreSQL-backed video worker
  • A managed PostgreSQL database
  • Backblaze B2 as durable media storage
  • An automated Alembic release migration

The readiness endpoint verifies PostgreSQL, the configured B2 bucket, and the worker heartbeat. CI runs backend tests, TypeScript checks, ESLint, and the frontend production build.

The deployment also contains an idempotent showcase campaign with brand assets, image versions, a playable video, provenance, and an exportable pack. Judges can inspect the complete workflow without first submitting a paid generation request, while the same application supports live generation.

What I Am Most Proud Of

SereneSet Spark completes the entire loop.

A user can open a campaign, attach brand context, generate an image, refine it from the latest version, queue a video, watch the job complete, inspect exactly what the model received, review the result, and export a durable campaign pack.

The generated file is not the end of the workflow. It becomes a versioned, reviewable, reusable, and explainable campaign asset.

What Comes Next

The next production milestones are team authentication, role-based approvals, comments, semantic asset search, CDN delivery, configurable retention policies, and multi-provider evaluation or fallback pipelines.

The longer-term vision is for SereneSet Spark to become a trusted creative operations layer between generative models and the teams responsible for publishing their output.

Built With

Share this project:

Updates

Submission history