ReleaseSeal

The last check before publish. ReleaseSeal catches hidden export failures, verifies revisions, safely fixes what it can, and proves the final file is the one you meant to ship.

Comment 3

The last mile of creation is still built on trust

A finished video can still be wrong.

It can contain six seconds of missing audio. A black gap left between cuts. Captions drifting out of sync. The wrong promo code. A thumbnail that looks fine at full size but falls apart where viewers actually see it. A client revision that never made it into V2.

Or something more dangerous: an editor fixes exactly what you asked for and accidentally changes something you never asked them to touch.

By that point, the creative work feels finished. Everyone wants to publish.

That is exactly when verification matters most.

Creative software has become extraordinarily good at helping us make and change things. AI is accelerating that even further. But the last step is still surprisingly dependent on trust:

someone has to decide whether the finished artifact is actually the one we meant to ship.

I came into this hackathon from video production and started, only a few hours after the event began, with a much smaller idea: a pre-upload QA checker for finished videos. The repository and product were built during the hackathon.

Then one question kept breaking the scope open:

How do you know the checker itself is right?

A detector can tell you there is a black segment. Fine.

But if the software removes it, who checks the new export?

If a client asks for five changes and V2 comes back shorter than V1, how do you know which later timestamps still correspond?

If an AI says a requirement was satisfied, what evidence is it actually using?

If a report describes one exact file, what happens when somebody accidentally ships another?

Those questions turned a simple preflight checker into ReleaseSeal.

What ReleaseSeal became

ReleaseSeal is a creative release assurance system for the point between "the edit is finished" and "ship it."

It has two core workflows: Final Export and Revision.

Final Export

Upload the finished video and its release package.

ReleaseSeal inspects the actual artifact for technical and delivery failures across picture, sound, captions, publishing metadata, release requirements, and thumbnail delivery conditions.

The goal is not to produce a vague score. Findings point back to evidence in the source artifact so a reviewer can see what triggered them and where.

For the small class of problems that can be corrected safely and deterministically, ReleaseSeal can go further:

SCAN
  ↓
EVIDENCE
  ↓
APPROVE
  ↓
FIX
  ↓
RE-SCAN
  ↓
VERIFY

The original file is never overwritten.

ReleaseSeal creates a new export, scans that new artifact again, verifies that the intended problem was resolved, and checks unrelated regions for unexpected changes.

That became one of the most important ideas in the project:

a successful fix is not enough. The fix itself needs verification.

Final Export also treats the video as part of a release package rather than an isolated file. The same workflow can inspect captions, publishing details, thumbnail delivery behavior, and explicit release requirements before the artifact reaches an audience.

Revision

The second workflow answers a different question:

What actually changed between V1 and V2?

That turns out to be harder than comparing matching timestamps.

If five seconds are removed near the beginning of a video, nearly every timestamp afterward moves. A naive comparison can make the rest of the revised cut appear different even when it is unchanged.

ReleaseSeal aligns the cuts first. Only then does it ask what changed.

It builds a deterministic mapping between the previous and revised timelines and identifies removed, inserted, changed, and unchanged regions.

Revision notes can then be correlated with the physical evidence.

That allows ReleaseSeal to separate:

  • requested changes that produced a detectable edit
  • requested areas that appear unchanged
  • requests that still need a usable timecode
  • Additional changes that were never mentioned in the supplied notes

That last category matters.

A revision workflow should not only answer, "Did the editor touch the places I requested?"

It should also ask:

What else changed?

Optional AI can help interpret whether a detected physical edit appears consistent with a human revision note, but ReleaseSeal preserves an important distinction:

Change detected does not mean instruction satisfied.

The physical comparison remains the source of truth for where the media actually changed.

Building trust into the architecture

One of the biggest decisions I made was that ReleaseSeal would not treat every question as an AI problem.

There are three different layers.

Deterministic evidence owns things software can actually measure: media structure, black frames, silence, caption timing, publishing-package facts, physical revision changes, artifact hashes, repair execution, and regression comparison.

Optional AI handles bounded interpretation: reviewing selected content questions, understanding a supplied release brief, or interpreting a small piece of revision evidence.

Humans retain ambiguous creative judgment and final approval.

That separation runs through the system.

The backend is built with Python, FastAPI, Pydantic, FFmpeg, and FFprobe. React and TypeScript power the interface. Gemini is used where semantic interpretation is useful, while local speech recognition can support caption generation and evidence recovery.

But provider failures cannot quietly become content failures.

Missing evidence does not become a pass. Machine-generated captions do not magically become trusted source captions. A physical edit does not become proof of creative intent. An AI answer does not overwrite a deterministic measurement.

Sometimes the correct answer is simply:

I cannot prove this. Review it.

Building a system that knows when to abstain became much more interesting to me than building one that always returns an answer.

The hardest challenge was avoiding false confidence

Synthetic test videos were useful, but authentic media exposed assumptions they never could.

One of the best examples happened while building the repair verifier.

I tested ReleaseSeal against real public-domain USGS Yellowstone footage. The repair itself worked, but the regression verifier reported several unrelated visual changes that did not actually exist.

The easy hackathon fix would have been to loosen the threshold until the demo turned green.

I refused to do that.

The actual problem was subtler.

After a fractional-time removal, some comparison samples were landing at slightly different positions between the original and repaired timelines. ReleaseSeal was occasionally comparing different frames and interpreting the difference as damage.

I corrected the sampling and alignment model instead.

Then I reran the tests with a deliberately mutated export and made sure ReleaseSeal could still detect a real unrelated change.

That experience shaped the rest of the project:

When the evidence disagrees with what I want the demo to say, fix the model, not the evidence.

That is also why ReleaseSeal distinguishes confidence from proof and why its stronger claims stay tied to inspectable evidence.

Making the proof itself trustworthy

I wanted judges to be able to inspect the strongest parts of ReleaseSeal without trusting a polished screenshot or waiting several minutes for media processing.

So I built Judge Proof.

It uses authentic public-domain USGS media and precomputed results generated by the production ReleaseSeal engine. It is explicitly labeled as precomputed because I did not want a fast judging path to pretend it was performing a live scan.

The proof bundle includes real detected failures, bounded repair, a repaired-media scan, regression verification, revision comparison, release-contract evaluation, and exact-artifact receipts.

The normal application is different.

It includes a Load demo button simply to save time. That button fills the real workflow with a known release package so someone can reach the interesting parts quickly. It does not switch the application into a simulated mode; arbitrary uploaded videos run through the same live workflow.

So the distinction is intentional:

Load demo = a shortcut into the real application.

Judge Proof = an explicitly precomputed, reproducible inspection path for judging.

The hosted hackathon deployment runs on fairly modest VPS infrastructure, so large uploads and media-heavy analysis can take time. With more compute, the same system can support faster processing and more work in parallel without changing the core trust model.

I chose to spend the hackathon making the verification system real rather than hiding those limits behind canned results.

What I learned

I started this project thinking the interesting problem was detecting mistakes in finished videos.

I ended it thinking the deeper problem is trust between transformations.

Every time a piece of media changes, another question appears.

Was the right thing changed?

Did something else change too?

Does this requirement have evidence?

Did the repair create another defect?

Does this report still belong to the file someone is about to publish?

Those questions become more important as creative workflows become more automated.

I also learned that reliability is not only a backend property.

While testing a much larger video against the hosted application, I noticed the interface could appear stuck near the beginning while the browser was still uploading the file. Nothing had actually failed, but the user had no way to know that.

So I added real browser upload progress and kept processing percentages tied only to genuine backend checkpoints.

That was a much smaller engineering problem than revision alignment or regression verification, but it reinforced the same principle:

trust depends on what the system communicates as well as what it computes.

Why ReleaseSeal matters now

The creator-tool ecosystem is racing toward generation.

Better scripts. Better thumbnails. Faster edits. More automated transformations. Increasingly autonomous creative pipelines.

ReleaseSeal is deliberately pointed in the opposite direction.

It does not try to become another editor.

It asks what happens after the editor says it is done.

The larger opportunity is a release-assurance layer behind human editors, AI editors, agencies, production teams, and automated content systems.

A system that checks the exact artifact they produced.

A system that can distinguish requested work from unrelated change.

A system that can repair what is safe to repair and then verify its own repair.

A system that knows the difference between evidence and interpretation.

And a system whose conclusions remain tied to the exact file that is ultimately shipped.

As creating and modifying content becomes easier, I think proving what actually made it into the final artifact becomes more valuable, not less.

Because at the end of every creative workflow, one question still matters:

Is this actually the file we meant to ship?

That is the question ReleaseSeal is built to answer.

ReleaseSeal

Scan. Fix. Verify.

Built With

Share this project:

Updates

Submission history