Résumé

  • La révision 04 du brouillon individuel SAMP introduit record_revision pour les résultats CONFIG et EXEC. Chaque changement matériel produit un numéro supérieur et conserve les états antérieurs dans un journal à ajout seul ; la révision 03 ne portait pas ce champ.
  • Un succès constaté après coup réclame une preuve de l'effet attribuable à la commande initiale. Une requête identique récupère l'état le plus récent sans réexécuter la commande. Si ce dernier état est impossible à établir, le point d'exécution répond back_pressure, sans résultat prétendument définitif.

Une preuve tardive n'est pas une nouvelle commande

Le cas le plus banal est celui d'un agent IA exploité comme service durable : un gestionnaire lui demande un changement de configuration au mauvais moment, avec un lien instable et une prise de poste entre deux équipes. Le projet SAMP décrit précisément cette interface de gestion des agents IA. La console affiche « indéterminé ». Quelques minutes plus tard, un enregistrement d'exécution authentifié permet de conclure que le changement a eu lieu. Effacer l'incertitude initiale prive l'équipe suivante du contexte. Traiter l'absence de réponse comme un échec risque, lui, de répéter la commande et donc son effet.

Le texte daté d'octobre garde la référence de l'opération et l'empreinte de la requête authentifiée. Le premier état faisant autorité prend le numéro 1. Si une preuve recevable résout le cas, le nouvel état prend le numéro 2 ; l'ancien état, le motif d'autorisation, la référence de preuve et l'heure de résolution restent inscrits. Réessayer avec les mêmes octets interroge le registre, il ne presse pas une seconde fois le bouton.

Le brouillon refuse aussi le raccourci du « bon état observé ». Quelqu'un d'autre a pu modifier le paramètre. Le profil de preuve doit rattacher l'effet à cette opération précise. Une décision de politique, un voyant de santé ou une valeur devenue conforme ne suffisent pas. Après un résultat final confirmé, une observation contradictoire devient un conflit d'audit à examiner, pas une gomme.

Même une panne d'enregistrement ne transforme pas un succès en échec. Le texte distingue execution_outcome de audit_persistence. Si une nouvelle révision peut être enregistrée, les deux faits sont rapportés séparément. Si, après redémarrage ou bascule, le point d'exécution ne sait plus quelle révision a été validée en dernier, il ne sert pas une ancienne copie comme vérité courante. La console conserve, de son côté, le plus grand numéro accepté et signale un retour en arrière ou un même numéro portant deux contenus.

La fiche IETF classe SAMP comme brouillon individuel visant le statut Experimental. Une trace authentifiée couvrant l'incertitude, la preuve tardive, l'incrément et le redémarrage permettrait de juger une implémentation réelle.

Sources : révision 04 ; révision 03 ; statut IETF.