Contrat de politique de conflit¶

Statut : CONTRACT

À quoi sert cette politique ?¶

La Conflict Policy — politique de conflit — détermine si les preuves disponibles sont compatibles, ambiguës, insuffisantes ou réellement contradictoires.

Elle ne choisit pas l'identité finale. Elle prépare une évaluation explicable que l'Identity Resolver utilisera ensuite pour décider.

Preuves normalisées
        ↓
     Candidats
        ↓
 Conflict Policy
        ↓
Évaluation du conflit
        ↓
 Identity Resolver
        ↓
Décision d'identité

Pour une personne qui reprend le projet, la phrase importante est :

La Conflict Policy classe les incompatibilités ; le Resolver prend la décision finale.

Pourquoi séparer conflit et résolution ?¶

Sans cette séparation, une règle qui constate « ces deux modèles sont incompatibles » pourrait aussi décider arbitrairement lequel doit gagner.

CMonChoix sépare donc :

l'observation des preuves ;
la classification de leurs incompatibilités ;
la résolution finale de l'identité.

Cette séparation rend les décisions testables et explicables.

Entrées¶

La politique reçoit un contexte d'évaluation en lecture seule pouvant contenir :

les candidats comparés ;
les identifiants normalisés ;
les attributs du produit ;
les attributs de variante ;
la provenance des preuves ;
les niveaux de confiance ;
les signaux spécialisés fournis par une verticale ;
les incompatibilités déjà détectées.

Elle ne doit pas aller chercher silencieusement des données manquantes dans WordPress, SQL ou un état Runtime mutable.

Sortie¶

Le résultat doit être structuré et sérialisable. Il expose notamment :

un état canonique ;
une gravité ;
des codes de raison stables ;
les preuves associées ;
le périmètre concerné : produit, variante ou attribut ;
éventuellement un niveau de confiance ;
éventuellement une demande de revue.

Les quatre états à connaître¶

État	Signification simple
`none`	Aucune incompatibilité importante n'a été trouvée.
`unknown`	Il manque des preuves pour conclure.
`ambiguous`	Plusieurs interprétations restent plausibles.
`conflict`	Des preuves se contredisent réellement et bloquent une résolution sûre.

Ces états ne sont pas interchangeables.

Exemple : `unknown`¶

Le marchand ne fournit pas la génération du produit et aucune autre source fiable ne permet de la déduire.

Ce n'est pas un conflit : l'information manque.

Exemple : `ambiguous`¶

Deux candidats restent compatibles avec les informations disponibles et aucun signal ne permet de les départager proprement.

Il ne faut pas choisir au hasard.

Exemple : `conflict`¶

Une preuve forte indique un modèle et une autre preuve forte indique un modèle incompatible.

Le conflit doit rester visible au lieu d'être masqué par un score moyen.

Familles de conflits¶

Les incompatibilités peuvent être classées dans des familles stables, par exemple :

marque ;
type ou famille de produit ;
modèle ;
génération ;
variante ;
identifiant ;
attribut ;
contradiction entre sources ;
preuves insuffisantes.

Une verticale peut ajouter des codes plus précis, mais ils doivent rester rattachables à une famille commune.

Gravité¶

La gravité exprime l'impact opérationnel du signal.

Niveaux recommandés :

info : différence sans conséquence importante ;
review : situation à examiner ou nécessitant davantage de preuves ;
blocking : incompatibilité empêchant une résolution sûre.

Une preuve faible ne doit jamais effacer silencieusement un conflit bloquant issu d'une preuve plus forte.

Ordre de raisonnement¶

Il est généralement plus sûr d'évaluer les frontières d'identité les plus fortes avant les détails secondaires :

marque
  ↓
type / famille de produit
  ↓
modèle / génération
  ↓
variante
  ↓
attributs secondaires

Pourquoi ? Parce que deux produits différents peuvent partager une couleur, une capacité ou un mot dans leur titre. Une ressemblance faible ne doit pas masquer une incompatibilité fondamentale.

Produit et variante : ne pas les confondre¶

Une différence de couleur ou de capacité peut parfois représenter deux variantes du même produit plutôt que deux produits distincts.

La politique doit donc préserver la frontière entre :

identité du produit ;
identité de la variante ;
simple attribut descriptif.

Cette distinction dépend en partie de la verticale concernée.

Rôle des Vertical Modules¶

Le contrat générique ne doit pas connaître tous les détails de chaque famille de produits.

Par exemple, des notions comme une édition de jeu, une monture photo ou une génération de smartphone peuvent nécessiter des règles spécialisées.

Les Vertical Modules peuvent fournir :

des preuves supplémentaires ;
des règles de comparaison ;
des codes de raison spécialisés ;
une gravité adaptée ;
des seuils de revue.

Mais ils ne doivent pas contourner le mécanisme générique ni décider directement à la place du Resolver.

Règles sur les preuves¶

Chaque raison de conflit doit permettre de retrouver :

les champs ou identifiants comparés ;
les valeurs normalisées ;
leur provenance ;
la règle de comparaison utilisée ;
la famille de conflit ;
la gravité obtenue.

Une absence de preuve ne doit pas être transformée en compatibilité positive.

Autrement dit :

« je ne sais pas » ≠ « c'est compatible »

Relation avec Media Quality¶

Media Quality peut détecter une incohérence entre une image et les informations attendues d'un produit, par exemple une couleur ou un modèle visuellement incompatible.

Cette observation reste d'abord une preuve de qualité média.

Elle ne doit pas automatiquement :

modifier l'identité produit ;
supprimer une image ;
vider image_norm ;
transformer une anomalie média en conflit d'identité.

Une mutation éventuelle passe par un Write Service distinct et explicitement autorisé.

Déterminisme¶

Avec les mêmes candidats, preuves, règles et configuration, la politique doit retourner le même résultat.

Cela implique notamment :

normalisation stable ;
priorité stable des règles ;
départage stable ;
absence de dépendance à l'heure courante ;
absence de dépendance à un ordre d'itération aléatoire ;
versionnement lorsqu'une règle change réellement le comportement.

Ce que la politique ne doit jamais faire¶

Elle ne doit jamais :

choisir elle-même le candidat gagnant ;
créer une Canonical Identity ;
calculer à elle seule le score global de qualité ;
modifier une offre ou une projection ;
écrire en SQL ;
dépendre de WordPress ;
masquer une contradiction de marque ou de famille ;
considérer une donnée absente comme une preuve positive ;
promouvoir une convention propre à un marchand en règle globale ;
mélanger identité produit et variante ;
contourner le Resolver.

Comment diagnostiquer un conflit¶

Quand un produit apparaît en conflict ou ambiguous, suivre cet ordre :

relever les reason_codes ;
retrouver les preuves correspondantes ;
vérifier leur provenance et leur normalisation ;
déterminer si le désaccord porte sur le produit ou seulement sur une variante ;
vérifier si une règle verticale intervient ;
vérifier la gravité attribuée ;
seulement ensuite examiner la décision du Resolver.

Ne commence pas par modifier le score ou forcer un candidat : cela masquerait potentiellement la cause réelle.

Observabilité¶

Les audits devraient pouvoir compter au minimum :

comparaisons évaluées ;
résultats none ;
résultats unknown ;
résultats ambiguous ;
conflits bloquants ;
occurrences par famille de raison ;
occurrences par verticale ;
occurrences par source ;
cas nécessitant une revue.

Les totaux doivent être réconciliables avec la population réellement évaluée.

Tests attendus¶

Chaque implémentation importante doit tester :

le déterminisme ;
la stabilité des codes de raison ;
la frontière produit / variante ;
les preuves manquantes donnant unknown ;
plusieurs candidats plausibles donnant ambiguous ;
les conflits bloquants de marque, famille et modèle ;
les enrichissements compatibles restant non bloquants ;
l'isolation des règles verticales ;
la sérialisation du résultat ;
l'absence de dépendance SQL, WordPress et Runtime ;
le comportement non destructif de Media Quality.

Invariants¶

La politique classe ; le Resolver décide.
Une preuve manquante est différente d'une preuve contradictoire.
Une ambiguïté reste visible au lieu d'être forcée en résolution.
Tout conflit possède des preuves et des codes de raison explicites.
Les règles propres aux verticales restent hors du mécanisme générique du Domain Core.
L'évaluation est déterministe, sans effet de bord et en lecture seule.
Une observation qualité ne modifie jamais implicitement l'identité ou une projection.

Règle de transmission¶

Si tu vois un conflit, ne cherche pas d'abord à le faire disparaître. Cherche à comprendre quelle preuve contredit quelle autre preuve.

Un conflit visible est souvent plus sain qu'une résolution apparemment parfaite obtenue en ignorant une information gênante.