What we do — and don't do — with your data, before the pilot starts
The longer-form counterpart to the “Security and data handling” accordion on the FAQ page — the same answers in the same voice, with a bit more room for the parts that didn't fit in the accordion.
When you paste a JSON object or a stream per line into the demo, that input is processed for your own detection and drafted plan during the request. The recorded row only carries the streams and anomalies that came out of the analysis — your email for the nurture sequence, and the structured result we reference back to you. The raw paste itself is one-shot: it lives only in the request that analyzed it.
Every signed-in operator sees only their own queued actions. The cross-customer catalogue view — the screen that would surface the founder's pick of the anomaly library, the demo runs, and the waitlist submissions across customers — is gated to a founding-team role and is never reached by a per-user data request. That separation is enforced at the data layer so a per-user query can't accidentally return rows from another customer's stream.
- In transit. Your data moves over TLS only. We don't pull from a separate origin that needs its own TLS configuration — the connectors sit behind the same TLS posture as the surface you're reading now.
- At rest. Whatever your control surface provides — our cloud or your own — is the protection applied to the rows that land in the database. We don't add an additional processor that would sit between your stream and that control surface; we don't replicate your data into a separate analytics store.
- At the edge. A strict content-security policy is enforced on every response — a per-request nonce on scripts and a closed allowlist of origins — so a stray injected asset can't load against your session.
The renderer produces a drafted action plan in-agent: the paste enters the request, the detector runs against it, and the plan comes back. What leaves the request boundary is the aggregate — the structured streams and anomalies that the nurture sequence references — not the raw paste. We do not train third-party models on your data, and we do not pass your paste to a provider whose terms would let them do so.
Your paste is gone the moment the request ends. The aggregate record on the row — the streams and anomalies your run produced, plus the email associated with the run — stays on the row until it's removed. Removal is on request: from your side when you ask us to remove it, or from ops / the founding team during the triage of stored intakes. There is no numeric auto-purge window; if you want the row gone sooner than that, the ask is a single message.
CAUTIOUS
High bar for “anomaly”: only draft plans for clear breaks from baseline. Fewest drafts, lowest false-positive rate. Use when alert fatigue is the dominant cost and your team needs to trust every draft that lands in the ticket.
STANDARD
Default pilot posture. Drafts land for confirmed sustained deviations. Tuned for daily and weekly seasonality so a Monday-morning spike isn't mistaken for an incident — and a real drift doesn't disappear inside the cycle.
AGGRESSIVE
Earlier drafts for emerging deviation. Higher signal volume — asks your team to triage more — but tuned for environments where missed anomalies are the dominant cost and a narrower false-positive budget is worth trading for earlier visibility.
Ready for the pilot?
See pricing on the pilot
6 weeks, one production stream, drafted corrective action plan delivered in week 1 — before any pricing conversation.