Global Video Production Guardrails

Apply these gates before every workflow-specific SKILL.md in this pack. A video that fails a hard gate must be marked BLOCK, not published or delivered as viewer-ready.

1. Content and factual accuracy gate

• Verify every product claim, feature description, statistic, or comparison in a generated video script against a primary or authoritative source before production; do not let a generation model invent or embellish a claim about a real product or service. [FTC-AICLAIMS-01]
• Treat AI-generated performance or comparative claims ("fastest," "clinically proven," "outperforms X") as advertising claims requiring the same substantiation an advertiser would need if it made the claim directly; do not publish a claim the producer cannot substantiate on request. [FTC-AICLAIMS-01]
• Never present an AI-generated or AI-altered testimonial, review, or "customer" statement as if it came from a real person with real experience of the product; fabricated or materially altered testimonials are prohibited even when the underlying product claim is accurate. [FTC-FAKEREVIEWS-01]

2. Likeness and consent gate

• Before generating or using an avatar, digital twin, voice clone, or any realistic depiction of an identifiable person, confirm and record documented consent (or a controlling license) from the person whose face or voice is being used; do not assume a provider's technical ability to clone a likeness implies the legal right to use it. [USCO-DIGITALREPLICA-01]
• Treat any video, image, or audio that has been digitally created or manipulated to realistically but falsely depict an identifiable individual — including a stand-in performer wearing another person's face or voice — as a "digital replica" requiring the depicted individual's authorization, independent of whether the underlying footage or model output is copyrightable. [USCO-DIGITALREPLICA-01]
• Before any skill uses an established character identity (a characters/<slug>.md record validating against ../../schemas/character-identity.schema.json) to generate content, verify all three of the following against that record before generating anything: (1) the record actually exists — a slug with no characters/<slug>.md file is not an identity that can be used; (2) the consent field for the modality actually being generated is captured: true with a real evidence_uri — face_consent if a visual representation is being invoked, voice_consent if a voice representation is being invoked, only the modality in use, never both by default, since a voice-only generation does not require face consent and vice versa; (3) the specific representations[] entry being invoked has verification.level: account_verified — documentation_verified or integration_verified alone confirm a representation's mechanism was declared or round-tripped, not that generating with this exact identity has actually been confirmed to work, so neither is sufficient to generate against in production. This is a mechanical precondition check on this gate's own principle above, not a separate rule.
• If any of the three checks fails, HALT — do not generate — and redirect the requester to ../05-character-identity-onboarding/SKILL.md: its create flow if no record exists for this identity anywhere, its import flow if a compatible provider-side representation already exists but has not yet been onboarded into a record. Never proceed with generation against an unverified or non-consented identity, and never fabricate or substitute a placeholder consent or verification signal to get past this check.

3. Platform-and-jurisdiction disclosure gate

Disclosure obligations vary along three independent dimensions — what kind of AI involvement the content has (content-property), where it is published (target), and whose disclosure law or policy applies (jurisdiction) — so treat disclosure as a matrix lookup, not a single flat rule.