Safety and security
Built to fail towards paging.
A missed page costs more than a noisy one. These are the rules BlipLite follows, how each one is enforced, and an honest list of what's still being decided.
Principles, and how they're enforced
AI can't silently suppress a page
AI may suggest a higher severity and explain an alert. It can't lower severity or hold back a page.
The decision step only accepts a suggestion above the alert's own severity. Anything lower is ignored.
Deterministic policy controls paging
Your paging policy decides page, notify or digest. The same alert under the same policy gets the same decision.
Policy presets today: 24/7, business hours, no paging, digest only. Custom rules are next.
Failure favours paging
If triage errors, times out or the model is unavailable, the alert continues at its original severity.
Hard 8-second timeout. On any failure a rules-only result is used, and that's recorded.
Every decision is explainable
Each group shows the policy, the rule that matched, whether AI raised it, and the reason in a sentence.
Stored with the decision, not regenerated later.
Every decision is auditable
What came in, what triage said and what went out, in order, per alert group.
A timeline per group with in, AI and out entries.
Shadow mode, enforced in code
Run BlipLite on real traffic while your existing routing keeps paging as it does today.
Live paging needs a production environment, a production deployment and the workspace switched on. Previews can never page.
Secrets stay out of the model
Labels and annotations that look like tokens, keys, passwords or cookies are redacted before triage.
Redaction runs before anything leaves BlipLite. The alert shows how many values were redacted.
Webhook secrets aren't stored
Each source gets a secret webhook URL, shown once. Only a hash is kept, and you can rotate it at any time.
SHA-256 of the secret. The old URL stops working immediately on rotation.
How your data is handled today
For the private beta. This covers the product, not this website (see Privacy for the site).
- Access
- Invite only during the beta. Sign in by email link, Google or GitHub. Every query is scoped to your workspace.
- Application and database
- Vercel (application, London region) and Neon Postgres (UK or EU region).
- Background jobs
- Inngest, in the US. Jobs carry IDs and counts only, never alert content or personal data.
- AI triage
- Anthropic's API (Claude), after redaction. Optional: a free deterministic triage can be used instead.
- Resend, for sign-in links and invites.
- Training on your data
- BlipLite doesn't train models on your alerts.
- Certifications
- None yet. No SOC 2 or ISO 27001. We'll say so here if that changes.
Still being decided
BlipLite is early. These are open on purpose, so design partners can shape them. If one of them is a blocker for you, say so when you request access.
- Retention period
- Agreed with design partners before anyone's data is kept long term. Until then, ask and we'll delete your workspace and its data.
- Self-hosting or a single-tenant option
- Being discussed. Tell us if it decides whether you can take part.
- SSO and roles
- Admin and member roles exist. SAML SSO is not planned for the beta.
- Published sub-processor list and DPA
- The list above is complete for the product today. A DPA will be offered before anything is paid for.
- Independent security testing
- Before general availability.
Found something? Tell us.
Security reports go to hello@bliplite.com. They're read by the person who wrote the code.
Private beta
Run it in shadow mode on your own alerts.
We're onboarding 10 teams. Your paging stays exactly as it is while you see what BlipLite would have done.
Try the demo first