Architecture de l'hypergraphe persistant

Statut documentaire : architecture — voir Maturité et preuves.

L'hypergraphe conceptuel dispose d'un chemin d'exécution persistant dans le moteur actuel. La persistance n'est pas modélisée comme un graphe métier séparé : elle implémente les mêmes identités conceptuelles, nœuds, relations et index avec des responsabilités de stockage durable.

Responsabilités architecturales vérifiées

Les sources actuelles du moteur montrent une couche d'hypergraphe persistant avec :

• gestion de segments sur disque ;
• support de fichiers mappés en mémoire ;
• identifiants de nœuds stables dans les segments stockés ;
• indexation persistante, notamment pour les noms formels/chaînes ;
• contextes de transaction liés à l'exécution ;
• modes de transaction explicite et automatique ;
• staging dans un journal write-ahead avant application durable ;
• coordination en arrière-plan du journal et de l'indexation.

Frontière transactionnelle

Les écritures sont rattachées à une transaction. Une transaction explicite est validée par l'appelant ; une transaction automatique peut être créée pour une écriture isolée. Une transaction atteint l'état de commit avant que ses modifications stagées soient émises comme lot journalisé validé.

modification conceptuelle
  -> contexte de transaction
  -> enregistrements journalisés stagés
  -> frontière de commit
  -> application durable segments/index

Cette séparation est importante : mutation conceptuelle, intention transactionnelle et persistance physique sont des préoccupations distinctes.

Règle de programmation publique

Le code applicatif doit utiliser les contrats publics Runtime/modèle de transaction et de persistance. Les segments disque, formats de blocs du journal, fichiers mappés et threads de coordination internes sont des détails d'implémentation susceptibles d'évoluer sans modifier le modèle conceptuel.

Ce que cette page ne promet pas

Les sources établissent clairement une architecture de stockage persistant et de journalisation write-ahead. Cette page ne définit pas de RPO, RTO, garantie de réplication ou SLA de reprise après crash. Ces garanties nécessitent un contrat opérationnel et une matrice de tests certifiés séparés.

Voir Durabilité et WAL pour la frontière de journalisation.