> ## 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.

# How it works

> The lifecycle of a licensed generation, from prompt to receipt, and who decides what.

<Note>
  This page describes the target production lifecycle. The current service is a fictional test
  sandbox: it simulates decisions and signs test receipts. Real talent, media evaluation, webhooks,
  sessions, revocation changes and settlement are not available. Run the supported
  [quickstart](/quickstart) and check [availability](/sandbox) before building against a feature.
</Note>

A licensed generation passes two checkpoints. The **check** decides whether a use may start. The
**generation** decides whether its output may be delivered. Both are decided against a license
the talent signed, and both leave a signed receipt. The talent can revoke consent after both.

```mermaid theme={null}
sequenceDiagram
    participant U as End user
    participant P as Your platform
    participant R as Reflections
    participant M as Model provider
    U->>P: Prompt and references
    P->>R: POST /v1/checks
    R-->>P: allow, obligations, authorization
    P->>M: Generate, with instructions and token
    M-->>P: Output
    P->>R: POST /v1/generations
    R-->>P: allow, findings, receipt
    P->>P: Embed receipt in C2PA manifest
    P-->>U: Deliver output with disclosure
```

## 1. The talent sets terms

A **talent** is a person whose name, likeness or voice is protected through Reflections. Each part
of their identity that can be licensed is a **facet**: a likeness, a voice, a persona, a body of
their own words. The talent, or a representative they appoint, signs **licenses** with
**licensees**: a brand for a campaign, or a platform for its own users' personal use.

A license is a signed document. Its terms say which facets, which modalities, which purposes,
channels and territories, for which dates, which changes to the talent's appearance are allowed,
which rules the talent wrote ("Do not show alcohol or tobacco"), and what the licensee owes. Each
signed version is a **license revision** with a `terms_digest`, and its terms never change.

Talent also publish a **posture**: their standing public answer for uses with no license, such as
`prohibited` for political advertising. See [Licenses](/concepts/licenses) and
[Talent and facets](/concepts/talent-and-facets).

## 2. The platform checks the use

Before generating, your platform sends a check: the request your model will receive (prompt,
system text, your rewritten prompt, references) and how the output will be used. Reflections
finds which talent the request invokes, finds the license that covers the use, and decides.

| Decision | What you do |
| - | - |
| `allow` | Generate. Meet every obligation. Submit the output. |
| `deny` | Do not generate. Show the user `reasons[].sentence`. `remedy` says what would change it. |
| `escalate` | Do not generate yet. A person with authority decides. Wait for `check.resolved`. |

An `allow` carries an **authorization**: a signed token bound to the exact request
(`request_digest`), with a generation count and an expiry. Pass it to the tool or provider that
generates; they can verify it offline. See [Decisions](/concepts/decisions).

## 3. The platform meets the obligations

An `allow` is conditional. **Obligations** say what must happen for the use to stay licensed: pass
the talent's rules to the model, submit every output, hold outputs for release, label the result,
embed the receipt, never train on the material, report usage. Each obligation is typed, so your
code can meet it without reading prose. See [Obligations](/concepts/obligations).

## 4. The platform submits the output

The output goes back to Reflections as a **generation**, bound to its check and candidate by its
SHA-256. Reflections checks the license's rules on the actual bytes: that the person is the same
person, that only licensed changes were made, and that the talent's own rules hold. Only the talent
the check covered are checked.

Most outputs return `allow` at once. Video and long audio are checked asynchronously. Licenses that
require the talent to approve each output return `escalate` with the output **held** until they
release it. See [Generation checks](/concepts/generation-checks).

## 5. The receipt is embedded in the output

Every decision produces a **receipt**: a JWS signed by Reflections that names the talent, the
license revision and its digest, the output's SHA-256, the obligations and the decision. You embed
it in the output's C2PA manifest as the `ai.reflections.license` assertion. A distribution
platform, a journalist or the talent can verify it, by manifest, by file, or by receipt ID, and
read its live status. See [Provenance](/concepts/provenance).

## 6. Consent can narrow at any time

A talent can revoke a license, suspend it during a dispute, or withdraw a facet. A **revocation**
stops new checks at once, voids pending and held work, terminates live sessions within seconds,
and tells you what to do with outputs already released. Your platform acknowledges that it
complied. See [Revocation](/concepts/revocation).

## 7. Usage is reported and reconciled

Licenses that carry compensation are settled from **usage records** your platform reports,
reconciled against Reflections' own record of checks and generations. Monthly **statements** show
what is owed. See [Usage and settlement](/concepts/usage-and-settlement).

## Who decides what

| Decision | Made by |
| - | - |
| What a license allows | The talent or their representative, by signing |
| Whether a license or a new revision is accepted | The licensee, on the hosted acceptance page |
| Whether a request is covered | Reflections, against the signed revision |
| Whether an escalated request may proceed | The talent, a representative, or Reflections trust and safety for platform licenses |
| Whether an output is delivered | Reflections' generation check, and a reviewer when the license holds outputs |
| Whether consent is withdrawn | The talent, always. A representative with `revoke` can also revoke one license |

No live-mode endpoint can sign, accept or widen a license. A license request asks; only a
signature on the talent's side grants.

## Related

<Columns cols={2}>
  <Card title="Parties" icon="users" href="/concepts/parties">
    Talent, representatives, licensees, platforms and end users.
  </Card>

  <Card title="What we enforce" icon="scale-balanced" href="/concepts/what-we-enforce">
    Checked terms, recorded terms, and assurance levels.
  </Card>
</Columns>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.