Service Level Objectives

An SLO is a target you commit to for your own deployment, on your own hardware. OGuardAI publishes no latency or throughput figures, and this page does not invent any: see Benchmarks for the rule and for the harnesses that produce numbers from a run you execute. What this page does give you is the axes worth setting a target on, and the limits and properties the runtime enforces regardless of what you target.

Availability

Availability targets are yours to set. These are common starting points, not vendor commitments.

Rehydrate deserves the tighter target of the two: a failed transform can be retried from the original text, while a failed rehydrate strands output the caller already paid an LLM to produce.

Latency

Set the latency objective per detector mode, because the two modes are bounded by different things:

• Builtin-only is in-process CPU work. It scales with payload length and match count, and it has no external dependency to wait on.
• Builtin + NER (both or advanced) adds a synchronous sidecar round trip and a model forward pass per detection. Its worst case is bounded by detector.timeout_secs, so that value, not a target you write down, is what actually caps the tail.
• Rehydrate performs local replacement and runs no detection, unless output NER scanning or a Redis-backed session or revocation backend puts it on the network. See Performance.

Measure your own baseline before committing to a number. The guardai_transform_duration_seconds and guardai_rehydrate_duration_seconds histograms give you the quantiles:

histogram_quantile(0.95, sum(rate(guardai_transform_duration_seconds_bucket[5m])) by (le))

Throughput

Throughput has two independent capacity axes, and sizing only one of them is the common mistake:

• The API instances handle the builtin path and scale horizontally, because sealed sessions carry state with the request and instances do not coordinate on the transform path.
• The NER sidecars handle model inference. A NER-heavy workload needs proportional sidecar capacity; adding API instances does not add NER throughput.

Optional shared backends (Redis sessions, replay protection) introduce a coordination point a purely sealed deployment does not have. Shared revocation is not optional in a multi-replica deployment, so count it in.

Payload Limits

These are enforced by the runtime, not targets.

A document refused by a size ceiling returns 413 GUARDAI_PAYLOAD_TOO_LARGE, not a 400: the document may be perfectly valid. See PDF Support. The server streaming endpoints add three fail-closed bounds: a request past the concurrency ceiling is refused 503 GUARDAI_STREAM_CAPACITY_EXHAUSTED with Retry-After: 1; a response whose total serialized egress exceeds the byte ceiling is refused 413 GUARDAI_PAYLOAD_TOO_LARGE before the stream opens; and a stream whose client drain outlasts the duration budget is cut with a single terminal GUARDAI_STREAM_BUDGET_EXCEEDED event (never a complete event, so the truncation is detectable).

Error Budget

Budget on the axes you can actually observe:

Detection accuracy is deliberately absent from this table. Precision and recall depend on the model, the language, and your own corpus, so they are not a number we can set on your behalf. Run benchmarks/ner_bakeoff/ against your own labelled data to get per-language and per-entity-type precision, recall, and F1, then budget from that.

Degraded Mode

When the NER sidecar is unavailable:

Session Security

Revocation

The binding version of these, including what the person cascade does and does not cover, is the Revocation Contract.

Monitoring

# Prometheus alerts (see deploy/prometheus/alerting-rules.yml)
- guardai_transforms_total          # request rate
- guardai_errors_total              # error rate
- guardai_transform_duration_seconds # latency
- guardai_rate_limit_rejections_total # capacity
- guardai_prompt_security_triggers_total # security

The shipped alerting rules carry starting thresholds, not tuned ones. See Monitoring.