Content custody terms

Status of this document

These are placeholder terms written by the ModelRig team and not yet reviewed by counsel. They are subject to change. They exist so that the consent recorded when you create an account points at a document you can actually read, rather than at an identifier alone. They are offered to design-partner accounts, not as general terms of service.

Do not send protected health information or other regulated data through ModelRig until a BAA or DPA is in place. This service is not offered for regulated data today, and nothing on this page should be read as agreeing to handle it.

Every version of this document has an identifier, and the identifier is stored with your acceptance. The version below is the one in force. If we change these terms materially we will publish a new version and ask you to accept it again; your earlier acceptance is kept as a record of what you agreed to at the time, and is never edited or deleted.

What is stored

There are two separate things ModelRig can keep, and they are governed separately. Telemetry is the metadata about a call: which route and model ran, token counts, latency, cost, cache behaviour, and the hashes that let a result be verified. Content is the text itself: the prompt sent to the model, the raw text the model returned, the parsed result, and any evidence or intermediate artifacts a run produced.

When content custody is on for your organization, content from calls routed through ModelRig is stored in the managed object store under your organization's own prefix, and the metadata rows that index it are scoped to your organization in the database. Bytes go from the SDK to the store directly; they are not written into the database.

Content custody is a per-organization setting with a per-route override. A route configured for zero retention stores nothing at all — no content, no metadata row, no hash. That refusal happens before anything is scrubbed or uploaded, and turning content custody on does not weaken it.

Why it is stored

Stored content is what makes the rest of the product possible. Comparing two models on your own traffic needs the actual inputs and outputs, not summaries. Showing you why a routing decision was made, or why a bill says what it says, needs the run it came from. Screening untrusted content for injection patterns and for personal or health identifiers operates on the text, and the receipt it produces refers back to it.

None of your content is used to train models — ours or a provider's — and none of it is shared with other organizations. Where AI models process your content to grade it or propose improvements, that processing and its limits are described below.

Grading and improvement: AI processing of stored content

When your organization is on the managed path, ModelRig-operated AI models — we call them graders — read stored content to do three things: grade outputs against the grading guide your organization writes, measure how closely the grader agrees with your own reviewers, and propose improvements, such as a revised prompt or a different model for a route. A proposal is a record, not an action: nothing about your routes, prompts, or configuration changes unless a person in your organization — or an automation your organization explicitly enabled — applies it.

Everything this processing produces — grades and their written comments, agreement measurements, and improvement proposals — is stored in your organization like the rest of your content: visible in the console, exportable, and deletable, with the same scoping the database enforces everywhere else.

Grading and improvement calls are served by third-party model providers acting as ModelRig's subprocessors. We use provider API terms under which your content is not used to train their models, we do not use it to train ours, and the current subprocessor list is available on request. Which specific models do the grading is an operational choice ModelRig makes and may change without notice; what you always see is the evidence — every grade's score and comment, and the measured agreement between the grader and your own reviewers, with sample sizes shown.

These processing calls are counted and metered, and the meter is visible to your organization. What, if anything, they cost is governed by the pricing terms in effect for your account.

The same control that turns off content custody turns this off with it: an organization on posture off or metadata (set in account settings — the console or the set_org_settings MCP tool), or a zero-retention route, gives the graders nothing to read. Content you delete is gone for grading and improvement the same as for everything else. Where we hold no content bytes, grading is limited to the scores and metadata your own systems send us.

Screening and masking, and their limits

On the managed path, content passes deterministic detectors for personal and health identifiers before it is stored, and the floor for a detected identifier is redaction. Detector coverage is published per identifier, and detection rates are measured on synthetic test data rather than assumed.

This is screening with published coverage, not a compliance control. Deterministic detectors plus your own dictionary reduce what gets stored; they do not make free text safe, and they are not an audit. That limit is the reason for the paragraph above about regulated data.

Who can reach it

Members of your organization can read your organization's content through the console, and the database enforces that scoping rather than the interface: a request carrying another organization's session returns nothing. There is no public access and no cross-organization access.

ModelRig staff can reach stored content, because the infrastructure credentials that operate the database and the object store can read them. There is no staff-facing interface for browsing customer content, no impersonation feature, and no routine access — but we are not claiming a technical barrier that does not exist. Access happens only to operate the service or to respond to a support request you raise, and today that restriction is a matter of practice rather than something the system enforces or logs per request.

How to turn it off

Your account settings are the one control, reachable two ways. In the console, your account settings page has the organization's capture posture and writes it directly — set it to off to capture nothing, or to metadata to keep hashes only. Through MCP, the set_org_settings tool changes the same posture. There is no deployment environment variable to set: one API key turns everything on, and you dial it back per organization from account settings.

Opting out is per organization and takes effect going forward: new calls stop being captured. It does not retroactively remove content already stored — see below. Opting out also stops grading and improvement from reading stored content, as described in the grading section above.

Retention and deletion

Each stored artifact records the retention horizon intended for it, and the object store's own lifecycle rules are what delete the bytes when that horizon passes. Deletion is therefore a property of the store, not a background job that could quietly stop running.

You can remove content you have already sent us, on request, without asking us. There are two forms and they differ in what survives. Deleting an artifact's content removes the stored bytes and keeps the record of the call — its metadata, its integrity hash, and the date the content was deleted — so you can still prove what ran, that its content was removed, and when. Purging an artifact removes that record too, leaving only an entry saying an artifact with that identifier was purged and when.

Both are irreversible and immediate. There is no grace period, no recycle bin, and no copy we keep aside: when the call returns, the bytes are gone from our store and we cannot restore them. Only an owner of your organization can do either, or a machine key you have explicitly granted the deletion scope — deletion is deliberately the narrowest permission we issue.

Two limits worth stating. Deletion is per artifact today, so there is not yet a single action that erases everything at once — ask us for that and we will do it for you. And an artifact whose content you have deleted cannot be re-uploaded under the same identifier; a later run that produces new content records a new artifact rather than refilling a record you asked us to empty.

Your acceptance of these terms is the one thing that is deliberately never deleted, edited, or overwritten, by anyone including us — it is the record of what you agreed to, and a record that could be altered afterwards would not be worth keeping. It stores your organization, the accepting user, the version of this document, and the time.