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

# Data handling and retention

> Your data is yours

Retention differs by what the data is. Uploaded rows go when the job ends, predictions last
1 hour, a fitted context lasts 7 days, and three records are never purged.

Below is each line, and what enforces it.

## What is kept, and for how long

| Data                                | Retained                               | Deleted by                                                                      |
| ----------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------- |
| Uploaded rows — training and scored | Until the job reaches a terminal state | Purged in the same transaction that ends the job, on failure as well as success |
| Scored predictions                  | 1 hour after completion                | A sweep every 15 minutes                                                        |
| Evaluation metric                   | 1 hour after completion                | The same sweep                                                                  |
| Fitted-context artifact             | 7 days                                 | Status flips to `expired` on an hourly sweep                                    |
| Jobs ledger                         | Indefinitely                           | Nothing                                                                         |
| Usage buckets                       | Indefinitely                           | Nothing                                                                         |
| API keys, including revoked ones    | Indefinitely                           | Nothing                                                                         |

A lapsed context stops working the moment its status flips, and a predict against it raises
`fitted_context_expired`. Its artifact bytes sit under a `contexts/` key, which the staging
purge refuses by design and the 1-day staging lifecycle rule does not cover.

## Uploaded rows

The uploaded payload is deleted the moment a job reaches a terminal state, and failure is a
terminal state. A job that dies with `worker_oom` purges its rows exactly as a successful one
does.

Two backstops sit behind that, for the case where a job never becomes terminal at all:

* **A 4-hour expiry** on the staged payload, swept every 15 minutes.
* **A 1-day lifecycle rule** on the storage bucket, which removes the bytes either way.

## Scored predictions are kept for one hour

Predictions are output derived from your rows. They are retained for one hour after the job
completes, so that the SDK can read them back.

A result over 512 KiB goes to object storage and comes back as a presigned URL. That object is
removed by the 1-day lifecycle rule, not by the one-hour sweep.

Reading a result after the hour raises `training_ref_expired`. The job record survives; the
data behind it does not.

## What is kept indefinitely

"Only hashes and counts" is not exact enough. The jobs ledger is never purged, and each row
holds:

* **Column names** — the target column on every job, and the feature column names on every
  fitted context.
* **Counts** — rows and columns per job.
* **Job metadata** — task, engine version, duration, status, and the content hash of the input.
* **The full error envelope** of a failed job, including its `problem` and `cause` strings.

No cell values are stored on these records. Column names are, and there is no way to redact
them.

## Encryption

In transit, uploads and API calls are HTTPS. At rest, the buckets are configured with
provider-managed AES-256 default encryption and block all public access.

Both are provisioning-time bucket settings, not something the request path applies per object,
and neither is visible in the console.

Customer-managed keys are not built. There is no client-side or envelope encryption anywhere in
the production path — the SDK uploads gzipped JSON to a presigned URL.

## The weights are frozen

No gradient update ever runs on anything you send. The model was pretrained once, before your
data existed, and nothing you upload changes a weight.

Your table is read as context while the job runs, then purged with the rest of the payload.
[How Hollerith works](/concepts/how-hollerith-works) covers why that is the whole mechanism.

## What is not built

* **Self-hosted or in-VPC deployment.** Hollerith runs in our infrastructure only.
* **Customer-managed encryption keys.**
* **Deleting a fitted context on demand.** No endpoint exists. A context expires 7 days after
  the fit that created it and cannot be removed sooner.

This page claims no compliance certification. Ask your Hollerith administrator what your
deployment holds rather than inferring it from anything here.

## Next

* [Authentication](/authentication) — key scope, rotation, and revocation
* [Usage and billing](/account/usage-and-billing) — what the retained counts are used for
* [The fitted context](/concepts/fitted-context) — the 7-day artifact and its expiry