> ## 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.
# Versions and changes
> How the Talent License Protocol is versioned, how changes are proposed and published, and the change log.
This page specifies how the Talent License Protocol is versioned, what a minor and a major version
may change, how implementations handle values from versions they do not know, and how changes are
proposed and published.
## Version numbers
TLP versions are `major.minor`, such as `1.0`. The version appears in `tlp.ver` in every token and
receipt, and in `protocol_versions` in the discovery document. A license server's own API versions,
such as the Talent API's `2026-10-15`, are separate from the protocol version.
**TLP-VER-1.** A minor version MUST be compatible with every earlier minor version of the same
major version. It MAY only:
* add values to a registry: obligation types, reason codes, remedy types, escalation reasons, and
values of the use vocabulary;
* add optional fields that a party may ignore and still behave conformantly;
* add requirements that apply only to the values and fields it adds;
* correct an error, where the correction does not change conformant behavior.
**TLP-VER-2.** A change that removes or renames anything, changes a meaning, adds a decision, or
requires a party on an earlier minor version to behave differently MUST be made in a new major
version. A change in what a platform must do for an existing obligation is a new obligation type
([TLP-OBL-15](/standard/obligations-registry#adding-a-type)).
## Handling unknown values
**TLP-VER-3.** A party that receives a value from a later minor version MUST handle it as follows:
| Value | Handling |
| - | - |
| Unknown obligation type | Unmet: do not proceed ([TLP-OBL-2](/standard/obligations-registry#rules-for-every-obligation)) |
| Unknown reason code | A reason like any other: show its `sentence`, act on the decision |
| Unknown remedy type | No remedy the party can act on |
| Unknown field | Ignored ([TLP-GEN-3](/standard/overview#wire-format)) |
| Unknown use vocabulary value, at a license server | Rejected with `parameter_invalid` ([TLP-USE-3](/standard/use-vocabulary#the-use-object)) |
| Unknown major version in `tlp.ver` | The token or receipt is not verified |
**TLP-VER-4.** A license server MUST keep verifying, and serving the live status of, every receipt
it signed under any version, for as long as it retains the receipt.
**TLP-VER-5.** A license server that adds a major version SHOULD serve the previous major version
alongside it for at least 24 months, and MUST list every version it serves in `protocol_versions`.
## Proposing a change
Reflections edits the Standard and keeps its registries. Anyone may propose a change: a
registry value, a correction, or a new requirement.
Send the proposal through [Reflections developer support](/production/support). A proposal for
an obligation type states what [TLP-OBL-14](/standard/obligations-registry#adding-a-type)
requires. Other proposals state the problem, the change to the text, and the effect on each
role.
The proposal is published for comment for at least 30 days. Implementers of every role may
comment.
An accepted change is published on these pages with a new version number and date, and listed
in the change log below and in the [changelog](/changelog).
Corrections that change no conformant behavior, such as fixing a typo or a broken link, are made
without a new version and noted in the change log.
## Change log
### 1.0, 2026-10-15
First publication. TLP 1.0 defines:
* the four roles: license server, platform, generation tool and verifier;
* the three decisions at the check, generation and session stages, escalation with a seven-day
maximum, and the honesty rule;
* the use vocabulary: five modalities, four use kinds, seven purposes, thirteen channels, and ISO
3166-1 territories with `WW`;
* the obligations registry, with ten types;
* the `tlp-auth+jwt`, `tlp-session+jwt` and `tlp-receipt+jwt` formats, ES256 signing, and the
`tlp-json-1` canonical form;
* receipt live status, receipt pages, and key publication and rotation;
* revocation with four scopes, three post-revocation policies, and acknowledgements;
* the discovery document at `/.well-known/talent-license` and the signed talent index;
* mappings to RSL 1.0, the Human Consent Standard, C2PA and ODRL 2.2.
## Related
The requirements each version sets for each role.
How the Talent API's dated versions work.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.