Quick Answer: How Should You Deliver AI UGC to a Client?

Deliver the exact approved AI UGC exports—not a loose folder of everything produced—with stable asset IDs, descriptive file names, a manifest that explains what each file is for, the approved copy and disclosure, a rights-and-approval summary, and a tested download link. State what the handoff includes and excludes, then record when the client received it.

The agreement still controls the deliverables. Prompts, presets, references, editable source files, rejected candidates, account access, and future variations are not automatically part of a final-file delivery. Include them only when the agreed scope names them.

That distinction matters because approval and delivery answer different questions. Approval says, “This exact version may proceed.” Delivery says, “These are the files the client received, this is what each one means, and these are the conditions attached to their use.” A clean handoff connects those two records so nobody has to guess which image called final-final-2.png is safe to publish.

Approval Is a Decision; Delivery Is a Transfer

An AI UGC approval workflow should identify the asset, version, reviewer, decision, and permitted channel. But an approval buried in a comment thread does not tell a media buyer which crop to upload. It does not give a social manager the disclosure copy. It does not prove that the client can open the folder or that the delivered file matches the approved one.

A useful delivery makes the approved decision portable. Someone who did not attend production should be able to open the package and answer five practical questions:

Which files are the final deliverables?
Where is each asset intended to run?
Which version was approved, and when?
What may the client edit or use?
Who should handle an access problem, correction, new size, or rights change?

If the package cannot answer those questions, the creator has handed over pixels but not an operating record. That creates avoidable review loops just when the project should be closing.

What Belongs in the Handoff

Most client deliveries need six connected parts. A small project can keep them in one folder and one manifest; a large campaign may store them in linked systems. The structure matters more than the software.

Part	What it establishes
Final exports	The exact files included in scope
Asset identity	A stable ID, descriptive name, version, format, and dimensions
Use context	Intended channel, placement, ratio, copy, and disclosure
Decision record	The approved version, reviewer, date, and any conditions
Rights summary	Permitted use, term, territory, edits, exclusions, and renewal owner
Transfer record	Delivery link, access role, recipient, sent time, and receipt status

This is not an invitation to produce six elaborate documents. A two-image job might need two export files, one short manifest, one copy document, and the signed scope or rights note. The goal is to preserve the decisions that make the files usable.

A copy-ready folder can begin like this:

CLIENT_CAMPAIGN_DELIVERY_2026-08-18/
  README.md
  delivery_manifest.csv
  01_final_exports/
  02_copy_and_disclosure/
  03_rights_and_approval/
  04_source_materials_if_in_scope/

Keep the fourth folder out when no source materials are owed. An empty folder labelled “source materials” can imply a missing deliverable. Likewise, do not mix rejected candidates or superseded finals into 01_final_exports. If the client needs a review archive, separate it from the release package and label its status clearly.

Give Every Asset an Identity That Survives the Download

Folder context disappears quickly. Files are downloaded, attached to tickets, copied into ad libraries, and renamed by operating systems. The file name therefore needs to carry enough identity to remain useful on its own.

A practical naming grammar is:

[client]_[campaign]_[asset-id]_[concept]_[placement]_[ratio]_[version].[ext]

For example:

acme_launch_A03_morning-routine_paid-social_4x5_v03.png

Use the actual fields the client needs; do not make every name enormous. A job with only one campaign may omit the campaign token. The stable pieces are the asset ID and version. They let the manifest, approval record, invoice, and later change request point to the same object.

Avoid using final as the only status signal. There may eventually be an approved crop, a localized version, or a correction. A03_v03 is traceable; final_NEW_USE_THIS.png is a mood.

The file-naming guidance from the US National Archives recommends meaningful, consistent names, stable component order, and platform-independent characters. Those archival principles work well for client delivery too. Use letters, numbers, hyphens, or underscores consistently; avoid spaces and characters that can break in another system.

Do not let the file name carry decisions it cannot safely contain. A name such as paid-ready is not a substitute for rights terms, claim review, or an approval record. Keep the name compact and put the richer context in the manifest.

The Manifest Is the Package's Map

The manifest is the package's operating map. It connects each physical file with the decision that authorized it. It can be a CSV, spreadsheet, or table in a readme, as long as the client can open it without your production tools.

Start with these fields:

asset_id,filename,approved_version,approval_date,placement,dimensions,copy_reference,disclosure_reference,rights_reference,allowed_edits,supersedes,notes
A03,acme_launch_A03_morning-routine_paid-social_4x5_v03.png,v03,2026-08-18,Paid social feed,2160x2700,copy-01,disclosure-01,rights-01,"crop; resize; subtitle",A03_v02,"Use approved product claim only"

Replace the example with the facts of the project. At minimum, every row should identify the delivered filename, stable asset ID, approved version, intended placement, and rights or approval reference. Add duration, territory, owner, language, product, creator, checksum, or renewal date when those fields matter to the job.

A checksum can help a technical team confirm that a downloaded file has not changed. It does not prove that the image is accurate, cleared, or approved. In the same way, an approval date proves a recorded decision occurred; it does not expand the usage license. Each field should do one job.

The manifest should also say what it does not include. That single boundary prevents a surprisingly common disagreement: the client sees a polished final package and assumes the production system behind it was transferred too.

Include when agreed	Do not assume is included
Exact final exports	Rejected candidates or alternate generations
Approved captions and disclosure	New copy for unplanned channels
Asset-level approval and rights summary	Unlimited or perpetual usage
Specifically listed source files	Every reference, prompt, preset, or editable file
Agreed language, ratio, and size variants	Future variations or free resizing
Named creator-system materials	The operator's software account or general methods

The AI UGC contract template explains how to define those units before production. The delivery package should faithfully report the signed scope, not quietly renegotiate it at the finish line.

Put Copy, Disclosure, and Rights Beside the Asset

An image can be visually approved and still be easy to misuse. The caption may contain a claim that belongs only on one channel. A disclosure may need to appear with the endorsement rather than in a separate profile page. Paid use may expire before organic use.

For each asset—or for a clearly identified group of assets—connect the relevant copy, disclosure, and rights note. The US Federal Trade Commission advises that an endorsement disclosure should be hard to miss and placed with the endorsement itself; its Disclosures 101 guide is a useful starting point for US campaigns. Applicable law and platform requirements still depend on the campaign, market, relationship, and content. An AI label also does not replace a material-connection disclosure when both are relevant.

The rights note should summarize, not invent, the deal. Include the allowed channels, territory, term, paid-media permission, editing permission, excluded uses, renewal date, and responsible owner. Link the exact approval record and signed scope. The AI UGC usage-rights guide provides a fuller rights register for jobs where inputs, likeness, trademarks, product evidence, and disclosure need asset-level tracking.

Some files may contain Content Credentials or other provenance metadata. The C2PA technical specification describes a way to bind signed provenance assertions and trust signals to an asset. Preserve those credentials when the agreed export supports them, but do not present them as proof that a claim is true, a license exists, or a client approved the file. Provenance can help describe history; the manifest and project records still explain permission and business status.

Access Is Part of Delivery, Not an Afterthought

The cleanest manifest is useless when the recipient cannot open the folder—or when everyone with the forwarded link can edit it.

Choose access deliberately. Google Drive, for example, distinguishes viewer, commenter, and editor roles, and files inside a shared folder inherit that folder's access. Its official sharing guidance also notes that eligible work or school accounts can set expirations. A viewer link is often enough for final delivery, but the client's real workflow and the agreement should decide the role.

Before sending, test the handoff as if you were the recipient:

Open the link in an account or private browser that does not own the folder.
Confirm that every promised file appears and every manifest filename matches exactly.
Download and open representative exports at full resolution.
Check that the client can access linked copy, rights, and approval records.
Confirm that unrelated client work, private references, or production materials are not exposed.
Record any agreed expiry and the person responsible for extending or closing access.

Do not set a surprise expiration merely to create urgency. If access will end, state the date in the agreement and delivery message, and give the client a reasonable way to retain what it purchased.

Send a Message That Closes the Loop

The delivery message should be short enough to read and precise enough to become part of the project record. It should not force the client to infer whether this is another review link or the contractual handoff.

Subject: [Project] — final AI UGC delivery [delivery ID]

Hi [name],

The approved files for [project] are ready:
[tested delivery link]

This handoff includes:
- [asset IDs and count]
- [formats, sizes, and language variants]
- [copy and disclosure record]
- [approval and rights summary]

It does not include:
- [prompts, presets, editable files, references, candidates, or other exclusions]

Access: [viewer/download role and expiry, if any]
Manifest version: [version]
Approval reference: [record and date]
Rights reference: [record and term]

Please confirm receipt by [date]. Access problems or defective files will be
corrected through [contact]. New formats, channels, copy, or creative changes
will be scoped through [change process].

Thanks,
[name]

Adapt the language to the agreement. “Confirm receipt” should mean that the link and listed files arrived, unless the contract makes it an acceptance event. Do not use a delivery email to shorten a negotiated review window or turn silence into acceptance when the agreement says otherwise.

Record Receipt Without Confusing It With Acceptance

Approval, delivery, receipt, and acceptance can occur on different dates. Keeping them separate makes later conversations much easier.

Approval: a reviewer authorizes an identified version for an identified use.
Delivery: the operator makes the agreed package available and records the transfer.
Receipt: the client confirms it can access the package described.
Acceptance: the contractual review condition is satisfied under the agreement.

Record the delivery ID, sent time, recipient, tested link, manifest version, asset IDs, access role, receipt, and any acceptance deadline. If a client says one file is corrupt, you can replace the defective transfer without reopening the creative approval. If the client asks for a new ratio, the stable asset ID shows which approved work the new version would derive from.

This is where a revision policy protects both sides. Route the request according to what changed:

Request after delivery	Usually belongs in
Link does not open	Delivery support
Delivered file is corrupt or differs from the approved version	Defect correction
In-scope spelling or export error	Correction under the agreement
New ratio, language, claim, channel, concept, or asset count	New scope or revision decision
Longer term, new territory, or paid-media permission	Rights change or renewal
Prompts, presets, references, or source files not in scope	Separate commercial decision

The agreement decides the final classification. The table gives the team a place to start without treating every post-delivery request as either free support or a dispute.

Where Synthetic AI Fits in the Handoff

Synthetic AI can support the production side of a traceable delivery. An operator can work with a persistent AI creator, approved reference images, recurring spaces, products, objects, and saved presets, then keep selected images in the saved-image gallery. When downloading an image, the export naming fields can record details such as the creative name, brand, content type, version, date, format, language, and author. Use those fields consistently with the asset IDs in the client manifest.

Synthetic AI does not assemble or share the final client package, approve an asset, clear rights, verify claims, record receipt, or decide what the contract includes. The operator remains responsible for selection, finishing, naming, review, disclosure, permissions, storage, transfer, and acceptance. Generated outputs should be treated as candidates until that human process says otherwise.

For an Earn-stage practice run, create an AI creator in Synthetic AI, produce two related still-image candidates, select one version of each, and rehearse the complete delivery: asset IDs, descriptive filenames, a two-row manifest, copy and disclosure, rights note, tested link, and receipt record. A small rehearsal exposes missing decisions before a paying client depends on them.

AI UGC Client Delivery FAQ

Should I give the client my prompts and presets?

Only when the agreement includes them. Final images, prompts, presets, reference files, account access, and a reusable creator system are different deliverables. Name exactly what transfers, what the client may do with it, and what remains part of the operator's general production method.

Which file format should I deliver?

Deliver the format, color profile, dimensions, compression, and transparency required by the intended placement and agreed technical specification. A social feed image, ecommerce composite, print file, and editable source do not have interchangeable requirements. Put the exact format and dimensions in the manifest rather than assuming “high resolution” resolves the choice.

Should I include source or editable files?

Not automatically. Include only the source files named in scope, after checking that the client is permitted to receive the underlying fonts, stock elements, product files, references, and other components. A flattened final and an editable production file carry different reuse possibilities and risks.

Should files be watermarked until payment?

There is no universal handoff rule. The agreement should connect preview quality, approval, payment, license activation, and final-file release. A watermark can help distinguish a review copy, but it does not replace clear payment and usage terms.

Do metadata or Content Credentials prove that an AI UGC asset is approved?

No. Metadata and provenance credentials can carry useful history or signed assertions, but approval, factual accuracy, permission, and usage scope come from the relevant people and records. Keep the technical provenance and commercial approval connected without treating them as the same thing.

What if the client asks for another size after delivery?

First determine whether that size was included in the signed deliverables. If it was, complete the missing export as an in-scope correction. If it introduces a new placement, composition, language, claim, or production step, route it through the agreed change process and preserve the original asset ID with a new version or derivative ID.

The Client Should Not Have to Guess

An AI UGC delivery is complete when the client can identify the exact approved files, understand where and how they may be used, access every promised item, and route the next request without reconstructing production from messages. The folder is only the container. The real handoff is the chain from asset ID to approved version, intended use, rights, access, and receipt.

Build that chain while the project is still fresh. It takes less time than explaining six weeks later which “final” was actually final.

Your AI UGC Is Approved. What Exactly Should You Send?