Why I Built a Rule Engine with Built-in Simulation

The Problem Nobody Talks About

Here's a scene most backend teams will recognize: a product manager walks over and says, "We need to lower the discount threshold."

Simple, right? Except here's what actually happens:

1. A developer writes the PR
2. Another developer reviews it
3. QA tests it (maybe)
4. It gets deployed to staging
5. Someone manually verifies a few cases
6. It goes to production
7. Everyone holds their breath

That last step, the breath-holding, is the real problem. Nobody knows what's going to happen. How many more customers will qualify for the discount? What's the revenue impact? Will it conflict with the VIP promotion that marketing launched last week?

In my 6 years as a backend engineer, I watched teams ship rule changes blind dozens of times. When I asked about the impact, the answer I got was: "We'll find out in production."

Rules Are Not Code Problems

The deeper issue is that engineering teams treat business rules as code problems, when a discount threshold is a business problem that happens to live in code.

When a pricing rule is hardcoded into a Spring Boot service, changing it requires the full software development lifecycle. But the business doesn't think in terms of PRs and deploy pipelines. They think in terms of "if the customer is VIP and the cart is over $100, give them 20% off."

This mismatch creates a bottleneck. Engineering becomes the gatekeeper for every business logic change. And because there's no way to preview the impact, every change carries risk. Pricing is where I've watched this fail most often, which is why how pricing logic built out of branches eventually falls apart got a post of its own.

What "Built-in Simulation" Actually Means

When I started building LexQ, the rule engine part was not the hard part. Plenty of solutions exist for defining if-then rules and executing them via API. Seeing the impact of a change before deploying is rarer. Commercial decisioning suites such as IBM ODM, Pega, and InRule offer it as simulation. The open-source engines teams usually pick are a different story: as of 2026-09-30, neither Drools nor OPA documents a way to replay recorded executions against a new rule version and compare the outcome with the current one.

Here's what simulation looks like in practice:

Dry Run: You write a rule, then test it with a single input: "If I send loyaltyTier=VIP, purchaseSubtotalUsd=100, what happens?" You see exactly which rules fire, which get blocked by conflict resolution, and what the output would be. All before publishing.

Impact Simulation: You take your last 10,000 real execution records and run them through the new rule version and a baseline version, usually the live one. The result? A side-by-side comparison showing:

• Match rate changes (did more or fewer records match?)
• Metric deltas (how did total discount amounts change?)
• Per-rule statistics (which specific rules matched more or less?)

This is the equivalent of a staging environment for business rules. Except it uses real data, not test fixtures someone wrote six months ago.

A/B Testing for Rules

Simulation tells you what would happen. A/B testing tells you what does happen.

LexQ lets you split live traffic between two rule versions, say 90% to your current rules and 10% to a candidate. You measure real outcomes, then promote the winner. Your application sends one stable key, such as the customer ID, in context.trafficKey. LexQ splits on that key, and changing the split needs no deploy. Requests without the key all stay on your current rules.

This is standard practice for frontend features, and credit decisioning has done it for decades under the name champion/challenger. General-purpose rule engines mostly leave it out: as of 2026-09-30, the documentation of Drools, OPA, GoRules, and DecisionRules describes no built-in way to split live traffic between rule versions. Built-in traffic splitting is worth checking for when you compare engines you run yourself with engines someone else operates.

The Architecture Decision

I deliberately built LexQ as a managed API, not a library you embed in your application. Here's why:

When rules live inside your application code (even if managed by a rule engine library), you still need to deploy your application to change them. The rule engine might separate the definition from the code, but the deployment is still coupled.

LexQ decouples all three: definition, execution, and deployment. You define rules in the console, test them with simulation, and deploy them in seconds. Your application just calls the API.

curl -X POST https://api.lexq.io/api/v1/execution/groups/{groupId} \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "facts": {
      "loyaltyTier": "VIP",
      "purchaseSubtotalUsd": 100.00
    },
    "context": {}
  }'

The response tells you which rules matched, what actions to execute, and provides a full trace for debugging. That same trace matters long after debugging, when the question shifts from what a rule does to which rule decided a specific case and on what evidence. How far back you can go depends on how long your plan keeps execution logs.

Who This Is For

LexQ is built for engineering teams that own the business decisions in their systems, not for everyone. If your business rules change once a year and are simple enough to manage with a few if-statements, you don't need a rule engine.

But if you recognize any of these patterns, you probably do:

• Your team deploys code every time a business rule changes. Pricing thresholds, eligibility criteria, fee calculations: every tweak requires engineering effort.
• Nobody knows the impact until production. You've been burned by a rule change that looked harmless but affected thousands of transactions.
• Business logic is scattered across services. The "real" rules exist in Slack messages and spreadsheets, not in any single source of truth.
• Product and ops teams wait weeks for changes that should take minutes. The backlog is full of "change this threshold" tickets.

What LexQ Is Today

That is the product I ended up building. LexQ is a Decision Operations Platform for engineering teams, live today with a visual rule builder, Git-style versioning, Impact Simulation, A/B testing, and an MCP server for AI agent integration. Simulation is one pillar of that, not the whole of it, and I've laid out where testing sits among the other jobs the platform has to do for anyone meeting the category for the first time.

I'm focused on getting this right for the first set of customers before expanding. If you're interested in trying it out, the free tier gives you 1,000 executions and 100 simulated records a month. That is enough to see whether LexQ fits your workflow, though a 10,000-record simulation like the one above needs a paid plan.

→ Start free at lexq.io