v2.0

GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here!

Watch the launch videoWatch
gorules
Book a demoGet started

The promotion engine
your commercial team can drive.

Discounts, promo codes, stacking rules, exclusions, and margin floors live in visual decision tables instead of your commerce platform's checkout code. Merchandising edits the rules, replays real carts to see what a campaign costs, and ships it the same day with approvals on the record.

One promo code,
one policy, every channel.

Watch a Saturday on a growth team: a sitewide code stacking onto clearance stock, a one-cell exclusion, a replay across 18,200 orders, a signed release - and web, app, and POS on the same rules inside the hour.

scroll to play
Saturday, 10:04

The summer sale is live.

SUMMER24 takes 20 percent off sitewide. A shopper drops running shoes, a clearance jacket, and a gift card in the bag and pastes the code at checkout.

The cart

Twenty percent, twice.

The jacket was already cut from $149 to $89, and the code takes another 20 percent on top. That line now sells at $71.20 against $74.15 of landed cost - a 4.1 percent loss on every clearance jacket in the sale.

One cell

Growth fixes it herself.

The stacking rule opens the live policy. The code stops combining with markdowns - on a branch, the gift-card exclusion untouched.

Proof before the weekend

18,200 orders replayed.

Thirty days of orders re-run against the draft while you watch: clearance margin comes back 2.3 points, full-price carts keep their 20 percent, and gift cards still discount by nothing at all.

Sign-off

Growth approves. v6.2.0 ships.

Jane Cooper signs the release, it promotes through staging to production with the full trail recorded. Rollback stays one click away.

Same hour

Web, app, and POS agree.

The stacked line drops off the cart, the total recounts, and the exclusion reaches every channel in the same hour - no platform release, no store-by-store config. Three queued campaigns go out behind it.

Your turn.
Edit the policy.

Edit the policy, watch the cart re-price. Run a guided mission or change a discount cell yourself - this is a real first-match decision table, evaluating in the browser as you type.

Promotion policyv2.4.0 · production
conditiondiscountshipping
promo code is SUMMER2420%free
tier is gold, over $20015%free
cart total over $30010%free
customer is new10%standard
otherwise 0%standard
evaluated in 0.4 ms
Cart
Subtotal$130.00
Campaign SUMMER24-$26.00
ShippingFree
Total$104.00

A real first-match policy: pick a mission and watch the rule change, or switch carts to see which row fires. In production your team edits the table, not the code.

A weekend campaign,
a two-week release train.

A promotion engine is supposed to be the one place discounts, codes, and offers are decided. In most retailers it is three places at once: a discount block inside the commerce platform's checkout code, a promo service someone wrote for the app, and a campaign calendar the merchandising team keeps in a spreadsheet. So a flash sale is a deploy, an exclusion is a ticket, and the person accountable for margin cannot change the rules that give it away.

Native platform discounts cover the simple cases and stop exactly where the money is. Stacking order, category exclusions, customer segments, per-cart caps, and margin floors either do not exist or exist as a checkbox with no audit trail, so the interesting rules leak into custom code. Then the code belongs to one channel: POS, the mobile app, the call center, and partner sites duplicate the logic or go without it, and they drift inside a quarter.

The failure mode is always the same and always expensive. A sitewide code lands on top of stock that was already marked down, and every clearance unit sells below landed cost until someone notices in the weekly margin report. Or the reverse: a cautious exclusion blocks a code on items that should have taken it, and support spends the weekend issuing manual credits.

Finance asks questions the code cannot answer either. Which rule version priced this order? Who approved the extra 20 percent? Which lines were excluded and why? When the answers live in a checkout service and someone's spreadsheet, every campaign post-mortem, every chargeback dispute, and every replatform starts with archaeology.

Promotion logic out
of the checkout path.

GoRules is the decision layer of your commerce stack: cart in, discounts out, every rule readable by the people who own the campaign.

01

Offers, exclusions, and stacking as decision tables

Every promotion starts with who and what qualifies: customer segments, order values, product categories, promo codes, first purchases. In a decision table each condition is a column and a promotion is a row that matches, which means the campaign brief and the production logic are finally the same document. Precedence is structural rather than a flag: rows evaluate top to bottom and the first hit wins, so exclusions like gift cards, marketplace items, and already-discounted stock sit above the offers and win by position. Drag a campaign above the loyalty reward and it takes priority. Where offers genuinely should combine, a collect policy gathers every matching row and an aggregation step decides the blend - additive, best-of, or capped.

02

Caps and margin floors finance can point at

A promotion engine should be the place finance sleeps well. Maximum discount value, maximum percentage, and a margin floor per category live as a final guard step after offer selection, so no campaign, however creative, prices below cost. Simulation makes the guarantee testable: replay last month's orders against a draft policy and read qualifying carts, projected discount spend, and margin impact before anything goes live.

03

Campaigns without a release train

A flash weekend, an app-exclusive code, a category boost on slow-moving stock: each is a branch on the live policy, not a change to checkout. Effective-from and expiry conditions sit in the same table as the offer, so a sale ends because its rule says so. Git-like version control gives every campaign its own history, approval workflow, and one-click rollback, and every past campaign stays reproducible: what a customer was quoted in March is exactly what the March policy quotes today.

Keep the checkout.
Move the rules.

Your commerce platform still takes the order and your payment stack still charges the card. GoRules owns the decisions between them.

01

Connect

Checkout, POS, the mobile app, and your subscription billing call GoRules over REST when the cart is priced, or you embed the MIT-licensed open-source ZEN Engine directly in the service that owns the cart, with SDKs for Node.js, Python, Java, Go, C#, and Rust. One ruleset serves every channel instead of a copy per codebase.

02

Model

Rebuild the promotion program as tables and graphs: the exclusion rows on top, the offer matrix under them, the stacking policy, and the cap-and-floor guard that runs last. Cart lines, customer segment, channel, code, and campaign window arrive as plain inputs, so the outcome stays deterministic and reviewable line by line.

03

Simulate

Branch a change and replay last month's orders through both versions. Compare qualifying carts, discount spend, and margin by category before a single customer sees the offer, then trace any one order through every rule that touched it.

04

Operate

Promote through dev, staging, and production with an approval recorded at each step. Every priced cart returns the rules that fired, so support can explain a total instead of guessing, and a campaign that misprices rolls back in one click.

Built for production,
not proof of concept.

  • Sub-millisecond evaluation with the open-source ZEN engine (Rust core), fast enough to sit inline in checkout and re-price a cart on every keystroke of a promo code
  • Git-like version control on the promotion program: a branch per campaign, full commit history, approval workflows, and one-click rollback when a code misfires
  • The same policy answers storefront, app, POS, call center, and partner channels, so an exclusion added on Saturday morning is live everywhere by Saturday afternoon
  • Every priced cart traces to the rules that fired, and every rule change records who changed what and when. SSO, RBAC, and SOC 2, self-hosted on Docker or Kubernetes or on GoRules Cloud
  • No lock-in: the core engine is open source under MIT, and 70+ industry templates, retail among them, give your promotion program a working starting point instead of a blank canvas

Questions, answered.

What is a promotion engine?

A promotion engine is the rules layer of a commerce stack: the component that decides which discounts, codes, offers, and benefits apply to a given cart or customer, in what order they combine, and where they stop. It is separate from the storefront that displays the offer, the cart service that holds the lines, and the payment stack that charges the total. Most engines ship as configuration buried inside a commerce platform or as code inside checkout, which is why an exclusion or a stacking change usually means a vendor ticket or a release. GoRules provides the engine on its own, as visual decision tables your commercial team edits directly, called over REST or embedded in your service.

How is this different from the discounts built into our commerce platform?

Native discount features cover percentage off, fixed amounts, and simple code redemption, and they stop where the margin risk starts. A rules-based promotion engine handles stacking order, category and product exclusions, customer segments, per-cart and per-customer caps, and margin floors, and it returns the reasoning with the result. It also applies the same logic across storefront, POS, mobile, and partner channels instead of one platform, so the answer a customer gets does not depend on where they are standing.

Can our merchandising team change promotions without an engineering release?

Yes. Offers, exclusions, stacking rules, and caps are decision tables edited in the browser, and natural-language rendering keeps every rule readable for whoever signs off on it. GoRules AI can draft a rule change, run the tests, and explain why a given cart priced the way it did. Changes still move through branch, simulation, approval, and versioned promotion, so nothing reaches production without sign-off and any release rolls back in one click.

How do you stop discounts from stacking into negative margin?

Precedence is row order. Under the first-hit policy a decision table evaluates top to bottom and stops at the first match, so an exclusion row above the offers cannot be overridden by a campaign below it - a sitewide code placed under a clearance exclusion simply never reaches marked-down stock. Where a program genuinely does stack, a collect-policy table returns every match and a capping rule bounds the total, for example a maximum discount percentage per cart or a margin floor per category applied as the last guard step. Before any of it ships, replay historical orders through the change and compare discount spend and margin against the current program.

How fast is evaluation at checkout, and can we self-host?

Embedded, the open-source ZEN engine evaluates a promotion policy in well under a millisecond, which is fast enough to re-price a cart inline while a shopper types a code. Behind the REST API, typical latency stays in single-digit milliseconds. You can run GoRules on Docker or Kubernetes inside your own infrastructure, use GoRules Cloud, or embed the MIT-licensed engine directly in the service that owns the cart, so order and customer data never has to leave your systems.

The same engine,
next door.

One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail.

Dynamic PricingThe same decision layer for priceLoyalty EngineEarn rates, burn rules, and tiersRetail and E-commerceEvery commerce decision, one layer

Ship your next promotion
without a deployment.

Model your offers, exclusions, and margin floors in the visual editor today, or send us the discount logic you run now and we will show it back as decision tables.

Get started Book a demo