> ## 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. # Privacy > Data minimization requirements on license servers and platforms: end users, prompts, outputs, biometric data and retention. This page specifies how little personal data the Talent License Protocol needs, what each side may send and keep, and what a license server must publish about retention. ## End users **TLP-PRV-1.** A platform MUST identify an end user by a stable ID scoped to the platform, and MUST NOT send an email address, name, phone number or other direct identifier as that ID or anywhere else in a check. **TLP-PRV-2.** A license server MUST store end-user IDs only as a keyed HMAC, and MUST NOT disclose them, or the HMAC key, to any party other than the platform that sent them. ## Prompts and inputs A platform chooses how much prompt text it sends with `prompt_handling.mode`: | Mode | The platform sends | Effect | | - | - | - | | `full` | The text as the model receives it | Rules that need the text are checked at the check | | `redacted` | The text, with personal data removed first | As `full`, on the redacted text | | `withheld` | No text: structured fields and media digests only | Rules that need the text are checked on the output, or reported as `unchecked` | **TLP-PRV-3.** A license server MUST honor the mode a platform sends. With `withheld`, it MUST NOT require text, and its receipts for the check MUST be `attested` ([TLP-DEC-29](/standard/decision-semantics#honesty)). **TLP-PRV-4.** A license server MUST delete the prompt text of a check decided `allow` once the check is decided; the receipt keeps the request digest. It MAY keep the text of a check decided `deny` or `escalate` for review and disputes, for a period it publishes. With `prompt_handling.retention` set to `none`, it MUST delete the text as soon as the check is decided, whatever the decision. **TLP-PRV-5.** A platform MUST NOT put personal data in `metadata`, and MUST NOT send personal data that the model does not receive, other than the end-user ID. ## Use of what a license server receives **TLP-PRV-6.** A license server MUST use the prompts, inputs, outputs and fingerprints it receives only to decide, prove and audit decisions, and MUST NOT train models on them. **TLP-PRV-7.** A license server SHOULD delete a file submitted for verification once the verification is done, keeping only the result. ## Biometric data **TLP-PRV-8.** A license server MUST hold a talent's face and voice templates only while the talent has protection turned on, and MUST delete them within 30 days after it is turned off. **TLP-PRV-9.** A license server MUST NOT store embeddings it computes from the reference images and voice samples it receives in a check or a resolution unless they match a protected talent, and MUST publish how long it keeps a match. ## What public objects contain **TLP-PRV-10.** Receipts, receipt pages, the talent index and the discovery document MUST NOT contain an end user's identity, prompt text or input media. The talent index MUST contain only names, aliases and transliterations the talent confirmed. ## Retention **TLP-PRV-11.** A license server MUST publish how long it keeps each kind of data it receives or derives, and MUST keep nothing longer than it publishes. The Talent API's published retention (informative): | Data | Kept | | - | - | | Prompt text on `allow` | Deleted once the check is decided; the receipt keeps the `request_digest` | | Prompt text on `deny` or `escalate` | 30 days, for review and disputes | | Artifacts on `allow` | Deleted within 24 hours; `sha256` and fingerprint kept for the license term plus 3 years | | Artifacts held for release | Until release or expiry, plus 30 days | | Reference embeddings | Not stored unless they match; matches kept 90 days | | Receipts, usage records, statements | 7 years | | End-user HMACs | 13 months | | Talent face and voice templates | While protection is on; deleted within 30 days after | For prompts and outputs, Reflections processes data for the platform under a data processing agreement. For talent identity data, it is the controller, acting for the talent. ## Related What the Talent API receives and keeps, explained. Full, redacted and withheld prompts, and their cost. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.