ProsGrow ProsGrow ProsGrow AI · Inference

Trust, limits & data handling

What we never store, what stays in memory while a request is served, where processing happens, published pricing, and the platform's operational limits.

ProsGrow Data Policy

DRAFT — under review, not yet in effect. This data policy is a draft under review and is not yet a binding commitment. It is published for stakeholder review and will take effect once finalized.

This policy applies to every model on the platform:

How we enforce the no-storage property. We never write your prompts or completions to logs, traces, metrics, or the billing database. The billing ledger is metadata-only and append-only; body logging is disabled at the gateway source and a process-wide scrubber redacts anything body- or credential-shaped before a log record is even constructed. An automated smoke test asserts this against real gateway logs on every deploy. While a request is being served, transient token and cache representations of it may remain in volatile memory until they are evicted or the cache is reset; we write none of that to disk.

What we store durably (per request)

  • Organization identifier and API key alias (never the secret key)
  • Model slug and served-artifact identity (image digest, manifest hash)
  • Prompt / completion token counts and computed cost (USD)
  • HTTP status code, streamed flag, request start/end timestamps
  • Your Idempotency-Key (retry deduplication)

What is never written to durable storage

  • Prompt text, system prompts, or message content of any kind
  • Model responses / completion text
  • Tool-call arguments or tool results
  • Training or fine-tuning on your data — never
  • API key secrets (shown once at creation, then unrecoverable)
  • Payment card numbers

Full statement: data-retention exhibit.

Data processing & regions

Under the draft data policy above, processing and all metadata we store are in the United States for every model. This is part of the draft policy under review and is not yet a binding commitment.

Pricing & served models

Per-model pricing and the full model catalog are shown in the console once you sign in. Inside the console you can enable models for your organization directly (confidential-tier models require an access request), and custom / private model deployments (bring-your-own weights) are arranged per engagement.

Rate limits — 429 / Retry-After semantics

When the platform sheds load, requests return HTTP 429 with a Retry-After header (seconds). A request rejected with 429 was not executed and not billed. Honor the header with exponential backoff and reuse the same Idempotency-Key on the retry — reusing a key prevents double-billing of a retried request. Per-key monthly token quotas and hard per-organization budgets are enforced server-side.

What key reuse does and does not do. The idempotency key guarantees a retried request is billed at most once; it does not recover a lost response. If a request completed but its response never reached you (a client timeout or dropped connection), it is billed and — because we store zero completion data — its output is gone; retrying the same key returns HTTP 409 (idempotency_key_reused) with a machine-readable idempotency_state of committed and a receipt (cost + token counts), never the original body. A key whose request is still executing returns 409 with idempotency_state = in_flight: wait, then look the key up at GET /v1/idempotency/{key}?model=… to learn the outcome. A request that genuinely failed writes no billable row, so the same key can be safely retried. 5xx responses are never metered.

Uptime, SLA & support

Availability is measured as the ratio of successful inference requests over 5-minute buckets; a timeout or a zero-byte (5xx / dropped) response counts as a failure, not a success. We monitor this signal internally to identify and investigate service interruptions.

Preview: this is a target, not yet a contractual commitment. The committed availability percentage, the measurement window (calendar-month vs rolling), the service-credit tiers, and the claim process are being finalized and are set by ProsGrow, not derived by engineering. Until they are published here as a commitment, treat the figure below as an operational target. A signed order form or the serving terms govern any binding SLA.

Subprocessors

We use no analytics, advertising, or data-broker subprocessors. Whether a subprocessor list is published, and what it names, is being finalized — see /legal/subprocessors. The serving terms of service and Data Processing Addendum are linked below.

Compliance posture

Security & disclosure

This page is versioned: 2026-08-02 (effective: not yet in effect).