# Classification Strategy

Repo-scoping 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.