De qué se trata
Esta es la versión pública de los objetivos de nivel de servicio de Mnemom. Cada indicador a continuación es la meta a la que Mnemom se compromete públicamente; cada indicador también es verificado por el harness de validación en CI. El estado actual en vivo está en status.mnemom.ai. Cuando un SLO consume su budget, se crea un incidente automáticamente y se publica allí.
Esta página es el resumen orientado al cliente del programa operativo interno de SLO de Mnemom: metas, alcance y el razonamiento detrás de cada compromiso.
Formato
Cada SLI define qué medimos. Cada SLO define la meta a la que nos comprometemos.
Gateway
Sobrecarga de dispatch de Safe House
Qué medimos: El tiempo que la Safe House de Mnemom añade a una solicitud del gateway, medido como gateway_total - upstream_provider - aip_analysis.
SLO: P50 ≤ 15 ms · P95 ≤ 60 ms.
Por qué: El dispatch de Safe House está en la ruta síncrona de solicitud. Debe ser barato. La afirmación al cliente es «Mnemom añade unos 15 ms»; este SLO es lo que la hace verdadera.
Sobrecarga de evaluación de policy CLPI
Qué medimos: Tiempo de evaluación de una llamada a herramienta contra la policy del agente cuando CLPI está activo. SLO: P50 ≤ 10 ms · P95 ≤ 40 ms. Por qué: CLPI filtra el uso de herramientas de forma síncrona. La latencia de cola es visible para el cliente.
Latencia añadida por análisis AIP
Qué medimos: Tiempo que añade el análisis de integridad, medido entre la finalización de la respuesta upstream y la entrega al cliente. AIP se ejecuta post-respuesta, pre-entrega — nunca como una interrupción a mitad de stream. SLO: P50 ≤ 800 ms · P95 ≤ 2 500 ms. Por qué: El análisis de integridad es el coste principal; lo acotamos explícitamente para que los clientes puedan planificar. El encuadre post-respuesta es honesto — hoy no hay capacidad de interrupción de streaming.
Fidelidad del modo off
Qué medimos: Conteo de checkpoints de integridad o evaluaciones de policy escritas cuando la card del agente dice integrity_mode: off o autonomy_mode: off.
SLO: Exactamente 0 sobre una ventana móvil de 7 días.
Por qué: Off significa off. Cualquier número distinto de cero viola el contrato del master switch.
Chat Always Completes
Qué medimos: La fracción de solicitudes visibles al cliente donde Safe House intervino en cualquier modo y en cualquier checkpoint y la solicitud devolvió 2xx al cliente. SLO: ≥ 99,99 % sobre una ventana móvil de 7 días. Más de 5 violaciones en cualquier semana dispara una revisión de causa raíz. Por qué: Este es el invariante unificador de Mnemom. Safe House actúa en el mismo turno — puerta de entrada (sustitución de entrada), interior.autonomía (intercepción de llamadas a herramientas), interior.integridad (sustitución de respuesta), puerta de salida (modificación de payload). Un no-2xx atribuible a Safe House es una violación de contrato.
Tasa de explicación visible al usuario
Qué medimos: La fracción de intervenciones nudge o enforce donde la respuesta entregada al cliente contiene lenguaje que nombra lo que prevenimos o modificamos. SLO: 100 % sobre una ventana móvil de 7 días. Por qué: La prevención silenciosa es una regresión de UX incluso cuando la acción se bloquea correctamente. Si intervenimos, lo decimos — cada vez. El gateway inyecta como sufijo una nota estructurada antes de la entrega si el lenguaje natural del agente no referenciaba ya la intervención.
Por proveedor
Cobertura AIP por proveedor
Qué medimos: La fracción de checkpoints de integridad (en modelos con capacidad de thinking) donde el verificador tuvo inspección completa de la traza de thinking, desglosado por proveedor upstream. Metas, ventana móvil de 30 días:
- Anthropic ≥ 99 % (exposición completa de extended thinking)
- Gemini ≥ 95 % (exposición completa del campo
thoughts) - OpenAI serie o ≥ 50 % (solo resúmenes de reasoning — cobertura parcial por definición)
- Modelos OpenAI sin thinking: excluidos del numerador; AIP degrada a un tratamiento no-thinking según la matriz de funcionalidades.
Por qué: Una calidad uniforme de checkpoints de integridad entre proveedores no es lo que Mnemom entrega, y no fingimos que lo sea. La promesa v1 es diferenciación honesta por proveedor. Este SLO es el compromiso público de que la diferenciación es la que decimos.
Sobrecarga de dispatch por proveedor
Qué medimos: P50/P95 de la latencia de dispatch de Safe House, agrupada por proveedor upstream. SLO: Cada proveedor cumple individualmente la envolvente de dispatch anterior. Las anomalías de cola en la forma de solicitud de un proveedor específico se documentan inline con un plan de mitigación. Por qué: «Mnemom añade ~15 ms» es condicional. Si la ruta de un proveedor es sistemáticamente más lenta, la documentación y la página de estado deben reflejarlo, no enterrarlo.
Latencia de análisis AIP por proveedor
Qué medimos: P50/P95 de la duración del análisis AIP, agrupada por proveedor upstream. SLO: Cada proveedor cumple individualmente la envolvente de latencia de análisis anterior. Por qué: El coste de AIP varía con el volumen de tokens de la respuesta upstream. Las rutas con mucho thinking (extended thinking Anthropic Opus) tienen colas distintas a las de salida ligera (Gemini Flash). Publicar por proveedor para que sepa qué esperar.
Ciclo de vida de las cards
Tiempo hasta canónico tras mutación de card
Qué medimos: Tiempo transcurrido desde un PUT exitoso de una alignment card o protection card hasta que la card canónica refleja el nuevo estado en toda la flota gateway. SLO: P50 ≤ 2 s · P95 ≤ 30 s · P99 ≤ 5 min. Por qué: Los clientes esperan que su guardado surta efecto rápidamente. Cinco minutos es el techo absoluto, no la meta.
Tasa de fallo de compose
Qué medimos: La fracción de mutaciones de card que tienen éxito en validate pero fallan en compose, disparando self-heal. SLO: ≤ 0,1 % sobre una ventana móvil de 7 días.
Latencia de lectura canónica
Qué medimos: P95 de las lecturas de card canónica en la ruta gateway. SLO: P95 ≤ 50 ms cuando el caché KV está caliente; P95 ≤ 200 ms cuando el caché KV está frío (post-despliegue o post-recompose-storm).
Pipeline de recetas
Latencia candidato → promovido
Qué medimos: Tiempo transcurrido desde la creación de una receta candidata hasta su promoción al conjunto activo de recetas. SLO: P50 ≤ 24 h · P95 ≤ 7 días en modo manual-reviewer. Los modos auto-approve aprietan esto a P50 ≤ 4 h, P95 ≤ 24 h para fuentes elegibles. Por qué: La realización de valor del throughput de Arena depende de esta latencia. El modo manual reconoce la carga de los revisores humanos; los modos auto-approve aprietan sustancialmente.
Promoción → propagación KV
Qué medimos: P95 del tiempo transcurrido desde que una receta es promovida hasta que el nuevo estado se refleja en todas las instancias de gateway. SLO: P95 ≤ 30 s. Por qué: El hot-load es la promesa v1. No se requiere despliegue para un nuevo detector.
Profundidad de cola de revisión
Qué medimos: Recetas candidatas pendientes de revisión. SLO: ≤ 100 en cualquier momento. Soft alert a 50; hard alert a 100. Por qué: El backlog es observable. Una cola creciente significa que la capacidad de revisión es el cuello de botella, y se necesita automatización o revisores adicionales.
Tasa de falsos positivos por receta
Qué medimos: Ratio de FP por receta sobre 30 días móviles, ponderado por volumen de hits. SLO: ≤ 2 % por receta sostenido sobre 30 días. Por encima dispara una revisión de retiro. Por qué: Los falsos positivos son los asesinos silenciosos de la confianza del cliente. El retiro integrado mantiene sano el corpus de detectores.
Entrega de webhooks
Cinco indicadores. Los tres primeros son los compromisos principales al cliente. Los dos últimos son suplementos operativos que nos ayudan a depurar la salud de la entrega.
Tasa de éxito de entrega a 10 minutos
Qué medimos: La fracción de eventos webhook que se entregan con éxito (2xx desde el endpoint del cliente, en cualquier intento dentro de la ventana de reintentos) en un plazo de 10 minutos desde la creación del evento. Los endpoints en estado failure_disabled se excluyen del denominador.
SLO: ≥ 99,5 % sobre una ventana móvil de 7 días.
Por qué: Este es el compromiso webhook principal — «si se suscribió, entregamos en 10 minutos» es el listón de la industria que Mnemom iguala.
Tasa de éxito de replay
Qué medimos: La fracción de replays de webhook iniciados por el operador que entregan en 60 segundos. SLO: ≥ 99 % sobre una ventana móvil de 7 días. Por qué: El replay es la superficie de recuperación cuando un endpoint del cliente estaba caído. Si el replay en sí es inestable, la superficie de recuperación no es fiable.
Latencia de primera entrega
Qué medimos: P95 del tiempo entre la creación del evento y el primer intento de entrega.
SLO: P95 ≤ 5 segundos.
Por qué: Este es el SLI de percepción del desarrollador — ¿apareció el webhook rápido en mnemom listen?
Tasa de éxito de entrega final
Qué medimos: La fracción de eventos webhook que finalmente se entregan bajo la política de reintentos antes de ser marcados como fallidos o de auto-deshabilitar el endpoint. SLO: ≥ 99,95 % sobre una ventana móvil de 7 días. Por qué: Suplementa la ventana de 10 minutos — «¿al final pasamos, ignorando el tiempo?» — útil para la salud de la política de reintentos.
Compatibilidad de verificación de firma
Qué medimos: Fallos de verificación HMAC reportados por el cliente por trimestre sobre payloads cuya entrega confirmamos como 2xx. SLO: ≤ 1 por trimestre. Por qué: La compatibilidad HMAC es binaria desde la perspectiva del cliente. Si nuestra convención de firma diverge de un SDK del cliente o de un ejemplo de documentación, todo el stream parece comprometido.
Superficie API
Disponibilidad de API
Qué medimos: La fracción de solicitudes /v1/* que devuelven no-5xx, excluyendo mantenimiento programado.
SLO: ≥ 99,9 % sobre una ventana móvil de 30 días.
Latencia P95 de API (excluyendo upstream LLM)
Qué medimos: Tiempo de respuesta P95 para endpoints /v1/*, excluyendo endpoints que proxean llamadas LLM (que están limitadas por el proveedor upstream).
SLO: ≤ 250 ms.
Corrección de replay de Idempotency-Key
Qué medimos: La fracción de solicitudes de mutación replayed (misma Idempotency-Key, mismo fingerprint de body) que devuelven la respuesta cacheada sin re-ejecutar la mutación. SLO: 100 % — cero doble ejecución.
Observer
Frescura de trazas
Qué medimos: P95 del tiempo transcurrido desde la solicitud al gateway hasta la aparición de una fila AP-Trace en el trace store del observer. SLO: P95 ≤ 5 min.
Cobertura de detección de deriva
Qué medimos: La fracción de agentes con integrity_mode != off y ≥ 10 trazas en los últimos 7 días que tienen al menos una evaluación de deriva en la misma ventana.
SLO: ≥ 99 % sobre una ventana móvil de 7 días.
Adversarial (Arena ↔ Safe House)
Tasa de caída del defensor en Arena
Qué medimos: La fracción de intentos de arena donde el agente defensor cayó ante un ataque a pesar de tener activada la superficie relevante de la Protection card. SLO: ≤ 5 % sobre una ventana móvil de 7 días. Una violación sostenida bloquea la promoción a producción. Por qué: La arena es una sonda continua de falsos negativos sobre la detección de Safe House. Un pico significa que una nueva categoría de ataque está sorteando la cadena — Safe House recibe una actualización de detector antes de que salga el siguiente despliegue.
Tasa de falsos positivos en Arena
Qué medimos: La fracción de intentos de arena juzgados estructuralmente benignos por revisión post-hoc que aun así dispararon una intervención de Safe House. SLO: ≤ 2 % sobre una ventana móvil de 30 días.
Cómo evolucionan estos SLO
- Esta página se revisa trimestralmente. La próxima revisión es Q3 2026.
- Una relajación de cualquier compromiso público requiere un razonamiento publicado.
- Un endurecimiento (superamos nuestra meta de forma constante) son buenas noticias y se retroporta aquí.
- El estado en vivo de cada SLO está en status.mnemom.ai.
- El consumo de budget dispara incidentes automáticos en la página de estado vía el hook Grafana → Betterstack.
De dónde viene esto
Estas metas se extraen del documento operativo interno de SLO de Mnemom. Ese documento lleva el contexto adicional — anclas de arquitectura, enlaces a dashboards, estado de instrumentación, timestamps de recalibración — que el programa Safe House Hardening usa internamente. Esta página pública lleva las metas y el razonamiento.
Elementos abiertos que la próxima ronda de expansión probablemente añadirá: tiempo de respuesta a incidentes (p. ej., detección de compromiso hasta notificación al cliente), cadencia de rotación de claves de firma, tasa de aprobación del corpus de pruebas adversariales, frescura de la deny-list del validator, integridad de firma de aprobación del pipeline de recetas.
