ISNAD Scientific Platform — Audit de l’ingestion et architecture cible

Date des observations : 3 novembre 2026
Référentiel inspecté : oboutj7/isnad-app-fr, branche master, commit 8a2503a
Périmètre : audit et conception uniquement ; aucune migration, aucun import, aucune écriture de production.

Statut des énoncés#

• OBSERVÉ : constat issu du code, du schéma ou d’une requête en lecture seule sur la base rattachée.
• TESTÉ : comportement démontré par une commande exécutée pendant l’audit, généralement sur fixture ou base jetable.
• PROPOSÉ : architecture, estimation ou critère à valider ; ce n’est pas une capacité existante.
• NON VÉRIFIÉ : information inaccessible ou preuve insuffisante.

Le fichier audit-artifacts/live-db-2026-11-03.json est la trace brute des mesures de base. Il est produit par scripts/audit/audit-ingestion-live.mjs, dans une transaction PostgreSQL READ ONLY. Les comptes constituent une photographie, pas un résultat scientifique de qualité.

---

ISNAD ne part pas de zéro. Le dépôt contient déjà un corpus public, un référentiel transversal de narrateurs, des assertions et preuves, des projections de commentaires, des traductions versionnées et une publication humaine. Le problème central n’est donc pas l’absence de modèle scientifique, mais l’absence d’un orchestrateur unique et durable reliant les capacités existantes.

Les constats les plus importants sont :

1. L’import OpenITI actuel est synchrone et monolithique. Une route HTTP acquit, segmente, écrit le staging et canonise dans une transaction, puis lance une extraction de domaine « best-effort » dont l’échec est absorbé. src/app/api/admin/openiti/import/route.ts:14-42 ; src/server/openiti/import-runner.ts:51-54,112-138,273-310.
2. La classification et l’extraction OpenITI sont spécialisées. Le classifieur reconnaît surtout des titres et URI de rijāl ; les autres ouvrages restent UNCLASSIFIED. src/server/openiti/prepare.ts:152-162.
3. Le moteur canonique générique existe mais n’est pas exposé en production. DefaultKnowledgeAcquisitionEngine, ObservedAcquisitionRunner et HadithCorpusProjector sont couverts par des tests, sans route applicative de production trouvée. Les bindings nécessaires sont vides dans la base observée.
4. Le corpus OpenITI n’alimente pas le corpus public générique. Les 15 126 hadiths publics ont corpus_id = NULL, et chaque hadith possède exactement une chaîne dans l’état actuel. Cela ne démontre pas que les sources ne contiennent qu’une chaîne ; cela décrit uniquement la projection stockée.
5. La résolution des identités reste incomplète. Sur 47 206 crosswalks, 6 665 sont matched, 3 195 ambiguous et 37 346 unresolved. Les 777 maillons publics sans narrator_id sont un autre périmètre, à ne pas additionner aux crosswalks.
6. Les traductions et commentaires sont réels, mais leurs statuts doivent rester explicites. Les 2 772 traductions de notices comprennent 1 139 REVIEWED et 1 633 COMPLETE_UNREVIEWED. Les 18 274 versions de traduction de commentaires se répartissent également entre états machine et publiés ; une ligne publiée n’est pas une preuve de revue humaine.
7. Le contrôle qualité incrémental n’a pas démarré sur la base liée. quality_engine_state et quality_decisions sont vides. Les 32 data_quality_snapshots ne prouvent pas l’exécution de ce moteur particulier.
8. L’atelier OCR/traduction possède une conception robuste mais non déployée ici. Le code gère leases, retries, budgets et fencing, mais aucun schéma book_workshop n’existe dans la base inspectée. src/infrastructure/book-workshop/postgres/worker.ts:36-83,132-183,187-214.

Décision recommandée : conserver les modèles scientifiques et construire une couche d’orchestration par runs, étapes, artefacts et tâches persistantes. Ne pas créer un second corpus public, une table générique de personnes ni un nouveau silo de traduction.

---

A1. Méthode, accès et limites#

Éléments effectivement inspectés#

• dépôt local, historique Git, branches locales et liste distante ;
• routes, services, domaines, adaptateurs et scripts d’import ;
• migrations présentes dans supabase/migrations ;
• schéma PostgreSQL réel dans public et openiti ;
• comptes, statuts, couverture des chaînes, traductions, alignements et volumes ;
• suites de tests ciblées et vérification TypeScript.

Limites explicites#

• NON VÉRIFIÉ : l’historique distant supabase_migrations.schema_migrations est refusé par les privilèges disponibles. Il est donc impossible de certifier l’ordre d’application des migrations.
• OBSERVÉ : aucun dossier supabase/functions ni configuration de cron n’a été trouvé dans le dépôt. Cela ne prouve pas l’absence de planificateurs configurés hors du dépôt.
• NON VÉRIFIÉ : aucun test de bout en bout n’a été réalisé contre l’application publique ou les routes d’administration déployées.
• NON VÉRIFIÉ : l’audit n’établit ni la licence effective des témoins OpenITI ni la justesse scientifique des contenus extraits.
• OBSERVÉ : GitHub expose 100 branches. Les branches locales feat/openiti-commentary-import et chore/retire-idrap-fr-legacy n’ont pas de commit ou diff propre par rapport à master. Le contenu exclusif des 98 autres branches distantes n’a pas été audité exhaustivement.
• Le dépôt contient des modifications utilisateur préexistantes. Elles ont été lues mais ni modifiées ni annulées.

A2. Architecture actuelle#

Interface admin OpenITI
  └─ POST /api/admin/openiti/import (synchrone, maxDuration 300 s)
      └─ runImport
          ├─ GitHub : URI → métadonnées → version → texte
          ├─ analyse mARkdown : entrées, pages, offsets, SHA-256
          ├─ staging openiti.stg_*
          ├─ fonction SQL openiti.canonicalize_import
          └─ extraction de domaine hors transaction, best-effort
              └─ pont narrateur exact-normalisé → external_narrators/crosswalk/assertions

Pipeline canonique générique, actuellement surtout testé
  CorpusAdapter/SourceReader
    → DefaultKnowledgeAcquisitionEngine
    → HadithCorpusProjector / adaptateurs spécialisés
    → corpus public, rijāl ou commentaires
  ObservedAcquisitionRunner → import_batches + dataset_acquisition_bindings

Services séparés
  traductions de notices / commentaires / atelier OCR
  publication éditoriale humaine / journaux / contrôles qualité

Références principales : src/server/openiti/import-runner.ts:1-10,273-320, supabase/migrations/20260905130000_openiti_auto_ingestion_support.sql:39, src/infrastructure/knowledge-acquisition/ObservedAcquisitionRunner.ts:1-32,99-193.

A3. Inventaire des quinze domaines demandés#

A4. Mesures réelles de la base rattachée#

Toutes les valeurs de cette section sont OBSERVÉES dans audit-artifacts/live-db-2026-11-03.json, clés queries.* et tableCounts.

Corpus public#

Le ratio 86 283 / 87 060, soit environ 99,11 %, mesure uniquement le remplissage de la clé étrangère dans les maillons existants. Il ne mesure ni l’exactitude des identifications ni le rappel d’extraction des chaînes.

Narrateurs et connaissances#

Ces statuts sont ceux stockés ; ils ne constituent pas une validation humaine globale.

OpenITI#

Les deux imports RUNNING datent du 3 septembre, n’ont ni URI d’œuvre ni dates de début/fin. Leur statut stocké ne prouve pas qu’un processus soit encore actif.

Les méthodes extractor:* historiques coexistent avec TAHDHIB_HEADER_BEFORE_RAWA_AN_V1, taqrib-grade-span-v1, taqrib-name-boundary-v1 et taqrib-tabaqa-v1. Les 76 602 faits produits par extractor:* sont NEEDS_REVIEW. Le code actuel du pont filtre explicitement sur extractor:* et documente les autres lignes comme héritées : src/server/openiti/narrator-bridge.ts:149-154.

Les cinq œuvres classées sont Taqrīb, Tahdhīb, Lisān al-Mīzān, Taʿjīl al-Manfaʿa et Taʿrīf Ahl al-Taqdīs. Bulūgh al-Marām, al-Iṣāba, al-Majmaʿ al-Muʾassis, Nukat ʿalā Ibn al-Ṣalāḥ et Nukhbat al-Fikar restent UNCLASSIFIED.

Commentaires et traductions#

Fatḥ al-Bārī : 2 973 documents et 11 343 passages. Nawawi : 1 document et 2 675 passages.

Tous les alignements sont MACHINE_REVIEW_NEEDED, y compris les EXACT. Les 2 974 documents de commentaires sont REVIEW_NEEDED pour les droits et MACHINE_REVIEW_NEEDED pour la vérification.

Les traductions de commentaires comprennent 9 137 lignes MACHINE_REVIEW_NEEDED et 9 137 lignes PUBLISHED pour les mêmes couples de modèles et volumes ; cela correspond vraisemblablement à des versions ou projections distinctes, mais la table de comptage seule ne suffit pas à établir leur cycle de vie. Ne pas conclure à 18 274 textes distincts publiés.

Orchestration et qualité#

• import_batches : 45 completed, 5 failed, 2 running.
• processing_runs : 2 PARSER / COMPLETED ; 346 RESOLVER / COMPLETED, 1 RUNNING, 1 FAILED, 2 CANCELLED.
• dataset_acquisition_bindings : 0.
• quality_engine_state : 0 ; quality_decisions : 0.
• data_quality_snapshots : 32.

Les journaux actuels ne sont ni interchangeables ni suffisants pour relancer une étape arbitraire avec ses entrées, versions et artefacts.

A5. Composants réutilisables#

A6. Doublons, fonctions manquantes et risques#

Doublons fonctionnels#

• Deux voies OpenITI coexistent : import openiti.* et adaptateurs du pipeline canonique, sans composition de production.
• Plusieurs pipelines d’écriture spécialisés coexistent pour hadiths, rijāl, Fatḥ, Nawawi et Ibn Hajar.
• Plusieurs orchestrations techniques coexistent : openiti.imports, import_batches, processing_runs, jobs de l’atelier.
• Plusieurs surfaces de traduction existent. Elles répondent à des objets différents, mais n’ont pas d’orchestrateur commun de planification et de coût.

Ces doublons ne doivent pas être supprimés avant cartographie des écritures, dépendances et décisions humaines.

Fonctions manquantes ou non câblées#

• orchestration générale asynchrone, reprise par étape et annulation contrôlée ;
• registre des versions de classifieurs, extracteurs, resolveurs et configurations ;
• classification scientifique générique avec revue et règles de capacité ;
• extraction générique de collections structurées dans l’import OpenITI principal ;
• projection OpenITI vers corpus_id et chaînes multiples en production ;
• gestion explicite des renvois incomplets et graphes de bifurcation/convergence dans le pipeline principal ;
• gestion des droits dans l’acquisition OpenITI générique ;
• tableau de bord unique de runs, étapes, coûts, couverture et erreurs ;
• déploiement du quality engine et de l’atelier dans la base liée.

Risques de régression#

Le DELETE FROM ibnhajar.shuyukh du script spécialisé est un risque réel si --apply est utilisé ; il n’a pas été exécuté pendant cet audit. scripts/ibnhajar/load-from-openiti.cjs:121-132.

A7. Tests effectivement exécutés#

La preuve indépendante couvre 50 hadiths, 136 chaînes et 577 nœuds sur fixture. Ces chiffres ne sont pas des comptes de production et ne doivent pas être comparés aux 15 126 hadiths publics.

---

---

C1. Principes non négociables#

1. Un seul référentiel de narrateurs : public.narrators reste canonique ; les mentions externes restent distinctes.
2. Un seul corpus public : les nouvelles acquisitions projettent dans le modèle existant ; pas de corpus OpenITI concurrent.
3. Le texte source est immutable ; toute normalisation est un artefact dérivé et versionné.
4. Une étape produit des artefacts, pas une vérité scientifique implicite.
5. Une extraction, une déduction et une décision humaine ont des provenances distinctes.
6. Aucune publication automatique. La publication et la vérification numérique restent des axes éditoriaux distincts.
7. Toute étape est idempotente et rejouable à périmètre constant.
8. Aucune suppression historique pendant la migration vers le nouvel orchestrateur.

C2. Flux logique proposé#

Demande admin
  → Acquisition planifiée
  → Document source + métadonnées + droits + empreinte
  → Classification des capacités
  → Segmentation structurelle
  → Extraction spécifique au type
  → Résolution progressive des identités
  → Enrichissement et relations scientifiques
  → Projection dans les modèles canoniques existants
  → Contrôles numériques
  → Traductions optionnelles et budgétées
  → Rapport de préparation
  → Décision humaine de publication

Chaque flèche = dépendance explicite entre étapes persistantes.
Chaque sortie = artefact versionné + provenance + métriques + anomalies.

Un échec de traduction ne remet pas en cause les étapes amont. Une correction d’identité déclenche seulement la résolution, les enrichissements dépendants et les projections affectées.

C3. Composants applicatifs proposés#

C4. Modèle de contrôle proposé#

Les noms ci-dessous sont logiques ; leur implémentation doit être revue avant toute migration.

• ingestion_run : demande, œuvre/version, périmètre, configuration, état global, demandeur.
• ingestion_stage : type, dépendances, version de code, entrée hash, état, compteurs, début/fin.
• ingestion_task : lot, lease, tentative, prochaine exécution, erreur, priorité.
• ingestion_artifact : sortie adressable, hash, schéma, producteur, métriques, rétention.
• ingestion_event : transitions append-only et actions humaines.
• ingestion_budget : plafond, réservation, consommation et coût monétaire observé.
• ingestion_binding : correspondance explicite entre run et import_batch, processing_run ou import historique.

Clé d’idempotence recommandée : (type_étape, document_sha256, périmètre, version_extracteur, configuration_hash). Les décisions humaines ne font jamais partie des artefacts supprimés lors d’un rejeu.

États techniques#

PENDING → READY → RUNNING → SUCCEEDED, avec FAILED_RETRYABLE, FAILED_FINAL, CANCEL_REQUESTED, CANCELLED, BLOCKED.

Un run techniquement réussi peut produire un rapport scientifique partiel. Cette distinction suit déjà ObservedAcquisitionRunner : src/infrastructure/knowledge-acquisition/ObservedAcquisitionRunner.ts:23-29,178-193.

C5. Contrats scientifiques par famille#

Collections de hadiths#

• conserver document, livre, chapitre, numéro source, ordre, offsets et verbatim ;
• modéliser chaque ṭarīq séparément et chaque maillon dans son ordre ;
• stocker ح, بهذا الإسناد, نحوه, مثله comme objets structurels typés ;
• représenter une référence non résolue comme telle, sans recopier silencieusement une chaîne précédente ;
• permettre bifurcations et convergences par chemins, sans déduire une convergence à partir du seul nom ;
• ne jamais confondre hadith documentaire, tradition, variante et chaîne.

Rijāl#

• chaque notice reste rattachée à son ouvrage et son édition ;
• génération de candidats à partir des noms, kunya, nisba, générations, dates et relations ;
• preuves contradictoires conservées ;
• correspondance plausible = candidat, jamais identité certaine automatique ;
• correction d’identité = nouvelle décision et reprojection ciblée.

Commentaires#

• passages et lemmes liés à leur document source ;
• cibles déclarées séparées des cibles calculées ;
• alignements exact/probable/ambigu/conflit conservés ;
• assertions attribuées à leur autorité avec citation et locator.

Traduction#

• source arabe et hash obligatoires ;
• modèle, prompt/profil, version, date, statut et revue obligatoires ;
• reprise par lots et invalidation par changement de hash ;
• aucune traduction ne remplace l’arabe ou une version humaine protégée.

C6. Interface administrative cible#

Une page « Ingestions » doit offrir :

• catalogue et sélection de version, droits et métadonnées ;
• estimation préalable du périmètre et du coût IA ;
• graphe d’étapes, progression, durée, retry et annulation ;
• compteurs distincts documents/hadiths/traditions/variantes/chaînes/maillons ;
• narrateurs non résolus, candidats, preuves et décisions ;
• anomalies bloquantes et non bloquantes ;
• aperçu côte à côte arabe/source/extraction/traduction ;
• retraitement sélectif avec affichage des dépendances ;
• rapport qualité et couverture de revue ;
• action de publication via les règles actuelles.

---

Ce plan est PROPOSÉ et subordonné à validation. Chaque étape est livrable indépendamment, sans migration destructive.

Règles de livraison#

• chaque étape inclut tests unitaires, tests PostgreSQL jetables, test de rejeu et test de rollback logique ;
• le chemin historique reste disponible jusqu’à preuve de parité sur le périmètre pilote ;
• les scripts destructifs ne sont pas intégrés au moteur ;
• aucune généralisation à partir du seul succès d’un test vert ;
• les changements de schéma sont additifs et accompagnés d’une analyse des lectures/écritures.

---

E1. Trois témoins#

Les textes et éditions doivent être épinglés par URI, commit et SHA-256. Les jeux de référence sont relus par des personnes compétentes, avec procédure de désaccord et version.

E2. Jeux de référence#

Chaque cas contient : identifiant source, verbatim, offsets, structure attendue, chaînes/chemins attendus, mentions, rattachements acceptés, ambiguïtés acceptées, variantes et traduction de référence lorsque pertinente.

Prévoir des strates : cas ordinaires, renvois, homonymes, notices courtes/longues, pagination absente, marqueurs inconnus, contradictions et erreurs volontairement injectées.

Aucun chiffre de qualité n’est calculé sur les seules lignes faciles ou déjà résolues.

E3. Indicateurs et dénominateurs#

Pour la traduction, rapporter séparément complétude mécanique, erreurs de sens, omissions, ajouts, terminologie et taux d’acceptation humaine. Un contrôle automatique n’est pas une validation linguistique ou scientifique.

E4. Tests techniques obligatoires#

• même entrée exécutée deux fois : aucun doublon, mêmes artefacts logiques ;
• interruption avant/après commit : reprise sans perte ni double appel non tracé ;
• lease expiré et deux workers : un seul commit valide ;
• correction d’extracteur : nouvelle version, ancienne preuve consultable ;
• correction d’identité : seules les projections dépendantes sont rejouées ;
• source arabe modifiée : traduction précédente devient obsolète, jamais écrasée ;
• traduction en échec : extraction et publication antérieure intactes ;
• publication concurrente : conflit optimiste visible ;
• source indisponible ou quota IA atteint : état explicite, reprise contrôlée ;
• aucune décision humaine supprimée par rejeu.

E5. Critères de passage à l’échelle#

Les seuils chiffrés doivent être approuvés après la baseline ; en fixer maintenant serait arbitraire. Conditions minimales :

1. référence humaine complète et versionnée sur chaque témoin ;
2. aucun défaut critique ouvert : faux lien silencieux, perte de verbatim, écrasement humain, doublon public ;
3. précision et rappel publiés avec intervalles, strates et dénominateurs ;
4. rejeu, interruption, concurrence et retraitement sélectif démontrés ;
5. coût et durée mesurés par unité documentaire ;
6. revue des droits et provenance complète ;
7. publication humaine et rollback logique démontrés.

L’extension se fait par cohorte limitée, avec comparaison à la baseline et arrêt en cas de régression.

---

F1. Mesures observées#

• Base PostgreSQL : 2 080 566 419 octets, environ 2,08 GB décimaux ou 1,94 GiB.
• Texte OpenITI canonique : 21 199 630 caractères ; même total en staging. La duplication logique du texte est donc réelle, sans déduire son coût physique exact du seul nombre de caractères.
• Documents de commentaires : somme déclarée de 41 091 313 octets.
• 352 processing_runs et 52 import_batches donnent un historique utile, mais pas une mesure actuelle de débit.
• Aucun tarif fournisseur, nombre de tokens ou coût réel consolidé n’a été mesuré par cet audit.

F2. Charge de développement — hypothèses#

Ordre de grandeur pour un développeur senior connaissant Next.js/PostgreSQL, avec revue scientifique séparée :

Cette estimation n’est ni un devis ni un engagement. Elle suppose la réutilisation effective des composants ; une refonte du corpus ou des identités la rendrait caduque. La constitution des références humaines peut représenter plusieurs semaines de travail expert et n’est pas comprise dans les jours de développement.

F3. Infrastructure#

PROPOSÉ :

• PostgreSQL/Supabase pour contrôle, files et données canoniques ;
• worker Node séparé, à concurrence bornée, sans transaction ouverte pendant un appel IA ;
• stockage objet pour artefacts volumineux et exports, avec hashes dans PostgreSQL ;
• secrets uniquement côté serveur, rôles minimaux et audit admin ;
• métriques de files, latence, erreurs, retries, coûts, saturation et stockage ;
• environnements jetables pour migrations et tests de rejeu.

Le choix d’hébergement du worker reste ouvert. L’import HTTP actuel ne doit pas devenir le worker long.

F4. Coût IA — modèle paramétré, sans prix inventé#

Pour chaque famille :

coût = Σ (tokens_entrée × prix_entrée + tokens_sortie × prix_sortie)
       + coût OCR éventuel + coût embeddings éventuel

coût_unitaire = coût_total_observé / unités réellement traitées
coût_projeté(N) = N × coût_unitaire / (1 − taux_de_rejeu_ou_échec)

À mesurer sur les trois témoins : caractères et tokens par entrée, contexte ajouté, sortie, taux de retry, taux de cache, modèle et prix à la date d’exécution.

Optimisations : traduction uniquement à hash modifié, lots adaptés, contexte borné, quotas par run, plafond avant lancement, cache et réutilisation des validations humaines. Les traductions existantes ne doivent pas être régénérées pour alimenter une nouvelle orchestration.

F5. Stockage et montée en charge#

Le coût futur dépend de W œuvres, C caractères par œuvre, V versions conservées, A artefacts dérivés et I index/embeddings :

volume_brut ≈ W × C × V + A + I + journaux + sauvegardes

Aucune projection monétaire fiable n’est possible sans tarifs et volumétrie cible. Les risques principaux sont les copies staging/canonique, les embeddings, les index de recherche, les traductions multiversion et les journaux.

Mesures recommandées : artefacts dérivés régénérables, rétention différenciée, partitionnement si mesuré nécessaire, traitement par lots, index surveillés et sauvegardes testées. Le texte original et les preuves ne sont pas des artefacts à purge automatique.

---

---

Approuver ou ajuster, dans l’ordre :

1. la conservation stricte du corpus et du référentiel existants ;
2. le modèle d’orchestration par runs/étapes/tâches/artefacts ;
3. les trois témoins et leurs périmètres exhaustifs ;
4. les responsables scientifiques des jeux de référence ;
5. les lots D0 à D2 comme premier incrément, en environnement non productif.

Aucun développement du moteur, migration ou import massif n’est justifié avant cette validation.