How to document Sora work for client delivery

Sora is OpenAI's video and audio generation model, reachable through sora.com and a standalone iOS app, with API access announced as the next step. It arrived with a provenance stack that is unusually explicit for a consumer video tool: OpenAI embeds C2PA metadata in every generated asset, stamps a visible moving watermark on videos downloaded from sora.com or the Sora app, and runs internal detection tools that can assess whether a piece of video or audio came from its products. If you deliver Sora work to clients, those three mechanisms are the starting point of your documentation story, not the end of it.

Each mechanism answers a narrow question. C2PA metadata gives the file an industry-standard statement of origin that survives as long as nobody re-encodes the file without carrying it over. The moving watermark tells any viewer that the clip is Sora output. The detection tools sit inside OpenAI. None of the three records what a client actually asks about at delivery: the prompt you ran, the versions you rejected, the date a shot was approved, and whether a real person's likeness was used with consent. Sora's cameo feature enforces opt-in consent inside the product, but the exported clip does not certify that the consent existed.

So the working rule for Sora is to treat OpenAI's provenance signals as the platform's statement about the file, and to build your own record for everything the signals do not say. That record is notarial in character. It can show which prompts, inputs, and outputs existed, that they have not changed since you recorded them, and when you recorded them. It cannot show that a particular input caused a particular frame, and no tool can. The checklist below keeps the two layers separate, so you never promise a client more than either layer can support.

What Sora stores on its side

• OpenAI's provenance tooling for Sora includes C2PA metadata on all assets, described as providing verifiable origin through an industry standard. Source
• Videos downloaded from sora.com or the Sora app carry a visible moving watermark. Source
• OpenAI runs internal detection tools to help assess whether a certain video or audio was created by its products. Source
• The cameo feature requires explicit opt-in consent and gives people controls over the use of their likeness. Source
• Sora 2 is available via sora.com and a standalone iOS Sora app, and OpenAI has stated it will also become available through the API. Source

What gets lost without your own record

• The visible moving watermark identifies a clip as Sora output, but it says nothing about which account, prompt, or settings produced it.
• C2PA metadata lives inside the file, so any downstream re-encode by a platform or an editing pipeline can leave the delivered copy with weaker provenance than your original download.
• OpenAI's detection tools are internal, so neither you nor your client can independently query OpenAI to confirm a clip's origin.
• Your prompts and in-app iteration history do not travel with the downloaded video file.
• Cameo consent is enforced inside the product at generation time, but the exported clip carries no certificate that the consent existed, so likeness clearances need their own paper trail.

The documentation checklist for Sora

1. Save the exact prompt text and any input images in the same folder as the downloaded clip, at the moment you download it.
2. Record which surface produced the clip, sora.com or the iOS app, together with the generation date and the model generation in use.
3. If the clip uses a cameo, write down whose cameo it was and archive your own likeness clearance with the delivery, because the exported file does not certify consent.
4. Keep the original watermarked download unmodified as the reference copy and store its hash, so you can show later that the delivered file matches it.
5. Inspect the Content Credentials of the download with a C2PA verification tool before delivery and file the verification result next to the clip.
6. Note in the delivery record which provenance signals the client's copy carries, since platform re-encoding can strip C2PA metadata downstream.

For teams delivering into the EU, Sora's marking helps with the machine-readable side of the EU AI Act's Article 50 transparency obligations, since C2PA metadata and a visible watermark are exactly the kind of signals the article contemplates. Your own record still has to show what was AI generated, how it was disclosed, and when, because the penalty regime for transparency violations reaches up to €15 million or 3% of worldwide turnover, and the disclosure duties for deployed content sit with the team that publishes it.

Keep the two evidence layers apart in your delivery language. OpenAI's signals say that this file came from Sora. Your records say that this prompt, this input, this consent, and this approval existed on this date and have not changed since. A record like that works as a notary, not as a witness to causation: it can show inclusion, integrity, and time, and it should never claim that a specific input caused a specific output.

Frequently asked questions