Skip to main content
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

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