Check Responses storage flags against the actual data-control route

Replace one broad privacy label with a concrete route

An application can emit store:false while a reviewer still lacks evidence about the effective project or an enabled feature’s temporary state. The useful decision is whether a particular request route satisfies a stated storage requirement, rather than whether a dashboard carries a reassuring label.

This guide concerns the OpenAI /v1/responses endpoint and official documentation checked on October 27, 2026. It adds feature-specific decisions to the sensitive request-data guide. It does not evaluate an account, recommend a provider, or determine compliance. Use fabricated text for the proposed review; no API request is needed to understand the distinctions.

Distinguish request storage from effective project controls

The official data-controls documentation separates application state from abuse-monitoring logs. It describes standard Responses application-state retention as at least 30 days when stored, subject to exceptions. ZDR changes store to effective false; MAM and ZDR require approval and can be configured at organization and project levels.

Consequently, an outbound false value does not prove approved Zero Data Retention. Identify the effective project, inherited or overridden setting, and applicable feature limitations. Keep that evidence outside the prompt: a string such as “ZDR project” in application metadata is merely your application’s assertion.

The review packet should name the endpoint and intended feature set precisely. Audio, files, caching, hosted tools, and third-party destinations have additional considerations; they are outside this narrow text-only worksheet. Adding one later requires another review, rather than inheriting the original decision.

Background mode changes the storage question

The current background-mode guide says ZDR-project background requests run with store=false while response data is temporarily stored on disk for roughly ten minutes for asynchronous execution and polling. Do not translate that into “nothing touches disk,” or treat roughly ten minutes as an independently measured deletion deadline.

The same guide makes a specific MAM distinction, including enhanced MAM: foreground requests with omitted or true store follow standard retention. Background responses persist beyond the polling period only with explicit store=true; omitted or false uses the temporary polling period. Therefore omission has different documented consequences in those two modes.

A workflow forbidding any temporary provider disk state cannot accept that background behavior merely because store is false. A different workflow may explicitly permit the documented polling state. That is a requirement decision by the responsible owner, not an automatic permission created by the API accepting a request.

Give Conversation state its own lifecycle decision

The Conversation-state guide says Response objects are saved for thirty days by default and that false disables that response-storage behavior. It separately states that Conversation objects and their items do not have that thirty-day TTL; items from an attached response persist without it.

Do not infer a Conversation’s expiry from an individual response flag. Record whether the route attaches a Conversation, who owns its lifecycle, and which documented deletion process and authorization apply. A request template change does not itself remove previously persisted items. If your requirement forbids persistent conversation state, leave that feature out rather than assuming a flag will erase it.

Use a proposed route matrix with explicit requirements

Invent workflow Cedar-Labels, processing only fabricated issue descriptions. Its example policy requires explicit store:false, forbids persistent Conversations, and permits background polling state only with a separately approved exception. These are invented operating rules, not OpenAI requirements or customer obligations. Every row below is UNRUN.

The permitted counterpart matters: a documented exception can make the background proposal acceptable to this invented policy. The matrix does not assert that any real account is eligible, configured, or observed behaving this way.

Ask each evidence source to prove only its own claim

A proposed local recorder should capture a sanitized request description: route identity, endpoint, mode, whether store was absent or explicitly false, and whether Conversation state was requested. Have another reviewer compare those records with prewritten matrix outcomes. Do not collapse omission and false into the same value before checking the selected rule.

That stub would establish outbound-field behavior only. Separately request authorized administrative evidence of the effective project controls, the responsible owner’s storage exception, and current documentation for the exact feature. Treat missing evidence as unresolved. This article grants no permission to inspect an account, expand scopes, or run a real retention experiment.

Version the route contract and review it when a fallback, project, adapter, or background option changes. Keep secrets, full prompts, response contents, and raw account identifiers out of shared evidence. Record requirements and limitations accurately instead of advertising a global no-storage guarantee.

All matrix and recorder checks are UNRUN; no model request, API call, file upload, account inspection, or deletion operation occurred. Boundary is a prelaunch commercial model router with planned request-path policies. It does not currently certify provider retention, grant ZDR eligibility, or implement the data-control verification described here.