Kind

Statut documentaire : architecture — voir Maturité et preuves.

Kind est une dimension structurelle distinguée du nœud conceptuel. Dans le moteur actuel, elle est obligatoire et constante dans le template de métadonnées, et le moteur de matching la traite séparément des slots participants ordinaires.

Cette distinction a un effet opérationnel : le matching sous-type/sur-type peut utiliser la position Kind avec les mappings d'héritage afin qu'un descendant correspondant soit projeté selon la bonne structure, plutôt que traité comme une valeur descendante brute sans mapping.

nœud candidat
  Kind -> type/kind conceptuel
  slots participants -> valeurs des rôles

pattern
  contrainte Kind -> recherche de type + mapping d'héritage
  contraintes de rôles -> matching des participants

Kind n'est donc pas un tag ou une catégorie générique. Des classifications métier comme CustomerTier, RiskLevel ou DocumentStatus doivent rester des concepts, rôles ou relations ordinaires sauf si elles définissent réellement une sémantique de type conceptuel reconnue par le Runtime.

Pourquoi cela affecte le matching

Le Runtime peut évaluer une contrainte de kind avant ou en parallèle des contraintes des participants. Lorsqu'il y a héritage, le résultat de kind peut transporter un mapping polyadique indiquant comment les rôles du descendant correspondent à la structure du sur-type attendu.

C'est une des raisons pour lesquelles Kind et Polyadic Map doivent être compris ensemble.

Règle d'utilisation publique

Utilisez les déclarations de type publiques et la syntaxe H-Logic. La position de stockage interne de Kind ne fait pas partie du contrat applicatif.