Runtime Intelligence : le verdict vient du réel
Un déploiement « qui s'est bien passé » n'est pas un déploiement qui marche. Runtime Intelligence lit l'état réel, compare baseline et candidate, et rend un verdict outcome indépendant — l'IA n'est jamais juge et partie de son propre changement.
Le mécanisme — du signal au verdict
Chaque changement porte un contrat d'outcome : les signaux attendus, les seuils, la fenêtre d'observation. Après l'action, l'évaluateur compare l'observé au promis — et les seuils sont calculés hors modèle : le LLM peut expliquer les résultats, il ne les décide pas.
verification: trace_id: uuid baseline_ref: evidence candidate_ref: artifact-digest signal_results: - signal_id: service.availability expected: ">= 99.9%" observed: "99.95%" status: pass verdict: pass | fail | unknown | degraded response: promote | hold | rollback | degrade | escalate
Quatre verdicts, pas deux
Le verdict le plus important est UNKNOWN : un signal périmé ou non attribuable ne devient pas « zéro problème » — il devient un aveu d'ignorance explicite, qui bloque la promotion.
Ce que ça rend déterministe
- Seuils hors prompt : les comparaisons sont calculées par du code, pas racontées par le modèle.
- Fraîcheur contractuelle : chaque signal déclare son
freshness_slo, son owner et son scope. - Attribution : hash d'artefact +
trace_idrelient le signal au changement — sans attribution suffisante, verdict UNKNOWN. - Hold / rollback sur régression : le runtime governor peut demander hold, freeze, rollback, isolate ou declare incident.
Vos déploiements IA sont-ils vérifiés ?
Auditons votre boucle outcome : qui rend le verdict après un changement, et sur quels signaux.
Réserver mon audit AIDO de 30 min