semantic-quick-review.md

Findings

1. High: Task type and complexity need a clearer contract

The proposal says semantic_classify produces both:

• task type: code, math, creative, general
• complexity: easy, hard

But it also says the result becomes “a new capability kind” consumed by intelligent_route.

That is unclear at the What? level because these are two separate pieces of information.

The proposal should clarify whether semantic classification produces multiple routing facts, for example:

task=code
complexity=hard

or whether they are expected to become one combined capability.

I would strongly prefer keeping them separate so additional classification dimensions can be added later without creating combinations such as code-hard, math-easy, etc.

This is not an implementation detail; it defines what signal this feature actually produces.

Proposal lines 22–29

---

2. High: The compliance guarantee should say the tier must be trusted

The proposal correctly says compliance is checked before classification and that disallowed requests should never reach the classifier.

The part that needs clarification is:

requests tagged with a compliance tier

That could sound like the request/client supplies the security decision.

For this first proposal, I would not require it to define exactly which component creates the tier or how it is transported. That belongs in How?.

But the What? section should establish the security rule:

The decision to allow classification must come from trusted policy context and must not be based solely on a client-controlled value.

Then the future How? can define:

• where that policy context comes from;
• which component validates it;
• how it is carried internally;
• what happens when it is missing.

Proposal lines 50–55

---

3. High: unclassified should not also mean “classifier failed”

The proposal does a good job defining unclassified as:

classification ran, but the result was not confident enough.

There is another important state:

classification could not run.

For example, the backend could be unavailable or fail.

The first proposal does not need to define timeout values, retries, circuit breakers, or exact fallback behavior. Those belong in How?.

But the feature contract should distinguish at least:

• classified
• unclassified
• skipped_by_policy
• unavailable

Otherwise intelligent_route cannot tell the difference between “we confidently decided not to classify this prompt” and “the classification system is broken.”

Proposal lines 47–49