provenance for generated advertising
Every asset leaves with a record of what made it, who signed it off, and whether a single byte has moved since. Open the file properties and the signature is right there. Your prompt is not.
No account. Nothing pre-recorded. The demo generates real images and lets you break the proof yourself.
Loading a signed specimen.
every one of these is a real signed file
Stills and clips, generated for this page. Click any tile: it downloads the actual asset and runs it through the checker in front of you, then offers you the signed file to keep.
What you see here is a small display copy, so a right click saves that. The stills are delivered as JPEG with the credit inside them, and the save link under each check gives you the real one.
who needs this
The client asks which parts were generated and who approved them. You send a spreadsheet, and they take your word for it. Here the answer travels inside the file: the model, the sign-off, the approver's own note, and a hash that fails the moment anyone retouches the delivery.
Today: the paper trail lives in your project tool and stops at your firewall.
From 2 August 2026, Article 50 asks providers to mark generated output in a machine readable way. A line in the caption is not a mark and does not survive a re-upload. This writes the IPTC digital source type into the asset itself, which is the vocabulary the checking tools already read.
Today: disclosure sits in the post copy, and the file arrives bare.
Acceptance rate, render latency and cost per usable asset are unknowable if you bin the failures. Every attempt is kept, rejects included, each with the note on why it lost. The rejects are the part that tells you whether the pipeline is working.
Those notes go inside the record before it is hashed, next to the name of the person who approved the winner. So the reason a shot was refused is as hard to rewrite as the picture that shipped, and it is on the marking record and in the checker output, not only in a database somebody owns.
Today: the misses are deleted, so the numbers are guesses.
what a client actually sees
A proof that only exists inside the system that made it is not much of a proof. So the signature is written into the file as ordinary image metadata, the kind Windows, macOS and every photo tool have read for twenty years.
It goes in before the file is hashed. That matters: the visible signature is part of the bytes the record covers, so editing the credit out breaks the check just like editing the picture does. It is not a caption sitting next to the asset, it is inside it.
Measured, not assumed. The same signature written into a PNG three separate ways shows nothing at all in the Windows properties dialog, because Windows has no property handler for PNG metadata. That is why the delivered asset is a JPEG.
the same file, one byte apart
The bytes hash to exactly what was recorded when the asset was generated and approved. Model, approver and date all resolve.
sha256 9f2c11ab … matches the hash struck into the file
Brighten it, crop it, flip one byte of it, or edit the credit out of the metadata. The record stays perfectly valid and stops describing this file.
sha256 4c81d0e7 … matches nothing the record declares
Both verdicts are produced by the same public endpoint, with no login and no relationship to whoever made the file. You can see it happen on the demo, on an image you generated yourself, in about two minutes.
two minutes, stills or a clip, one broken proof