Asset-level permission tracking helps teams stop rights details from being separated from the photo, voice, character, or source material they describe. It also gives downstream products a specific record to check.
Create a record for each rights-bearing input
Do not attach one project-wide status to every asset in a campaign. Create a record for each person, voice, image, brand element, and source work that requires a rights check. Use identifiers that stay stable when filenames or project folders change.
Link each record to its rights holder, evidence, intended scope, exclusions, and review history. Make the difference between verified information and user-entered claims visible so a producer can tell what still needs confirmation.
Check permission against the current request
A permission record is useful only when it can be compared with the client's actual request. Include the campaign, category, territory, channel, term, and asset selection. If one field does not match the terms, surface the conflict and stop the next action.
When a request changes, run the check again. A replacement voice, new product, additional territory, or extended campaign may alter the relevant permission. Preserve both the old and new request so the team can see what changed.
Keep provider status as a separate field
Provider review is not the same as permission from a rights holder. Store the provider identity, request reference, response, conditions, and timestamp in its own status record when an authorized connection supplies that information.
If the provider path is not connected, show that it is unavailable. Do not create a local record that appears to be a submission or approval. The system should make this limitation visible to the user at the point where it matters.
Give the downstream app a safe answer
An API response should state the asset, status source, scope version, and whether a requested action is allowed, blocked, or unknown. Avoid returning a broad true value without explaining which checks were run.
Approved.video is intended as a rights and status layer for studio and application workflows. Each customer can integrate its own talent records or a contributor pool, subject to the actual authorization and provider paths in use.
CLARIFICATIONS
Questions & answers
Why track permissions per asset instead of per campaign?
A campaign often combines assets with different rights holders, terms, and restrictions. Asset-level tracking makes those differences visible.