> ## 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.
# Conformance plan
> Proposed integration cases for production readiness. A hosted conformance runner is not yet available.
Recorded production acceptance covers the fictional [sandbox](/sandbox) and three
[live account/license reads](/api-reference/introduction#test-and-live-mode). The initial live
image code is deployed; signing activation and production acceptance remain separate.
There is no hosted conformance runner or dashboard run control. Follow the [quickstart](/quickstart)
to exercise the supported test check, generation and receipt journey.
The cases below are the proposed production conformance plan. They preserve the requirements for
handling decisions, held outputs, revocations, sessions, provenance, signatures and retries.
Several cases depend on endpoints and automation that the sandbox does not serve yet. Passing
your own tests against the supported subset is not production certification or clearance to use
real talent.
## What you can test today
* Use the fictional talent fixtures to exercise `allow`, `deny` and `escalate` decisions.
* Resolve a supported escalation with the test helper and retrieve the resulting object.
* Submit a fixture artifact, retrieve its signed test receipt and verify the receipt.
* Record request IDs and test your application's handling of errors and retries.
See [Sandbox](/sandbox) for the exact supported endpoints and limits. The current server does not
interpret `metadata.conformance_case` as an instruction to run a test, inject failures or report
a pass. File provenance inspection, hosted webhook delivery, session termination and revocation
orchestration in the tables below remain proposed test capabilities.
## Initial live image implementation
The source implements live check creation and retrieval, inline PNG submission and generation
retrieval, public receipt retrieval, and JSON verification. This is a bounded image path: one
owned license, text inputs totaling at most 64 KiB, commercial advertising or branded content,
exact signed channels and territories, one candidate, and `on_escalate: "deny"`. Output submission
requires the declared provider and model and one still PNG of at most 7 MiB with its exact SHA-256.
See the [integration guide](/guides/image-and-video-platforms#initial-live-image-implementation).
Local source and regression tests are separate from these required production observations:
| Boundary | Evidence required before calling the journey accepted |
| - | - |
| Deployment | The admitted schema and worker/web fleet run the same qualified source |
| Consent | A newly signed license explicitly grants `externalCreation: "images.v1"` and `externalCreationPostRevocation: "retain"` within the selected scope |
| Signing | Protected operator activation uses the published key after its full 30-day publication interval, with fresh key and release evidence |
| Request evaluation | An authorized provider run evaluates the bound request; pending `409` retries use the same body and key without another paid start |
| Exact output and release | The submitted PNG matches the judged and released bytes; POST replay stays `202`; GET is `checking` or `held` while pending, and only actual talent release yields `released` / `allow`; denied or expired output remains private |
| Receipts | An independent client verifies the check and final generation receipts and current use status; no private metadata appears in the public projection |
| Retention and processing | Private details return `404` after their window; local purges work; supplier agreements and processing settings separately support upstream claims |
| Partner behavior | A client built from the public docs keeps clean output private until `released` and `decision: "allow"`, handles denial and expiry, and obeys signed obligations |
The complete set of production observations has not been established for the initial live image journey.
Publishing a verification key, passing local tests or completing sandbox examples does not
establish them. No upstream account-level zero-data-retention guarantee has been verified.
Live lists, cancellation, withdrawal, revocation feeds, files, video, OAuth and webhooks remain
unsupported. The broader cases below continue to describe planned conformance coverage.
## Proposed case IDs and Standard requirements
Each case has an ID that starts with `CT-`, such as CT-CHK-01. The last column of each table
names the numbered requirements of the [Talent License Protocol](/standard/conformance) that the
case would exercise, which start with `TLP-`, such as TLP-DEC-4. References to “the suite” in these
tables describe the proposed runner.
## Checks
| ID | What it does | What passes | Standard requirements |
| - | - | - | - |
| CT-CHK-01 | Checks an image use of Maya Okafor, then generates | The check comes before any generation and carries every input your pipeline gives the model, `execution.provider`, `execution.model` and an `end_user.id` that is not an email address. | TLP-DEC-4, TLP-DEC-26, TLP-USE-1, TLP-PRV-1 |
| CT-CHK-02 | Checks a use of Iris Calder, who has no license | No generation is submitted and nothing is delivered. | TLP-DEC-2, TLP-DEC-5 |
| CT-CHK-03 | Checks a use of Dev Marlow, whose posture is `prohibited` | No generation is submitted, nothing is delivered and no license request is sent. | TLP-DEC-2, TLP-DEC-5 |
| CT-CHK-04 | Escalates with `rfl_test_escalate`; the suite allows it after 60 seconds | Nothing is generated before `check.resolved`. Polling, if any, is no faster than every 5 seconds. Generations follow under the same check. | TLP-DEC-6 |
| CT-CHK-05 | Escalates; the suite lets it expire, so the check ends `denied` with `hold_expired` | Your endpoint answers `check.resolved` with a `2xx`. No generation is submitted. | TLP-DEC-2, TLP-DEC-6 |
| CT-CHK-06 | Sends `rfl_test_escalate` from a surface you marked interactive | The check carries `on_escalate: "deny"`. No generation is submitted. | TLP-DEC-19 |
| CT-CHK-07 | Escalates, then the harness reports that the user left | The check is cancelled and its `status` is `cancelled`. | None; this case tests Talent API behavior |
| CT-CHK-08 | Allows a check without `reuse`, then the harness edits the prompt | A new check with the edited inputs comes before any generation of the edited request. | TLP-DEC-4, TLP-DEC-26 |
| CT-CHK-09 | Names Maya Okafor and Iris Calder in one prompt | No generation is submitted and nothing is delivered. | TLP-DEC-2, TLP-DEC-5 |
## Generations
| ID | What it does | What passes | Standard requirements |
| - | - | - | - |
| CT-GEN-01 | Generates four candidates under one check | Four generations with distinct `candidate_index` values, correct `sha256` values, and no `artifact_digest_mismatch`. Each comes before its output is delivered. | TLP-DEC-9, TLP-OBL-4 |
| CT-GEN-02 | Forces `prohibited_custom_term` with `rfl_test_rule_violated` | The output is never delivered. | TLP-DEC-9 |
| CT-GEN-03 | Makes an asynchronous result with `rfl_test_async` | Nothing is delivered before `generation.allowed`. The output is delivered after it. | TLP-DEC-9 |
| CT-GEN-04 | Leaves a rule unchecked with `rfl_test_unchecked` | The output is delivered with its receipt embedded. | TLP-OBL-10, TLP-C2PA-1 |
## Holds
| ID | What it does | What passes | Standard requirements |
| - | - | - | - |
| CT-HLD-01 | Generates Jonah Reyes, whose license holds every output; the suite releases it | No clean output is delivered while it is `held`. After `generation.released`, it is delivered with its receipt embedded. | TLP-DEC-10, TLP-OBL-5, TLP-OBL-6, TLP-OBL-10 |
| CT-HLD-02 | Holds an output; the suite declines it, so it ends `denied` with `review_declined` | The output is never delivered. | TLP-DEC-9, TLP-DEC-10, TLP-OBL-5 |
| CT-HLD-03 | Holds an output; the suite lets it expire, so it ends `expired` with `review_expired` | The output is never delivered. | TLP-DEC-10, TLP-OBL-5 |
## Revocations
| ID | What it does | What passes | Standard requirements |
| - | - | - | - |
| CT-RVK-01 | Allows a check with a `reuse` window, then revokes Maya Okafor's license | No generation is submitted under the window after `effective_at`. The acknowledgement lists every required action and arrives before `acknowledge_by`. | TLP-RVK-7, TLP-RVK-8, TLP-RVK-12 |
| CT-RVK-02 | Revokes a license without sending the webhook | Your platform reads the feed with `after` within 60 seconds of `effective_at`, and acknowledges before `acknowledge_by`. | TLP-RVK-7, TLP-RVK-12 |
| CT-RVK-03 | Withdraws a facet that has a copy at a provider | The acknowledgement includes `delete_provider_copies` and a `deleted_copies` entry for the copy's `external_id`. | TLP-RVK-10, TLP-RVK-12 |
| CT-RVK-04 | Revokes for cause with `post_revocation.policy: "withdraw"` | Released outputs are withdrawn before `withdraw_by`, and an acknowledgement listing `withdraw_outputs` arrives before `withdraw_by`. | TLP-RVK-11, TLP-RVK-12 |
## Sessions
These cases apply when you run sessions.
| ID | What it does | What passes | Standard requirements |
| - | - | - | - |
| CT-SES-01 | Runs a three-minute session in Maya Okafor's voice | The token is renewed at least every 60 seconds. Audio windows are no longer than 15 seconds and cover the generated speech. A transcript sample follows each turn. | TLP-DEC-14 |
| CT-SES-02 | Sends `rfl_test_terminate` in a transcript sample | The session is ended within 1 second of the `deny`, and no sample or renewal follows. | TLP-DEC-14 |
| CT-SES-03 | Revokes the voice license during a session | The session is ended within 1 second of `session.terminated` on the stream, and no renewal follows. | TLP-DEC-14, TLP-RVK-9 |
| CT-SES-04 | Starts a session for Jonah Reyes, whose license holds every output | The `denied` session is not retried, and no sample is sent. | TLP-DEC-2, TLP-DEC-5 |
## Provenance
| ID | What it does | What passes | Standard requirements |
| - | - | - | - |
| CT-PRV-01 | Verifies the delivered file from CT-CHK-01 | `result` is `verified` and `method` is `manifest`, with `assertion_present` and `signature_valid` both `true`, and your platform as `signer`. | TLP-OBL-10, TLP-C2PA-1, TLP-C2PA-2, TLP-C2PA-5 |
| CT-PRV-02 | Reads the same manifest | It has a `c2pa.actions` assertion with a `c2pa.created` action whose `digitalSourceType` is `http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia`. | TLP-C2PA-4 |
## Webhooks
| ID | What it does | What passes | Standard requirements |
| - | - | - | - |
| CT-WHK-01 | Sends a correctly signed event | Your endpoint answers with a `2xx` within 10 seconds. | TLP-SEC-7 |
| CT-WHK-02 | Sends an event with a wrong signature | Your endpoint answers with a non-`2xx` status and acts on nothing in it. | TLP-SEC-7 |
| CT-WHK-03 | Sends an event whose `webhook-timestamp` is more than 5 minutes old | Your endpoint answers with a non-`2xx` status. | TLP-SEC-7 |
| CT-WHK-04 | Sends an event with two signatures, only the second valid, as during a secret rotation | Your endpoint accepts it. | TLP-SEC-7 |
| CT-WHK-05 | Delivers the same `check.resolved` twice | One generation per candidate, and no `generation_already_submitted`. | TLP-SEC-8 |
## Retries
| ID | What it does | What passes | Standard requirements |
| - | - | - | - |
| CT-IDM-01 | Withholds the first response to a check for 15 seconds | The retry carries the same `Idempotency-Key`, and only one check exists. | TLP-GEN-4 |
| CT-IDM-02 | Answers the first generation with `500 internal_error` | The retry carries the same key. One generation exists for the candidate, and no `generation_already_submitted` is returned. | TLP-GEN-4 |
| CT-IDM-03 | Answers checks with `503 service_unavailable` for two minutes, for a prompt that names Maya Okafor and for a request that names no one and carries a reference image of her | Nothing is generated for either until a check allows it. Retries carry the same key and wait for `Retry-After`. | TLP-GEN-4, TLP-DEC-32, TLP-DEC-33 |
| CT-IDM-04 | Answers a check with `429 rate_limited` and `Retry-After: 2` | The retry waits at least 2 seconds and carries the same key. | TLP-GEN-4, TLP-SEC-10 |
## Human checks in the plan
The proposed suite would not see your interface. Your team must also check that you show `reasons[].sentence`, that
the disclosure label is visible, that previews carry the draft mark, or that you report usage on
time. Your team signs those off on the [production checklist](/production/checklist).
## Production access
Create a live key in the [dashboard](https://app.reflections.ai/developers/keys) to read your own
account and licenses; these reads do not require passing the proposed conformance suite.
Live checks, output submission and receipts have source implementations with the limits above.
They still require signing activation and production acceptance evidence; the proposed cases do
not enable them or authorize real talent use.
These cases map intended evidence to the requirements in their last column. The
[Standard's conformance page](/standard/conformance) lists every platform requirement, including
those no case tests.
## Related
Requirements to prepare for a future live integration.
The supported endpoints, talent fixtures and test inputs.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.