F.4:1 - Problem Frame

A local system-role kind often needs a recognizable description before people can classify a candidate, assign a system, compare kinds, or use the kind in a Method condition. A name such as InspectorSystemRole is not self-explanatory. Readers need to know which systems are candidates, what condition distinguishes intended members from relevant non-members, when that distinction continues, which KindSignature states it, and where neighboring claims begin. Source or practice provenance can help them locate and compare that definition; it cannot decide kind identity.

The recurring failure is to make the description carry too much. A compact card is tempting: put kind, status, permission, responsibility, evidence, capability, Method, assignment, Work, and publication cues into one “assignable” template. That convenience creates duplicate ontology. A standard used as a requirement source becomes a “standard role”; a report used as evidence becomes an “evidence role”; an access-control label becomes a system-role kind; a kind name becomes proof of capability or performed Work.

F.4 instead treats the description as an episteme about one exact local kind. It may cite neighboring relations but does not absorb them.