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

# Limits & SLAs

> Payload caps, retention behaviour by plan, and what sovseal does and does not commit to on availability.

This page states what is **enforced in code today**, not what is planned. Where something is not implemented, it says so.

## Payload size limit

* **Maximum ciphertext payload: 256 KB** per replicated chunk (`MAX_PAYLOAD_BYTES = 262_144`).
* Exceeding it is rejected at the edge function with HTTP `413 Payload Too Large`.

<Warning>
  This is a hard cap, and it is smaller than most people assume. If you are batching many memories into one envelope, split them. A single `store_memory` call is far below this limit; bulk replication chunks are the case to watch.
</Warning>

## Rate limits

**There is no rate limiting enforced at the edge function today.** No per-key RPM ceiling, no burst allowance, and no `429` responses are implemented.

Fair-use ceilings on paid plans (Solo 10k, Team 50k, Business 100k monthly operations — see [Billing](/platform/features/billing-and-credits)) are **commercial** soft limits reviewed by a human, not runtime throttles. Crossing one starts a conversation; it does not return an error.

If you are planning a high-throughput workload and need a guaranteed ceiling, raise it before you build — it is not currently enforceable in either direction.

## Retention

Retention is **plan-gated and off by default**. It fails closed: sovseal never deletes memories without an explicit entitlement and configuration.

| Plan                         | Retention behaviour                                                                 |
| :--------------------------- | :---------------------------------------------------------------------------------- |
| **Local**, **Solo**          | **No retention.** Memories are kept indefinitely. Any TTL configuration is ignored. |
| **Team**                     | Per-namespace TTL, configurable **7–365 days**.                                     |
| **Business**, **Enterprise** | TTL, plus a persistent retention audit log at `~/.sovseal/retention-audit.log`.     |

Where TTL is active:

* Each memory is stamped with `expires_at` at write time. Reinforcing a memory **resets its TTL window**, so an actively restated fact is not purged on its original deadline.
* A local sweep runs every 24 hours and hard-deletes expired vectors.
* The cloud purge runs daily and deletes replicated blocks only after a mandatory **7-day grace period** past expiry.

Configuration lives under the `retention` key in `~/.sovseal/config.json`. See [Billing](/platform/features/billing-and-credits) for the plan ladder.

## Availability

<Note>
  **The only contractual availability commitment is 99.9% uptime on Enterprise**, agreed per contract. Every other plan is **best-effort**.

  sovseal is operated by a small team. There is no 24/7 monitoring rotation and no service-credit scheme. We would rather state that than publish an availability number we cannot defend under scrutiny.

  A public status page at `status.sovseal.com` is **in progress** — the domain is provisioned but not yet serving. It is deliberately not linked until it is live.
</Note>

What you *can* verify yourself, independent of any uptime promise:

* **Local reads and writes never depend on our availability.** Capture and recall run entirely on-device at 0 RTT. If the replication endpoint is down, your agent keeps working; sync resumes when it returns.
* **The Packet-Capture Guarantee** — run any traffic inspection, any time. If plaintext memory leaves a device, we publish the finding and your team keeps sovseal free forever.

If you need a contractual SLA with service credits, that is an Enterprise conversation: `enterprise@sovseal.com`.