repo-scoping/docs/classification-strategy.md

Classification Strategy

Repo-registry needs classification for orientation without pretending repository behavior is always cleanly separable. The review UI should therefore support two layers of classification:

• primary_class: the main class-defining attribute used for grouping, filtering, and first-glance orientation.
• attributes: additional labels that can overlap, qualify, or challenge the primary class.

Observed facts already follow this shape informally: kind is the primary class (interface, framework, test, documentation, and so on), while path, name, value, and metadata provide secondary attributes.

For approved and candidate graph elements, the target model is:

• Ability primary classes describe the repository's core domain or operational purpose, such as repository-intelligence, workflow-automation, content- publishing, or developer-tooling.
• Capability primary classes describe the kind of behavior exposed, such as ingestion, analysis, review, search, export, coordination, or deployment.
• Feature primary classes describe the delivery surface or user-visible feature family, such as business-usecase, ui, api, cli, backend, storage, integration, or diagnostic.

Features are the most fluid layer. A single feature can be both ui and review, or both api and ingestion. The primary class should answer "where should a curator first look for this?" Secondary attributes should preserve the overlap: surface (ui, api, cli), intent (review, search, diagnostic), and domain (repository-intelligence, capability-mapping) can all be true at once.

Current implementation status:

• Facts can be searched and filtered by kind in the element listing UI.
• Features can be searched and filtered by their existing single type.
• Abilities and capabilities currently use placeholder classes (ability, capability) until the schema gains primary_class and attributes.

Next schema step: add primary_class plus a JSON/list attributes field to candidate and approved abilities, capabilities, and features. Candidate generation can then propose classifications, while review keeps the right to correct them.