Off By Cents

I want to introduce BOE, my new rule engine platform at boerules.com. But the announcement is the easy part. The more honest post is the one that explains why someone who walked away from rule engines over a decade ago spent last year building thirty five of them.

So here is the long version. It starts fifteen years ago, goes quiet for most of the time in between, and then turns on a single bug I found last year.

MeshAlpha

Almost fifteen years ago I wrote MeshAlpha, a Forward Chaining RETE-OO engine in C#, tested and debugged by hand, before any of us had an AI assistant looking over our shoulders. Mesh for the discrimination network and a nod to the Von Neumann machine architecture I was studying at the time, Alpha for the first node type every RETE tutorial hands you. I read Forgy’s original papers and Robert Doorenbos’s 1995 CMU thesis on RETE/UL, kept a running study of Drools and the lesser known engines beside it. All of it traced back to FICO, where I started my career working with rule engines in my twenties. The part that ends most rule engine side projects, mine included, is the business rule management system that all of the majors had. I could not compete with any of it as one person on a side project. So I put MeshAlpha down and stayed on my architecture track. That is where things sat for more than a decade.

Last year, and then Off By Cents

That changed last year, in 2025, when AI got genuinely good at writing code and the gap between having an idea and having a working implementation of it stopped being the obstacle. I was building an integrations scaffold on an AWS native platform, and part of it was a cost skill: tell me what a given integration costs to run at different volumes. Ahead of a demo it ran clean five times in a row, memory cleared between each run, numbers exact every time. On the sixth run the calculation came back “off by cents”, and took longer than it should have to get there. Nobody else in the room noticed. An answer that drifts by cents while deciding what a system costs to run is a real problem, and I had spent enough of my career on rule engines to know exactly where that kind of drift comes from. It sent me straight back to FICO, back to Forgy, back to everything I had read and built and set aside years earlier. So I built the Pricing Engine.

Why I built the Pricing Engine

I did not build the Pricing Engine for the company I was working for. I built it for myself, to prove something I had believed for a long time and never had a clean chance to prove: less is more, simple is fast, and fast can still be reliable and deterministic.

Once the Pricing Engine worked the way I wanted, I kept going. Forward Chaining next, then Backward Chaining, Bayesian, Sequential, Constraint Satisfaction, Utility and Multi Criteria Decision Making. Twenty engines by January 1st, 2026. Today there are more than thirty five, and the list keeps growing.

The gap I actually found

Somewhere in that stretch of building I noticed the actual shape of the market, not the shape I had assumed it had back when I put MeshAlpha down. On one end sit the large commercial players. On the other sits a long tail of open source rule engines, each with its own conventions, little to no support, and rarely anything you could call a real BRMS. Most of them hand you a config file, a YAML document, or a JSON schema and call that authoring.

I also noticed something about scale that the industry rarely says out loud. Most production rulesets sit well under 2,500 rules. Most of them are closer to 250 or 500. Past that, a ruleset stops being something a team can reason about, and honestly even 500 rules is pushing it for most teams. Fact volume tells a similar story. In my entire career I have never seen an engine handed millions of facts in a single pass. What I have seen, over and over, are millions of small fact sets, 10 or 20 objects each, triggering an engine individually or in async batches.

That gave me a number to build toward. If I could run 2,500 rules against 2,500 facts and get an answer back in 125 milliseconds, I would have something worth shipping.

They land well inside it.

Micro Engines

The last realization shaped BOE more than any of the others. Most rule engines on the market, commercial or open source, ship one engine type, or maybe as many as five, and then bend every problem to fit whichever one you licensed. A Scoring problem gets modeled as a Forward Chaining problem because Forward Chaining is what the vendor sells. An Eligibility check runs through the same general purpose evaluator as a pricing calculation, because that evaluator is the only tool in the box.

I built the opposite of that. Every engine in BOE is its own thing: its own shape, its own runtime, its own input and output schema, its own algorithm tuned for exactly the decision it makes. A Scoring engine does scoring. An Eligibility engine does eligibility. Nothing gets reused just because it happens to already be sitting there.

I never needed to compete with ILOG or Pega or Drools on their own terms. Their architecture solves a much bigger problem than most teams actually have, and that scope is exactly what makes them heavy to adopt and slow to change. My problem was smaller and clearer than that from the start: thirty five specific Micro Engines, each one built the way it should have been built if nobody had to compromise for the sake of a shared platform underneath it.