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 can carry 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 end to end; request shapes for individual endpoints 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.

​
Operator walkthrough — obtain and hand over a token

Voice (dashboard). In Voice → Voice Clones, open the Watermark dialog on a ready clone (the shield icon on the clone row). Two tabs:
  1. Create credential — upload the synthesized clip (up to ~30 MB). Orbit hashes it server-side and returns the credential token in a copyable field, plus the resolved audible disclaimer to prepend on playback.
  2. Verify — paste a token, optionally attach the audio in hand. The result panel shows valid/invalid, the reason code, and the decoded manifest fields (clone id, provider, audio digest, marked-at instant).
Voice (API). Mint with POST /api/v1/voice/clones/:id/watermark and keep the token with the clip. Verify with POST /api/v1/voice/clones/watermark/verify. Both endpoints are documented in the endpoint catalog below. Video. Read the minted token for a finished render from GET /api/v1/video/avatar-video-renders/:id; the job record carries the credential alongside its output_url. Hand that token to whoever needs to verify it.

​
Offline verification for a regulator

A reviewer can check a credential without an Orbit account, but they do need trust material you supply — control of the verifier is tenant-owned:
  • Detached token (voice or video). The token is an HMAC token whose key derives from your API secret. Hand your reviewer the token plus a verifier you run — either a direct call to the verify endpoint with their own API key, or a local check recomputing the HMAC with your API secret (which you may share on a need-to-know basis). Signature math and the payload layout are fully specified under “Manifest field spec” below.
  • Embedded C2PA credential (voice, WAV only). When you mint via the audio_base64 path on a WAV clip, a standards-based C2PA credential is embedded in the file itself. Any standalone C2PA-aware tool can extract and validate it offline with no Orbit call. Route C2PA-embedded files to external reviewers wherever possible — it removes the trust-material exchange above entirely.

​
Verify endpoint catalog

Verification is a stateless POST — no client, no persistence. One endpoint per modality: Video — POST /api/v1/video/avatar-video-renders/verify
Response: { valid, reason, manifest }. Voice — POST /api/v1/voice/clones/watermark/verify
*At least one of token or audio_base64 is required. Supplying audio_base64 alone is valid: the endpoint also checks for an embedded C2PA credential in the bytes, which is how a file minted through the C2PA path verifies without a detached token. Response: { valid, reason, manifest, c2pa } where c2pa is { found, valid, reason } or null. Mint endpoints (for completeness):
  • Voice: POST /api/v1/voice/clones/:id/watermark — body accepts audio_base64 (clip bytes) or audio_sha256 + audio_bytes together (digest-only path). Optionally synthesized_at (ISO-8601). The digest-only path returns just the detached token; the bytes path additionally returns a c2pa block.
  • Video: the credential is minted automatically when a render transitions to completed — there is no client-callable mint endpoint. Read it back from GET /api/v1/video/avatar-video-renders/:id.

​
Manifest field spec

The base64url middle segment of each token decodes to this JSON. Voice manifest: Video manifest differs in three identity fields and one extra bind: The signature segment is a base64url HMAC-SHA256 over the literal <version>.<payload> string (payload = base64url of the manifest JSON above, nothing dropped and nothing canonicalized).

​
Key rotation semantics

Both tokens are signed with a purpose-separated subkey: the base API secret (DEVOTEL_API_SECRET_KEY) HMACs a domain label — orbit:synthetic-voice-watermark:v1 for voice, orbit:avatar-video-provenance:v1 for video — and the result signs/verifies tokens. A leak of one modality’s key never degrades the other, JWT signing, or the API secret itself. On API-secret rotation: because the subkey derives from the API secret, rotating the secret invalidates every previously minted token — verification reports signature_invalid. The remedy is re-minting (voice: re-call the mint endpoint with the clip bytes or the recorded digest pair; video: a re-render). There is no key-id segment in the token; treat old tokens as stale after rotation and stop handing them to reviewers. For embedded C2PA credentials the signing identity is ES256 (P-256) derived from the same secret by a separate domain label, so the same rotation rule applies and rotation doesn’t strand existing embedded files — the embedded credential is self-contained and still verifies against whichever key you extract from the file’s own manifest.

​
C2PA embedding — format coverage

The C2PA embedded path (voice mint with audio_base64) supports exactly one container today: If your pipeline produces MP3 or AAC, transcode to WAV before minting to get embedded provenance; otherwise keep and hand over the detached token. A digest-only mint (audio_sha256 + audio_bytes) returns c2pa.embedded = false — there were no bytes to embed into. Verify-side, any audio buffer (even a detached token alone) also runs the C2PA extractor; the c2pa block in the response reports found plus its own validity so you can tell which credential verified.

​
Verify error enum

The reason field on both verify endpoints reports the first failing check, in this order: When the token comes back audio_mismatch on a WAV file Orbit itself marked via the C2PA path, the endpoint retries the bind against the bytes excluding the embedded C2PA chunk Orbit appended — the only forgiveness applied — so a self-marked file verifies cleanly. A modified audio_sha256 you computed yourself can never bypass this. The C2PA extractor’s own reason values (found block): ok, no_credential, not_wav, malformed_jumbf, signature_invalid, audio_mismatch.

​
EU AI Act Article 50 mapping

Article 50 requires AI-generated or AI-manipulated content to be marked as artificially generated, in a machine-readable format, and (for synthetic audio) detectable as such. Which Orbit flag satisfies which clause: Have your compliance team confirm this mapping against the EU AI Act page, which lists the tenant-level opt-ins and the known limitations (WAV-only C2PA coverage, digest-only video persistence).

​
Your control, your responsibility

The credential mechanism is infrastructure you operate: tenant-owned, never platform-mandated. Orbit mints and verifies the mark, and declares the Art. 50 / FCC basis inside it, but whether your specific traffic requires the mark, how you present it to recipients, and how you preserve provenance downstream (which of your sends carry watermarked clips, which don’t) is your compliance posture. Orbit does not certify your output as compliant — the pages below frame what the platform provides so your counsel can decide the rest.

​
See also