ADR-0003 — Identité canonique, cycle de vie des sources et projections reconstruisibles

• Statut : Accepté
• Date : 2026-09-02
• Portée : toute entité canonique, toute source importée, toute représentation linguistique et tout futur moteur de réconciliation
• Décision de validation : D1–D6 obligatoires ; D7 défini comme contrat anticipé ; D8 explicitement différé
• Jalon de preuve initial : S1.6 — Independent Source Proof
• Références : planning/epics/scientific-knowledge-layer-roadmap.md, ADR-0001, ADR-0002, docs/scientific/knowledge-model.md, docs/scientific/scientific-principles.md, planning/epics/b0-hadith-persistence-contract.md

---

1. Contexte#

ISNAD doit pouvoir intégrer plusieurs recueils, dictionnaires de rijāl, éditions, commentaires et traductions sans transformer chaque import en nouvelles entités concurrentes. Il doit aussi pouvoir retirer une source erronée sans casser les identités stables, les liens, les autres sources ni l'application.

Les cas qui motivent cette décision sont notamment :

• une même valeur arabe représentée en français par Abu, Abou, Abū ou d'autres variantes ;
• une mention tronquée telle que عائشة بنت أبي ou « Aïcha bint Abu », qui ne doit ni être complétée silencieusement ni créer automatiquement une nouvelle personne ;
• plusieurs dictionnaires décrivant le même narrateur avec des informations complémentaires ou contradictoires ;
• une source qui doit être mise en quarantaine, retirée de la projection courante ou exceptionnellement purgée ;
• de futurs traitements nocturnes lourds qui proposeront des rapprochements sans devenir eux-mêmes la source de vérité.

L'architecture existante fournit déjà provenance, témoins d'acquisition, assertions, preuves, décisions de réconciliation, crosswalks et séparation acquisition/aval. Cette ADR fixe les invariants qui doivent empêcher les futures automatisations de contourner ces fondations.

---

2. Décision#

2.1 Invariants D1–D8#

2.2 Contrat de représentation linguistique#

Le concept est transversal, mais l'implémentation physique reste typée par bounded context jusqu'à ce que deux cas réels structurellement différents justifient une généralisation.

Exemple conceptuel :

Narrator #123
  canonical_ar       أبو بكر الصديق
  normalized_ar      ابو بكر الصديق
  preferred_fr       Abou Bakr al-Siddiq
  alias_fr           Abu Bakr al-Siddiq
  transliteration    Abū Bakr al-Ṣiddīq

Toutes ces formes conduisent à la même identité. Modifier la préférence d'affichage ne modifie aucun identifiant, isnād, hadith ou lien scientifique.

2.3 Contrat mention → candidat → identité#

témoin source immuable
        ↓
mention extraite non résolue
        ↓
candidats classés
        ↓
décision sourcée et versionnée
        ↓
identité canonique

Une mention tronquée reste conservée verbatim. Une complétion ou un rapprochement est une assertion révisable avec méthode, score, preuves et décision. Une décision annulée ne réécrit pas le témoin source.

2.4 Retrait d'une source#

Le retrait logique suit cet ordre :

1. enregistrer une décision auditée de changement de statut ;
2. exclure la source de l'ensemble effectif utilisé par les projections courantes ;
3. invalider ou mettre en révision les décisions dépendant exclusivement de cette source ;
4. reconstruire les projections affectées à partir des autres contributions actives ;
5. conserver les identifiants stables, redirects, décisions et tombstones nécessaires à l'audit ;
6. publier explicitement l'état UNSUPPORTED / « preuve courante insuffisante » lorsque plus aucune contribution active ne justifie une donnée, sans la présenter comme CANONICAL_CURRENT.

WITHDRAWN ne réécrit ni ne détruit le témoin importé. Une purge physique, si elle est légalement ou scientifiquement nécessaire, est une procédure distincte et ne peut effacer la trace minimale de retrait.

2.5 Fusion canonique#

Une fusion future doit au minimum porter :

loser_id
survivor_id
decision_id
reason
evidence_refs
effective_at
superseded_by_merge_id?

Toute ancienne URL ou référence vers loser_id doit se résoudre vers survivor_id. Une décision ultérieure peut superséder la fusion sans falsifier son historique.

Aucune table générique canonical_entity_merge n'est imposée maintenant. E4 doit d'abord implémenter le cas réel des narrateurs ; une abstraction transversale ne sera envisagée qu'après un second bounded context.

2.6 Contrat de traduction versionnée#

Le modèle conceptuel minimal est :

source_segment immutable
    ↓
translation_variant[]  (langue, modèle/auteur, prompt/protocole, version, date)
    ↓
translation_review / decision
    ↓
preferred_translation projection

Un champ français unique écrasé à chaque retraduction est interdit pour les corpus scientifiques. D7 ne déclenche en E1 ni traduction massive, ni appel de modèle, ni nouvelle table universelle.

2.7 Futurs agents nocturnes#

Les futurs agents consommeront les mêmes ports et écriront dans les mêmes journaux de propositions, preuves et décisions que les traitements interactifs. Ils devront :

• enregistrer version de code, moteur, modèle de connaissance et règles ;
• distinguer score de classement, confiance d'identité et décision ;
• respecter l'auto-override interdit sur une décision humaine validée ;
• rester rejouables et idempotents ;
• placer les cas ambigus en révision ;
• ne jamais modifier directement un témoin source ou une identité canonique.

---

3. Placement dans la roadmap#

S1.5 — mécanismes minimaux#

S1.5 fournit, pour le vertical slice HADITH uniquement :

• persistance d'une mention brute sans création de narrateur ;
• rattachement explicite à la provenance ;
• cycle logique minimal de la source ;
• exclusion déterministe des sources non effectives ;
• point de reconstruction des projections ;
• interdiction des cascades destructrices source → entité canonique.

S1.5 ne développe aucun agent nocturne, aucune fusion générique, aucun moteur d'alias et aucun moteur de traduction.

S1.6 — preuve sur source indépendante#

S1.6 est le premier jalon de preuve de D1, D3, D5 et D6. La même source indépendante utilisée pour prouver le pipeline doit servir à démontrer :

1. import initial ;
2. persistance d'au moins une mention non résolue sans création de personne ;
3. second import sans doublon et sans perte aval ;
4. mise en quarantaine puis retrait logique de la source ;
5. absence de suppression en cascade d'une identité canonique ;
6. reconstruction déterministe depuis l'ensemble effectif restant ;
7. fonctionnement de l'application et visibilité explicite des données devenues non supportées.

S1.6 vérifie aussi, par matrice de conformité, que le modèle n'empêche pas D2, D4 et D7. Il n'en anticipe pas l'implémentation.

E3, E4 et E7#

• E3 généralise provenance et cycle de vie après un second cas documentaire réel.
• E4 implémente formes de noms/alias typées, résolution mention → narrateur et redirect de fusion canonique.
• E7 applique conflits, supersession, invalidation et réconciliation aux dépendances de sources retirées.

---

4. Critères de conformité#

Une évolution est non conforme si elle :

• utilise une graphie française comme clé de personne ;
• crée un narrateur uniquement parce qu'une mention n'a pas été résolue ;
• fait porter l'existence d'une entité canonique par une seule ligne source avec suppression en cascade ;
• écrase une traduction précédente ;
• supprime un doublon canonique sans redirect ni décision ;
• rend impossible la reconstruction d'une projection ;
• permet à un agent automatique d'écraser une décision humaine validée ;
• cache qu'une donnée ne dispose plus de preuve active.

---

5. Conséquences#

Positives#

• imports multi-dictionnaires sans duplication systématique ;
• corrections et fusions révisables ;
• retrait sûr d'une source ;
• stabilité des identifiants et des liens ;
• traduction massive ultérieure sans écrasement ;
• agents nocturnes remplaçables et auditables.

Coûts acceptés#

• davantage de tables ou relations typées dans les vertical slices futurs ;
• reconstruction et invalidation plus complexes qu'un CRUD direct ;
• maintien de tombstones et redirects ;
• nécessité de distinguer état scientifique courant et historique complet.

---

6. Alternatives rejetées#

1. Normaliser directement Abu en Abou dans les données existantes : détruit la provenance et confond affichage et identité.
2. Créer une personne pour chaque forme rencontrée : multiplie les doublons et rend la fusion destructive.
3. Faire posséder une entité canonique par sa première source : rend le retrait de source dangereux.
4. Supprimer physiquement une source en cascade : brise l'audit, les liens et les décisions.
5. Stocker une seule traduction mutable : empêche comparaison, révision et reproductibilité.
6. Construire immédiatement un framework universel d'identité/traduction/merge : viole la règle de généralisation après deux cas réels.
7. Développer les agents nocturnes dans E1 : automatise avant d'avoir démontré les invariants de persistance et de reconstruction.