Di cosa si tratta
Questa è la versione pubblica dei service-level objectives di Mnemom. Ogni indicatore qui sotto è il target a cui Mnemom si impegna pubblicamente; ogni indicatore è anche verificato dal validation harness in CI. Lo stato live corrente è su status.mnemom.ai. Quando uno SLO consuma il suo budget, viene creato automaticamente un incidente e pubblicato lì.
Questa pagina è il riassunto rivolto ai clienti del programma operativo interno di SLO di Mnemom: target, ambito e il razionale dietro ogni impegno.
Formato
Ogni SLI definisce cosa misuriamo. Ogni SLO definisce il target a cui ci impegniamo.
Gateway
Overhead di dispatch Safe House
Cosa misuriamo: Il tempo che la Safe House di Mnemom aggiunge a una richiesta gateway, misurato come gateway_total - upstream_provider - aip_analysis.
SLO: P50 ≤ 15 ms · P95 ≤ 60 ms.
Perché: Il dispatch Safe House è nel percorso sincrono della richiesta. Deve essere economico. L'affermazione al cliente è «Mnemom aggiunge circa 15 ms»; questo SLO è ciò che la rende vera.
Overhead di valutazione policy CLPI
Cosa misuriamo: Tempo per valutare una chiamata a tool rispetto alla policy dell'agente quando CLPI è attivo. SLO: P50 ≤ 10 ms · P95 ≤ 40 ms. Perché: CLPI controlla l'uso dei tool in modo sincrono. La latenza di coda è visibile al cliente.
Latenza aggiunta dall'analisi AIP
Cosa misuriamo: Tempo che l'analisi di integrità aggiunge, misurato tra il completamento della risposta upstream e la consegna al cliente. AIP gira post-risposta, pre-consegna — mai come interruzione mid-stream. SLO: P50 ≤ 800 ms · P95 ≤ 2 500 ms. Perché: L'analisi di integrità è il costo portante; lo limitiamo esplicitamente perché i clienti possano pianificare. Il framing post-risposta è onesto — oggi non c'è capacità di interruzione streaming.
Fedeltà della modalità off
Cosa misuriamo: Numero di checkpoint di integrità o valutazioni di policy scritte quando la card dell'agente dice integrity_mode: off o autonomy_mode: off.
SLO: Esattamente 0 su finestra mobile di 7 giorni.
Perché: Off vuol dire off. Qualsiasi valore non nullo viola il contratto del master switch.
Chat Always Completes
Cosa misuriamo: La frazione di richieste visibili al cliente in cui Safe House è intervenuta in qualsiasi modalità su qualsiasi checkpoint e la richiesta ha restituito 2xx al cliente. SLO: ≥ 99,99 % su finestra mobile di 7 giorni. Più di 5 violazioni in una settimana fanno scattare una root-cause review. Perché: Questo è l'invariante unificante di Mnemom. Safe House interviene nello stesso turno — porta d'ingresso (sostituzione di input), interno.autonomia (intercettazione di chiamate a tool), interno.integrità (sostituzione di risposta), porta d'uscita (modifica di payload). Un non-2xx attribuibile a Safe House è una violazione del contratto.
Tasso di spiegazione visibile all'utente
Cosa misuriamo: La frazione di interventi nudge o enforce in cui la risposta consegnata al cliente contiene linguaggio che nomina ciò che abbiamo impedito o modificato. SLO: 100 % su finestra mobile di 7 giorni. Perché: La prevenzione silenziosa è una regressione UX anche quando l'azione è correttamente bloccata. Se interveniamo, lo diciamo — ogni volta. Il gateway inietta in suffisso una nota strutturata prima della consegna se il linguaggio naturale dell'agente non riferiva già l'intervento.
Per provider
Copertura AIP per provider
Cosa misuriamo: La frazione di checkpoint di integrità (su modelli capaci di thinking) in cui il verificatore aveva ispezione completa della trace di thinking, ripartita per provider upstream. Target, finestra mobile di 30 giorni:
- Anthropic ≥ 99 % (esposizione completa dell'extended thinking)
- Gemini ≥ 95 % (esposizione completa del campo
thoughts) - OpenAI serie o ≥ 50 % (solo riassunti di reasoning — copertura parziale per definizione)
- Modelli OpenAI senza thinking: esclusi dal numeratore; AIP degrada a un trattamento non-thinking secondo la matrice di funzionalità.
Perché: Una qualità uniforme dei checkpoint di integrità tra provider non è ciò che Mnemom consegna, e non facciamo finta. La promessa v1 è una differenziazione per provider onesta. Questo SLO è l'impegno pubblico che la differenziazione è quella che dichiariamo.
Overhead di dispatch per provider
Cosa misuriamo: P50/P95 della latenza di dispatch Safe House, raggruppate per provider upstream. SLO: Ogni provider soddisfa individualmente l'envelope di dispatch sopra. Le anomalie di coda sulla forma di richiesta di uno specifico provider sono documentate inline con un piano di mitigazione. Perché: «Mnemom aggiunge ~15 ms» è condizionale. Se il percorso di un provider è sistematicamente più lento, la documentazione e la status page devono rifletterlo, non seppellirlo.
Latenza di analisi AIP per provider
Cosa misuriamo: P50/P95 della durata dell'analisi AIP, raggruppate per provider upstream. SLO: Ogni provider soddisfa individualmente l'envelope di latenza di analisi sopra. Perché: Il costo AIP varia con il volume di token della risposta upstream. I percorsi thinking-pesanti (extended thinking Anthropic Opus) hanno code diverse dai percorsi a output snello (Gemini Flash). Pubblicare per provider perché tu sappia cosa aspettarti.
Ciclo di vita delle card
Time-to-canonical dopo mutazione di card
Cosa misuriamo: Tempo trascorso da un PUT riuscito di una alignment card o protection card fino a quando la card canonica riflette il nuovo stato sull'intera flotta gateway. SLO: P50 ≤ 2 s · P95 ≤ 30 s · P99 ≤ 5 min. Perché: I clienti si aspettano che il loro save abbia effetto velocemente. Cinque minuti è il tetto assoluto, non il target.
Tasso di fallimento di compose
Cosa misuriamo: La frazione di mutazioni di card che hanno successo al validate ma falliscono al compose, attivando self-heal. SLO: ≤ 0,1 % su finestra mobile di 7 giorni.
Latenza di lettura canonica
Cosa misuriamo: P95 delle letture di card canonica sul percorso gateway. SLO: P95 ≤ 50 ms quando la cache KV è calda; P95 ≤ 200 ms quando la cache KV è fredda (post-deploy o post-recompose-storm).
Pipeline delle ricette
Latenza candidato → promosso
Cosa misuriamo: Tempo trascorso dalla creazione di una ricetta candidata alla sua promozione nel set attivo di ricette. SLO: P50 ≤ 24 h · P95 ≤ 7 giorni in modalità manual-reviewer. Le modalità auto-approve stringono questo a P50 ≤ 4 h, P95 ≤ 24 h per le sorgenti eligible. Perché: La realizzazione di valore del throughput Arena dipende da questa latenza. La modalità manuale riconosce il carico dei reviewer umani; le modalità auto-approve stringono sostanzialmente.
Promozione → propagazione KV
Cosa misuriamo: P95 del tempo trascorso da quando una ricetta è promossa a quando il nuovo stato si riflette su tutte le istanze gateway. SLO: P95 ≤ 30 s. Perché: L'hot-load è la promessa v1. Nessun deploy richiesto per un nuovo detector.
Profondità della coda di review
Cosa misuriamo: Ricette candidate in attesa di review. SLO: ≤ 100 in qualsiasi momento. Soft alert a 50; hard alert a 100. Perché: Il backlog è osservabile. Una coda crescente significa che la capacità di review è il collo di bottiglia, e servono o automazione o reviewer aggiuntivi.
Tasso di falsi positivi per ricetta
Cosa misuriamo: Rapporto FP per ricetta su 30 giorni mobili, pesato per volume di hit. SLO: ≤ 2 % per ricetta sostenuto su 30 giorni. Sopra fa scattare una review di retirement. Perché: I falsi positivi sono gli assassini silenziosi della fiducia del cliente. Il retirement integrato mantiene sano il corpus di detector.
Consegna webhook
Cinque indicatori. I primi tre sono gli impegni portanti verso il cliente. Gli ultimi due sono supplementi operativi che ci aiutano a debuggare la salute della consegna.
Tasso di successo di consegna a 10 minuti
Cosa misuriamo: La frazione di eventi webhook che vengono consegnati con successo (2xx dall'endpoint del cliente, in qualsiasi tentativo entro la finestra di retry) entro 10 minuti dalla creazione dell'evento. Gli endpoint in stato failure_disabled sono esclusi dal denominatore.
SLO: ≥ 99,5 % su finestra mobile di 7 giorni.
Perché: Questo è l'impegno webhook principale — «se ti sei iscritto, abbiamo consegnato entro 10 minuti» è l'asticella di settore che Mnemom eguaglia.
Tasso di successo di replay
Cosa misuriamo: La frazione di replay webhook iniziati dall'operatore che consegnano entro 60 secondi. SLO: ≥ 99 % su finestra mobile di 7 giorni. Perché: Il replay è la superficie di recovery quando un endpoint del cliente era down. Se il replay stesso è instabile, la superficie di recovery non è affidabile.
Latenza di prima consegna
Cosa misuriamo: P95 del tempo tra creazione dell'evento e primo tentativo di consegna.
SLO: P95 ≤ 5 secondi.
Perché: Questo è lo SLI di percezione sviluppatore — il webhook è apparso velocemente in mnemom listen?
Tasso di successo di consegna finale
Cosa misuriamo: La frazione di eventi webhook che alla fine vengono consegnati sotto la retry policy prima di essere marcati come failed o di auto-disabilitare l'endpoint. SLO: ≥ 99,95 % su finestra mobile di 7 giorni. Perché: Supplementa la finestra di 10 minuti — «alla fine siamo passati, ignorando il tempo» — utile per la salute della retry policy.
Compatibilità di verifica firma
Cosa misuriamo: Fallimenti di verifica HMAC segnalati dal cliente per trimestre su payload la cui consegna abbiamo confermato come 2xx. SLO: ≤ 1 per trimestre. Perché: La compatibilità HMAC è binaria dalla prospettiva del cliente. Se la nostra convenzione di firma diverge da un SDK del cliente o da un esempio di documentazione, l'intero stream sembra compromesso.
Superficie API
Disponibilità API
Cosa misuriamo: La frazione di richieste /v1/* che restituiscono non-5xx, esclusa la manutenzione programmata.
SLO: ≥ 99,9 % su finestra mobile di 30 giorni.
Latenza P95 API (esclusi upstream LLM)
Cosa misuriamo: Tempo di risposta P95 per gli endpoint /v1/*, esclusi gli endpoint che proxano chiamate LLM (che sono limitati dal provider upstream).
SLO: ≤ 250 ms.
Correttezza del replay con Idempotency-Key
Cosa misuriamo: La frazione di richieste di mutation rieseguite (stessa Idempotency-Key, stesso fingerprint del body) che restituiscono la risposta cachata senza ri-eseguire la mutation. SLO: 100 % — zero doppia esecuzione.
Observer
Freschezza delle trace
Cosa misuriamo: P95 del tempo trascorso dalla richiesta al gateway alla comparsa di una riga AP-Trace nel trace store dell'observer. SLO: P95 ≤ 5 min.
Copertura della detection di drift
Cosa misuriamo: La frazione di agenti con integrity_mode != off e ≥ 10 trace negli ultimi 7 giorni che hanno almeno una valutazione di drift nella stessa finestra.
SLO: ≥ 99 % su finestra mobile di 7 giorni.
Adversarial (Arena ↔ Safe House)
Tasso di caduta del difensore in Arena
Cosa misuriamo: La frazione di tentativi arena in cui l'agente difensore è caduto a un attacco nonostante la superficie rilevante della Protection card fosse attiva. SLO: ≤ 5 % su finestra mobile di 7 giorni. Una violazione sostenuta blocca la promozione in produzione. Perché: L'arena è una sonda continua di falsi negativi sulla detection Safe House. Un picco significa che una nuova categoria di attacco sta aggirando la catena — Safe House riceve un aggiornamento di detector prima del prossimo deploy.
Tasso di falsi positivi in Arena
Cosa misuriamo: La frazione di tentativi arena giudicati strutturalmente benigni da review post-hoc che hanno comunque attivato un intervento Safe House. SLO: ≤ 2 % su finestra mobile di 30 giorni.
Come evolvono questi SLO
- Questa pagina è rivista trimestralmente. La prossima revisione è Q3 2026.
- Un allentamento di qualsiasi impegno pubblico richiede un razionale pubblicato.
- Un irrigidimento (superiamo il nostro target in modo costante) è una buona notizia e viene retroportato qui.
- Lo stato live di ogni SLO è su status.mnemom.ai.
- Il consumo di budget fa scattare incidenti automatici sulla status page tramite l'hook Grafana → Betterstack.
Da dove viene
Questi target sono tratti dal documento operativo interno degli SLO di Mnemom. Quel documento porta il contesto aggiuntivo — ancore di architettura, link di dashboard, stato di strumentazione, timestamp di ricalibrazione — che il programma Safe House Hardening usa internamente. Questa pagina pubblica porta i target e il razionale.
Punti aperti che la prossima espansione probabilmente aggiungerà: tempo di risposta agli incidenti (es. detection di compromissione fino alla notifica al cliente), cadenza di rotazione delle signing key, tasso di superamento del corpus di test adversariali, freschezza della deny-list del validator, integrità della firma di approvazione nella pipeline delle ricette.
