Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Usually, no. Resolve inputs with deterministic code when the answer is unambiguous, send only the uncertain remainder to a classifier, and define a fallback for classifier outages. That is the three-tier pattern Michael Hairetis describes in his September 24, 2026 DEV Community article. It is an architectural argument, not a benchmark proving that the pattern is always cheaper or faster.
How the three-tier pipeline works
Hairetis names the tiers mechanical, classifier, and fallback. Each has a distinct job: settle clear cases without inference, interpret the ambiguous ones, and keep the system’s behavior defined when classification cannot run.
Mechanical: resolve what ordinary code can know
Start with exact rules for cases that have a single, predictable answer. Hairetis gives an exact pipeline-name lookup as an example. A direct lookup or similarly narrow match can settle that request without a model call.
The key is to keep this tier genuinely deterministic. A rule should not silently claim certainty where inputs vary in meaning or wording. If a request does not match a known case, pass it on rather than forcing it into a possibly incorrect match.
Classifier: interpret the ambiguous remainder
Use a classifier when the request needs interpretation—such as deciding how an unfamiliar or variably phrased input maps to a supported action. In Hairetis’s implementation, a general-purpose agent fills this role. A purpose-built decision model is another possible choice, but model choice and pipeline order are separate decisions: even a specialized classifier need not handle requests that exact code can already resolve.
Fallback: define behavior when classification is unavailable
Decide in advance what happens if the classifier times out, errors, or is otherwise unavailable. The fallback might return a safe default, ask for clarification, defer the request, or report that it could not be classified. Which response is appropriate depends on the consequences of a wrong decision. The important design property is that classifier failure does not leave the pipeline’s behavior undefined.
Why put deterministic handling first?
A model call adds work, so it is unnecessary when a deterministic lookup already provides the answer. Hairetis summarizes his rationale this way: “The cheapest call is the one you do not make, and the second cheapest is the one whose answer you can predict without asking.” That is a design rationale, not a measured cost result.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →The ordering can also make outcomes easier to diagnose. Record which tier handled each request: a mechanical match, classifier decision, or fallback. That attribution helps separate rule coverage problems from model mistakes and availability failures. It is most useful when logs preserve the reason for a mechanical match or the classifier’s structured result, subject to appropriate privacy and data-retention controls.
Do not assume the first tier will produce savings in every deployment. The value depends on how many requests deterministic rules actually resolve, the cost of model calls and operating the rules, and the cost of any added routing. Hairetis notes that per-call metering could change the economics. His article supplies no traffic breakdown, controlled benchmark, or quantified savings.
Where Jev fits—and what its launch does not prove
TypeSafe AI announced Jev on September 15, 2026, as its first “System One Model,” in early access. The company describes it as taking unstructured state and typed questions and returning typed probabilistic decisions rather than generated prose. Its announcement names classification, routing, scoring, extraction, and branching as intended task types. See the official Jev announcement.
Hairetis says Jev can return probabilities, answer multiple questions about one state in parallel, and provide latency suited to a hot path; those are claims discussed in his article, not independent measurements. TypeSafe’s launch announcement also presents speed and efficiency claims that should be treated as vendor claims unless evaluated on the workload in question. A typed decision output may suit downstream code that needs a defined result shape, but suitability does not establish that a model should be the pipeline’s first stop.
Hairetis says his classifier tier was in production in April, but that deployment date and details are his account, not independently verified here. He explicitly does not claim that using a model as a classifier was novel in April. The relevant distinction is between his integration pattern, which uses a general-purpose agent for classification, and Jev’s stated purpose-built focus on structured decisions—not a claim that one invented model-based classification first.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose a classifier approach against your workload
Before putting any model in a decision path, assess the factors that determine whether it is useful and safe for your application. The available articles do not provide independent benchmark values for these comparisons, so measure them in your own environment.
Quick Recap
- Ambiguity: Identify which inputs can be settled by exact rules and which genuinely require interpretation. The classifier should handle the latter, not substitute for every known lookup.
- Cost at expected volume: Estimate call charges alongside the work of maintaining deterministic rules and operating the pipeline. A lower call count alone does not establish lower total cost.
- Latency on the relevant path: Measure end-to-end time under representative conditions, including routing and fallback behavior. A vendor’s qualitative speed claim is not a workload-specific latency result.
- Output requirements: Decide whether downstream code needs only a label or also a probability and multiple typed decisions. Choose an output format that can be validated and consumed safely.
- Failure behavior: Exercise timeouts, errors, and unavailable-classifier scenarios. Confirm the fallback is appropriate for the consequences of the decision.
- Observability: Log which tier answered and enough structured context to investigate errors. Track mechanical misses, classifier outcomes, and fallback activations separately.
Put the pattern into practice
- Write down deterministic cases. List inputs with a single known answer and implement narrowly scoped checks for them, such as exact pipeline-name lookup.
- Make the handoff explicit. If no rule resolves the request, pass it to the classifier rather than guessing in the mechanical tier.
- Validate classifier output. Check that its result conforms to the expected labels or typed structure before downstream actions rely on it. Treat uncertain or malformed output according to your decision policy.
- Specify outage behavior. Choose the fallback for timeouts and errors, and make sure it fails safely for the action being considered.
- Instrument each tier. Capture the tier, outcome, and relevant failure reason so you can distinguish rule gaps, classification errors, and service availability issues.
- Evaluate with representative requests. Compare end-to-end latency, costs, decision quality, and fallback frequency for the actual traffic mix. Do not infer a universal benefit from the architecture alone.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
