Selection methodology

The canonical index is designed to be routable by an LLM. The sequence below is the recommended decision process and should be treated as more important than simple semantic similarity.

Repository selection sequence

1. Extract the project objective, constraints, environment, and desired outputs.
2. Match the request against semantic profiles, user-intent phrases, and task categories.
3. Apply do-not-select rules and prerequisite conditions before ranking candidates.
4. Evaluate relevant internal components rather than selecting only at repository level.
5. Compare setup effort, compatibility, maturity, security, and production readiness.
6. Apply repository relationships and combination rules when one repository is insufficient.
7. Return the selected repository IDs, component IDs, rationale, risks, and execution order.

Required selection output

Ambiguity handling

• Do not select a repository based only on keyword overlap.
• Prefer verified capabilities over inferred capabilities.
• When two repositories are similarly suitable, compare differentiators and constraints.
• When confidence is low, state what additional project information is needed.
• Never invent undocumented components, paths, compatibility, or commands.

Decision matrix interpretation

Matrix scores are general-purpose routing heuristics. They summarize how easy a repository is to route to from an arbitrary project request; they do not claim that a higher-scoring repository is better software.

Evidence policy