Data-retention exhibit

Version: 2026-08-02 (effective: not yet in effect)

DRAFT — under review, not yet in effect. This exhibit is published for
stakeholder review and is not yet a binding commitment.

ProsGrow Serving — Data Policy (DRAFT)
======================================

1. Scope
--------
This exhibit describes how ProsGrow Serving handles the content of API requests
("Customer Content": prompts, system prompts, messages, tool-call arguments and
results, and model completions) submitted to the OpenAI-compatible inference
API, and what the platform retains for billing and operations. The policy below
applies UNIFORMLY to every model on the platform.

2. Data policy (applies to all models)
---------------------------------------
  * ProsGrow does not train on your data — Customer Content is never used to
    train, fine-tune, evaluate, or improve any model.
  * No durable retention — prompts and completions are processed transiently and
    are not durably retained after the response is returned.
  * Processing region: United States.

This is the draft policy under review; it is not yet a binding commitment.

3. Durable storage: how the no-retention property is enforced
-------------------------------------------------------------
Customer Content is processed in memory for the sole purpose of generating the
requested completion and is never committed to durable storage:

  * no prompt or completion text is written to any database, log file, trace,
    APM system, metrics series, object store, or backup;
  * error messages and gateway logs are scrubbed so that backend errors
    cannot echo request content into an operational record;
  * this property is asserted end to end by an automated smoke test that greps
    the real gateway logs for the probe's own prompt and completion text; the
    test runs on every deploy and a failure blocks the deploy.

Transient processing: serving a request necessarily means holding it in memory.
Transient token and cache representations of a request may remain in volatile
memory after the response is returned, until they are evicted, the process
restarts, or the cache is reset. ProsGrow writes none of that state to disk, and
it does not survive a restart. This is why the policy states "no DURABLE
retention" rather than an unqualified "zero data retention".

4. Metadata retained (billing ledger)
-------------------------------------
For each request the platform retains ONLY the following metadata, in an
append-only billing ledger located in the United States:

  * organization identifier and API key alias (never the secret key);
  * model slug and the pinned served-artifact identity (image digest and
    manifest hash) that produced the response;
  * prompt and completion TOKEN COUNTS (integers, not text) and the computed
    cost in USD at the published per-token price;
  * HTTP status code, streamed flag, and request start/end timestamps;
  * the caller-supplied Idempotency-Key, used exclusively to deduplicate
    retried requests so a network retry is never double-billed.

5. Enforcement (defense in depth)
---------------------------------
The section 2 commitment is enforced in the serving stack itself, not by policy
alone:

  * body logging is disabled at the gateway source and asserted at process
    start — a misconfiguration cannot silently re-enable it;
  * a process-wide log-record scrubber redacts message bodies and
    credential-shaped values (API keys, bearer tokens) before any log record
    is constructed, covering every logger and handler in the process;
  * automated tests and smoke checks assert end-to-end that request and
    response text never appears in captured logs.

6. Data location
----------------
Under the draft policy in section 2, inference processing and all retained
metadata remain within United States datacenters for every model. No Customer
Content or metadata is transferred outside the US. This is part of the draft
policy under review and is not yet a binding commitment.

7. Compliance boundaries
------------------------
ProsGrow Serving does not sign Business Associate Agreements (no BAA) and is
not HIPAA-eligible; do not submit protected health information. A Data
Processing Addendum (DPA) is available on request.

8. Verification
---------------
Customers may request a walkthrough of the enforcement mechanisms above via
support. This exhibit is versioned with the serving stack and republished when
the stack changes.