> ## Documentation Index > Fetch the complete documentation index at: https://docs.reflections.ai/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > The OpenAPI document at /api-reference/openapi.yaml defines the target contract. Its x-reflections-availability field and each operation's availability notice identify supported test and live forms. Do not infer implementation from a schema or code sample. Live keys support account details, reads of the licenses the calling account holds as licensee or issued as talent (GET /v1/licenses?role=issuer), and GET /v1/generations?license=… for the state of outputs under such a license (summaries only: no prompt, reference, bytes or metadata). Live image checks, submissions and receipts are built but not activated: until activation, a live POST /v1/checks or /v1/generations returns 403 live_not_activated, which must not be retried. Discovery and JWKS are at the origin root (https://app.reflections.ai/.well-known/...), not under /v1. > Three rules hold everywhere: a decision is never an error (deny and escalate are 200 responses, and a live check still evaluating is a 202 with status checking); generate nothing for a named talent without an allow; deliver nothing until the generation is allow. > The sandbox accepts personal rk_test_ keys. Persist a separate Idempotency-Key and body for each logical /v1 POST; retry an unknown outcome with the same key and body. OAuth and Talent API MCP remain planned. # Talent License Protocol > TLP 1.0, an open protocol for deciding, proving and revoking uses of a real person's name, likeness and voice in generative AI. The Talent License Protocol (TLP) 1.0 specifies how a license server decides whether a use of a real person's identity may proceed, how platforms and generation tools act on that decision, how anyone verifies it afterwards, and how consent is withdrawn. Any license server, platform, generation tool or verifier can implement it. The Reflections Talent API is one implementation. ## Status | Field | Value | | - | - | | Name | Talent License Protocol (TLP) | | Version | 1.0 | | Published | 2026-10-15 | | Status | Stable. Changes are made only as described in [Versions and changes](/standard/changes). | | Editor | Reflections | ## Notation The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY and OPTIONAL in these pages are to be interpreted as described in BCP 14 (RFC 2119, RFC 8174) when, and only when, they appear in all capitals. Requirements are numbered per page, such as TLP-DEC-4 on [Decision semantics](/standard/decision-semantics). Each requirement names the role it binds. [Conformance](/standard/conformance) lists the requirements of each role. Examples, diagrams and sections marked informative are not requirements. ## Scope TLP 1.0 covers: * deciding a use of a talent before anything is generated (the **check**), on the output itself (the **generation**), and during live generation (the **session**); * the three decisions, `allow`, `deny` and `escalate`, and when each may be returned; * the vocabulary that describes a use, and the registry of obligations a decision can carry; * signed tokens that carry an `allow` to the tool that runs the model; * signed receipts that anyone can verify offline, and their live status; * revocation, the deadlines that follow it, and acknowledgements; * how a platform finds the license server for a talent, and how anyone finds a license server's keys. ## Roles | Role | What it does | Example | | - | - | - | | License server | Holds talents' licenses and postures. Decides checks, generations and sessions. Signs tokens and receipts. Publishes revocations. | The Talent API | | Platform | Generates a real person for its end users or for licensees. Sends checks and generations, meets obligations, honors revocations. | Northlight, an image and video generation platform | | Generation tool | Runs the model. Verifies an authorization or session token before it generates. | A model provider, or a tool an agent calls | | Verifier | Checks a receipt, and reads its live status. | A distribution platform, a publisher, the talent | One product can hold several roles. A platform that runs its own models is also a generation tool, and it meets the requirements of both. Talent, representatives, licensees and end users are parties, not protocol roles: they act through a license server or a platform. See [Terminology](/standard/terminology). ```mermaid theme={null} flowchart LR T[Talent] -->|signs licenses| LS[License server] P[Platform] -->|check and generation| LS LS -->|decision, token, receipt| P P -->|request and token| G[Generation tool] G -.->|keys from JWKS| LS V[Verifier] -.->|receipt status| LS ``` ## Out of scope * **Contracts.** TLP carries signed license revisions and their digests. It does not define how a license is negotiated or signed, what legal effect a signature has, or how disputes are settled. * **Payments.** TLP does not move money or define invoices. A license may state compensation, and the `usage_report` obligation requires usage to be reported, but billing and payment are outside the protocol. * **Model training consent.** Beyond the `no_training` obligation and a license's training term, TLP does not govern whether a model may be trained on a person's data. * **Identity and accounts.** How a license server confirms who a talent is, how a platform authenticates to a license server, and how a licensee lets a platform act for it are implementation choices. * **Content policy.** TLP enforces the terms a talent signed and the posture they published. It does not define what content is lawful or acceptable in general. ## Wire format **TLP-GEN-1.** A license server, platform, generation tool and verifier MUST exchange TLP objects as JSON (RFC 8259) encoded in UTF-8. Timestamps in objects MUST be RFC 3339 date-times in UTC. Durations MUST be ISO 8601 durations, such as `PT60S` or `P7D`. Times in tokens and receipts are JWT NumericDate values (seconds since the epoch). **TLP-GEN-2.** A license server MUST accept and return the check, generation, session, session sample, receipt, verification and revocation objects, and the events about them, with the fields, types and enumerated values the [Talent API reference](/api-reference/introduction) defines for the object of the same name in version `2026-10-15`, except where these pages define a format themselves (tokens, receipts, the canonical form, the discovery document). A license server MAY add fields. It MAY serve these objects at any paths it lists in its [discovery document](/standard/discovery). **TLP-GEN-3.** A recipient MUST ignore object fields it does not recognize, with one exception: an obligation whose type it does not recognize is unmet ([TLP-OBL-2](/standard/obligations-registry)). **TLP-GEN-4.** A license server MUST make every `POST` operation idempotent under an `Idempotency-Key` request header: the same key and the same body return the original response. A platform MUST retry an operation whose outcome it does not know with the same key, never with a new one. ## Document set | Page | Specifies | | - | - | | [Conformance](/standard/conformance) | The requirements of each role, and the conformance suite | | [Terminology](/standard/terminology) | Normative definitions and identifier formats | | [Decision semantics](/standard/decision-semantics) | The three decisions at each stage, escalation, binding and the honesty rule | | [Use vocabulary](/standard/use-vocabulary) | Modalities, use kinds, purposes, channels and territories | | [Obligations registry](/standard/obligations-registry) | The registered obligation types and how new ones are added | | [Tokens](/standard/tokens) | Authorization and session tokens, verification, and the canonical form | | [Receipts](/standard/receipts) | Receipt formats, signing keys, rotation, live status and receipt pages | | [Revocation](/standard/revocation) | What revocation cuts, the deadlines that follow, and acknowledgements | | [Discovery](/standard/discovery) | The discovery document and how a platform finds a talent's license server | | [Security](/standard/security) | The threat model and the requirements it sets | | [Privacy](/standard/privacy) | Data minimization on both sides | | [Versions and changes](/standard/changes) | How the protocol is versioned and amended, and the change log | Interoperability pages map TLP to [RSL 1.0](/standard/interop/rsl), the [Human Consent Standard](/standard/interop/human-consent-standard), [C2PA](/standard/interop/c2pa) and [ODRL 2.2](/standard/interop/odrl). ## Relationship to the Talent API The Talent API is a license server that implements TLP 1.0. Its reference is the HTTP binding of the TLP objects. Features of the Talent API that TLP does not define, such as usage records, statements, connections and the MCP server, are documented in the reference and are not part of the protocol. ## Related The requirements of each role, in one place. `allow`, `deny` and `escalate`, normatively. Authorization and session tokens, and how to verify them. Find a license server and its keys. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.