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

​
What actually holds it up

The selection service holds no database on the request path — no persistent store, no cache, no queue. Records ride in on each request and the in-memory state that holds them lives and dies with that request.This started as an architectural choice for latency and scaling: a stateless service performs no coordination and no lookups. The trust property is a consequence of it, which is why it is stable — removing it would mean giving up the performance property too.
The service’s execution role grants log writing and nothing else. No storage permission, no database permission, no message-queue permission.This is the part worth checking, because it 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 permission boundary. “We do not store your records” is enforced by something that cannot be argued with under deadline pressure.
Gateway-level request/response logging and data tracing are off on the serving stage. Our own 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.
Everything else you send — records[].text, title, task.prompt, recent_prompts — is processed and discarded, never written anywhere.

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

​
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. There is no downstream model call in a selection, so there is no third-party processor to disclose for it.
If we ever add a surface that does send your content to a third party — an in-browser demo that compares two answers, for instance — the provider will be named at the point of action, consent will be per use, and the residual (a provider may retain data where required by law or where its trust-and-safety systems flag a request) will be disclosed rather than glossed. No such surface is live today.

​
What we do not claim

Stated plainly, because a trust page that only lists strengths is not a trust page:
  • No SLA yet. We publish an availability objective and operate against it. A contractual service-level agreement belongs with an enterprise agreement, and we are not offering one before general availability.
  • No compliance certification date. The controls a SOC 2 audit looks for — audit logging, access review, change management, a vendor inventory — are being built and tracked. We are not committing to a 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.