> **Agent?** Fastest path: MCP at `https://api.mnemom.ai/mcp` — call `get_started` first (zero-auth, no args). Full agent guide: # Service-Level Objectives — Mnemom Trust Center ```json {"@context":"https://schema.org","@type":"TechArticle","name":"Service-Level Objectives","headline":"Service-Level Objectives","description":"\u00d6ffentliche SLO-Commitments f\u00fcr die Mnemom Trust-Ebene","url":"https://trust.mnemom.ai/de/slos","inLanguage":"de-DE","datePublished":"Mai 2026","dateModified":"Mai 2026","author":{"@type":"Organization","name":"Mnemom Trust + Reliability","url":"https://www.mnemom.ai"},"publisher":{"@id":"https://www.mnemom.ai#organization"},"license":"https://creativecommons.org/licenses/by/4.0/"} ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Start","item":"https://www.mnemom.ai/de/"},{"@type":"ListItem","position":2,"name":"Trust Center","item":"https://trust.mnemom.ai/de"},{"@type":"ListItem","position":3,"name":"Service-Level Objectives","item":"https://trust.mnemom.ai/de/slos"}]} ``` [Trust Center](/trust) # Service-Level Objectives Öffentliche SLO-Commitments für die Mnemom Trust-Ebene Mnemom Trust + Reliability·Mai 2026·Version 1.0·CC BY 4.0 [Interne Quelle](https://github.com/mnemom/safe-house-hardening/blob/main/slos.md)[Live-Status](https://status.mnemom.ai) ## 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](https://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](https://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. --- _Source: /de/trust/slos/index.html · Generated by build-markdown-mirrors.mjs · For agent-readability commitment #4 see https://www.mnemom.ai/for-agents/_