> ## 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. # Human Consent Standard > How Human Consent Standard declarations map to TLP decisions, and the three places TLP diverges from it. This page specifies how a TLP license server and platform treat declarations made under the Human Consent Standard (HCS), how each declaration level maps to a TLP decision, and where TLP diverges. ## HCS in brief (informative) The Human Consent Standard is a draft standard of the Human Consent Foundation (formerly RSL Media). It extends RSL so that rights holders, registries and authorized representatives can publish machine-readable terms for AI use of creative rights, including a person's identity. In plain terms, its model is: * **Rights subjects.** The thing protected: a person's identity, a work, a character or a mark, each with a stable identifier, such as one issued by the Human Consent Registry. * **Declarations.** For a kind of use, such as AI generation or AI training, a statement at one of three levels: allowed, allowed with terms, or prohibited. * **Clearance.** Where a user goes to obtain permission: a licensing path, a contact or a payment path. * **Registries and representatives.** Registries publish declarations and defaults for the people or repertoires they represent; representatives publish for the subjects they act for. ## Correspondence | HCS | TLP | | - | - | | Rights subject whose subject is a person's identity | Talent. `hcs_subject_id` on the talent carries the registry identifier. | | Representative | Representative, acting under a mandate | | Declarations for a subject | The talent's posture | | A declaration for a kind of use | A posture rule | | Allowed / allowed with terms / prohibited | `allowed` / `license_required` / `prohibited` | | Clearance path | A license request at the talent's license server | | The server a declaration names | The talent's TLP license server | ## Declarations mapped to decisions **TLP-HCS-1.** A license server that decides for a talent with HCS declarations MUST decide as this table specifies, using the declaration that matches the use as a posture rule ([TLP-DEC-20](/standard/decision-semantics#when-no-license-covers-the-use)): | Declaration | Decision | | - | - | | Prohibited | `deny` with reason `talent_prohibits`, term `talent:`, and no remedy. No license changes it. | | Allowed with terms | `deny` with reason `no_license` and a remedy of type `license_request`, unless a license of the licensee covers the use. If one does, the use is decided on that license, and `allow` when its terms are met. | | Allowed | `allow` with the declaration's obligations, and `license`, `license_revision` and `terms_digest` set to `null` | **TLP-HCS-2.** A license server that publishes HCS declarations for a talent MUST keep them equal to the talent's posture, level for level, and MUST name itself as the server in each. **TLP-HCS-3.** A platform that finds a declaration naming a TLP license server for a talent MUST send its checks for that talent there ([TLP-DSC-5](/standard/discovery#finding-the-license-server-for-a-talent)). It MUST NOT decide `allow` from the declaration alone. It MAY treat a prohibited declaration as `deny` without calling the server. **TLP-HCS-4.** When a talent's declarations and licenses disagree, a license server MUST decide by the prohibited declaration ([TLP-DEC-23](/standard/decision-semantics#when-no-license-covers-the-use)). ### Example (informative) Maya Okafor's posture, published as declarations by her license server: | Use | Declaration | A check for that use | | - | - | - | | Political advertising | Prohibited | `deny`, `talent_prohibits` | | Commercial image and video | Allowed with terms | `deny`, `no_license`, `license_request`; `allow` for Ridgeline under license `K7Q4M2` | | Personal, non-commercial speech on a platform holding her platform license | Allowed with terms | `allow` under Northlight's platform license | ## Divergences TLP diverges from HCS in three places. 1. **A decision per request, not a published declaration.** An HCS declaration is a standing, published statement. A TLP decision is made for one request, bound to a signed license revision by its `terms_digest` and to the request by its `request_digest`, and proved by a signed receipt. A declaration says what a talent permits in general; a decision says whether this request may proceed. 2. **`escalate` has no HCS counterpart.** HCS has no state for "a person with authority must decide this request". TLP's `escalate` defers the decision to the talent, a representative or the license server's reviewers, and expires to `deny`. 3. **The clearance path is the license request.** HCS describes clearance as a path to authorization. In TLP, that path is a license request to the talent's license server, and the license server is what a declaration's server points at. A cleared request becomes a signed license revision, and later checks are decided on it. ## Related The standard HCS extends, and RSL license tokens. Posture rules and the missing-license rule. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.