> ## 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. # Revocation > What a revocation cuts, the deadlines a license server and a conformant platform meet, post-revocation policies, and acknowledgements. This page specifies what happens when consent narrows: what a revocation cuts at once, what it leaves, the deadlines each side meets, how released outputs are treated, and how a platform acknowledges that it complied. ## Scope A revocation has a `scope` and `targets`, and takes effect at `effective_at`. | `scope` | What it cuts | | - | - | | `license` | One license | | `facet` | A withdrawn facet, which narrows every license that covers it | | `mandate` | A representative's authority, and the licenses `targets` names | | `talent` | Consent everywhere: every license of the talent | ## What the license server does **TLP-RVK-1.** From `effective_at`, a license server MUST deny every new check and session under the targets with `license_revoked`, and MUST issue no new authorization or session token under them. **TLP-RVK-2.** At `effective_at`, a license server MUST resolve every open escalation under the targets to `deny` with `license_revoked`, MUST deny every held output under them with `license_revoked` and send `generation.denied` for it, so it can no longer be released, and MUST deny any generation submitted later against a check under them. **TLP-RVK-3.** A license server MUST terminate every live session under the targets, pushing `session.terminated` with the revocation's ID on the session stream and as an event. It SHOULD do so within 2 seconds of `effective_at` at the 95th percentile. **TLP-RVK-4.** A license server MUST list the revocation in its revocation feed from `effective_at`, readable oldest first after a cursor, and MUST send `revocation.created`. It SHOULD send the event within 5 seconds of `effective_at` at the 95th percentile. **TLP-RVK-5.** A revocation MUST state its `required_actions` from `stop_generation`, `purge_cached_decisions`, `delete_provider_copies`, `cease_distribution` and `withdraw_outputs`; every copy held at a provider that must be deleted, in `provider_copies`; and an `acknowledge_by` 24 hours after `effective_at`. **TLP-RVK-6.** A license server MUST take the `post_revocation` policy from the license's signed terms, MUST apply `withdraw` only when the revocation is for cause (`for_cause: true`), and MUST update the live status of every affected receipt at `effective_at`. ## Post-revocation policies Released outputs are governed by the policy the talent signed into the license. | Policy | Released outputs | Receipt `use_status` | | - | - | - | | `retain` | Stay usable within their original scope and window | Stays `permitted` until the window ends | | `cease_distribution` | Existing placements stay; no new placements after `effective_at` | `ceased` | | `withdraw` | Taken down by `post_revocation.withdraw_by`. Only for revocation for cause. | `withdrawn` | Unreleased work is void under every policy: pending checks, open escalations and held outputs are denied. ## What a conformant platform does | Action | Deadline | | - | - | | Stop starting generations under the targets | On learning of the revocation, and no later than 60 seconds after it appears in the feed | | Purge cached checks and authorizations for the targets | On learning of the revocation | | Stop live output after `session.terminated` | Within 1 second | | Delete copies listed in `provider_copies` | Before `acknowledge_by` | | Apply `cease_distribution` | No new placements after `effective_at` | | Apply `withdraw` | Before `post_revocation.withdraw_by` | | Acknowledge every required action except `withdraw_outputs` | Before `acknowledge_by`, 24 hours after `effective_at` | | Acknowledge `withdraw_outputs`, when required | Before `post_revocation.withdraw_by` | **TLP-RVK-7.** A platform MUST receive `revocation.created` events. A platform that caches checks, authorizations or decisions MUST also read the revocation feed at least every 60 seconds; the feed is the source of truth and events are the fast path. **TLP-RVK-8.** On learning of a revocation, a platform MUST start no new generation under the targets and MUST discard its cached checks and authorizations for them. It MUST NOT pass a token under the targets to a generation tool after that point. **TLP-RVK-9.** A platform MUST stop output within one second of `session.terminated`, and MUST NOT renew or restart the session. **TLP-RVK-10.** A platform MUST delete each copy listed in `provider_copies`, at its provider, before `acknowledge_by`. **TLP-RVK-11.** A platform MUST apply the revocation's `post_revocation` policy to the outputs it released and still distributes or hosts. **TLP-RVK-12.** Before `acknowledge_by`, a platform MUST acknowledge every action in `required_actions` except `withdraw_outputs`, listing every deleted copy with its `deleted_at`. When `required_actions` includes `withdraw_outputs`, the platform MUST acknowledge it in a later acknowledgement, before `post_revocation.withdraw_by`. It MUST NOT list an action it has not completed. Each acknowledgement adds to the revocation's `acknowledgements`, is an attestation, and is shown on the talent's record. **TLP-RVK-13.** A license server MUST keep a revocation `pending_acknowledgement` until every required action is acknowledged, then mark it `acknowledged`. It MUST mark the revocation `overdue` when either deadline passes first: `acknowledge_by` with an action other than `withdraw_outputs` unacknowledged, or `post_revocation.withdraw_by` with `withdraw_outputs` unacknowledged. It then sends `revocation.overdue` and shows the revocation as overdue on the talent's record. ## Tokens already issued A generation tool verifies tokens offline and cannot learn of a revocation. Exposure after `effective_at` is therefore bounded by token lifetimes: an authorization token expires at most 15 minutes after issue and a session token at most 5 minutes after issue. A platform closes the window sooner by not passing tokens after it learns ([TLP-RVK-8](#what-a-conformant-platform-does)). A generation submitted afterwards is denied ([TLP-RVK-2](#what-the-license-server-does)), so its output is never delivered. ```mermaid theme={null} sequenceDiagram participant T as Talent participant LS as License server participant P as Platform participant G as Generation tool T->>LS: Revoke license LS->>LS: Deny new checks and held outputs LS-->>P: session.terminated within 2 s P->>P: Stop live output within 1 s LS-->>P: revocation.created within 5 s P->>P: Stop generating, purge caches P->>G: Delete provider copies P->>LS: Acknowledge within 24 h P->>LS: Acknowledge withdraw_outputs by withdraw_by ``` ## Suspension A suspension pauses a license, such as during a dispute. It is not a revocation, creates no revocation object and needs no acknowledgement. **TLP-RVK-14.** While a license is `suspended`, a license server MUST deny checks under it with `license_suspended`, terminate its sessions and refuse their renewal. Held outputs stay held, and released outputs are unaffected. Checks are decided again normally after `license.resumed`. **TLP-RVK-15.** A platform that caches decisions MUST discard them for a license when it receives `license.suspended`. ## What revocation leaves A receipt signed before `effective_at` stays valid evidence that the decision was made under a license in force. Its live status, not its signature, says what use is permitted now ([Receipts](/standard/receipts#live-status)). ## Related The feed, purges, provider copies and acknowledgements in practice. The revocation feed in the Talent API. The acknowledgement call. The event that starts the clock. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.