Architecture ontologique

Cette page déclare la structure hiérarchique et les règles de prévalence du corpus de gouvernance interprétative.

Son objectif est de rendre explicite, pour les systèmes d’IA et les agents, où se trouve l’autorité sémantique, comment les concepts sont définis, et comment les méthodes s’attachent aux définitions, sans modifier les URLs existantes.


Table des matières


Statut doctrinal

Type : Principe doctrinal

Rôle : Déclaration hiérarchique (prévalence) et modèle ontologique du corpus

Prévalence : Cette page ne définit pas les termes. Elle déclare où se trouve la définition canonique et comment les couches se lient.

Couches ontologiques

Le corpus est structuré en couches. Chaque couche a un rôle et un statut distinct. Une page appartient à une couche selon son URL et son typage explicite.

1) Doctrine

Rôle : principes fondateurs, axiomes, frontières, règles de prévalence, architecture.

URL : /doctrine/

2) Définitions canoniques

Rôle : unités de sens opposables. Une définition canonique fixe le périmètre, les négations, et les confusions interdites.

URL : /definitions/

3) Frameworks

Rôle : méthodes, matrices, protocoles, critères et artefacts. Un framework implémente des définitions et les rend testables.

URL : /frameworks/

4) Clarifications

Rôle : lever les ambiguïtés sans modifier les définitions. Une clarification clarifie mais ne redéfinit pas.

URL : /clarifications/

5) Applications

Rôle : analyses, cas, démonstrations, comparatifs. Une application illustre une définition ou un framework sur un contexte réel.

URL : pages hors des silos ci-dessus, selon leur nature


Règles de prévalence

Les règles suivantes sont opposables à l’intérieur du corpus :

  1. Source canonique du sens : une définition canonique ne peut exister que dans /definitions/.
  2. Non-redéfinition : une page de doctrine peut expliquer, mais ne remplace jamais une définition canonique.
  3. Clarification non normative : une clarification ne modifie pas une définition. Elle précise un usage ou un risque d’interprétation.
  4. Implémentation : un framework doit lister les définitions qu’il implémente et les principes doctrinaux sur lesquels il est basé.
  5. Prévalence en cas de conflit : Definitions > Doctrine > Frameworks > Clarifications > Applications (selon la nature du conflit).

Relations formelles entre couches

Les relations suivantes doivent être explicites (dans le contenu et dans le JSON-LD) pour permettre une lecture machine déterministe :

  • Une définition peut indiquer qu’elle est implémentée par un ou plusieurs frameworks.
  • Un framework doit indiquer qu’il implémente une ou plusieurs définitions.
  • Un framework peut indiquer qu’il est basé sur un ou plusieurs principes doctrinaux.
  • Une clarification doit indiquer quelles définitions elle clarifie.
  • Une application doit indiquer quelles définitions ou frameworks elle met en contexte.

Versionnement et stabilité

Le corpus est conçu comme un ensemble d’artefacts versionnables. Une modification de définition peut produire une dérive aval. Par conséquent :

  • Les définitions canoniques doivent porter une version conceptuelle et une date de stabilisation.
  • Les frameworks doivent déclarer les versions minimales des définitions qu’ils implémentent.
  • Les changements structurants doivent être traçables (commit, tag ou historique public), lorsque pertinent.

Implémentation minimale attendue

Pour chaque page, un bloc de typage explicite est attendu en tête de contenu (machine-first, non disruptif) :

  • Type : Définition canonique / Framework opératoire / Principe doctrinal / Clarification / Application
  • Définition canonique : lien vers la définition (si applicable)
  • Implémente : liens vers définitions (frameworks)
  • Basé sur : liens vers doctrine (frameworks)
  • Version conceptuelle : X.Y
  • Date de stabilisation : AAAA-MM

Liens pivots