Skip to main content
Mnemom’s availability commitments scale with plan tier. The free tier is best-effort; paid tiers carry contractual targets, with Enterprise escalating to custom terms. This page documents the public position. The authoritative numbers for any given contract live in the MSA and its SLA exhibit.
A public status page is live at status.mnemom.ai. It shows per-service operational state and 90-day uptime history. Incident communications go through the status page and email (for contractual customers).

​
Uptime targets by tier

Uptime is measured monthly against the gateway control plane — the endpoints under api.mnemom.ai/v1. Data-plane components in the Safe House (front-door checkpoint, back-door checkpoint, AIP) inherit the control-plane target; when the gateway is up, enforcement is up. Scheduled maintenance is excluded from uptime calculation on Developer and Team tiers with at least 72 hours advance notice. Enterprise contracts negotiate maintenance windows individually. Emergency security patches are never excluded. Measurement basis. Uptime is computed as (total minutes in the month − unavailable minutes) ÷ total minutes. A minute is “unavailable” when the synthetic monitors that exercise the public API return a non-success status from at least two geographic probes simultaneously.

​
Recovery objectives

The primary data store (Supabase Postgres) runs continuous point-in-time recovery (PITR), which sets the platform RPO at 5 minutes and a database recovery RTO of 1 hour. The stateless API and website layers redeploy from version control in ≤ 15 minutes with no data loss of their own. The per-tier objectives above are contractual commitments and are never tighter than this underlying technical capability; Enterprise contracts may negotiate custom terms within it. RTO and RPO apply to the control plane (dashboard, API, Supabase-backed state). Proof-chain commitments (Tier 1) are hash-chained and append-only — once anchored, they are not lost even under full-region failure; they become temporarily unretrievable, not corrupted.

​
Incident severity

Incidents are classified on declaration and re-classified as facts change. SEV-1 and SEV-2 invoke the on-call runbook within minutes of detection; remediation and communication run in parallel.

​
Incident communication

Who hears what, when, and through which channel. Security-impacting incidents (confirmed exposure, canary leak, credential compromise, supply-chain event) also trigger:
  • Dashboard enforcement-mode downgrade notice if Safe House falls back to observe mode during the incident.
  • Breach-notification support for customers with a regulator obligation under GDPR Article 33, HIPAA Breach Notification Rule, or sector-specific law. Mnemom provides the timeline, technical detail, and attestations needed for the customer’s notification; the customer is the reporting party. See Compliance — shared-responsibility boundaries.
Post-mortems are published within 5 business days of SEV-1 resolution for Enterprise customers (private, under NDA) and within 10 business days of SEV-1 resolution for all customers in summary form.

​
How customers reach us

Responsible disclosure is acknowledged within 48 hours; fix or mitigation target is 7 days for high-severity findings.

​
Status page

status.mnemom.ai is live and publishes:
  • Current operational state for each service (gateway, dashboard, proof-chain anchoring) per region.
  • Active incidents with a live update log.
  • 90-day uptime history.
Scheduled maintenance windows are announced on the status page in advance. Contractual customers also receive email notification per the incident communication table above.

​
SLA credits

Enterprise and Team contracts include SLA credits against the subscription fee when monthly uptime misses the contractual target. The credit schedule is in the MSA’s SLA exhibit; typical structure:
  • Below target but ≥ 99.0%: 10% credit on the monthly subscription.
  • Below 99.0% but ≥ 95.0%: 25% credit.
  • Below 95.0%: 50% credit.
Credits are applied to the next invoice after the customer raises the claim with evidence. Free and Developer tiers do not accrue credits.

​
See also

  • Launch SLOs & Deferrals — Per-scenario SLO commitments (S1–S10) and the explicit deferral list
  • Compliance posture — Regulatory status and shared-responsibility boundaries
  • Safe House — the per-customer perimeter the uptime target covers
  • AEGIS — the cross-tenant Protection Network and its published SLOs
  • Managed Rules — the signed rule pipeline whose propagation latency is published as an SLO
  • Observability — Customer-side signals for detecting degradation early
  • API reference overview — Error codes, rate limits, and timeouts

​
AEGIS SLO commitments

AEGIS publishes Protection-Network SLOs at /trust/slos: The KV → R2 → in-isolate read pipeline + the three independent signing chains (RECIPE_PROMOTION_SIGNING_KEY, RECIPE_KV_SIGNING_KEY, RECIPE_R2_SIGNING_KEY) are the mechanisms behind these commitments. See Managed rule envelope schema for the failover behavior and alert tags.