Aller au contenu

resolution-status-audit

resolution-status-audit est la page opérateur pour exploiter le Resolution Status Audit dans les validations Platform.

La définition du Read Service et sa place conceptuelle sont documentées dans ../read-services/resolution-status-audit.md.

Cette page décrit uniquement :

  • quand lancer l'audit ;
  • ce qu'il faut observer dans les statuts ;
  • comment décider si un delta de statut est acceptable ;
  • comment préparer une simulation ou un patch virtuel.

Rôle pratique

Cette étape sert à répondre à une question simple :

l'identité est-elle réellement mauvaise, ou est-ce surtout le statut de résolution qui diverge ?

Elle est particulièrement utile quand :

  • old_identity == platform_identity ;
  • mais old_status != platform_status ;
  • ou quand une verticale semble trop stricte sur certains cas bruités.

Position dans le workflow

real-sample-comparison
-> difference-family-audit
-> resolution-status-audit
-> virtual-patch
-> validation-report

Quand l'utiliser

Utiliser resolution-status-audit quand :

  • les écarts semblent concentrés sur resolved, invalid, conflict_blocking ou un statut voisin ;
  • l'identité retenue paraît correcte mais la Platform reste trop prudente ;
  • on veut distinguer un vrai conflit d'un simple delta de sévérité ;
  • on prépare un assouplissement local de policy dans une verticale.

Entrées attendues

L'audit s'appuie en pratique sur :

  • les identités old/new ;
  • les statuts old/new ;
  • les candidats retenus et rejetés si disponibles ;
  • les raisons de conflit ou de blocage ;
  • les attributs métier détectés ;
  • les titres marchands et sources pour comprendre le bruit.

Sorties attendues

On attend typiquement :

  • la répartition des transitions de statut ;
  • les cas resolution_status_only ;
  • les causes probables par famille ;
  • des exemples détaillés ;
  • une recommandation : garder strict, simuler un assouplissement, ou ne rien faire.

Comment lire les résultats

Lecture recommandée :

  • identité différente + statut différent : problème métier plus large ;
  • identité identique + statut différent : bon candidat à une simulation locale ;
  • statut plus strict à cause de signaux forts : mount, focal, refurb, cross-brand, vrai conflit : garder strict ;
  • statut plus strict à cause de pollution accessoire ou bruit marchand : possible candidat à virtual-patch.

Décision industrielle

Après resolution-status-audit, on doit pouvoir classer les cas en trois groupes :

  • à laisser stricts ;
  • à simuler ;
  • à exclure de tout patch immédiat.

Un bon audit de statut évite les patches trop larges qui dégraderaient les garde-fous.

Garde-fous

resolution-status-audit ne doit jamais être utilisé pour :

  • assouplir à l'aveugle des conflits réels ;
  • mélanger bruit marchand et vrai conflit métier ;
  • modifier le Core directement ;
  • justifier un patch sans cas explicitement mesurés.

Voir aussi