Skip to main content
Sandbox and protocol reference. Multiple fictional talent can be named in a test check. Image and voice recognition, production review and remedies described below remain planned. Start with the runnable quickstart and sandbox support matrix.
A prompt can name two people, and a reference image can show a second face. Each protected talent is decided separately against their own license or posture, and the request gets the most restrictive answer.

How a check decides

Every talent the request invokes gets its own entry in talent[], with its own decision, license, license_revision and terms_digest. The check’s decision is the most restrictive of them: When more than one talent is escalate, each has their own escalation, named in talent[].escalation and decided by that talent’s side. The check becomes allow when every one allows. It becomes deny at the first deny, or when the first escalation expires, and the others are cancelled. While the check is open, its escalation shows the one that expires first. Only an allow for everyone carries an authorization. Its token lists every talent and facet in tlp.talent and tlp.facets, and every license that applied in tlp.licenses. See What the token and receipt carry.

Example: one licensed, one not

This example runs in test mode, against the sandbox talent. Ridgeline’s prompt names Maya Okafor, whose license covers the use, and Iris Calder, who has licensed nothing to Ridgeline.
Each reason names its talent, and remedy.talent names the talent the remedy is for. Show your user which person blocked the request. They can remove Iris Calder from the prompt, which is a new request and a new check, or Ridgeline can request a license from her with the denied check’s ID. Do not send exclude_talent to drop a talent the prompt names on purpose. It is only for a person your user confirmed they did not mean.

Combine obligations

When every talent is allow, obligations holds what every license requires. Meet all of them:
  • generation_instructions: pass every instruction to the model, for every talent.
  • hold_until_release: one talent’s hold holds the whole output, because the output shows everyone. In test mode, Maya Okafor with Jonah Reyes returns allow with a hold_until_release obligation, and the generation is held until Jonah Reyes’s side releases it.
  • disclosure: two disclosure obligations mean two labels. Show each text.
  • usage_report: report every unit the usage_report obligations name. A usage record counts against one license, so for a generation made under several licenses, send one record per license with its license set. A record is rejected as duplicate when the same subject, license and units were already reported.
When an obligation carries a term, the address names the license it comes from.

What the token and receipt carry

A token or receipt for several talent names each license that applied in tlp.licenses: one entry per talent, in the order of tlp.talent, with the license, the signed revision and its terms_digest. A talent whose posture allows the use without a license has no entry, so tlp.licenses can be shorter than tlp.talent. In test mode, a check for Maya Okafor and Jonah Reyes returns allow. Its authorization token carries these two claims, shown here without the tlp. prefix:
The token is signed with the test key, so its header kid is rfl-test-2026-10-docs3. Jonah Reyes’s license holds every output, so the generation is held and gets its receipt when it is released. In test mode, release it with POST /v1/test_helpers/escalations/{escalation_id}/resolve. The receipt’s tlp.licenses carries the same two entries. The receipt object from GET /v1/receipts/{receipt_id} lists them in licenses, where each entry names its revision license_revision:
Test receipts verify only with a test key.

Name several talent explicitly

When your user picks people from a cast list, send them all in talent, up to 10 on a check and 4 on a session:
Explicit IDs do not hide anyone else. If the inputs also name or show another protected talent, the check adds them to talent[] and decides for them too.

Narrow after disambiguation

A common name can match several talent, or a surname can match one weakly. Every candidate at medium confidence or higher is treated as invoked, so an unintended match can deny a request your user meant for someone else. When that happens:
1

Show the candidates

Call POST /v1/resolutions to get each candidate with the words that matched, and ask your user who they meant.
2

Send the answer on the check

Put the people they meant in talent, and the people they did not mean in exclude_talent.
See Resolve talent for the full flow.

Talent the check did not name

A generation is checked only for the talent its check covered. Reflections does not look for other people in the output, so the check has to carry everyone the request invokes: each name, and each reference image or voice sample. When your user adds a person after the check, run a new check that names them all; it is decided like any other.

Decisions

allow, deny and escalate at each stage.

Resolve talent

Explicit IDs, disambiguation and the name index.

Obligations

Every obligation and how to meet it.

Submit outputs

Findings at the generation.