Skip to main content

​
The short version

Your record content is never stored and never logged. Not for a retention window, not in a debug log, not in a cache. On the selection path it exists in memory for the duration of one request and is gone when the response is written. The one exception is a capture you ask for in writing, described below. That is not a promise about our operational discipline. It is a property of how the service is built, and the mechanisms that hold it are listed below so you can check them rather than take our word. One feature does send content further, and it is not the selection path: the Answer Lab in the signed-in console. It is described in full below, and it is the only one.

​
What actually holds it up

The selection path is stateless. Records ride in on each request, exist in memory for the duration of that request, and are gone once the response is written. Nothing is persisted between calls.This is not a retention policy applied to a store. There is no store on the request path for a policy to apply to.
Storage is not merely unused on the selection path. It is unavailable to it: the service’s only authority to write content anywhere is the opt-in capture described below, into one private store, for a key whose owner asked for it in writing. For every other destination it has no write authority at all.This is the difference between a policy and a boundary. A future change that tried to add a lookup or a write to the selection path does not fail a code review, it fails at the boundary. “We do not store your records” is enforced by something that cannot be argued with under deadline pressure.
Body logging and request tracing are off. Our logs are structured, metadata-only lines: counts, token numbers, latency, the operating point, the outcome. Not text.Even the engine’s own error strings are reduced to the exception class before they are written, because an exception message can carry a fragment of its input.
A sentinel value is planted in the fields a caller controls, a request is run, and the logs are searched for it. If it appears anywhere, the build fails.An automated proof rather than a promise, and specifically a test that probes the paths we do not already trust, since a test that only exercises the path you are confident about is not a test.

​
The one field you control that does reach our logs

request_id is logged, deliberately. It is your correlation key, and a log that drops it cannot answer “what happened to my request”.It is bounded to 128 characters from [A-Za-z0-9._:-], and anything outside that is truncated and de-fanged before it is written; the response then carries format_metrics.request_id_sanitized: true so you can see it happened.But bounding is not erasure. A legal string under the cap reaches our logs intact. So: put an identifier in request_id. Never record content, never customer text, never a credential, never a URL with a token in it.One consequence worth designing for: because the internal copy is truncated at 128 characters, two ids that differ only past that point are indistinguishable in our logs. Put the part that varies at the front.
Everything else you send to /v1/context/select (records[].text, title, task.prompt, recent_prompts) is processed and discarded, never written anywhere. The Answer Lab in the console is a separate feature and is covered in the note below.

​
Opt-in capture for engine review

At a customer’s written request we can record that customer’s requests and responses for a limited period to review selection quality with them. It is off for every key unless the customer asks, applies only to that key, is stored encrypted in a private store for 30 days, and is never used for anything but that review.

​
Retention schedule

The 13-month telemetry window exists so you can compare this month against the same month last year. It holds counts and token numbers, never content.

​
Data-subject requests are simple here, and that is not an accident

If you receive a deletion or access request covering something you sent us, the answer is short: we do not have it. The only personal data we can hold is account data (who signed up, which organisation they belong to) and that is an account-plane operation entirely disconnected from anything you ever sent to /v1/context/select. There is no payload archive to search, no embedding store to purge, and no derived index that might contain a fragment of a document. Most vendors in this space have to give you a process here. We have to give you a sentence. Content sent to the Answer Lab is one exception. We hold none of it either, but OpenAI may have a copy for up to 30 days, so a request covering it has to reach them too. The other is a key whose owner asked in writing for the engine-review capture: for that key we hold the captured requests and responses for up to 30 days, and delete them earlier on request.

​
Transport and tenancy

  • TLS only. There is no unencrypted path to the service.
  • Credentials are org-scoped and resolved per request. A key resolves to exactly one organisation’s limits and policy.
  • No content leaves the selection path. A selection makes no downstream model call, so there is no third-party processor to disclose for /v1/context/select. The Answer Lab in the console is a separate feature and is covered in the note below.
One surface does send your content to a third party, and it is not the selection path. The Answer Lab in the signed-in console sends the records you supplied and your question to OpenAI, which writes the two answers it shows you. It runs on our OpenAI account, only when you press the button, and is capped at five comparisons and five judge runs per organization per day. OpenAI does not use API content to train its models, and may retain it for up to 30 days for abuse monitoring. The provider is named on the panel itself, not only here.

​
What we do not claim

Stated plainly, because a trust page that only lists strengths is not a trust page:
  • No SLA. We publish an availability objective and operate against it. A contractual service-level agreement is part of an enterprise agreement.
  • No compliance certification. We hold no SOC 2 report and publish no certification date.
  • Metadata is real data. We keep counts, token numbers, timings and outcomes. That is enough to know how much you used the service and roughly how large your requests are. It is not enough to know what they said.