Kind

Documentation status: architecture — see Maturity and evidence.

Kind is a distinguished structural dimension of a conceptual node. In the current engine it is mandatory and constant for the node metadata template, and the matching engine treats it separately from ordinary participant slots.

That distinction is operationally important: subtype/supertype matching can use the kind position together with inheritance mappings so that a matched descendant can be projected through the correct structural mapping rather than treated as an unrelated raw value.

A useful model is:

candidate node
  Kind -> conceptual type/kind
  participant slots -> role values

pattern
  Kind constraint -> type search + inheritance mapping
  role constraints -> participant matching

Therefore Kind is not a general-purpose category or tag field. Business classifications such as CustomerTier, RiskLevel, or DocumentStatus should remain ordinary concepts, roles, or relations unless they truly define Runtime-level conceptual type semantics.

Why it affects matching

The Runtime can evaluate a kind constraint before or alongside participant constraints. When inheritance is involved, the kind match can carry a polyadic mapping describing how descendant roles correspond to the expected supertype structure.

This is one reason Kind and Polyadic Map must be understood together.

Public usage rule

Use public type declarations and H-Logic type syntax. The internal storage position of Kind is deliberately not part of the application contract.