Assets

The asset manager is a file browser over your Organization's own Cloud Storage bucket. If you have used Google Drive, it will feel familiar: folders on one side, files on the other, with upload, rename, move, download, and delete.

What works today

The asset manager works end to end. Files live in your own Cloud Storage bucket, so you own them. Everything here is wired: folders, uploads, search, downloads, and the read-only protection on generated and synced assets.

Folders and files

• Organise assets into a folder tree. Folders can nest.
• Upload files up to 200 MB each.
• Rename and move assets and folders. Moves are bookkeeping in Klyo's database; they never re-shuffle the underlying objects in storage.
• Download any asset.
• Search files by name across every folder. Media pickers filter to the right kind on their own, for example images only.
• Delete assets, and delete empty folders.

The library holds media only: images, video, and audio. A document, a spreadsheet, or an archive is refused as you pick it rather than after the upload, because nothing downstream could put it in a creative. That media-only rule and the 200 MB limit hold wherever a file comes in, whether you upload it here, upload it on the spot from a picker, or import it from Google Drive.

Wherever the app asks you to pick an asset (binding a campaign field, linking a catalogue item), the same picker lets you upload a new file on the spot, including by dragging it straight in, rather than sending you here first.

Generated assets are read-only

When Klyo generates an asset (from generation or a render), it lands in an automatically created Generated folder and is marked system-managed. You can see it and download it, but you cannot rename, move, or delete it through the browser. This is freeze-at-render at the storage layer: a produced asset stays exactly as it was made.

Content Credentials on generated files

When Vertex generates a video clip it attaches a Content Credential: a C2PA manifest, cryptographically signed by Google at the moment of generation, naming what produced the bytes and stating that they are AI-generated. Klyo reads that manifest as the file lands and keeps the summary on the asset. Open a generated file's preview and, where it carried one, a Content Credentials strip under the media reads "Signed by Google LLC" with the date on the signature.

Klyo signs nothing itself. It holds no certificate and adds no credential of its own, so the strip is always a report of what Google signed, never a claim of Klyo's. A file that carried no manifest shows no strip, because absent evidence is recorded as absent rather than filled in.

Three limits are worth knowing, all measured rather than assumed:

• The finished video carries none. Creatomate re-encodes the composite when it renders, and the credential does not survive that. So a Final Video has no Content Credential, and the generated clip inside it is where the evidence lives. That asset row is the only lasting record of it.
• A generated image came back unsigned. Google's documentation says its image model signs its output. Checked against a freshly generated image, that did not hold: the file carried no manifest at all. Klyo stores nothing rather than inventing a credential, so treat image provenance as unconfirmed.
• Voiceover carries none. The text-to-speech model is not on Google's list of signing models. Klyo checks anyway, so the strip appears the day Google starts signing it.

Content Credentials are separate from the AI content disclosure Klyo sends to a channel on activation. The credential is evidence on a generated input file; the disclosure is the declaration that travels with the released creative.

SynthID

Google also embeds SynthID, an invisible watermark, in the video, images, and voiceover its models generate. It is on by default, there is no way to turn it off, and it is a different mechanism from a Content Credential: SynthID is carried in the pixels and audio samples themselves, while a Content Credential is a signed record attached to the file.

Three things follow, and they matter if anyone asks you to prove a creative is AI-generated.

• Klyo cannot check it. Google offers no way for anyone outside Google to verify SynthID in video or audio, so Klyo can state that the models embed it but can never confirm it on a particular file.
• Whether it survives the render is unknown. The render scales and crops the clip, lays text and logos over it, and often replaces the audio. Google says the watermark tolerates cropping and compression, and also that it is not proof against heavy manipulation. With no way to check, treat it as unconfirmed on a finished video.
• The ad copy is not watermarked. SynthID covers the generated video, images, and voiceover, not the written headlines and descriptions.

So SynthID is a property of what Google's models produce, not the thing that makes a released creative compliant. The AI content disclosure is what actually tells a channel and a viewer that a creative is AI-generated.

Synced assets are read-only too

When a feed imports product images from web links, Klyo downloads the bytes into a second system folder, Synced, also marked system-managed. Synced assets are mirrored to the live feed: an image stays only as long as the feed still references it. Like generated assets, you can view and download them but not rename, move, or delete them.

Assets and catalogues

Assets can be linked to catalogues, for example a product catalogue item carrying its pack shot. If you delete an asset that a catalogue item points at, Klyo does not hide the gap: it flips the link to unresolved so the missing file is visible rather than silently dropped.

What you can do today

• Browse and search assets.
• Create folders and organise files into them.
• Upload, rename, move, download, and delete.
• Keep generated and synced assets safe as read-only files.
• See the Content Credential a generated file arrived with, where Google's model signed one.