The Four Engines: What Actually Decides Whether You Get a Discount

Every Reclavio decision passes through four independent engines before anything reaches a shopper. Each engine has one job, one authority, and one veto. If any engine says no, the answer is no—regardless of what the others think.

This separation isn't cosmetic. It's why a bug in the AI can't burn your margin. It's why a misconfigured rule can't bypass your product exclusions. And it's why every decision is auditable, reversible, and explainable.

The pipeline: Conversation Engine → Rule Engine → Exclusion Engine → IPOE. Every request walks this path. No shortcuts.

---

Author: Brodie, Founder @ Reclavio Status: Private beta (pre–Shopify App Store) Last updated: February 2026

---

The 60-Second Flow: One Cart, Four Engines

Before the architecture, here's what actually happens when a shopper with a $220 cart types "any discounts available?":

1. Conversation Engine classifies the message → route = NEGOTIATION (only route that can issue offers)
2. Rule Engine checks merchant rules → cart ≥ $200, free shipping eligible → ✅ eligible, offer = free shipping
3. Exclusion Engine checks every item → two items clean, one is in the "Clearance" collection → ❌ excluded item removed from discount scope
4. IPOE scores the offer → EIP = positive (profitable after discount) → guardrails pass → Thompson Sampling selects the action → ✅ proceed
5. Shopper sees: "Great news—your cart qualifies for free shipping!" with a one-time code

Four engines. Four independent verdicts. One answer.

If step 1 had classified her message as a shipping question, the pipeline would have answered it and stopped. No discount considered—because the Conversation Engine never opened the gate. If the Rule Engine said no in step 2, the shopper gets a polite explanation—not silence. If the Exclusion Engine blocked everything in step 3, same. Each engine contributes a clear, logged reason.

---

Engine 1: The Conversation Engine

Classify intent. Route to the right handler. Only one route can mint discounts.

When a shopper sends a message, the first decision isn't "should we discount?"—it's "what does this person actually need?"

The Conversation Engine uses a multi-layer intent classifier (keyword heuristics → weighted scoring → ML fallback) to route every message to a specialized handler:

MIXED_INTENT answers the policy question first, then explicitly prompts: "Would you also like me to check for available offers?" Only when the shopper confirms does it transition to NEGOTIATION.

Why this matters for your margin

Most shopper messages aren't price objections. In our pilot testing, the majority were shipping and returns questions. Without intent classification, a naive system would check discount eligibility on every single message—and either waste compute or, worse, proactively offer discounts to someone who just wanted to know if Saturday delivery was available.

The Conversation Engine ensures the discount pipeline only activates when the shopper explicitly raises a price concern. Everything else gets a fast, helpful answer—at zero margin cost.

The conversation, word for word

🛒 Shopper: How long will shipping take to Austin?

🤖 Reclavio: Standard shipping to Austin is 3–5 business days. Express (1–2 days) is available at checkout.

🛒 Shopper: Will it get here by Friday?

🤖 Reclavio: If you order today with Express, it should arrive by Friday. Standard would arrive Monday or Tuesday.

Two messages. Two answers. Zero discount checks. The POLICY route handled both in under 50ms with no LLM call—deterministic responses pulled from the merchant's store policies.

🛒 Shopper: Hmm, this is a bit expensive. Any discounts?

🤖 Reclavio: Let me check what's available for your cart... ✅ Your cart qualifies for free shipping on orders over $200! Here's your offer—use it at checkout.

Only now—on the third message, when the shopper raised a price objection—did the Conversation Engine route to NEGOTIATION and trigger the downstream engines.

Design principle: The AI writes the sentence. Deterministic code writes the policy. The LLM shapes delivery, never eligibility.

---

Engine 2: The Rule Engine

Your rules. Your thresholds. Always authoritative.

Once the Conversation Engine routes a message to NEGOTIATION, the Rule Engine evaluates whether the cart qualifies for an offer—and what that offer should be.

Rules are structured as typed conditions with explicit actions:

WHEN cart_value >= $100
AND customer_type = "new"
THEN offer 10% off (max $25)

How priority works

Most merchants have multiple rules. What happens when a $200 cart triggers three of them?

The Rule Engine resolves conflicts with a strict precedence:

1. Priority number (lower = higher priority) — you set this
2. Specificity — more conditions = more specific = wins ties
3. Offer type hierarchy — fixed amount > percentage > free shipping (when all else is equal)

The highest-priority matching rule wins. One offer per cart, period. No stacking, no confusion.

What you control

The nuance: what "no matching rule" means

If no rule matches the cart, the Rule Engine returns no offer—and the shopper gets a polite, credible explanation. Not silence, not an error, not a generic "sorry." The AI explains what the store offers and suggests how the shopper might qualify (e.g., "Free shipping kicks in at $100—you're $15 away!").

Trust contract: The Rule Engine is the source of truth for offer eligibility. The AI cannot override, extend, or invent rules. Period.

---

Engine 3: The Exclusion Engine

Even if the rules say yes, exclusions can still say no.

The Exclusion Engine is a fail-closed safety net that runs independently of the Rule Engine. Its job: ensure protected products never receive a Reclavio discount, regardless of what the rules permit.

The fail-closed philosophy

The Exclusion Engine operates on a simple axiom: unknown = excluded.

If a product can't be resolved (API timeout, missing metadata, unexpected product type), it's treated as excluded. The system errs on the side of protecting your margin, never on the side of issuing an offer.

The 7-check pipeline

Every product in the cart passes through seven independent checks. If any check flags an item, that item is excluded from the discount scope:

What happens in a mixed cart?

Real-world carts are messy. A shopper might have three eligible items and one excluded item.

The Exclusion Engine doesn't reject the entire cart—it scopes the discount. The eligible items get the offer; the excluded item is untouched. The shopper sees a clear explanation: "Your discount applies to 3 of 4 items in your cart."

This is enforced across all Reclavio surfaces—widget, checkout extensions, and the AI agent. A product excluded by any check will never receive a Reclavio discount, no matter how the shopper interacts with your store.

Configuring exclusions

Go to Settings → Exclusions in the Reclavio dashboard. Add products, collections, tags, vendors, or product types. Changes take effect immediately—no cache delay, no propagation wait.

Trust contract: The Exclusion Engine cannot be bypassed by the AI, the Rule Engine, or IPOE. It runs on every decision path. Protected products stay protected.

---

Engine 4: IPOE (Incremental Profit Offer Engine)

Don't just check eligibility. Optimize for profit.

The first three engines answer: "Is this offer allowed?" IPOE answers a harder question: "Is this offer profitable?"

Traditional recovery tools optimize for conversion rate—more discounts = more conversions = green dashboards. But if 40% of those shoppers would have bought anyway, you're paying margin for nothing. IPOE ensures every offer creates incremental profit—the kind that wouldn't have happened without the intervention.

How it works: Expected Incremental Profit (EIP)

IPOE scores every possible action (no offer, 5% off, 10% off, free shipping) using a single formula:

EIP = [P(convert | action) × profit(action)] − [P(convert | no action) × profit(no action)]

In plain English: "How much more profit do we expect if we make this offer, compared to doing nothing?"

• P(convert | action) — probability the shopper converts with the offer (estimated from cart value, session behavior, customer segment)
• profit(action) — revenue minus COGS minus discount minus intervention cost
• P(convert | no action) — probability they convert without any offer

If EIP is negative, the offer would cost more in margin than it generates in incremental revenue. IPOE blocks it—even if the Rule Engine approved it.

The guardrails (G1–G7)

Before any offer reaches the shopper, it passes through seven guardrails:

Every guardrail can independently block an offer. The reasons are logged and visible in your Activity Log as "Smart Blocks."

The safety fuse: Circuit Breaker (G8)

What if a bug causes IPOE to offer discounts on every session? The Circuit Breaker monitors the treatment discount rate across a sliding window and automatically pauses offers if something looks wrong:

When Red trips, IPOE is paused for your store within seconds. No manual intervention required. And when you resume, the circuit breaker resets cleanly—no stale data causing an immediate re-trip.

For the full circuit breaker architecture (sliding windows, pause priority, clean reset semantics), see the architecture deep dive.

Proving it works: holdout groups

IPOE includes built-in holdout groups (treatment vs. control) so you can measure whether discounts create incremental profit—or just subsidize buyers who would have converted anyway. Configure a holdout percentage (0–50%) in Settings, review your Holdout Comparison Card after the 7-day minimum runtime, and see the data for yourself.

Trust contract: IPOE optimizes within your rules, never beyond them. If the Rule Engine says no, IPOE never sees the request. If IPOE says no, it logs why—and you can review every blocked decision.

---

How the Four Engines Work Together

Here's the full pipeline for a single request:

sequenceDiagram
    participant S as Shopper
    participant W as Widget
    participant CE as Conversation Engine
    participant RE as Rule Engine
    participant EE as Exclusion Engine
    participant IP as IPOE

    S->>W: "Any discounts available?"
    W->>CE: Classify intent
    CE->>CE: Route = NEGOTIATION ✅

    CE->>RE: Check rules (cart $220)
    RE->>RE: Rule matched: free shipping over $200
    RE-->>CE: Eligible ✅

    CE->>EE: Check all items
    EE->>EE: 7-check pipeline
    EE-->>CE: 2/3 items eligible, 1 excluded

    CE->>IP: Score offer (EIP)
    IP->>IP: EIP > 0 ✅, Guardrails pass ✅
    IP-->>CE: Proceed ✅

    CE-->>W: "Free shipping on eligible items" + discount code
    W-->>S: Offer card displayed

Key properties of this pipeline:

• Serial veto power — each engine can independently block the request
• No engine can override another — IPOE can't bypass exclusions; the AI can't bypass rules
• Every decision is logged — for auditability, you can trace exactly which engine said what
• Fail-safe defaults — if any engine errors, the default is "no offer" (fail-closed)

---

The Trust Contract: What Each Engine Promises NOT to Do

---

FAQ

Q: Can I disable IPOE and just use rules? A: Yes. IPOE is optional. You can run in OFF mode (rules-only), SHADOW mode (IPOE evaluates but doesn't act), LIVE mode (full optimization), or ADAPTIVE mode (LIVE with dynamic exploration via Thompson Sampling). Switch anytime in Settings.

Q: What if the AI agent gets manipulated into offering unauthorized discounts? A: The AI can only request offers through the NEGOTIATION route. Even then, rules, exclusions, and IPOE all independently validate the request. The LLM shapes the delivery message—deterministic code decides eligibility. Additionally, a server-side "FinalGate" validates every discount creation attempt as a last-resort safety net.

Q: Will four engines make responses slow? A: The Rule Engine and Exclusion Engine run in under 50ms combined. IPOE scoring is sub-100ms. The dominant latency is the LLM response (2–5 seconds for streaming). The engines add negligible overhead.

Q: What happens to excluded items in a mixed cart? A: The discount is scoped to eligible items only. Excluded items remain at full price. The shopper sees a clear explanation.

Q: Can I see why an offer was blocked? A: Yes. Every decision is logged with the blocking engine and specific reason (e.g., "G1: margin floor violated" or "COLLECTION exclusion: Clearance"). Review these in your Activity Log under "Smart Blocks."

---

What happens next: You'll get the pack + Shadow Mode checklist. Run Shadow Mode → see your Opportunities card → review candidates → adjust rules → go live. If you want early access, reply to the email.

---

Every discount Reclavio issues passes through four independent engines. Every "no" is logged and explained. Every "yes" is profitable by design.

The four engines don't just protect your margin. They make every recovery decision transparent, auditable, and reversible—so you can trust the system at 3 AM when you're not watching.

Get the templates (free) →

---

For the product story, read The $14 Problem: Why Cart Recovery Tools Destroy Margin. For the full engineering architecture, read How We Built Profit-Aware Cart Recovery on Shopify. Have questions? Check the Help Center →.

---

References

How I verify claims: Shopify platform constraints are cited to official Shopify documentation (shopify.dev). Product metrics are labeled as "pre-launch test results" or "targets." All engine behaviors described here are verified against the codebase as of February 2026.