I
Identify the subject

Who are we protecting?

Every protected identity is registered against an identifier the platform side can resolve. Living artists are protected during life and (in most jurisdictions) for a statutory postmortem term thereafter. Deceased personalities are protected for the term their domicile prescribes.

Status
II
Establish authority

Who has standing to sign?

Postmortem rights pass to a successor by operation of law and instrument. The platform side will not honor an assertion without a chain of authority that resolves back to a verifiable source — a trust, a will, a court order. The chain we build here becomes the evidentiary backbone of every detection, takedown, and recovery downstream.

Role of the signing party
Trust / will / court order PDF or image. Held under attorney-client privilege; not part of the public consent ledger record. We sign a hash, not the document.
Death certificate Postmortem only. Confirms the controlling-statute period.
Evidentiary chain begins here Every detection, takedown, and recovery we route downstream cites this chain of authority. AB 1836 in California requires registration before damages accrue — most estates do not realize this until their first violation is already in progress.
III
Likeness assets

What references the platform fingerprints?

A protected identity is only as strong as its reference set. We accept reference media in five categories — each becomes a cryptographic fingerprint that our detection arm and partner-platform pre-generation checks match against. The richer the profile, the higher the recall on unauthorized use.

Estimated detection coverage Adjust the asset selection to project recall coverage across voice, image, and video modalities. Selecting all five typically yields 95%+ recall on industry-grade unauthorized AI output.
IV
Declare what is restricted

What we tell the world is denied by default.

The platform side reads this list. When a generator or trust-and-safety system asks "may we use this likeness for X?", the answer is computed from the boxes below. Every capability you restrict is added to the public-facing assertion the rights-holder signs at the end of this wizard.

Platform-specific deny list
What this signs You are declaring a default-deny posture across 8 capability classes and 8 named platforms. Every unauthorized use becomes an evidentiary event under your controlling statute.
V
Authorized uses (optional)

The yes-faster pathway.

Restriction is the default; authorization is the exception. If the estate has chosen to engage on specific projects — a studio license, a documentary, a posthumous performance — record those grants here. The same machinery that returns a deny in milliseconds returns an allow in milliseconds.

No grants on file Most postmortem estates begin here. Robin Williams' trust has historically granted no posthumous AI engagements. Living artists may have one or many.
+ Add an authorized grant
The same record format Restriction assertions and authorization grants are the same data model — only the scope token differs. Verifiers issue a deny in milliseconds when no grant matches, and an allow in milliseconds when one does. No clearance email chain. No human in the verification path.
VI
Term & jurisdiction

For how long. And where.

Every assertion carries an explicit term. Postmortem terms are bounded by the controlling jurisdictional ceiling — your domicile's statute. Within that ceiling, the rights-holder may declare a custom embargo period, a phased release, or a permitted-after date.

Declared term against jurisdictional ceiling
VII
Review & sign

The assertion the trust will sign.

What follows is the canonical consent ledger entry produced from your declarations. Sign it — eIDAS, DocuSign, or wet-ink with a notarized affidavit — and the platform side begins enforcing within hours.

Consent ledger entry · draft did:litprov:<tbd>
Subject
Authority
Controlling statute
Term
Restricted
Authorized grants
None
Audit disclosure
Schedule a 30-minute onboarding call