Signals & reporting

A signal is a short record of a decision the core already made: what kind of event it was, how it was classified, what action was taken, and when. It is a summary of behaviour, not a copy of traffic.

• Product identifier — which of your systems reported.
• Event class and severity from the classifier.
• Action taken locally (allowed, throttled, challenged, blocked).
• Timestamp and the core's release version.
• Coarse counters used for your usage rollups.

• Request bodies, form contents or uploaded files.
• Your customers' names, emails or account records.
• Session cookies, tokens or credentials.
• Your database contents. The core's state stays in your database.

This is a design constraint, not a setting. There is no mode that turns it off, because a payload we never hold cannot leak from us.

• My security — live posture, signal volume and open incidents per system.
• Account overview — the short version, plus your onboarding state.
• Support — attach an incident to a ticket when you want us to look at it.

Individual signals are kept for the operating window needed to investigate incidents, then rolled up into daily aggregates and discarded. Aggregates carry no per-event detail. Closing your contract removes your signal history from our side.

If we are unreachable or rate-limiting, the core queues reports locally and retries with backoff. Protection is unaffected while that happens — reporting is downstream of the decision, never upstream of it.