Concepts

Le modèle en cinq couches — permissions, schéma, liaisons, actions et moteur de contexte.

La couche ontologie repose sur cinq préoccupations distinctes, chacune avec son propre ensemble de concepts. Comprendre cette séparation rend le reste de la section plus lisible.

Les cinq couches

Couche	Rôle
C1 — Permissions	Décide qui peut voir quoi au niveau du type et de l'instance. Repose sur la couche d'autorisation de la plateforme et le modèle de habilitation des documents.
C2 — Schéma	Définit les types d'objets, les types de liens, les types d'actions et les règles d'identité. Versionné dans des branches.
C3 — Liaisons	Déclare comment une instance d'objet typée est projetée depuis une vraie source — une table gérée, une page de la base de connaissances, une tâche de flux de processus.
C4 — Actions	Mutations côté serveur validées par le point de décision de politique (`AssignAsset`, `FileSAR`, etc.).
C5 — Moteur de contexte	La surface de récupération — recherche sémantique sur des objets typés avec citations.

Ce qui est typé, ce qui ne l'est pas

Typé : les types d'objets, les types de liens, les types d'actions, les règles d'identité. Ils résident dans le schéma d'ontologie.

Non typé : les données brutes en dessous. Les tables gérées ont leur propre schéma ; les pages de la base de connaissances sont du markdown non structuré ; les tâches de flux de processus ont leur propre modèle. L'ontologie leur donne une vue typée.

Règles d'identité

Chaque type d'objet déclare une règle d'identité — comment dériver un ID d'instance stable depuis sa source. Schémas typiques :

Une seule colonne d'une table gérée (customer.id).
Une clé composite — plusieurs colonnes combinées.
Un slug de page depuis une entrée de la base de connaissances.
Une expression personnalisée impliquant plusieurs champs.

Les règles d'identité sont importantes parce qu'elles permettent à la plateforme de déterminer si deux enregistrements représentent la même instance. Re-téléverser un CSV ne crée pas de nouveaux ID tant que les colonnes d'identité sont stables.

Types de propriétés

Les propriétés d'un type d'objet sont typées avec un petit ensemble de primitives et de types structurés :

Type	Remarques
`string`	Texte libre
`number`	Entiers + flottants
`boolean`	vrai / faux
`date`, `datetime`	ISO 8601
`enum`	Ensemble fermé de chaînes
`geo`	Coordonnées
`currency`	Montant + code devise
`array<T>`	Listes des types ci-dessus
`link<TargetType>`	Référence à un autre objet typé

Chaque propriété peut être marquée required, searchable (indexée pour la récupération), ou porter des étiquettes DLP / classification qui se propagent dans le pipeline de masquage.

Types de liens vs. références intégrées

Une propriété peut être un link<TargetType> pour une référence 1-à-1. Pour les relations 1-à-plusieurs ou plusieurs-à-plusieurs, vous déclarez un type de lien :

LinkType: "owns"
  from: Customer
  to: Account
  binding: customer.id matches account.owner_id in `customers_accounts` table

Le lien est projeté au moment de la requête depuis la table de jointure.

Types d'actions

Les actions sont des mutations côté serveur. Contrairement aux outils de workflow (qui sont des wrappers typés autour d'une opération sans état), les types d'actions portent des contrats d'état :

ActionType: "AssignAsset"
  input: { assetId, userId }
  preconditions: asset is unassigned, user is in workspace
  postconditions: asset.owner = user
  side effects: audit event, downstream link creation

Les actions sont validées par le point de décision de politique — un appelant sans la bonne autorisation ne peut pas les déclencher. Les préconditions non respectées produisent une erreur typée sur laquelle le workflow peut se brancher.

Branches

Le schéma est versionné. main est la référence publiée ; chaque modification se fait sur une branche de proposition. Les propositions sont examinées et soit :

Publiées — elles remplacent la référence de main.
Archivées — elles sont abandonnées.

C'est essentiel en production : une faute de frappe dans une définition de type d'objet peut casser tous les workflows qui l'utilisent. Les propositions rendent ce changement vérifiable.

Voir aussi

Types d'objets — définir les entités.
Types de liens — définir les relations.
Types d'actions — définir les mutations.
Liaisons — projeter depuis des données réelles.
Branches et propositions — versionner le schéma.

Concepts

Sur cette page