Resolution Status Audit¶

Status: CURRENT

À quoi sert cet audit ?¶

Le Resolution Status Audit est un Read Service qui observe les décisions déjà produites par le Resolver et mesure la répartition des statuts de résolution.

Il ne résout rien lui-même. Il explique l'état réel des décisions et aide à distinguer une absence de preuve, une ambiguïté, un conflit et une résolution effectivement obtenue.

Données normalisées
      ↓
Resolver
      ↓
Decision de résolution
      ↓
Resolution Status Audit
      ↓
Répartition + raisons + échantillons

Vocabulaire canonique¶

Les statuts métier à utiliser sont :

Statut	Signification
`resolved`	Une identité est retenue avec des preuves suffisantes et sans conflit bloquant.
`unknown`	Les informations disponibles ne permettent pas de former une hypothèse exploitable.
`ambiguous`	Plusieurs candidats restent plausibles sans preuve suffisante pour les départager.
`conflict`	Des évidences incompatibles empêchent volontairement la résolution.

Les anciennes catégories telles que « résolution complète », « partielle » ou « impossible » peuvent exister dans des rapports historiques, mais elles ne doivent pas créer un vocabulaire métier parallèle lorsque le Resolver expose les statuts canoniques ci-dessus.

Pourquoi il existe¶

Un taux global de résolution ne suffit pas à diagnostiquer le Domain Core.

Par exemple, une baisse de resolved peut signifier :

davantage de données réellement insuffisantes ;
une nouvelle règle qui expose mieux les conflits ;
une régression de normalisation ;
une population différente ;
une projection ou un snapshot obsolète.

L'audit doit donc conserver les raisons et le périmètre, pas seulement les pourcentages.

Entrées¶

Une exécution reproductible doit identifier :

le run, snapshot ou dataset ;
la verticale et les feeds concernés ;
la version du Resolver et des règles ;
les filtres ;
la population éligible ;
les éventuelles exclusions.

Selon l'implémentation, l'audit peut lire :

les décisions sérialisées ;
les Canonical Identities ;
les candidats et reason codes ;
les conflits enregistrés ;
les métadonnées de confiance.

Sorties attendues¶

Le rapport doit exposer au minimum :

nombre total de cas évalués ;
compteurs resolved, unknown, ambiguous, conflict ;
ratios correspondants ;
reason codes principaux ;
distribution éventuelle des niveaux de confiance ;
exemples représentatifs ;
exclusions et erreurs techniques.

Exemple de réconciliation :

eligible
= resolved
+ unknown
+ ambiguous
+ conflict
+ technical_failure

La formule exacte dépend du service, mais les erreurs techniques ne doivent jamais être fusionnées avec unknown.

Lecture seule¶

Le Resolution Status Audit peut :

lire les décisions existantes ;
agréger les statuts ;
analyser les raisons ;
sélectionner des échantillons ;
produire un rapport.

Il ne doit jamais :

modifier une Canonical Identity ;
relancer une résolution ;
modifier les candidats ;
appeler un Write Service ;
corriger automatiquement un conflit ;
changer une projection ou un feed.

Comment diagnostiquer une variation¶

Si la répartition change entre deux exécutions, vérifier dans cet ordre :

la population comparée est-elle la même ?
les runs ou snapshots sont-ils comparables ?
les règles et configurations sont-elles identiques ?
la normalisation en amont a-t-elle changé ?
les reason codes indiquent-ils une famille précise ?
les conflits nouveaux sont-ils légitimes ?
des erreurs techniques ont-elles été comptées à tort comme unknown ?

Il faut éviter d'optimiser artificiellement le taux resolved en transformant des conflits ou ambiguïtés réels en décisions forcées.

Ce qu'il ne faut pas en déduire¶

Un taux resolved élevé n'est pas automatiquement un signe de qualité.

Une Platform qui force systématiquement une décision peut afficher un meilleur KPI tout en augmentant les faux positifs.

À l'inverse, une hausse de conflict peut être saine si une nouvelle règle expose des contradictions auparavant masquées.

L'audit doit être interprété avec :

les reason codes ;
les exemples ;
les données source ;
les comparaisons avant/après ;
les critères métier de la verticale.

Relation avec les autres Read Services¶

Virtual Candidates Dump : explique les candidats et évidences derrière une décision.
Difference Family Audit : regroupe les causes récurrentes d'écarts.
Real Sample Comparison : analyse des cas concrets par rapport à une référence.
Remaining Audit : mesure ce qui reste à traiter en fin de cycle.

Le Resolution Status Audit fournit la vue quantitative de la résolution ; les autres services aident à expliquer les causes.

Reproductibilité¶

À dataset, configuration et version identiques, les compteurs métier doivent être stables.

Le rapport doit conserver :

le run ou snapshot ;
les filtres ;
la version du code ;
la version des règles ;
les options de calcul.

Tests attendus¶

Les tests doivent couvrir :

les quatre statuts canoniques ;
la réconciliation des compteurs ;
l'absence d'écriture ;
la séparation entre unknown et erreur technique ;
la stabilité des reason codes ;
le déterminisme ;
des cas ambigus et conflictuels représentatifs.

Invariants¶

L'audit est read-only.
Les statuts canoniques sont resolved, unknown, ambiguous, conflict.
Les erreurs techniques restent séparées des statuts métier.
Les compteurs sont réconciliables.
Les raisons accompagnent les totaux.
Un bon KPI ne justifie jamais une décision forcée.
L'audit observe le Resolver sans participer à la résolution.