ISNAD — Knowledge Model (V1)

Mission 16R.1 — modèle scientifique uniquement. Aucun code, aucune migration, aucune implémentation. Ce document fige le vocabulaire et les relations qui gouverneront toutes les étapes ultérieures (16R.2+).

• Base : Quality Engine 16A.3 / 16A.4, Dependency Graph 16D.1–16D.3, couche narrator_assertions / assertion_evidence / narrator_reconciliation_decisions déjà présente (inventaire 16A.1).
• Statut : DESIGN.

---

0. Décision fondatrice#

Les livres de rijāl ne sont pas des tables de narrateurs. Ce sont des sources scientifiques.

État actuel : la base provient d'une saisie structurée de Taqrīb al-Tahdhīb — une ligne « narrateur » ≈ une notice (tarjama) de Taqrīb aplatie. Ce raccourci a servi de socle mais confond deux niveaux :

Le modèle V1 sépare ces niveaux : une entité canonique unique, sur laquelle chaque ouvrage dépose des assertions sourcées. Taqrīb devient une source parmi d'autres, pas la table.

---

1. Narrator — entité canonique#

Définition. Un Narrator est une personne historique unique de la chaîne de transmission. Il n'a aucune donnée savante en propre : il ne porte que ce qui est nécessaire pour l'identifier et le désambiguïser.

Champs d'identité (stables, non savants).

Ce qui n'est PAS sur le Narrator : le grade critique (jarḥ / taʿdīl), la fiabilité, les maîtres/élèves affirmés, les jugements, les dates précises, les anecdotes. Tout cela est un ensemble d'assertions (§4).

Règle d'or. Le canonical_name et tout attribut « résumé » affiché sont calculés à partir des assertions courantes (§4.4) — jamais saisis en dur. Le Narrator est un point d'ancrage, pas un enregistrement de contenu.

Correspondance base actuelle. La ligne narrators d'aujourd'hui = Narrator (identité) + un Knowledge Entry Taqrīb (§3) + N Assertion (§4). La migration 16R.2 extraira ces trois niveaux ; ce document ne la spécifie pas.

---

2. Knowledge Source — l'ouvrage savant#

Définition. Une KnowledgeSource est un ouvrage de référence du patrimoine critique, considéré comme témoin scientifique. Elle est citable, datable, attribuable, et versionnable (édition).

Exemples visés (non exhaustif).

Champs.

Édition (SourceEdition) : une source a des éditions concrètes (muḥaqqiq, éditeur, année, pagination). Une citation pointe une édition précise — même logique que commentary_editions déjà en base.

Correspondance base actuelle. data_sources / datasets couvrent la provenance d'import (fichier, licence, checksum). KnowledgeSource est le niveau au-dessus : l'ouvrage en tant qu'objet scientifique, indépendant du support numérisé qui l'a fait entrer dans la base.

---

3. Knowledge Entry — la notice (tarjama)#

Définition. Un KnowledgeEntry est la notice qu'une source consacre à un narrateur : la tarjama de Hishām b. ʿUrwa dans Tahdhīb al-Kamāl, le paragraphe de Taqrīb, l'entrée du Mīzān…

C'est le pont entre un Narrator (§1) et une KnowledgeSource (§2).

Champs.

Cardinalité.

• Une notice appartient à exactement une source.
• Une notice résolue pointe un Narrator.
• Un Narrator a 0..N notices — idéalement une par source majeure.
• Une notice non résolue (UNLINKED/AMBIGUOUS) existe quand même : elle attend une décision de rapprochement (§ crosswalk, déjà en base).

Pourquoi séparer Entry et Assertion. La notice est l'unité de citation (« voir Tahdhīb al-Kamāl, XXX/123 ») ; l'assertion est l'unité de raisonnement. Une notice produit plusieurs assertions ; une assertion sait toujours de quelle notice elle vient.

---

4. Assertion — la brique de connaissance#

Définition. Une Assertion est une affirmation atomique et typée extraite d'une notice, rattachée au Narrator canonique.

« D'après Taqrīb (notice #7302), Hishām b. ʿUrwa est thiqa. » « D'après Mīzān (notice #9218), il a changé (taghayyara) après son installation à Kūfa. » « D'après Tahdhīb al-Kamāl, il a entendu de son père ʿUrwa. »

Champs (aligne le contrat déjà présent narrator_assertions).

4.1 Atomicité#

Une phrase de source = souvent plusieurs assertions. « thiqa faqīh rubbamā dallasa » → GRADE_CRITICAL = thiqa (TAWTHIQ) + BIOGRAPHICAL_EVENT = faqīh (NEUTRAL) + TADLIS = occasionnel (NUANCE).

4.2 Append-only#

Aucune assertion n'est modifiée ni supprimée. Une ré-extraction, une correction humaine, un changement d'édition → nouvelle assertion qui supersedes l'ancienne. Même discipline que commentary_validated_rules et narrator_reconciliation_decisions.

4.3 Assertions contradictoires = normal#

al-Thiqāt dit fiable, al-Kāmil nuance : les deux assertions coexistent. Le modèle ne tranche pas au niveau assertion. La réconciliation (narrator_reconciliation_decisions, déjà en base) produit une décision datée et justifiée, jamais un écrasement.

4.4 Vue « narrateur consolidé »#

Ce qu'affiche l'app pour un narrateur (grade retenu, ṭabaqa, dates, maîtres/élèves) est une projection calculée : pour chaque field_type, les assertions CANONICAL_CURRENT + la décision de réconciliation courante. Purement dérivé, reproductible, réversible.

---

5. Evidence — l'ancrage probant#

Définition. Une Evidence est le fragment vérifiable qui soutient une assertion : le texte cité, sa localisation exacte, sa provenance.

Champs (aligne assertion_evidence déjà présent).

Invariant d'honnêteté. Une assertion CANONICAL_CURRENT doit avoir au moins une evidence SUPPORTS de type SOURCE_QUOTE. Pas de citation → l'assertion reste NOT_REVIEWED. Même règle que commentary_validated_rules (VALIDATED_RULE exige une preuve citée).

Evidence ≠ Assertion. L'evidence est le texte ; l'assertion est ce qu'on en tire. Deux assertions peuvent partager la même evidence ; une assertion peut être soutenue par plusieurs evidences de sources différentes.

---

6. Relier Fatḥ al-Bārī à ce modèle#

Fatḥ al-Bārī est déjà modélisé (commentary foundation 15C/15D : commentary_documents, commentary_passages, commentary_alignments, commentary_validated_rules, moteur fath-matcher branché 16D.3). Le Knowledge Model ne le remplace pas — il l'absorbe comme une KnowledgeSource de type HADITH_COMMENTARY.

Deux usages distincts de Fatḥ, deux rattachements.

1. Commentaire d'un ḥadīth (usage principal actuel) : inchangé. commentary_passage → commentary_alignment → ḥadīth. Le Dependency Graph 16D.1 gère déjà la propagation.

2. Assertion incidente sur un narrateur : quand Ibn Ḥajar, en commentant un ḥadīth, juge un transmetteur (« wa-huwa thiqa lākinnahu kāna yudallis »), ce passage devient :

   • une KnowledgeSource = Fatḥ al-Bārī (work_type = HADITH_COMMENTARY) ;
   • un KnowledgeEntry léger = le passage concerné (pas une tarjama structurée : locator = document + offsets du passage) ;
   • une ou plusieurs Assertion (field_type critique, assertion_basis = SOURCE_STATEMENT, attributed_authority = Ibn Ḥajar) ;
   • une Evidence SOURCE_QUOTE = le passage exact (le commentary_passage sert d'ancrage — evidence.locator réutilise document_id + offsets).

Pont technique. Un commentary_passage de passage_kind critique (NARRATOR_COMMENTARY, et cas ciblés de ISNAD) est candidat à produire une Assertion + Evidence rattachées à un Narrator. Le rapprochement passage→narrateur réutilise la logique de résolution de mentions (narrator-resolver, contextual-resolver-core). C'est un futur moteur du Dependency Graph (commentary-assertion-extractor, hors périmètre 16R.1), pas une modification du moteur fath-matcher.

Résultat : Fatḥ contribue au dossier scientifique d'un narrateur au même titre que le Mīzān, tout en restant un commentaire de ḥadīth. Une seule source, deux projections.

---

7. Le clic sur un narrateur → toutes les sources#

Écran cible : le dossier scientifique (« tarjama agrégée »).

NARRATEUR : Hishām b. ʿUrwa b. al-Zubayr al-Asadī   [CONSOLIDATED]
────────────────────────────────────────────────────────────────
IDENTITÉ (calculée)
  kunya Abū l-Mundhir · ṭabaqa 5 · † 146 h · Médine → Kūfa

GRADE CRITIQUE (assertions par source)
  Taqrīb (Ibn Ḥajar) ........... thiqa faqīh, rubbamā dallasa   « … »  [voir]
  al-Kāshif (al-Dhahabī) ....... ḥujja                          « … »  [voir]
  Mīzān (al-Dhahabī) .......... thiqa, mais taghayyara à Kūfa   « … »  [voir]
  al-Kāmil (Ibn ʿAdī) ......... défend sa fiabilité             « … »  [voir]
  Fatḥ al-Bārī (Ibn Ḥajar) .... thiqa, yudallis  (ḥadīth #1234) « … »  [voir]
  ─ rapporté par : Yaḥyā b. Maʿīn → thiqa   (via Tahdhīb al-Kamāl)

  DÉCISION ISNAD : thiqa ; tadlīs à surveiller sur chaînes muʿanʿana
                   tardives → maillon PROBABLE hors samāʿ explicite
                   [décision du 2026-.. · justifiée · révisable]

MAÎTRES / ÉLÈVES (assertions + corpus)
  entend de : ʿUrwa (père) [Tahdhīb al-Kamāl + 412 chaînes] …
  transmet à : Mālik, al-Thawrī, … 

CHRONOLOGIE DES SOURCES  (naissance … 146h … Taqrīb 852h)

Mécanique.

1. Narrator.id → toutes les KnowledgeEntry (LINKED), groupées par KnowledgeSource, triées par authority_weight puis date d'auteur.
2. Pour chaque entrée : ses Assertion CANONICAL_CURRENT, par field_type.
3. Chaque assertion affiche sa valeur normalisée + sa citation exacte (Evidence.quoted_text_ar) + un lien [voir] vers la notice/édition/page (ou le passage de Fatḥ).
4. Les blocs « calculés » (identité, décision isnād) affichent leur provenance : quelles assertions + quelle décision de réconciliation.
5. Assertions SUPERSEDED / REJECTED restées consultables (historique).
6. Entrées AMBIGUOUS / CONFLICTED signalées, jamais masquées.

Aucune donnée n'est « la vérité » sans source. Chaque ligne de l'écran remonte à une Evidence citable ou à une décision humaine datée.

---

8. Préparation du Hadith Reasoning Engine#

Le futur moteur de raisonnement sur les ḥadīths (grading d'une chaîne, détection de ʿilal, comparaison de ṭuruq) a besoin d'entrées atomiques, sourcées, pondérables, non écrasées. Le Knowledge Model les fournit :

En une phrase. Le Reasoning Engine ne raisonnera jamais sur des « narrateurs » : il raisonnera sur des assertions sourcées attachées à des entités canoniques, exactement comme le Quality Engine raisonne aujourd'hui sur des commentary_alignment hash-gated et audités.

---

9. Récapitulatif du modèle#

Schéma entité-relation (résumé) :

ASSERTION.supersedes_assertion_id (§4.2) est une auto-référence append-only, omise ci-dessus pour lisibilité : une correction crée toujours une nouvelle ligne ASSERTION, jamais une modification en place.

Schéma texte équivalent (flux de lecture) :

KnowledgeSource (ouvrage)  ──1..N──>  SourceEdition
      │
      │ 1..N
      ▼
KnowledgeEntry (tarjama / passage)  ──N..1──>  Narrator (entité canonique)
      │                                              ▲
      │ 1..N                                          │ projection calculée
      ▼                                               │
  Assertion (claim atomique typé)  ──N..1────────────┘
      │
      │ 1..N
      ▼
  Evidence (citation + locator + provenance)

Réconciliation :  narrator_reconciliation_decisions  (datée, justifiée, append-only)
Fatḥ al-Bārī   :  KnowledgeSource(HADITH_COMMENTARY) → Entry léger → Assertion + Evidence

Invariants.

1. Le Narrator ne porte aucune donnée savante — seulement de l'identité.
2. Toute donnée savante = Assertion rattachée à une KnowledgeEntry d'une KnowledgeSource.
3. Toute Assertion CANONICAL_CURRENT a une Evidence SOURCE_QUOTE.
4. Rien n'est écrasé : correction = nouvelle ligne + supersedes.
5. Les contradictions entre sources coexistent ; seule une décision datée et justifiée tranche, jamais un import.
6. Tout ce qu'affiche l'app remonte à une citation ou à une décision humaine.

---

10. Hors périmètre 16R.1 (pour mémoire)#

• Migration d'extraction Taqrīb → (Narrator + Entry + Assertions) : 16R.2.
• Ingestion des autres sources (Tahdhīb al-Kamāl, Mīzān…) : 16R.3+.
• Moteur commentary-assertion-extractor (Fatḥ → assertions narrateur).
• Moteurs de raisonnement ḥadīth (chain-grader, illa-scanner).
• Pondération d'autorité automatique (reste manuelle/indicative en V1).

---

V1 — 16R.1. Modèle gelé. Prochaine étape : 16R.2 (extraction Taqrīb, sans perte, réversible).