shipwithjev

Blog / Comparisons / FIG. 102

Jev vs Rules Engines

Rules engine vs AI: when rules beat models, where Jev's verdicts take over, and the rules-floor pattern that keeps both honest in one pipeline.

The rules engine vs AI argument is older than most of the people having it, and it usually ends with someone quietly adding another regex. That's not a failure. Rules are free, instant, deterministic, and easy to audit, and a lot of production logic should stay that way. The question isn't which one wins; it's where the line sits between what a rule can say and what needs a reader.

Jev, TypeSafe AI's decision model, sits on the other side of that line. It answers closed questions about language (is this a refund request, does this comment threaten someone) with a probability per answer, per ecosystem documentation. It doesn't generate text, and it doesn't replace your rules. It replaces the rules you were never able to write.

When rules beat models

Rules win outright when the condition is mechanical:

  • Format and value checks. Is this a valid email address, is the amount over the limit, is the date in the future.
  • Exact matches. Banned terms, known-bad domains, blocked account IDs, SKU patterns.
  • Hard business limits. Refunds over a set amount need approval. Accounts under a day old can't post links.
  • Anything that must be explainable line by line. An auditor can read a rule. A probability needs a log and a gold set to be trusted.

If the rule is right every time, a model adds cost, latency, and a small chance of being wrong. Keep the rule.

When models beat rules

Rules break on meaning. "Contains the word refund" catches "I don't want a refund, just the right size" and misses "I'd like my money back." Every team that's tried to encode intent in regex knows the shape of the result: a growing file of patterns, exceptions to patterns, and a comment that says "don't touch this."

One builder put it plainly: AI coding tools leave a lot of regex and hard-coded rules behind, so he moved that logic in three of his products to Jev calls, which he reports are very fast (build, as reported). The pattern generalizes. When the condition is about what text means rather than what it contains, a ruling beats a rule.

Signs you've crossed the line: your rule has more than two exceptions, it needs a synonym list that keeps growing, or two people on the team disagree about whether it fired correctly.

The rules-floor pattern

The mature answer is both, in order. Rules run first and handle the unambiguous floor: the exact matches, the format checks, the hard limits. Only what the rules can't settle reaches the model. The content moderation stack shows this as its first tier; the routing guide shows the same idea extended with a frontier model on top.

The floor pays three ways. It's free for the cases it catches. It's deterministic where determinism matters most (hard limits, known-bad lists). And it keeps the model's job focused on the genuinely ambiguous middle, where its verdicts are worth their cost.

There's a mirror image of the pattern, too: the model decides, the rules act. One log-triage build has Jev score batches for noise, severity, and whether an operator should act; plain code then maps those answers to suppress, watch, review, notify, or page, and nothing is executed automatically (build, as described by its author). The model supplies judgment; the rules supply the policy about what judgment is allowed to trigger.

Here's the combined shape as pseudocode (not real syntax; see docs.typesafe.ai for the actual interface):

pseudocode:
if message matches known-bad list:      block for review (rule)
else if amount over approval limit:     route to approver (rule)
else:
    p = jev.ask("Is this a refund request?", choices = [YES, NO, UNCLEAR])
    if p.YES is high:   route to refunds queue
    else if p.NO is high: normal queue
    else:               human

Note that nothing in that flow issues a refund, deletes an account, or sends money. Rules and verdicts route; irreversible actions go to a person or a separate, explicitly approved step.

Rules engine vs AI is a false choice

Sometimes the rules are fine and the problem is picking which ones apply. One cataloged tool, jev-rules, has Jev decide which of your rules are relevant to a request so the downstream model only sees those (behavior as described by its author). The most practical systems let each side do what it's good at.

Frequently asked questions

Should I replace my rules engine with AI?

No. Keep rules for mechanical conditions and hard limits, and add a decision model only for the cases where the condition depends on meaning. Rules first, model second.

When do rules beat models?

When the condition is exact (formats, known values, hard limits), when it must be right every time, or when an auditor needs to read the logic line by line.

What is the rules-floor pattern?

Rules run first and settle the unambiguous cases; only what they can't settle reaches the model. It's the first tier in the moderation stack.

Are AI verdicts auditable like rules?

Not line by line, but they can be: log the question, its version, the input, and the probability for every verdict, and test questions against a gold set. Verdict logging covers the setup.

Can a model's verdict trigger actions directly?

It can route and label. Anything irreversible, like refunds, deletions, or bans, should wait on a human or a rule-governed approval step, never a lone verdict.

Numbers throughout are as reported by the build authors, not verified by shipwithjev. Code-shaped examples are pseudocode; the official docs live at docs.typesafe.ai.