Why an ontology is needed
Routers cannot select specialists from vague names. A model called fast-helper-v2 says almost nothing. A capability ontology defines what the system means by summarization, extraction, classification, planning, code review, math reasoning, refusal, escalation, and tool use.
Ontology dimensions
| Dimension | Examples |
|---|---|
| Task | classify, summarize, transform, extract, judge, route |
| Domain | code, legal, medical, industrial telemetry, education |
| Modality | text, image, audio, tabular, event stream |
| Risk | low impact, regulated, safety critical, security sensitive |
| Runtime | browser, edge CPU, GPU, batch, offline |
| Output | JSON, Markdown, scorecard, trace, executable patch |
| Evidence | benchmark slice, human review, production shadow, red-team pass |
Capability record
RECORD Capability
capability_id
display_name
task_type
domain_tags
input_types
output_schema
risk_tier
required_evidence
allowed_runtime_profiles
escalation_target
END RECORDRouter use
FUNCTION route_request(request, registry, ontology, policy)
needed <- CLASSIFY_CAPABILITIES(request, ontology)
candidates <- registry.FIND_BY_CAPABILITY(needed)
candidates <- FILTER_BY_PERMISSIONS(candidates, request.context, policy)
candidates <- SORT_BY_EXPECTED_VIABILITY(candidates, request)
IF candidates IS EMPTY
RETURN ESCALATE(request, ontology.escalation_target)
END IF
RETURN candidates[0]
END FUNCTIONAvoid tag inflation
A model should not claim every capability. Require evidence for each capability tag. A specialist with five proven tags is more valuable than a model with thirty aspirational tags.
Version the ontology
Changing the ontology can change router behavior and evaluation coverage. Treat ontology changes as release events with migration notes and regression tests.
Source reports used for this guide
These reports are preserved verbatim in the site archive. The guide above is an editorial synthesis and may narrow, qualify, or reorganize claims from the source material.