Every software engineer has been there: a simple conditional that grows into nested if-else hell. What starts as if (age > 18) becomes hundreds of lines handling edge cases, exceptions, and business rules that change every quarter. In regulated industries like fintech, insurtech, healthcare and government systems, this gets serious fast. When auditors ask "why was this loan rejected?" or regulators demand "show me how this decision was made," pointing at tangled code doesn't cut it. if (age > 18) The answer isn't just cleaner code. It's rethinking how we handle business logic entirely. Here's what I've learned building decision systems for regulated industries. The Decision Engine Spectrum Modern decision systems fall into a few categories, each with real trade-offs: Hardcoded Logic: Your standard if-else in code. Easy to start with, nightmare to maintain. Every change needs a developer and a full deployment. Hardcoded Logic: JSON Logic - Rules stored as data. Something like {"and": [{">": [{"var": "age"}, 18]}, {"==": [{"var": "verified"}, true]}]} sits in your database and updates without touching code. Light and portable, but hits limits with complex scenarios. JSON Logic {"and": [{">": [{"var": "age"}, 18]}, {"==": [{"var": "verified"}, true]}]} Rules Engines - Proper systems like Drools or GoRules Zen. They handle conflict resolution, rule chaining, complex inference. Great for intricate business logic, but they're heavy. Rules Engines AI-Based Systems - Models that learn decision patterns from data. Powerful for spotting patterns, but explaining why they made a choice? That's the hard part, especially when regulators come knocking. AI-Based Systems Most teams start hardcoded, move to JSON logic when they're drowning in conditionals, and only go full rules engine when things get really complicated. Knowing when to make each jump matters. The Core Comparison: JSON Logic vs Rules Engines Let's get practical. Say you're building loan approval logic. Here's what JSON logic looks like: { "and": [ {">": [{"var": "credit_score"}, 650]}, {"<": [{"var": "debt_to_income"}, 0.43]}, {">=": [{"var": "employment_months"}, 24]} ] } { "and": [ {">": [{"var": "credit_score"}, 650]}, {"<": [{"var": "debt_to_income"}, 0.43]}, {">=": [{"var": "employment_months"}, 24]} ] } You evaluate it directly in your code with a simple JSON logic library. Performance is solid, evaluating these rules takes microseconds. But what happens when your rules get more complex? Say you're building an insurance underwriting system. You need to handle different policy types, risk assessments, regional regulations, existing claim history, age-based pricing tiers. JSON logic files get messy fast. This is where a proper rules engine comes in. Here's what it looks like using GoRules Zen: engine := zen.NewEngine(zen.EngineConfig{}) underwritingGraph, err := os.ReadFile("./underwriting_rules.json") if err != nil { panic(err) } underwritingDecision, err := engine.CreateDecision(underwritingGraph) if err != nil { panic(err) } // Test with different insurance scenarios testUnderwritingRules(underwritingDecision, map[string]any{ "applicant_age": 34, "annual_income": 75000, "credit_score": 720, "employment_status": "employed", "existing_claims": 0, "coverage_amount": 250000, "policy_type": "life", "region": "London", }) // High risk scenario testUnderwritingRules(underwritingDecision, map[string]any{ "applicant_age": 58, "annual_income": 42000, "credit_score": 580, "employment_status": "self_employed", "existing_claims": 3, "coverage_amount": 500000, "policy_type": "critical_illness", "region": "Manchester", }) engine := zen.NewEngine(zen.EngineConfig{}) underwritingGraph, err := os.ReadFile("./underwriting_rules.json") if err != nil { panic(err) } underwritingDecision, err := engine.CreateDecision(underwritingGraph) if err != nil { panic(err) } // Test with different insurance scenarios testUnderwritingRules(underwritingDecision, map[string]any{ "applicant_age": 34, "annual_income": 75000, "credit_score": 720, "employment_status": "employed", "existing_claims": 0, "coverage_amount": 250000, "policy_type": "life", "region": "London", }) // High risk scenario testUnderwritingRules(underwritingDecision, map[string]any{ "applicant_age": 58, "annual_income": 42000, "credit_score": 580, "employment_status": "self_employed", "existing_claims": 3, "coverage_amount": 500000, "policy_type": "critical_illness", "region": "Manchester", }) Rules engine gives us the ability to load complex rule graphs, not just simple conditionals. When to use JSON logic: When to use JSON logic: Under 20-30 simple, independent rulesRules change occasionallyYou want zero infrastructure overheadDirect evaluation in your code is fine Under 20-30 simple, independent rules Rules change occasionally You want zero infrastructure overhead Direct evaluation in your code is fine When to use a rules engine: When to use a rules engine: Rules are complex or interconnectedRules depend on other rules (chaining, inference)Business users need to manage rules through visual tools Rules are complex or interconnected Rules depend on other rules (chaining, inference) Business users need to manage rules through visual tools The AI Question AI is everywhere right now, especially in workflows. But here's the thing, AI alone isn't enough when it comes to decision-making in regulated industries. The real power comes from combining AI with rules engines inside workflows. Think about a loan application workflow. An AI model might assess risk, summarise the application, flag potential issues. But the actual decision, approve, reject, escalate, needs to follow strict rules. This is where rules engines step in as the backbone of the workflow. Here's an example, an AI component receives an application, extracts and enriches the data, maybe does some analysis on supporting documents. Then it hands off to a rules engine which evaluates credit score, income ratios, compliance checks. The rules engine makes the decision, logs it, and the workflow continues, sending notifications, generating reports, whatever comes next. In agentic workflows, AI handles the "thinking" parts while rules engines handle the "deciding" parts. The rules engine acts as a guardrail, keeping the workflow compliant, auditable, and explainable even when AI is doing the heavy lifting around it. The beauty of this approach? You get the best of both worlds. AI handles complexity, pattern recognition, and automation. The rules engine provides structure and regulatory compliance. Neither works as well alone in these scenarios. If you're in fintech, insurance, healthcare, or government systems, you need to explain your decisions. This means showing: Decision trails - Every decision traced back to specific rule versions. When did rule X change? Who approved it? What decisions used the old vs new version? Reproducibility - Given the same inputs and rule version, you get the same output. Always. Reproducibility Human-readable logic - Compliance teams and regulators need to understand why decisions happened without parsing code. Human-readable logic JSON logic and rules engines both handle this better than hardcoded logic. You can design your system so each decision stores which rule version it used. The format matters too. JSON logic is genuinely readable to non-engineers with minimal training. Rules engine DSLs vary some are clear, others get cryptic. Pick one where your compliance team can actually follow the logic. Don't forget performance monitoring. In high-volume systems (payment processing, real-time fraud checks), you need rule evaluation to stay under 10ms per evaluation. Both JSON logic and modern rules engines can hit this, but test with production-scale data. Decision Framework Decision Framework Start with hardcoded if: You have under 10 rulesThey rarely changeIt's not a regulated domainYou're prototyping You have under 10 rules They rarely change It's not a regulated domain You're prototyping Move to JSON logic when: Rules reach 10-50+Business wants to adjust rules without deploysYou need decision traceabilityYour team is smallRules are simple and independent Rules reach 10-50+ Business wants to adjust rules without deploys You need decision traceability Your team is small Rules are simple and independent Adopt a rules engine when: Rules exceed 50-100Rules depend on other rulesMultiple teams manage different rule setsThe domain is genuinely complex (insurance pricing, clinical decision support) Rules exceed 50-100 Rules depend on other rules Multiple teams manage different rule sets The domain is genuinely complex (insurance pricing, clinical decision support) Red flags to take note of, if you've outgrown your current approach: Developers scared to touch the decision codeRules taking 30+ minutes to update in productionBusiness is constantly asking "why did X happen?"Explaining past decisions takes weeks instead of hours Developers scared to touch the decision code Rules taking 30+ minutes to update in production Business is constantly asking "why did X happen?" Explaining past decisions takes weeks instead of hours The right decision engine depends on your constraints. The best teams start simple and scale deliberately. JSON logic handles 80% of scenarios with 20% of the complexity. Rules engines solve the remaining 20% when you actually need them. AI augments both but rarely replaces them in regulated environments. The key is building for traceability from day one. Whether you choose JSON logic or a full rules engine, make decisions explainable, reproducible, and understandable. Your future self will thank you.
