Likeness and consent policy

This is the product behaviour, not a statement of intent. The gates live in the domain layer and run before minutes are reserved or a job is queued.

Whose likeness may be used

• Fictional. No real person. Consent is not required. The output is your marketing asset.
• Authorized real person. A named person who is not you. Consent is required before any generation.
• Digital twin. You, or a person using the organisation as their production tool. Consent is required before any generation.

A persona is built from a nine-slot reference pack (face, close-ups, profiles, full body, expressions, reference video) and is not marked ready until every slot is present and the version is locked. Partial packs cannot generate — that is how identity drift starts.

How consent is captured and recorded

Consent is a stored record on the persona, not a boolean. The fields are:

• consent_subject — self or the named person.
• consent_confirmed_by — the signed-in user who confirmed it.
• consent_confirmed_at — timestamp.
• consent_evidence_url — optional evidence (for example a signed document).

For authorized_real_person and digital_twin, assertPersonaGenerable refuses the job if consent_confirmed_at is null. The UI cannot bypass this. How the evidence is collected in the interface (in-app checkbox, upload, wet-ink scan) is [TO CONFIRM].

Withdrawal

withdrawConsent sets the persona status to consent_withdrawn and stamps consent_withdrawn_at. New generation is refused immediately. Existing content is kept. We do not silently delete live campaigns; you may need those records. The withdrawn state is visible on the persona.

You cannot re-consent on a withdrawn persona. A new persona is required. That is deliberate: withdrawal is not a toggle.

Erasure (a real person's right to be forgotten)

Deleting an authorized_real_person or digital_twin persona is immediate, not a later reaper job. In order:

• Inventory every content item derived from that likeness, and every schedule in state published, publishing or scheduled, including platform and external_post_id.
• Delete the media objects from our storage (renders and generated assets). A failed object delete aborts so a retry still sees the inventory.
• Write an erasure_requests row: organisation, persona id and name, identity type, who asked, the item list (the removal task), count of objects deleted. This table has no foreign key to personas — it must outlive the row it erases.
• Mark those content items discarded, clear their media paths, and null the copy written about that person — hook, script, scenes, caption, hashtags, and the generation prompts. Nulled, not search-and-replaced: a real erasure has no known string to match, so redaction leaves behind every nickname, forename and misspelling. Delete the generated asset rows.
• Delete every reference-pack object (all versions), then the persona row itself. The persona row is the consent record; it goes with the person. Reference asset rows follow.

What we cannot do: log into Instagram, Facebook, TikTok, YouTube or LinkedIn and pull the post. The erasure record is the task list for taking those posts down, and today it is reachable by writing to [TO CONFIRM], not from inside the product — the screen that shows it to you is not built yet, and we would rather say so than imply otherwise. An owner or editor sets resolved_at when the work is done.

How long we keep the record

The erasure record keeps the person’s name, because “an erasure happened” proves nothing on its own. Storage limitation means not forever: after [TO CONFIRM] the name is replaced with a salted hash, and the captions snapshotted into the item list are dropped. The record still answers the only question it exists for — someone asking “did you erase me?” can have their name hashed against it — while no longer containing the name. The salt is per record, so the table cannot be run against a dictionary of common names. The retention interval itself is not yet settled.

Fictional personas

Deleting a fictional persona removes the person and the reference pack. Generated content stays — it is your asset — with persona_id set to null. No erasure request is written.

Asking us

Organisation owners and editors can run this from the product once that UI ships. A data subject who is not a user of the organisation should write to [TO CONFIRM]. We will match them to a persona via the consent subject and evidence, then run the same erasure path. Turnaround time is [TO CONFIRM].