Skip to main content
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 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. 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 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 specifies. Because unknown types are unmet (TLP-OBL-2), 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.

Obligations

Every obligation, explained with examples.

Versions and changes

How registry additions are published.