De quoi il s'agit
Voici la version publique des objectifs de niveau de service de Mnemom. Chaque indicateur ci-dessous est la cible à laquelle Mnemom s'engage publiquement ; chaque indicateur est également vérifié par le harnais de validation en CI. L'état courant en direct est sur status.mnemom.ai. Lorsqu'un SLO consomme son budget, un incident est créé automatiquement et publié là-bas.
Cette page est le résumé orienté client du programme opérationnel interne de SLO de Mnemom : cibles, périmètre et raisonnement derrière chaque engagement.
Format
Chaque SLI définit ce que nous mesurons. Chaque SLO définit la cible que nous nous engageons à tenir.
Gateway
Surcharge de dispatch Safe House
Ce que nous mesurons : Le temps que la Safe House de Mnemom ajoute à une requête gateway, mesuré comme gateway_total - upstream_provider - aip_analysis.
SLO : P50 ≤ 15 ms · P95 ≤ 60 ms.
Pourquoi : Le dispatch Safe House est dans le chemin de requête synchrone. Il doit être peu coûteux. L'affirmation client est « Mnemom ajoute environ 15 ms » ; ce SLO est ce qui rend cela vrai.
Surcharge d'évaluation de policy CLPI
Ce que nous mesurons : Temps d'évaluation d'un appel d'outil par rapport à la policy de l'agent quand CLPI est actif. SLO : P50 ≤ 10 ms · P95 ≤ 40 ms. Pourquoi : CLPI filtre l'usage des outils de manière synchrone. La latence de queue est visible côté client.
Latence ajoutée par l'analyse AIP
Ce que nous mesurons : Temps ajouté par l'analyse d'intégrité, mesuré entre la fin de la réponse upstream et la livraison au client. AIP s'exécute post-réponse, avant livraison — jamais comme une interruption en cours de stream. SLO : P50 ≤ 800 ms · P95 ≤ 2 500 ms. Pourquoi : L'analyse d'intégrité est le coût principal ; nous le bornons explicitement pour que les clients puissent planifier. Le cadre post-réponse est honnête — il n'y a pas aujourd'hui de capacité d'interruption en cours de stream.
Fidélité du mode off
Ce que nous mesurons : Nombre de checkpoints d'intégrité ou d'évaluations de policy écrits lorsque la card de l'agent indique integrity_mode: off ou autonomy_mode: off.
SLO : Exactement 0 sur une fenêtre glissante de 7 jours.
Pourquoi : Off veut dire off. Tout nombre non nul viole le contrat du master switch.
Chat Always Completes
Ce que nous mesurons : La proportion de requêtes client-visibles où Safe House est intervenue dans n'importe quel mode sur n'importe quel checkpoint et la requête a renvoyé 2xx au client. SLO : ≥ 99,99 % sur une fenêtre glissante de 7 jours. Plus de 5 violations dans une même semaine déclenche une revue de cause racine. Pourquoi : C'est l'invariant unifiant de Mnemom. Safe House applique les contrôles dans le même tour — porte d'entrée (remplacement d'entrée), intérieur.autonomie (interception d'appel d'outil), intérieur.intégrité (remplacement de réponse), porte de sortie (modification de payload). Un non-2xx attribuable à Safe House est une violation de contrat.
Taux d'explication visible utilisateur
Ce que nous mesurons : La proportion d'interventions de type nudge ou enforce où la réponse livrée au client contient une formulation nommant ce que nous avons empêché ou modifié. SLO : 100 % sur une fenêtre glissante de 7 jours. Pourquoi : La prévention silencieuse est une régression UX même quand l'action est correctement bloquée. Si nous intervenons, nous le disons — à chaque fois. Le gateway injecte en suffixe une note structurée avant livraison si le langage naturel de l'agent ne référençait pas déjà l'intervention.
Par provider
Couverture AIP par provider
Ce que nous mesurons : La proportion de checkpoints d'intégrité (sur les modèles capables de thinking) où le vérificateur disposait de l'inspection complète de la trace de thinking, ventilée par provider upstream. Cibles, fenêtre glissante de 30 jours :
- Anthropic ≥ 99 % (exposition complète de l'extended thinking)
- Gemini ≥ 95 % (exposition complète du champ
thoughts) - OpenAI série o ≥ 50 % (résumés de reasoning uniquement — couverture partielle par définition)
- Modèles OpenAI sans thinking : exclus du numérateur ; AIP dégrade vers un traitement non-thinking selon la matrice de fonctionnalités.
Pourquoi : Une qualité uniforme des checkpoints d'intégrité entre providers n'est pas ce que Mnemom livre, et nous ne prétendons pas le contraire. La promesse v1 est une différenciation honnête par provider. Ce SLO est l'engagement public que la différenciation est bien celle que nous annonçons.
Surcharge de dispatch par provider
Ce que nous mesurons : P50/P95 de la latence de dispatch Safe House, groupés par provider upstream. SLO : Chaque provider respecte individuellement l'enveloppe de dispatch ci-dessus. Les anomalies de queue sur la forme de requête d'un provider spécifique sont documentées en ligne avec un plan de mitigation. Pourquoi : « Mnemom ajoute ~15 ms » est conditionnel. Si le chemin d'un provider est systématiquement plus lent, la doc et la page de statut doivent le refléter, pas l'enterrer.
Latence d'analyse AIP par provider
Ce que nous mesurons : P50/P95 de la durée d'analyse AIP, groupés par provider upstream. SLO : Chaque provider respecte individuellement l'enveloppe de latence d'analyse ci-dessus. Pourquoi : Le coût AIP varie selon le volume de tokens de la réponse upstream. Les chemins lourds en thinking (extended thinking Anthropic Opus) ont des queues différentes des chemins à sortie maigre (Gemini Flash). Publier par provider pour que vous sachiez à quoi vous attendre.
Cycle de vie des cards
Time-to-canonical après mutation de card
Ce que nous mesurons : Temps écoulé entre un PUT réussi d'une alignment card ou d'une protection card et la card canonique reflétant le nouvel état sur l'ensemble de la flotte gateway. SLO : P50 ≤ 2 s · P95 ≤ 30 s · P99 ≤ 5 min. Pourquoi : Les clients s'attendent à ce que leur sauvegarde prenne effet rapidement. Cinq minutes est le plafond absolu, pas la cible.
Taux d'échec de compose
Ce que nous mesurons : La proportion de mutations de card qui réussissent au validate mais échouent au compose, déclenchant le self-heal. SLO : ≤ 0,1 % sur une fenêtre glissante de 7 jours.
Latence de lecture canonique
Ce que nous mesurons : P95 des lectures de card canonique sur le chemin gateway. SLO : P95 ≤ 50 ms quand le cache KV est chaud ; P95 ≤ 200 ms quand le cache KV est froid (post-déploiement ou post-recompose-storm).
Pipeline de recettes
Latence candidat → promu
Ce que nous mesurons : Temps écoulé entre la création d'une recette candidate et sa promotion vers l'ensemble actif de recettes. SLO : P50 ≤ 24 h · P95 ≤ 7 jours en mode manual-reviewer. Les modes auto-approve serrent cela à P50 ≤ 4 h, P95 ≤ 24 h pour les sources éligibles. Pourquoi : La création de valeur du throughput Arena dépend de cette latence. Le mode manuel reconnaît la charge des reviewers humains ; les modes auto-approve serrent significativement.
Propagation promu → KV
Ce que nous mesurons : Temps P95 écoulé entre la promotion d'une recette et la propagation du nouvel état sur toutes les instances gateway. SLO : P95 ≤ 30 s. Pourquoi : Le hot-load est la promesse v1. Aucun déploiement requis pour un nouveau détecteur.
Profondeur de file de review
Ce que nous mesurons : Recettes candidates en attente de review. SLO : ≤ 100 à tout moment. Soft alert à 50 ; hard alert à 100. Pourquoi : Le backlog est observable. Une file qui grandit signifie que la capacité de review est le goulot, et il faut soit de l'automatisation soit des reviewers supplémentaires.
Taux de faux positifs par recette
Ce que nous mesurons : Ratio de faux positifs par recette sur 30 jours glissants, pondéré par le volume de hits. SLO : ≤ 2 % par recette soutenu sur 30 jours. Au-delà, déclenche une revue de retrait. Pourquoi : Les faux positifs sont les tueurs silencieux de la confiance client. Le retrait intégré garde le corpus de détecteurs sain.
Livraison de webhook
Cinq indicateurs. Les trois premiers sont les engagements client principaux. Les deux derniers sont des suppléments opérationnels qui nous aident à déboguer la santé de la livraison.
Taux de succès de livraison à 10 minutes
Ce que nous mesurons : La proportion d'événements webhook qui aboutissent à une livraison réussie (2xx du endpoint client, à n'importe quel essai dans la fenêtre de retry) dans les 10 minutes après la création de l'événement. Les endpoints en état failure_disabled sont exclus du dénominateur.
SLO : ≥ 99,5 % sur une fenêtre glissante de 7 jours.
Pourquoi : C'est l'engagement webhook principal — « si vous êtes abonné, nous avons livré dans les 10 minutes » est la barre industrielle que Mnemom atteint.
Taux de succès de replay
Ce que nous mesurons : La proportion de replays webhook lancés par l'opérateur qui livrent en moins de 60 secondes. SLO : ≥ 99 % sur une fenêtre glissante de 7 jours. Pourquoi : Le replay est la surface de récupération quand un endpoint client était down. Si le replay lui-même est instable, la surface de récupération est peu fiable.
Latence de première livraison
Ce que nous mesurons : P95 du temps entre la création d'événement et la première tentative de livraison.
SLO : P95 ≤ 5 secondes.
Pourquoi : C'est le SLI de perception développeur — le webhook est-il apparu rapidement dans mnemom listen ?
Taux de succès de livraison éventuelle
Ce que nous mesurons : La proportion d'événements webhook qui finissent par être livrés sous la politique de retry avant d'être marqués failed ou avant l'auto-disable du endpoint. SLO : ≥ 99,95 % sur une fenêtre glissante de 7 jours. Pourquoi : Supplément à la fenêtre de 10 minutes — « avons-nous fini par passer, en ignorant le temps » — utile pour la santé de la politique de retry.
Compatibilité de vérification de signature
Ce que nous mesurons : Échecs de vérification HMAC signalés par les clients par trimestre sur des payloads que notre livraison a confirmés 2xx. SLO : ≤ 1 par trimestre. Pourquoi : La compatibilité HMAC est binaire du point de vue du client. Si notre convention de signature diverge d'un SDK client ou d'un exemple de doc, le stream entier paraît compromis.
Surface API
Disponibilité API
Ce que nous mesurons : La proportion de requêtes /v1/* renvoyant un non-5xx, hors maintenance planifiée.
SLO : ≥ 99,9 % sur une fenêtre glissante de 30 jours.
Latence P95 API (hors upstream LLM)
Ce que nous mesurons : Temps de réponse P95 pour les endpoints /v1/*, hors endpoints qui font proxy d'appels LLM (qui sont bornés par le provider upstream).
SLO : ≤ 250 ms.
Correction du replay d'Idempotency-Key
Ce que nous mesurons : La proportion de requêtes de mutation rejouées (même Idempotency-Key, même empreinte de corps) qui renvoient la réponse cachée sans ré-exécuter la mutation. SLO : 100 % — zéro double-exécution.
Observer
Fraîcheur des traces
Ce que nous mesurons : P95 du temps écoulé entre la requête gateway et l'apparition d'une ligne AP-Trace dans le trace store de l'observer. SLO : P95 ≤ 5 min.
Couverture de détection de dérive
Ce que nous mesurons : La proportion d'agents avec integrity_mode != off et ≥ 10 traces dans les 7 derniers jours qui ont au moins une évaluation de dérive dans la même fenêtre.
SLO : ≥ 99 % sur une fenêtre glissante de 7 jours.
Adversarial (Arena ↔ Safe House)
Taux de chute du défenseur Arena
Ce que nous mesurons : La proportion de tentatives arena où l'agent défenseur est tombé face à une attaque malgré la surface pertinente de la Protection card activée. SLO : ≤ 5 % sur une fenêtre glissante de 7 jours. Une violation soutenue bloque la promotion en production. Pourquoi : L'arena est une sonde continue de faux négatifs sur la détection Safe House. Un pic signifie qu'une nouvelle catégorie d'attaque contourne la chaîne — Safe House reçoit une mise à jour de détecteur avant le prochain déploiement.
Taux de faux positifs Arena
Ce que nous mesurons : La proportion de tentatives arena jugées structurellement bénignes par revue a posteriori qui ont néanmoins déclenché une intervention Safe House. SLO : ≤ 2 % sur une fenêtre glissante de 30 jours.
Comment ces SLO évoluent
- Cette page est revue trimestriellement. La prochaine revue est T3 2026.
- Une relaxation d'un engagement public requiert un raisonnement publié.
- Un resserrement (nous dépassons notre cible de façon constante) est une bonne nouvelle et est rétroporté ici.
- L'état en direct de chaque SLO est sur status.mnemom.ai.
- Les consommations de budget déclenchent automatiquement des incidents sur la page de statut via le hook Grafana → Betterstack.
D'où cela vient
Ces cibles sont issues du document opérationnel interne des SLO de Mnemom. Ce document porte le contexte additionnel — ancres d'architecture, liens de dashboards, statut d'instrumentation, timestamps de recalibration — que le programme Safe House Hardening utilise en interne. Cette page publique porte les cibles et le raisonnement.
Items ouverts que la prochaine vague d'expansion ajoutera probablement : temps de réponse aux incidents (par exemple, détection de compromission jusqu'à notification client), cadence de rotation des clés de signature, taux de réussite du corpus de tests adversariaux, fraîcheur de la deny-list du validator, intégrité de signature d'approbation dans le pipeline de recettes.
