Skip to main content

​
Synthetic-media provenance

There are two places in Orbit where AI fabricates a human-sounding or human-looking asset: cloned voice and AI-avatar video. Every clip those surfaces produce carries a machine-readable content credential — a signed token any reviewer (a recipient, your compliance team, or a regulator) can check to confirm the clip is AI-generated. This page explains the model; request shapes live in the API reference pages linked below.

​
What the credential is for

A consent-registered voice clone in Voice → Voice Clones only gates the clone’s creation. Once that clone synthesizes speech, or one of your avatar personas renders a video clip, the output bytes look no different from a human recording. The credential closes that gap: it proves, in a form a machine can check, “this clip was AI-generated by tenant T’s clone or persona at a stated time.” The motivation is regulatory direction — EU AI Act Article 50 (AI-generated content marking, binding 2026-08-02) and the FCC synthetic-voice rules — but the control belongs to you: the credential is minted on every eligible render whether or not your specific traffic requires it. The regulatory posture and your tenant-level opt-ins are in the EU AI Act page; this page is about how the marking mechanism works.

​
The two sibling covers

Two modality services mint credentials, built on one shared, stateless signing pipeline:
  • Voice — a ready clone id + synthetic speech. Every watermark request returns a token pairing the machine-readable manifest with your resolved spoken disclaimer (tenant-configured intro text or audio URL, falling back to Orbit’s default “This message uses an AI-generated voice.”).
  • Video — an avatar persona + async render job. When your render runtime reports completed on a vavr_ render job, the transition handler mints the credential from the clip digest.
Both sit on the same primitives: a <version>.<manifest>.<signature> token signed with a purpose-separated HMAC-SHA256 subkey derived from the API secret — a leaked voice-watermark key never degrades the video key, JWT signing, or the API secret itself. Each modality owns its own manifest shape and key domain (voice tokens start ov1, video ovv1); the pipeline is shared. Verification is stateless — the token IS the record, so the credential capability shipped with zero schema migration.

​
What gets bound to the clip

The manifest inside each token binds three things:
  1. The exact clip bytes — a lower-hex SHA-256 digest (audio_sha256 for voice, video_sha256 for video). Any edit to the clip after marking — re-encode, splice, partial lift — breaks the bind and verification reports a mismatch instead of passing.
  2. The generator identity — the clone id (vclone_…) for voice, the persona id and render-job id for video. For video the manifest additionally binds the rendered script’s digest, so the credential cannot be restapled to a clip saying something else.
  3. The declared disclosure — a human-readable statement plus flags noting the mark satisfies the EU AI Act Article 50 synthetic-media obligation. A regulator reading the credential alone sees the declared basis without calling Orbit.

​
Where the credential travels

For video, the credential is persisted on the render job alongside its output_url, so when you attach that URL to a campaign send or a 1:1 MMS/WhatsApp message, the provenance travels with the clip. GET /api/v1/video/avatar-video-renders/:id returns the full job record, including the minted token. For voice, the credential is detached by design: you get the token back when you mark a clip, and you keep it with the clip wherever it goes. When you hand Orbit the actual audio bytes (not just a digest), the voice surface additionally embeds a C2PA content credential directly inside a WAV clip, so a C2PA-aware consumer can validate provenance without calling Orbit at all.

​
Providers differ

The detached token is provider-agnostic — the digest bind works regardless of which synthesis or render provider produced the clip. Other marks differ:
  • In-audio watermarking some TTS providers (ElevenLabs, Resemble) embed inside their output is a per-provider capability. Coverage varies by the configured voice provider, so treat it as an extra signal rather than a guaranteed layer.
  • C2PA embedding in WAV bytes is only possible when you pass the clip itself to the watermark endpoint — the digest-only path has no bytes to embed into.

​
Verify in your hands

Verification is a stateless POST — no client, no persistence: Video:
Pass only the token to check its signature. Also pass the clip — as video_base64 or a pre-computed video_sha256 — and verify bind-checks it: a genuine token stapled onto different clip bytes reports video_mismatch instead of ok. Voice: the same idea on POST /api/v1/voice/clones/:id/watermark (mint) — read back the token and keep it with the clip. The render surface’s GET /api/v1/video/avatar-video-renders/:id returns the minted token verbatim so you can hand it to a reviewer.

​
See also