Introduction
This page carries the limits this documentation can state accurately, and says plainly which ones it cannot. That is a shorter page than you may want, and it is the honest version — a plausible number in a reference table gets designed around and never questioned again.
Telemetry retention — 30 days
Traces, sessions and spans age out of retention after thirty days. The product states this where it matters most: when you ask an evaluator to backfill over past traffic, it warns that records older than thirty days have aged out.
This is the single most consequential limit in the product, because several workflows quietly depend on it:
What expires | What does not |
Traces, sessions, spans | Incident records |
The evidence behind an incident | The incident's own detection, severity, action, provenance |
The ability to backfill evaluation over old traffic | Datasets already built from those sessions |
The trace an incident's | Triage notes written while it existed |
Note: The corroborating detail expires before the finding does. An incident persists as a record long after the trace it points at is gone. For anything you expect to matter — a genuine breach, a regulator-facing finding, anything feeding a report — capture what you need from the trace into the incident's notes during triage, while it still exists. A note written at the time is contemporaneous evidence; a reconstruction later is not.
Limits that follow from how things work
These are not configured quotas, but they behave like limits and cause the same surprises:
Limit | Why |
Only | Enforcement needs a point in the request path the platform provides — see Governing Vendors Without a Control API |
Mask and redact are per-check | They need a check that reports the match position. Not every check does |
A metric scores only cases carrying all its parameters | Declared parameters act as a filter — see Input Parameters Reference |
Evaluation covers a sample, not everything | Sampling is the cost control. Coverage is reported alongside quality for this reason |
Cost figures are a floor, never a ceiling | Every gap in instrumentation makes them read low — see How Cost & Tokens Are Calculated |
Limits this page cannot state
The following are real and enforced somewhere, and none of them is knowable from the sources this documentation is written against. Rather than estimate:
Trace ingest rate limits, and behaviour when one is exceeded.
Maximum controls per policy, or policies per asset.
Maximum test cases per dataset, or concurrent experiment runs.
Latency a control adds to a request.
Whether a control that fails or times out lets the request proceed or stops it.
Registered-asset ceilings, if any.
If your design depends on any of these, get the answer from your UnifyApps account team before you build on an assumption. The last two in particular have opposite risk profiles depending on the answer, and they are raised again on Where Controls Run.
"A reference page with a wrong number is worse than one with a gap. Nobody re-checks a number that looked authoritative."
Planning around the one limit you do know
Build datasets from sessions promptly — A session worth turning into a test case is available for thirty days. After that the case has to be written from memory.
Backfill evaluation early — A newly added evaluator can score past traffic, but only back to the retention boundary.
Write triage notes while the trace exists — The single most valuable habit this limit implies.
Do not design a quarterly review around trace-level detail — By the time a quarterly review runs, most of the quarter's traces are gone. Design it around incidents, which persist.