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

# Production checklist

> Planned production requirements, grouped by area. Live access currently supports account and license reads.

The Talent API serves the fictional [sandbox](/sandbox) and three
[live account/license reads](/api-reference/introduction#test-and-live-mode). Start with the
[quickstart](/quickstart) for the supported test check, generation and receipt journey. There is
no hosted conformance runner.

This checklist records the requirements for a future live integration. Work through it with the
people who own each area as those capabilities become available. Case IDs refer to the
[proposed conformance cases](/production/conformance), not tests currently run by Reflections.
Signing off this list does not enable live checks or output submission, or authorize real talent use.

## Keys and access

| Requirement | Guide | Case |
| - | - | - |
| Secret keys live only on your servers, in a secret manager, never in a client or a repository. | [Security](/production/security) | |
| Each service uses a restricted key with only the scopes it needs. | [Security](/production/security) | |
| You can rotate a key without downtime, and you have done it once. | [Security](/production/security) | |
| `Reflections-Account` is set from your own record of which licensee a user acts for, never from user input. | [Security](/production/security) | |
| You handle `connection.revoked` by stopping checks for that licensee. | [Connection revoked](/api-reference/webhooks/connection-revoked) | |

## Checks

| Requirement | Guide | Case |
| - | - | - |
| Every request that names a talent, matches the name index, or sends a reference or voice sample is checked before it is generated. | [Resolve talent](/build/resolving-talent) | CT-CHK-01 |
| The check carries the request the model receives: system text, rewritten prompt, references, model. | [Bind the request](/build/binding-the-request) | CT-CHK-01 |
| A changed request gets a new check. | [Bind the request](/build/binding-the-request) | CT-CHK-08 |
| `end_user.id` is an opaque platform ID, never an email or a name. | [Privacy modes](/build/privacy-modes) | CT-CHK-01 |
| On `deny`, nothing is generated and the user sees `reasons[].sentence` as written. | [Decisions](/concepts/decisions) | CT-CHK-02, CT-CHK-03 |
| A `license_request` remedy is offered only where your product supports requesting licenses. | [Request a license](/api-reference/license-requests/request-a-license) | |
| Requests naming several talent are decided for all of them. | [Multi-talent requests](/build/multi-talent) | CT-CHK-09 |
| Disambiguation sends `talent` or `exclude_talent` only after the user answers. | [Resolve talent](/build/resolving-talent) | |

## Escalations

| Requirement | Guide | Case |
| - | - | - |
| `escalate` shows a pending state and generates nothing. | [Handle escalations](/build/handling-escalations) | CT-CHK-04 |
| `check.resolved` is handled for `allow`, `deny` and expiry. | [Handle escalations](/build/handling-escalations) | CT-CHK-04, CT-CHK-05 |
| Polling, if used, is no faster than every 5 seconds. | [Handle escalations](/build/handling-escalations) | CT-CHK-04 |
| Checks the user abandons are cancelled. | [Handle escalations](/build/handling-escalations) | CT-CHK-07 |
| Every interactive surface sends `on_escalate: "deny"`. | [Handle escalations](/build/handling-escalations) | CT-CHK-06 |

## Outputs

| Requirement | Guide | Case |
| - | - | - |
| Every output is submitted as a generation, or the sampled share when the obligation says `sampled`. | [Submit outputs](/build/submitting-outputs) | CT-GEN-01 |
| Nothing is delivered until the generation's decision is `allow`. | [Submit outputs](/build/submitting-outputs) | CT-GEN-02, CT-GEN-03 |
| Held outputs stay private; previews carry the draft mark when `draft_watermark` applies. | [Handle escalations](/build/handling-escalations) | CT-HLD-01 |
| `generation.released`, `generation.denied` and `generation.expired` are handled. | [Handle escalations](/build/handling-escalations) | CT-HLD-01, CT-HLD-02, CT-HLD-03 |
| Every `generation_instructions` entry reaches the model. | [Obligations](/concepts/obligations) | |

## Provenance

| Requirement | Guide | Case |
| - | - | - |
| The `ai.reflections.license` assertion is embedded unchanged, signed by your platform's C2PA certificate. | [Embed provenance](/build/embedding-provenance) | CT-PRV-01 |
| The manifest declares `trainedAlgorithmicMedia` in a `c2pa.actions` entry. | [Embed provenance](/build/embedding-provenance) | CT-PRV-02 |
| The disclosure text is shown as written, where its `placement` says. | [Embed provenance](/build/embedding-provenance) | |
| The bytes submitted are the bytes delivered, apart from the manifest. | [Submit outputs](/build/submitting-outputs) | CT-PRV-01 |

## Sessions

Skip this area if you do not run live voice or video.

| Requirement | Guide | Case |
| - | - | - |
| Tokens are renewed every `renew_every`, and output stops when renewal returns `session_not_active`. | [Real-time sessions](/build/real-time-sessions) | CT-SES-01 |
| Samples are sent at the `sampling` rate. | [Real-time sessions](/build/real-time-sessions) | CT-SES-01 |
| Output stops within 1 second of a `deny` sample or `session.terminated`, including queued audio. | [Real-time sessions](/build/real-time-sessions) | CT-SES-02, CT-SES-03 |
| Output never continues past the current token's `expires_at`. | [Real-time sessions](/build/real-time-sessions) | |
| The disclosure is shown for the whole session. | [Embed provenance](/build/embedding-provenance) | |

## Revocations

| Requirement | Guide | Case |
| - | - | - |
| `revocation.created` is verified, deduplicated and queued within 10 seconds. | [Handle revocations](/build/handling-revocations) | CT-RVK-01 |
| The revocation feed is read with `after` at least every 60 seconds if you cache decisions. | [Handle revocations](/build/handling-revocations) | CT-RVK-02 |
| Cached checks, authorizations and reuse windows are purged. | [Handle revocations](/build/handling-revocations) | CT-RVK-01 |
| Provider copies are deleted and listed in the acknowledgement. | [Handle revocations](/build/handling-revocations) | CT-RVK-03 |
| `post_revocation` is applied to released outputs. | [Handle revocations](/build/handling-revocations) | CT-RVK-04 |
| Every revocation is acknowledged before `acknowledge_by`, and someone is alerted when one is not. | [Monitoring](/production/monitoring) | CT-RVK-01 |

## Webhooks

| Requirement | Guide | Case |
| - | - | - |
| Signatures are verified on the raw body, against every `v1` entry, with a 5-minute tolerance. | [Handle revocations](/build/handling-revocations) | CT-WHK-01 to CT-WHK-04 |
| Duplicate deliveries are ignored by event ID, and older `sequence` values are ignored. | [Webhooks](/api-reference/webhooks/overview) | CT-WHK-05 |
| The endpoint answers within 10 seconds and does slow work in a queue. | [Webhooks](/api-reference/webhooks/overview) | CT-WHK-01 |
| A secret rotation has been rehearsed. | [Security](/production/security) | CT-WHK-04 |

## Usage

| Requirement | Guide | Case |
| - | - | - |
| Usage is reported in the units and within the time each `usage_report` obligation names. | [Report usage](/build/reporting-usage) | |
| Rejected records are logged and corrected with `correction_of`. | [Report usage](/build/reporting-usage) | |
| Session usage is reported after each session ends. | [Real-time sessions](/build/real-time-sessions) | |

## Resilience

| Requirement | Guide | Case |
| - | - | - |
| Every retry reuses its `Idempotency-Key`. | [Caching and outages](/build/caching-and-outages) | CT-IDM-01, CT-IDM-02 |
| `503` and timeouts fail closed for any request that names a talent, matches the name index, or carries a reference or voice sample. | [Caching and outages](/build/caching-and-outages) | CT-IDM-03 |
| `429` waits for `Retry-After`. | [Caching and outages](/build/caching-and-outages) | CT-IDM-04 |
| The JWKS is cached and refetched once on an unknown `kid`. | [Security](/production/security) | |

## Privacy

| Requirement | Guide | Case |
| - | - | - |
| A prompt mode is chosen on purpose for each surface: `full`, `redacted` or `withheld`. | [Privacy modes](/build/privacy-modes) | |
| `metadata` carries no personal data. | [Privacy modes](/build/privacy-modes) | |
| Your privacy notice describes what you send to Reflections. | [Privacy](/concepts/privacy) | |

## Operations

| Requirement | Guide | Case |
| - | - | - |
| Request IDs are logged with every call. | [Monitoring](/production/monitoring) | |
| Alerts exist for webhook failures, overdue revocations and `503` rates. | [Monitoring](/production/monitoring) | |
| Your on-call runbook links to [status.reflections.ai](https://status.reflections.ai) and records the monitoring coverage you have confirmed. | [Monitoring](/production/monitoring) | |
| Your team knows how to reach support and what to send. | [Support](/production/support) | |

## Sign-off

| Area | Owner | Date |
| - | - | - |
| Keys and access | | |
| Checks and escalations | | |
| Outputs and provenance | | |
| Sessions | | |
| Revocations and webhooks | | |
| Usage | | |
| Resilience, privacy and operations | | |

Keep the sign-off with your integration's evidence. The hosted conformance suite is not available
yet. Live keys are created separately in the [dashboard](https://app.reflections.ai/developers/keys)
and support only account and license reads. Use the [sandbox](/sandbox) to test the supported
check and output endpoints.


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