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

# Obligations registry

> The registered obligation types, their fields, how each is met, and how new types are added.

This page specifies the registry of obligation types a decision can carry, the fields of each,
what a platform must do to meet it, and how the registry changes.

## Rules for every obligation

An obligation is an object with a `type` and the fields listed for that type. Its `term`, when
present, is the [address](/standard/terminology#addresses) of the license term it comes from.

**TLP-OBL-1.** A platform that proceeds on an `allow` MUST meet every obligation the decision
carries. An obligation applies to every generation and every output made under the decision.

**TLP-OBL-2.** A platform or generation tool that receives an obligation whose type it does not
recognize MUST treat it as unmet, and MUST NOT proceed: it does not generate on a check, and does
not deliver on a generation.

**TLP-OBL-3.** A license server MUST return only obligation types registered in the protocol
version it serves, and only the fields registered for each type. It MUST list the types it can
return in its discovery document's `obligation_types`.

## Registry

The registry for TLP 1.0 is equal to the `ObligationType` enumeration of the Talent API reference.

| Type | Fields | Platform must | License server knows it by |
| - | - | - | - |
| `generation_check` | `required` (`all`, `sampled`), `sample_rate` | Submit outputs as a generation before delivery | Observation: it receives the outputs |
| `hold_until_release` | `reviewer` (`talent`, `representative`, `reflections`) | Deliver nothing until a reviewer releases it | Observation: it holds the release |
| `draft_watermark` | none | Mark anything shown before release as a draft | Attestation |
| `generation_instructions` | `instructions`, `term` | Pass the instructions to the model | Attestation |
| `disclosure` | `level` (`licensed`, `brand`, `scope`), `text`, `placement` (`visible`, `metadata`, `both`) | Label the output | Attestation; the metadata label is observed when a file is verified |
| `attribution` | `text` | Credit the talent where the output appears | Attestation |
| `c2pa_manifest` | none | Embed the receipt in the output's C2PA manifest | Observation when a file is verified |
| `no_training` | `material` (`references`, `voice`, `outputs`) | Train no model on the material | Attestation |
| `delete_material` | `material`, `within` | Delete the material in time | Attestation, such as a revocation acknowledgement |
| `usage_report` | `units` (`outputs`, `seconds`, `characters`, `placements`, `impressions`), `within` | Report usage in time | Observation: it receives the reports and reconciles them |

`within` is an ISO 8601 duration. It is counted from the decision for `delete_material`, and from
the generation's decision or the session's end for `usage_report`.

## Meeting each type

**TLP-OBL-4. `generation_check`.** When `required` is `all`, a platform MUST submit every output as a
generation before it delivers it. When `required` is `sampled`, it MUST submit at least the share
`sample_rate` of outputs, chosen without regard to their content, and MAY deliver the others
without a generation decision.

**TLP-OBL-5. `hold_until_release`.** A platform MUST NOT deliver an output until its generation is
released, as signaled by `generation.released`. `reviewer` names who releases it.

**TLP-OBL-6. `draft_watermark`.** Anything a platform shows before release MUST carry a visible mark,
across the image, frame or player, stating that it is an unreleased draft. A platform MUST NOT show
an unmarked output before release.

**TLP-OBL-7. `generation_instructions`.** A platform MUST include each instruction, as written, in
what the model receives for every generation under the decision, such as in the system text. It MAY
add its own instructions. It MUST NOT drop, shorten or paraphrase these.

**TLP-OBL-8. `disclosure`.** A platform MUST show `text` with the output. With `placement`
`visible`, the text appears where the output is seen or heard. With `metadata`, it travels in the
output's metadata: the receipt in the output's C2PA manifest carries the disclosure obligation and
its text, and meets this placement. An output with no C2PA manifest carries the text in its
format's own description metadata. With `both`, it is in both places. `level` says
what the text discloses: `licensed` that the likeness is licensed, `brand` also who licensed it,
`scope` also the use.

**TLP-OBL-9. `attribution`.** A platform MUST show `text` as a credit wherever the output appears,
in the form the channel allows.

**TLP-OBL-10. `c2pa_manifest`.** A platform MUST embed the generation's receipt in the output's C2PA
manifest, as [C2PA](/standard/interop/c2pa) specifies, before it delivers the output.

**TLP-OBL-11. `no_training`.** A platform MUST NOT use the `material` named (references, voice or
outputs) to train or fine-tune any model, and MUST bind every provider it sends the material to by
the same restriction.

**TLP-OBL-12. `delete_material`.** A platform MUST delete the `material` named, including copies held
at providers, within `within` of the decision that carried the obligation.

**TLP-OBL-13. `usage_report`.** A platform MUST report usage of each output or session in `units`,
to the endpoint the license server documents, within `within` of the generation's decision or, for
a session, of the session's end.

## Adding a type

New obligation types are added only by a published change to the Standard with a new minor
version, as [Versions and changes](/standard/changes) specifies. Because unknown types are unmet
([TLP-OBL-2](#rules-for-every-obligation)), a new type never loosens what an older platform does: it
stops instead.

**TLP-OBL-14.** A proposal for a new obligation type MUST state:

1. the type name, in lowercase `snake_case`, not already registered;
2. what a platform must do to meet it, as testable requirements;
3. its fields, their types and allowed values;
4. the stages at which it can appear;
5. how a license server knows whether it was met: observation or attestation;
6. the license term it comes from.

**TLP-OBL-15.** A registered type MUST NOT be removed or changed in meaning within a major version.
A change in what a platform must do MUST be registered as a new type.

## Related

<Columns cols={2}>
  <Card title="Obligations" icon="book" href="/concepts/obligations">
    Every obligation, explained with examples.
  </Card>

  <Card title="Versions and changes" icon="code-branch" href="/standard/changes">
    How registry additions are published.
  </Card>
</Columns>


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