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. 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 runs without the authority to put your content anywhere.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.

​
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 the 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.

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