jev| Approach | When to consider it | Work to account for |
|---|---|---|
| Rules | Exact mappings and conditions | Maintaining exceptions |
| Trained classifier | Defined labels and labeled examples | Data, training and deployment |
| Jev | Judgments expressed as questions | API dependency, rubric and evaluation |
Use code when the rule is exact
If an order is overdue when its delivery date is before today, calculate that in code. If a known account status maps to a queue, use that mapping. Adding a model to an exact rule introduces an unnecessary failure point.
Try a semantic decision when wording varies
A rule for the word “charge” may catch a payment complaint but also a question about charging a device. A described category can express the distinction more directly. Test this on the messages that defeat your rules, along with routine cases the rules already handle.
Include the classifier you already have
If you have labeled data and a working classifier, compare its errors before replacing it. Account for the cost of new labels, retraining and deployment alongside API usage. Stable labels with lots of examples create a different maintenance problem from a policy that changes every week.
Run the same examples through each approach
Use identical labels and a fixed test set. Record per-category errors and how many examples are left for review. Also check practical constraints: whether input can leave your environment, how an outage is handled and how a category change is deployed. These can decide the choice even when quality is similar.