> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nextmoca.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Retention and trust

> What we keep, for how long, what enforces it — and the one field you control that does reach our logs.

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

<AccordionGroup>
  <Accordion title="There is nowhere to write it">
    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.
  </Accordion>

  <Accordion title="The permissions do not allow it">
    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.
  </Accordion>

  <Accordion title="Request and response bodies are not logged">
    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.
  </Accordion>

  <Accordion title="A test proves it, on every build">
    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.
  </Accordion>
</AccordionGroup>

## The one field you control that does reach our logs

<Warning>
  **`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.
</Warning>

Everything else you send — `records[].text`, `title`, `task.prompt`,
`recent_prompts` — is processed and discarded, never written anywhere.

## Retention schedule

| Data                                                           | Retention                                                       | Status                   |
| -------------------------------------------------------------- | --------------------------------------------------------------- | ------------------------ |
| **Your record content**                                        | **Never stored. Never logged.** Zero retention by construction. | Live                     |
| Service logs (metadata only: counts, tokens, latency, outcome) | 14 days                                                         | Live                     |
| Usage telemetry (metadata only)                                | 13 months, then aggregated                                      | With metering            |
| Account records (users, organisations, memberships)            | Life of the account, then a defined deletion window             | With self-serve accounts |
| Ledger entries and invoices                                    | 7 years                                                         | With billing             |
| Audit log                                                      | 7 years for money-moving actions, 2 years otherwise             | With billing             |

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.

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

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