Resolver¶

Status: CURRENT

Vue d'ensemble¶

Le Resolver est le moteur de décision du Domain Core.

Il reçoit un ensemble de candidats construits à partir des évidences disponibles, compare leur compatibilité et produit une décision explicable. Il ne fabrique pas une vérité artificielle lorsque les données restent insuffisantes ou contradictoires.

Evidence
   ↓
Candidates
   ↓
Resolver
   ↓
Resolution Decision
   ↓
Canonical Identity (si résolue)

Le Resolver est générique. Les Vertical Modules fournissent des critères et politiques spécialisés, mais ne remplacent pas le mécanisme de décision.

Responsabilités¶

Le Resolver est responsable de :

comparer les candidats sur une base déterministe ;
évaluer les compatibilités et incompatibilités ;
détecter les ambiguïtés et les conflits ;
sélectionner une identité uniquement lorsque les preuves sont suffisantes ;
produire un statut de résolution explicite ;
exposer les raisons principales de la décision ;
préserver les éléments de preuve nécessaires aux audits.

Il n'est pas responsable de :

normaliser les données marchandes ;
extraire les attributs propres à une verticale ;
calculer une projection de lecture ;
exécuter une écriture SQL ;
orchestrer un run ;
appliquer une règle de présentation.

Modèle d'entrée¶

Chaque candidat doit exposer au minimum :

une identité proposée ;
les attributs de produit et de variante concernés ;
les évidences positives ;
les évidences négatives ou contradictoires ;
la provenance des signaux ;
un score ou niveau de confiance explicable ;
les raisons de construction du candidat.

Un candidat sans preuve suffisante reste une hypothèse. Il ne doit pas être promu en identité uniquement parce qu'il est le seul candidat présent.

Statuts de résolution¶

Le Resolver utilise des états explicites et stables.

`resolved`¶

Une seule identité est suffisamment soutenue et aucune contradiction bloquante ne subsiste.

`unknown`¶

Les données disponibles ne permettent pas de construire une décision fiable.

L'absence de preuve n'est pas une preuve négative.

`ambiguous`¶

Plusieurs candidats restent plausibles et les évidences ne permettent pas de les départager avec un niveau de confiance suffisant.

`conflict`¶

Des évidences incompatibles rendent la résolution non fiable ou indiquent que plusieurs identités distinctes ont été mélangées.

Ces états ne doivent pas être remplacés par une sélection forcée.

Cycle de résolution¶

1. Validation des entrées¶

Le Resolver vérifie la forme des candidats et la présence des informations minimales nécessaires à leur comparaison.

2. Déduplication¶

Les candidats strictement équivalents peuvent être regroupés sans perdre leur provenance ni leurs raisons.

3. Compatibilité¶

Les attributs et identifiants sont comparés selon les contrats génériques et les politiques de verticale applicables.

4. Détection des contradictions¶

Les conflits de marque, famille, modèle, génération, variante ou identifiant fort sont rendus explicites.

5. Classement¶

Les candidats compatibles sont ordonnés selon des critères déterministes. L'ordre ne doit jamais dépendre de l'ordre SQL, du marchand ou de l'ordre d'arrivée.

6. Décision¶

Le Resolver retourne une décision structurée contenant :

le statut ;
l'identité retenue lorsqu'elle existe ;
le candidat retenu ;
les candidats rejetés ;
les raisons ;
les conflits détectés ;
le niveau de confiance ;
les éléments nécessitant une revue.

Décision structurée¶

Une décision de résolution doit pouvoir être sérialisée pour les audits et comparaisons.

Exemple conceptuel :

status: ambiguous
selected_candidate: null
confidence: medium
reason_codes:
  - same_brand
  - same_family
  - conflicting_generation
candidates:
  - candidate_a
  - candidate_b
review_required: true

Les codes de raison doivent être stables, documentés et exploitables par les outils de diagnostic.

Vertical Modules¶

Les Vertical Modules peuvent fournir :

des extracteurs d'attributs spécialisés ;
des comparateurs métier ;
des politiques de conflit ;
des pondérations ;
des seuils de décision ;
des codes de raison spécifiques.

Ils ne doivent jamais :

écrire en base ;
dépendre du Frontend ;
contourner les statuts unknown, ambiguous ou conflict ;
masquer une contradiction afin d'améliorer artificiellement un KPI ;
sélectionner directement une identité en dehors du contrat du Resolver.

Relation avec Quality¶

Le scoring de qualité et la résolution sont séparés.

Un score élevé peut soutenir une décision, mais il ne remplace pas la politique de compatibilité. Inversement, une identité peut être correctement résolue tout en présentant une qualité documentaire faible.

Resolution = quelle identité ?
Quality    = quelle confiance et quelle qualité des données ?

Le Resolver peut consommer des scores explicables, mais ne doit pas déléguer la décision finale à un score opaque.

Relation avec Media Quality¶

Media Quality n'est pas un Resolver d'identité produit.

Il évalue la cohérence entre les médias observés et les attributs attendus. Ses résultats peuvent produire des évidences, des diagnostics ou un besoin de revue, mais ils ne doivent pas :

effacer une image implicitement ;
changer une Canonical Identity ;
forcer une résolution ;
transformer un doute média en conflit produit sans règle explicite.

Le comportement par défaut reste audit-first et non destructif.

Déterminisme¶

À entrées identiques, configuration identique et versions de règles identiques, le Resolver doit produire :

le même statut ;
le même candidat retenu ;
le même classement ;
les mêmes codes de raison ;
le même niveau de confiance.

Les égalités doivent être résolues par un critère stable documenté, jamais par l'ordre d'arrivée.

Traçabilité¶

Chaque décision doit pouvoir être reliée :

aux candidats évalués ;
aux évidences utilisées ;
aux règles et versions de politique ;
aux raisons de rejet ;
aux contradictions détectées ;
au contexte de run ou d'audit lorsque pertinent.

Cette traçabilité est obligatoire pour les simulations, comparaisons et rapports de validation.

Garde-fous¶

Le Resolver ne doit jamais :

modifier les données d'entrée ;
écrire une projection ;
dépendre de WordPress, SQL, HTTP ou WP-CLI ;
utiliser le marchand comme vérité métier ;
confondre produit et variante ;
masquer une ambiguïté ;
créer une identité faute de candidat fiable ;
traiter un score numérique comme une preuve suffisante à lui seul.

Tests attendus¶

La suite de tests doit couvrir au minimum :

candidat unique compatible ;
aucun candidat exploitable ;
candidats équivalents ;
candidats ambigus ;
conflit fort ;
séparation produit / variante ;
stabilité de l'ordre ;
stabilité des codes de raison ;
politiques de verticale ;
absence d'effet de bord ;
sérialisation de la décision ;
comportement Media Quality non destructif.

Invariants¶

Le Resolver décide ; il ne persiste pas.
Toute décision est explicable.
unknown, ambiguous et conflict sont des résultats valides.
Une absence de preuve ne déclenche jamais une sélection forcée.
Les Vertical Modules spécialisent les règles sans remplacer le Resolver.
La résolution reste indépendante du Frontend, du Runtime, de SQL et de WordPress.
La qualité et la résolution restent deux responsabilités distinctes.
Media Quality reste audit-first et non destructif par défaut.