Worum es hier geht
Dies ist die öffentliche Version der Service-Level Objectives von Mnemom. Jeder Indikator unten ist das Ziel, zu dem sich Mnemom öffentlich verpflichtet; jeder Indikator wird zudem vom Validation-Harness in der CI asserted. Der aktuelle Live-Status liegt auf status.mnemom.ai. Wenn ein SLO sein Budget aufzehrt, wird automatisch ein Incident angelegt und dort veröffentlicht.
Diese Seite ist die kundenseitige Zusammenfassung von Mnemoms internem operativem SLO-Programm: Ziele, Scope und die Begründung hinter jedem Commitment.
Format
Jeder SLI definiert, was wir messen. Jedes SLO definiert das Ziel, dem wir uns verpflichten.
Gateway
Safe-House-Dispatch-Overhead
Was wir messen: Die Zeit, die Mnemoms Safe House zu einer Gateway-Anfrage hinzufügt, gemessen als gateway_total - upstream_provider - aip_analysis.
SLO: P50 ≤ 15 ms · P95 ≤ 60 ms.
Warum: Safe-House-Dispatch liegt im synchronen Request-Pfad. Er muss billig sein. Die Kunden-Aussage lautet „Mnemom fügt rund 15 ms hinzu"; dieses SLO macht das wahr.
CLPI-Policy-Evaluation-Overhead
Was wir messen: Zeit zur Auswertung eines Tool-Calls gegen die Policy des Agenten, wenn CLPI aktiv ist. SLO: P50 ≤ 10 ms · P95 ≤ 40 ms. Warum: CLPI gated die Tool-Nutzung synchron. Tail-Latenz ist für den Kunden sichtbar.
AIP-Analyse — hinzugefügte Latenz
Was wir messen: Zeit, die die Integrity-Analyse hinzufügt, gemessen zwischen Abschluss der Upstream-Antwort und der Auslieferung an den Kunden. AIP läuft nach der Antwort, vor der Auslieferung — nie als Mid-Stream-Interrupt. SLO: P50 ≤ 800 ms · P95 ≤ 2 500 ms. Warum: Die Integrity-Analyse ist der tragende Kostenpunkt; wir begrenzen ihn explizit, damit Kunden planen können. Das Framing als Post-Response ist ehrlich — eine Streaming-Interrupt-Fähigkeit gibt es heute nicht.
off-Modus-Treue
Was wir messen: Anzahl der Integrity-Checkpoints oder Policy-Evaluations, die geschrieben werden, wenn die Card des Agenten integrity_mode: off oder autonomy_mode: off sagt.
SLO: Genau 0 über ein rollierendes 7-Tage-Fenster.
Warum: Off bedeutet off. Jeder Wert ungleich null verletzt den Master-Switch-Vertrag.
Chat Always Completes
Was wir messen: Der Anteil kundenseitiger Anfragen, bei denen Safe House in irgendeinem Modus an irgendeinem Checkpoint eingegriffen hat und die Anfrage 2xx an den Kunden zurückgegeben hat. SLO: ≥ 99,99 % über ein rollierendes 7-Tage-Fenster. Mehr als 5 Verletzungen in einer Woche lösen einen Root-Cause-Review aus. Warum: Dies ist die einigende Invariante von Mnemom. Safe House greift im selben Turn ein — Front Door (Input-Ersatz), Inside.Autonomy (Tool-Call-Intercept), Inside.Integrity (Antwort-Ersatz), Back Door (Payload-Modifikation). Ein Nicht-2xx, das Safe House zuzuschreiben ist, ist eine Vertragsverletzung.
Nutzersichtbare Erklärungsrate
Was wir messen: Der Anteil von Nudge- oder Enforce-Interventionen, bei denen die an den Kunden gelieferte Antwort Sprache enthält, die benennt, was wir verhindert oder verändert haben. SLO: 100 % über ein rollierendes 7-Tage-Fenster. Warum: Stille Prävention ist eine UX-Regression, auch wenn die Aktion korrekt blockiert wird. Wenn wir eingreifen, sagen wir es — jedes Mal. Das Gateway injiziert vor der Auslieferung eine strukturierte Suffix-Notiz, falls die natürliche Sprache des Agenten nicht bereits auf die Intervention verweist.
Pro Provider
AIP-Coverage pro Provider
Was wir messen: Der Anteil von Integrity-Checkpoints (auf thinking-fähigen Modellen), bei denen der Verifier vollständige Einsicht in die Thinking-Trace hatte, aufgeschlüsselt nach Upstream-Provider. Ziele, rollierendes 30-Tage-Fenster:
- Anthropic ≥ 99 % (volle Extended-Thinking-Exposure)
- Gemini ≥ 95 % (volle
thoughts-Feld-Exposure) - OpenAI o-Serie ≥ 50 % (nur Reasoning-Summaries — partielle Coverage per Definition)
- OpenAI Nicht-Thinking-Modelle: vom Zähler ausgeschlossen; AIP degradiert auf eine Nicht-Thinking-Behandlung gemäß Feature-Matrix.
Warum: Uniforme Integrity-Checkpoint-Qualität über alle Provider hinweg ist nicht das, was Mnemom liefert, und wir tun nicht so. Das v1-Versprechen ist ehrliche Provider-spezifische Differenzierung. Dieses SLO ist die öffentliche Verpflichtung, dass die Differenzierung das ist, was wir sagen.
Dispatch-Overhead pro Provider
Was wir messen: P50/P95 der Safe-House-Dispatch-Latenz, gruppiert nach Upstream-Provider. SLO: Jeder Provider erfüllt einzeln die obige Dispatch-Envelope. Tail-Anomalien auf der Request-Form eines bestimmten Providers werden inline mit einem Mitigation-Plan dokumentiert. Warum: „Mnemom fügt ~15 ms hinzu" ist konditional. Wenn der Pfad eines Providers konstant langsamer ist, müssen Docs und Status-Page das reflektieren, nicht verstecken.
AIP-Analyse-Latenz pro Provider
Was wir messen: P50/P95 der AIP-Analyse-Dauer, gruppiert nach Upstream-Provider. SLO: Jeder Provider erfüllt einzeln die obige Analyse-Latenz-Envelope. Warum: AIP-Kosten variieren mit dem Upstream-Response-Token-Volumen. Thinking-lastige Pfade (Anthropic Opus Extended Thinking) haben andere Tails als dünnoutput-Pfade (Gemini Flash). Pro Provider veröffentlichen, damit klar ist, was zu erwarten ist.
Card-Lifecycle
Time-to-Canonical nach Card-Mutation
Was wir messen: Verstrichene Zeit von einem erfolgreichen PUT einer Alignment Card oder Protection Card bis die kanonische Card den neuen Zustand über die Gateway-Flotte hinweg widerspiegelt. SLO: P50 ≤ 2 s · P95 ≤ 30 s · P99 ≤ 5 min. Warum: Kunden erwarten, dass ihr Save schnell wirkt. Fünf Minuten ist die absolute Obergrenze, nicht das Ziel.
Compose-Fehlerrate
Was wir messen: Der Anteil von Card-Mutationen, die im Validate erfolgreich sind, aber im Compose fehlschlagen und Self-Heal auslösen. SLO: ≤ 0,1 % über ein rollierendes 7-Tage-Fenster.
Canonical-Read-Latenz
Was wir messen: P95 der Canonical-Card-Reads auf dem Gateway-Pfad. SLO: P95 ≤ 50 ms bei warmem KV-Cache; P95 ≤ 200 ms bei kaltem KV-Cache (Post-Deploy oder Post-Recompose-Storm).
Recipe-Pipeline
Latenz Candidate → Promoted
Was wir messen: Verstrichene Zeit von der Erstellung eines Recipe-Kandidaten bis zu seiner Promotion in das aktive Recipe-Set. SLO: P50 ≤ 24 h · P95 ≤ 7 Tage im Manual-Reviewer-Modus. Auto-Approve-Modi straffen das für eligible Quellen auf P50 ≤ 4 h, P95 ≤ 24 h. Warum: Die Value-Realization des Arena-Throughputs hängt von dieser Latenz ab. Manual-Modus erkennt die Last der Human-Reviewer an; Auto-Approve-Modi straffen deutlich.
Promotion → KV-Propagation
Was wir messen: P95-Verstreichungszeit von der Promotion eines Recipes bis der neue Zustand über alle Gateway-Instanzen reflektiert ist. SLO: P95 ≤ 30 s. Warum: Hot-Load ist das v1-Versprechen. Kein Deploy für einen neuen Detector nötig.
Review-Queue-Tiefe
Was wir messen: Recipe-Kandidaten, die auf Review warten. SLO: ≤ 100 zu jeder Zeit. Soft-Alert bei 50; Hard-Alert bei 100. Warum: Backlog ist beobachtbar. Eine wachsende Queue bedeutet, dass Review-Kapazität der Engpass ist und entweder Automation oder zusätzliche Reviewer nötig sind.
Recipe-False-Positive-Rate
Was wir messen: FP-Verhältnis pro Recipe über rollierende 30 Tage, gewichtet nach Hit-Volumen. SLO: ≤ 2 % pro Recipe nachhaltig über 30 Tage. Darüber löst Retirement-Review aus. Warum: False Positives sind die stillen Killer des Kundenvertrauens. Built-in Retirement hält den Detector-Korpus gesund.
Webhook-Delivery
Fünf Indikatoren. Die ersten drei sind die tragenden Kunden-Commitments. Die letzten zwei sind operative Ergänzungen, die uns bei der Diagnose der Delivery-Gesundheit helfen.
10-Minuten-Delivery-Erfolgsrate
Was wir messen: Der Anteil von Webhook-Events, die erfolgreich ausgeliefert werden (2xx vom Kunden-Endpoint, bei irgendeinem Versuch innerhalb des Retry-Fensters) innerhalb von 10 Minuten nach Event-Erstellung. Endpoints im Zustand failure_disabled sind vom Nenner ausgeschlossen.
SLO: ≥ 99,5 % über ein rollierendes 7-Tage-Fenster.
Warum: Dies ist das Headline-Webhook-Commitment — „wenn Sie abonniert haben, haben wir innerhalb von 10 Minuten ausgeliefert" ist die Branchen-Latte, die Mnemom hält.
Replay-Erfolgsrate
Was wir messen: Der Anteil operator-initiierter Webhook-Replays, die innerhalb von 60 Sekunden ausliefern. SLO: ≥ 99 % über ein rollierendes 7-Tage-Fenster. Warum: Replay ist die Recovery-Surface, wenn ein Kunden-Endpoint down war. Wenn Replay selbst flaky ist, ist die Recovery-Surface unzuverlässig.
First-Delivery-Latenz
Was wir messen: P95 der Zeit zwischen Event-Erstellung und erstem Delivery-Versuch.
SLO: P95 ≤ 5 Sekunden.
Warum: Dies ist der Developer-Perception-SLI — ist der Webhook in mnemom listen schnell aufgetaucht?
Eventual-Delivery-Erfolgsrate
Was wir messen: Der Anteil von Webhook-Events, die letztlich unter der Retry-Policy ausgeliefert werden, bevor sie als failed markiert oder der Endpoint auto-disabled wird. SLO: ≥ 99,95 % über ein rollierendes 7-Tage-Fenster. Warum: Ergänzung des 10-Minuten-Fensters — „haben wir letztlich durchgekommen, Zeit ignoriert" — nützlich für die Gesundheit der Retry-Policy.
Signatur-Verifikations-Kompatibilität
Was wir messen: Vom Kunden gemeldete HMAC-Verifikationsfehler pro Quartal auf Payloads, deren Auslieferung wir als 2xx bestätigt haben. SLO: ≤ 1 pro Quartal. Warum: HMAC-Kompatibilität ist aus Kundensicht binär. Wenn unsere Signatur-Konvention von einem Kunden-SDK oder Doku-Beispiel divergiert, sieht der gesamte Stream kompromittiert aus.
API-Surface
API-Verfügbarkeit
Was wir messen: Der Anteil von /v1/*-Anfragen, die kein 5xx zurückgeben, ausgenommen geplante Wartungsfenster.
SLO: ≥ 99,9 % über ein rollierendes 30-Tage-Fenster.
API-P95-Latenz (ohne LLM-Upstream)
Was wir messen: P95-Response-Time für /v1/*-Endpoints, ausgenommen Endpoints, die LLM-Calls proxen (welche durch den Upstream-Provider gebunden sind).
SLO: ≤ 250 ms.
Idempotency-Key-Replay-Korrektheit
Was wir messen: Der Anteil wiederholter Mutation-Requests (gleicher Idempotency-Key, gleicher Body-Fingerprint), die die gecachte Response zurückgeben, ohne die Mutation erneut auszuführen. SLO: 100 % — null Doppelausführung.
Observer
Trace-Frische
Was wir messen: P95-Verstreichungszeit von der Gateway-Anfrage bis zum Auftreten einer AP-Trace-Zeile im Trace-Store des Observers. SLO: P95 ≤ 5 min.
Drift-Detection-Coverage
Was wir messen: Der Anteil von Agenten mit integrity_mode != off und ≥ 10 Traces in den letzten 7 Tagen, die mindestens eine Drift-Evaluation im selben Fenster haben.
SLO: ≥ 99 % über ein rollierendes 7-Tage-Fenster.
Adversarial (Arena ↔ Safe House)
Arena-Verteidiger-Fall-Rate
Was wir messen: Der Anteil von Arena-Versuchen, bei denen der Verteidiger-Agent einem Angriff erlag, obwohl die relevante Surface der Protection Card aktiviert war. SLO: ≤ 5 % über ein rollierendes 7-Tage-Fenster. Anhaltende Verletzung blockiert die Produktions-Promotion. Warum: Die Arena ist eine kontinuierliche False-Negative-Sonde auf die Safe-House-Detection. Ein Spike bedeutet, dass eine neue Angriffskategorie die Kette umgeht — Safe House bekommt ein Detector-Update, bevor der nächste Deploy rausgeht.
Arena-False-Positive-Rate
Was wir messen: Der Anteil von Arena-Versuchen, die per Post-Hoc-Review als strukturell harmlos beurteilt wurden und dennoch eine Safe-House-Intervention auslösten. SLO: ≤ 2 % über ein rollierendes 30-Tage-Fenster.
Wie sich diese SLOs weiterentwickeln
- Diese Seite wird quartalsweise überprüft. Der nächste Review ist Q3 2026.
- Eine Lockerung eines öffentlichen Commitments erfordert eine veröffentlichte Begründung.
- Eine Verschärfung (wir übertreffen unser Ziel konstant) sind gute Nachrichten und wird hier rückportiert.
- Live-Status jedes SLO ist auf status.mnemom.ai.
- Budget-Verbrauch löst automatische Incidents auf der Status-Page über den Grafana → Betterstack Hook aus.
Woher das kommt
Diese Ziele stammen aus Mnemoms internem operativem SLO-Dokument. Dieses Dokument trägt den zusätzlichen Kontext — Architektur-Anker, Dashboard-Links, Instrumentierungsstatus, Rekalibrierungs-Timestamps —, den das Safe-House-Hardening-Programm intern nutzt. Diese öffentliche Seite trägt die Ziele und die Begründung.
Offene Punkte, die die nächste Erweiterungsrunde wahrscheinlich hinzufügt: Incident-Response-Zeit (z. B. Kompromittierungs-Detection bis Kundenbenachrichtigung), Rotationskadenz für Signing-Keys, Pass-Rate des Adversarial-Test-Korpus, Frische der Validator-Deny-Liste, Approval-Signing-Integrität der Recipe-Pipeline.
