Skip to main content
Composo stores the content you send so that evaluations are reviewable: you can open a trace, see what was scored, and track quality over time in Insights. Where that is not acceptable — a contract that forbids a third party holding the data, a regulated workload, a single strict end-client — you can turn it off. Retention is controlled in two places, and the more restrictive of the two always wins.

Account-level

Zero data retention can be enabled for your whole account. Contact your Composo representative to turn it on. Once enabled, every request from every API key on the account is treated as zero retention, and no per-request setting can loosen it.

Per-request

Requires composo 0.4.0 or later (pip install --upgrade composo). On earlier versions the parameter is not accepted by the client. The REST endpoints accept it regardless of SDK version.
Set data_retention on an individual evaluation to restrict that request only:
data_retention is available on evaluate() and evaluate_trace(), and on the /reward and /trace endpoints. If you omit it, nothing changes: older SDKs and calls that never set it behave exactly as before.

Values

Requests sent with "none" do not appear in Insights. There is no stored evaluation for the dashboards to aggregate, so those requests contribute nothing to score trends, failure rates or criteria breakdowns. You still receive the score in the API response — if you need to track quality for these requests, record the returned score in your own system.

Defaults and precedence

  • Omitting data_retention means "standard". An absent value never stops data being retained.
  • The account setting and the request value are resolved most-restrictive-wins. A request can ask for "none" on a standard account, but a request asking for "standard" on a zero-retention account is still treated as "none".
This means a per-request value can only ever tighten retention. If you set it wrongly, you over-protect — you never accidentally store something you meant to withhold.

Serving multiple end-clients

The common case for the per-request value is reselling Composo to your own customers, where some of them permit storage and some do not. Set data_retention="none" on the calls belonging to the strict clients and leave the rest at the default.
There is no per-client configuration and no dashboard view of which requests were retained. The value is chosen by the calling code on every request, so a call site that omits it stores content. If you serve clients on different terms, route all Composo calls through a single wrapper that sets the value from your own client record, rather than setting it at each call site.

What is not yet supported

  • Deleting content already stored. Retention applies from the moment a request is made; it does not remove history. If you need existing content for a particular end-client removed, contact support — it is a manual operation.
  • Time-limited retention. Only “store it” and “store nothing” exist today. A fixed-window tier (for example, 30 days) is not yet available.
  • Monitoring without content. There is currently no mode that withholds your content while still showing scores in Insights. Zero-retention requests are absent from the dashboards rather than redacted within them.