> ## 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. # C2PA > Where a TLP receipt goes in a C2PA manifest, the digital source type to declare, soft bindings for lookup, and what survives when metadata is stripped. This page specifies how a platform carries a TLP receipt in an output's C2PA manifest: the assertion's label and content, where it is placed, the action and digital source type that go with it, how soft bindings lead back to a receipt, and what a verifier can still establish when the manifest is gone. ## The assertion The receipt travels as an assertion whose label is the license server's `c2pa_assertion_label`. For the Talent API, the label is `ai.reflections.license`. | Field | Value | | - | - | | `label` | `ai.reflections.license` | | `data.receipt` | The receipt, as its compact JWS | | `data.verify_url` | The receipt's page, from the `receipt_page` template | **TLP-C2PA-1.** A platform meeting a `c2pa_manifest` obligation MUST add this assertion to the output's active manifest, the manifest whose claim the platform signs, with exactly the `receipt` and `verify_url` the generation returned. It MUST NOT alter either value. **TLP-C2PA-2.** The platform MUST sign the claim, as its claim generator, with its own C2PA signing credential. The license server does not sign the manifest. The receipt inside the assertion carries the license server's own signature, so a verifier can check it independently of the claim signature. A platform that declares its claim-signing certificate's thumbprint as `c2pa_signer` when it submits the generation gets a receipt that names it as `tlp.c2pa_signer` ([TLP-RCP-15](/standard/receipts#binding-to-a-c2pa-claim-signer)). A verifier then rejects a copy of the assertion in a manifest that another certificate signed ([TLP-RCP-16](/standard/receipts#binding-to-a-c2pa-claim-signer)). Without it, the assertion is evidence of a decision, not of the file that carries it. **TLP-C2PA-3.** In a C2PA 2.x claim, the platform SHOULD list the assertion among the claim's gathered assertions, because its content comes from the license server and not from the claim generator. ## The action **TLP-C2PA-4.** The same manifest MUST contain a `c2pa.actions` assertion (label `c2pa.actions.v2` in C2PA 2.x) with a `c2pa.created` action whose `digitalSourceType` is the IPTC value `http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia`. ### Example (informative) The assertions a platform adds for the line of speech Northlight generated in Maya Okafor's voice, in the manifest definition format C2PA tools accept: ```json theme={null} { "assertions": [ { "label": "c2pa.actions.v2", "data": { "actions": [ { "action": "c2pa.created", "digitalSourceType": "http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia" } ] } }, { "label": "ai.reflections.license", "data": { "receipt": "eyJhbGciOiJFUzI1NiIsImtpZCI6InJmbC0yMDI2LTEwLWRvY3MzIiwidHlwIjoidGxwLXJlY2VpcHQrand0In0…", "verify_url": "https://app.reflections.ai/r/rcpt_hk5zba2q8v1m3n7p4r6s9t0wxy" } } ] } ``` The Talent API returns the second assertion, ready to add, as the generation's `c2pa` field. ## Order of operations **TLP-C2PA-5.** A platform MUST submit the output to the generation check first, then embed the manifest, then deliver. `artifact_sha256` in the receipt is the digest of the output as submitted, before the manifest was embedded. After the generation check, a platform MUST NOT change the output's content, as opposed to its metadata. ## Soft bindings A soft binding identifies content by what it looks or sounds like rather than by its exact bytes, so it survives re-encoding. TLP uses two: | Binding | Registered by | Looked up by | | - | - | - | | Fingerprint | The license server, from the bytes it checked (`pdq`, `vpdq`, `chromaprint`, with face or voice embeddings) | A file, URL or fingerprint sent to the verification endpoint | | Watermark | The platform, as `watermark.algorithm` and `watermark.id` on the generation | A file sent to the verification endpoint, when the license server reads that algorithm | **TLP-C2PA-6.** A license server MUST answer a verification of a file by its exact digest first and then by fingerprint, and MUST report which method matched and with what confidence. A platform that applies a watermark SHOULD register it on the generation, and MAY also record it in a C2PA `c2pa.soft-binding` assertion. **TLP-C2PA-7.** A verifier MUST treat a verification result of `not_found` as no information about whether the content is licensed. ## What survives stripping | What happened to the file | Manifest and receipt in the file | Lookup by exact digest | Lookup by fingerprint | Lookup by watermark | | - | - | - | - | - | | Delivered as embedded | Yes: verify the receipt offline | No: the receipt's digest is of the output before embedding | Yes | Yes, if registered | | Metadata stripped, content untouched | No | Yes, when stripping restores the submitted bytes | Yes | Yes, if registered | | Re-encoded, resized or trimmed | No | No | Yes, at `high` or `medium` confidence | Depends on the algorithm | | Re-recorded or heavily edited | No | No | Possibly | Depends on the algorithm | **TLP-C2PA-8.** A verifier holding a file with the assertion MUST verify the receipt ([TLP-RCP-5](/standard/receipts#verifying-a-receipt)), its claim signer binding ([TLP-RCP-16](/standard/receipts#binding-to-a-c2pa-claim-signer)), and the C2PA claim signature and bindings. The claim binds the manifest to the file; the receipt binds the decision to the submitted output. A verifier holding a file without the assertion MUST use a lookup, and MUST NOT treat a receipt it found elsewhere as proof about the file unless a lookup relates them. ## Related Writing the assertion and the disclosure label in practice. The `ai.reflections.license` assertion in the Talent API. Lookup by receipt, manifest, digest, fingerprint or file. The C2PA technical specification. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.