Canonical Identity¶

Status: CURRENT

Rôle¶

La Canonical Identity représente l'identité métier stable d'un produit dans CMonChoix Platform.

Elle est indépendante :

des marchands ;
des feeds ;
des prix ;
du stock ;
du frontend ;
du transport technique utilisé pour la construire.

Elle ne doit pas être confondue avec une offre normalisée, une projection de catalogue ou une fiche d'affichage.

Position dans le cycle¶

Identifiers / observations
          ↓
Candidates
          ↓
Resolver
          ↓
Canonical Identity
          ↓
Projection Engine
          ↓
Catalog / Frontend

La Canonical Identity est une décision métier produite à partir d'évidences explicites. Elle ne doit jamais être déduite d'un simple effet de bord de persistance ou d'affichage.

Modèle conceptuel¶

Une identité canonique peut contenir :

une marque normalisée ;
une famille ou série ;
un modèle ;
une génération ;
un type produit ;
des identifiants stables ;
des attributs techniques structurants ;
des variantes ;
des éléments de provenance et d'explicabilité.

La structure exacte peut être enrichie par les Vertical Modules, mais le concept d'identité reste générique et partagé.

Identité, variante et offre¶

Ces trois niveaux doivent rester distincts.

Canonical Identity
    └── Variant
          └── Merchant Offer

La Canonical Identity décrit le produit de référence.

La variante décrit une déclinaison pertinente du produit, par exemple :

stockage ;
couleur ;
taille ;
connectivité ;
édition ;
capacité.

L'offre décrit les conditions commerciales d'un marchand :

prix ;
stock ;
vendeur ;
livraison ;
URL ;
images fournies par la source ;
promotion.

Une donnée commerciale ne doit jamais modifier à elle seule l'identité canonique.

Évidences et décision¶

La construction d'une Canonical Identity doit reposer sur des évidences traçables :

identifiants normalisés ;
attributs observés ;
informations dérivées ;
règles génériques ;
règles verticales ciblées ;
niveau de confiance ;
reason codes ;
conflits et ambiguïtés éventuels.

Le système doit pouvoir distinguer explicitement :

resolved : décision suffisamment établie ;
unknown : information insuffisante ;
ambiguous : plusieurs décisions restent plausibles ;
conflict : les évidences se contredisent.

L'absence de preuve ne doit jamais être transformée silencieusement en certitude.

Responsabilités¶

La Canonical Identity sert à :

représenter un produit de manière stable ;
rattacher plusieurs observations marchandes au même produit ;
structurer les variantes ;
alimenter les projections ;
fournir une base commune aux audits ;
garantir une référence indépendante du frontend.

Elle ne sert pas à :

calculer un prix ;
choisir un marchand ;
trier des offres ;
appliquer une règle d'affichage ;
muter une image marchande ;
masquer un conflit de données.

Stabilité et évolution¶

Une Canonical Identity doit être stable, mais pas figée artificiellement.

Une évolution est acceptable lorsqu'elle résulte :

d'une nouvelle évidence fiable ;
d'une correction explicite ;
d'une résolution de conflit ;
d'une migration contrôlée ;
d'une amélioration validée du Resolver.

Toute évolution doit rester explicable et auditable.

Une modification de titre, de prix, de disponibilité ou de source marchande ne constitue pas à elle seule une raison suffisante pour changer l'identité.

Relation avec les Vertical Modules¶

Les Vertical Modules peuvent :

fournir des extracteurs spécialisés ;
définir des attributs discriminants ;
contribuer aux candidats ;
produire des reason codes ;
ajuster les règles de variante.

Ils ne doivent pas :

remplacer le concept générique d'identité ;
introduire une seconde vérité métier ;
dépendre du frontend ;
écrire directement dans les projections ;
contourner le Resolver commun.

Relation avec la projection¶

La projection est dérivée de la Canonical Identity et des observations associées.

Elle peut être reconstruite à tout moment.

Canonical Identity = vérité métier
Projection = vue dérivée

Une erreur de projection ne doit pas conduire à modifier silencieusement la vérité métier. Elle doit être corrigée dans le moteur de projection ou dans les données d'entrée appropriées.

Relation avec Quality et Media Quality¶

Les modules Quality évaluent l'état des informations ; ils ne deviennent pas propriétaires de l'identité.

Media Quality peut produire :

des observations ;
des scores ;
des reason codes ;
des propositions de remplacement ;
des métriques d'audit.

Par défaut, Media Quality fonctionne en mode audit-first et non destructif. Une image jugée incohérente ne doit pas être supprimée automatiquement de l'offre ou de l'identité sans politique de mutation explicite, preuve suffisante et chemin d'écriture contrôlé.

Exemples¶

Smartphone¶

Identity
- brand: Apple
- family: iPhone
- model: 16 Pro
- generation: 16

Variants
- 128 GB / noir
- 256 GB / titane naturel

Télévision¶

Identity
- brand: Samsung
- series: OLED S95
- generation: 2025

Variants
- 55 pouces
- 65 pouces
- 77 pouces

Gaming¶

Identity
- brand: Sony
- family: PlayStation 5
- model: Slim

Variants
- Standard Edition
- Digital Edition

Tests attendus¶

Les tests doivent vérifier au minimum :

la stabilité à données équivalentes ;
la séparation identité / variante / offre ;
la conservation des états unknown, ambiguous et conflict ;
l'explicabilité des décisions ;
l'absence de dépendance à WordPress, SQL ou au frontend dans le Domain Core ;
la reconstruction déterministe des projections ;
l'absence de mutation destructive implicite par les composants Quality.

Invariants¶

Une identité canonique représente un produit, pas une offre.
Les données commerciales restent extérieures à l'identité.
Une décision doit être fondée sur des évidences explicites.
Les ambiguïtés et conflits ne sont jamais masqués.
Les variantes restent séparées des offres marchandes.
La projection est dérivée et reconstruisible.
Les Vertical Modules spécialisent sans créer une seconde vérité.
Quality mesure ; il ne décide ni ne mute implicitement l'identité.
Le Domain Core reste indépendant du runtime, du stockage et du frontend.