# GoRules - Complete Documentation > This document contains the full content of all GoRules documentation pages. --- ## Why GoRules? - The Business Rules Engine Built Different **URL:** https://gorules.io/why-gorules **Description:** Native performance, runs anywhere, no per-eval pricing, open source core. Discover why GoRules is the modern choice for business rules management. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # The rules engine built different. Most rules engines are stuck in the past - slow, expensive, locked to the cloud. GoRules is native, fast, and runs anywhere. Here's what makes us different. ## Not an API wrapper. Most 'SDKs' claim support for Python, Go, and Node.js - but under the hood, every decision is a REST call to someone else's server. The ZEN engine compiles to native code and runs in your process, on your device, in microseconds. _Typical vendor_ Your appInternetTheir server `~50ms` _GoRules_ Your app + ZEN engine, embedded `~50μs` No network hop - the round trip is the whole difference. - Native Rust core - Native bindings for Node.js, Python, Go, iOS, Android - No network hop - 1000x faster ## One engine. Every environment. Cloud, self-hosted, mobile, edge, air-gapped - the same engine runs everywhere, not different products stitched together. Build once, deploy anywhere. ### Cloud Managed BRMS. We handle infrastructure. ### Self-hosted Your VPC. Your data. Docker or K8s. ### Mobile Native iOS and Android. On device. ### Edge & IoT Warehouses, kiosks, devices. ### Air-gapped Fully disconnected. Still works. ## Unlimited decisions. Predictable costs. Most vendors charge per evaluation. Sounds cheap at first - until you're running millions of decisions a day. GoRules is flat-rate. _Typical vendors_ 1M evaluations`$1,000/mo` 10M evaluations`$10,000/mo` 100M evaluations`$100,000/mo` Pricing model`Per evaluation` _GoRules_ 1M evaluations`Included` 10M evaluations`Included` 100M evaluations`Included` Pricing model`Flat rate` No surprises. No meter anxiety. No “we need to optimize our rule calls” conversations. ## Audit every line. The ZEN engine is fully open source. Not 'source available' with restrictions, not 'open core' with the good parts behind a paywall - actually open, because critical business logic shouldn't be a black box. - Full source on GitHub - Fork it if you need to - Self-host forever - even if we disappear - Community contributions welcome - No vendor lock-in - your rules are portable JSON [View on GitHub](https://github.com/gorules/zen) ## Business users and developers. One platform. Rules engines usually pick a side - either dumbed down for business users, or powerful but dev-only. We refuse to choose. ### For business users - Spreadsheet-like decision tables - Edit rules in Excel, import back - Visual flow builder - drag and drop - No code required - Test with real data before publishing ### For developers - Git-like workflow - branches, commits, rollback - Full JavaScript functions when you need them - Native SDKs - not wrappers - CI/CD integration - Microsecond-level performance tracing Same graph. Same rules. Different interfaces for different people. ## Built different. See for yourself. Start free on GoRules Cloud, or self-host the open-source engine - your rules stay portable JSON either way. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## What is a Business Rules Engine? Complete Guide **URL:** https://gorules.io/what-is-business-rules-engine **Description:** A business rules engine (BRE) automates decision-making by executing predefined business logic. Learn how BREs work, key components, use cases by industry. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # What is a business rules engine? The complete guide to understanding business rules engines - how they work, when you need one, and how they transform decision-making at scale. [Try GoRules free](https://us1.gorules.io)[Explore BRMS](/brms) ## In a nutshell A business rules engine (BRE) is software that automates decision-making by executing predefined business logic - without requiring code changes. It separates “what to decide” from “how to execute,” enabling faster policy updates, consistent outcomes at scale, and complete audit trails for compliance. ## How does a business rules engine work? Input data goes in, predefined rules are evaluated, decisions come out - a specialized if-this-then-that processor built to handle thousands of conditions and millions of decisions per second with complete consistency. **Input data** Loan application, transaction, customer profile, or any structured data **Rules engine** Evaluates conditions, applies logic, calculates results **Decision output** Approve, deny, calculate price, route request, trigger action The power of this approach lies in the separation of concerns. Application developers build systems that can execute decisions, while business users define what those decisions should be. When business logic changes - new regulations, updated policies, competitive responses - only the rules need to change, not the underlying applications. ### A practical example: loan approval Consider a lending company that processes thousands of loan applications daily. Without a business rules engine, the approval logic is hardcoded into the application: every change to lending criteria means developers modifying code, testing it, and deploying a new version - a process that takes weeks or months. With a business rules engine, those lending criteria exist as configurable rules. A compliance officer can update the debt-to-income threshold in minutes. A product manager can create new approval tiers for preferred customers. A risk analyst can add fraud detection rules. All without writing code, waiting for sprints, or risking production stability. credit.scoredebt-to-incomedecisionrate at least 700below 0.4approve4.5% 650 to 699below 0.4approve6.2% 600 to 649below 0.35review7.8% below 600anydecline\- ### The evaluation process When the rules engine receives a request, it follows a systematic process: 1. **Input validation:** the engine validates incoming data against expected schemas, ensuring all required fields are present and correctly formatted before evaluation begins. 2. **Rule selection:** based on the input context, the engine identifies which rules apply - all rules in a decision table, or a subset based on filters and conditions. 3. **Condition evaluation:** each applicable rule's conditions are evaluated against the input data. Complex expressions, calculations, and external lookups happen at this stage. 4. **Action execution:** when conditions match, corresponding actions execute - setting output values, triggering calculations, or routing to sub-decisions for additional processing. 5. **Result assembly:** the engine assembles the final output, including the primary decision, supporting data, and metadata for audit purposes. ## Business rules engine vs. alternatives Business rules engines excel in specific scenarios, but they're not the only option. Understanding how BREs compare to hardcoded logic, workflow engines, and machine learning helps you pick the right approach - or combination of approaches. ### Use a business rules engine when - You need instant, deterministic decisions with full explainability - Compliance and audit trails are mandatory - Business users need to manage logic - The same rules apply across multiple systems Examples: credit decisioning, pricing rules, eligibility determination, fraud rules, policy enforcement. ### Use a workflow engine when - Processes span hours, days, or weeks - Human approvals and tasks are involved - You orchestrate multiple systems and services - State must be maintained across interactions Examples: employee onboarding, loan underwriting processes, customer support tickets, order fulfillment. ### Use machine learning when - Patterns are complex and not easily expressed as rules - Historical data is available for training - Probabilistic predictions are acceptable - The problem involves classification, ranking, or anomaly detection Examples: fraud scoring, recommendation engines, document classification, demand forecasting. ### The hybrid approach: best of all worlds Modern architectures increasingly combine these technologies. A fraud detection system might use ML models to generate risk scores, then feed those scores into a business rules engine that applies deterministic policies (e.g., “if risk\_score > 0.8 AND transaction\_amount > $10,000, decline and flag for review”). This hybrid approach provides the pattern recognition power of ML with the explainability, control, and compliance capabilities of rules engines. ## Key components of a business rules engine A complete business rules platform combines several interconnected components, each serving a specific function in the rule lifecycle. ### Rule Repository Central storage for all business rules with full version history. Organize rules across projects, search and discover existing logic, track every change made over time. ### Visual Rule Editor Intuitive authoring interface for creating rules without code. Decision tables, expression builders, and flow designers enable business users to participate directly. ### Execution Engine High-performance core optimized for both throughput and latency. Evaluates rules against input data and returns decisions consistently regardless of scale. ### Testing & Simulation Validate rules before production deployment. Run test cases, batch test with historical data, simulate how changes impact outcomes before they affect real decisions. ### Audit & Compliance Complete audit trail of every change and decision. Track who modified rules, what changed, when. Essential documentation for compliance reviews and regulatory examinations. ### Deployment Management Promote rules through environments with approval workflows. Configure sign-offs before changes go live. Roll back to any previous version instantly if issues arise. ### Types of business rules engines Not all business rules engines work the same way. Understanding the different approaches helps you choose the right tool for your specific use case and performance requirements. - **Production rules (forward chaining):** rules are evaluated when conditions match, potentially triggering other rules in a chain until no more rules fire. Used for complex inference where one decision leads to another. - **Deterministic rules:** rules are evaluated in a defined order, and each input produces exactly one output. No chaining or inference - simpler, faster, and easier to debug, ideal for straightforward business decisions where predictability is paramount. - **Event-driven rules:** rules trigger in response to events in real-time. Common in fraud detection, IoT applications, and streaming scenarios where decisions must happen as data arrives. - **Stateful vs stateless:** stateless engines evaluate each request independently with no memory between calls - simpler to scale and debug. Stateful engines maintain context across multiple interactions, useful for shopping cart rules, session-based decisions, or multi-step approval workflows. [See how GoRules BRMS implements this](/brms) ## Use cases by industry Business rules engines power decisions wherever consistency, speed, and auditability matter. Here's how different industries put them to work. ### Financial Services Banks, lenders, and financial institutions use business rules engines to automate critical decisions while maintaining regulatory compliance. From credit decisioning that evaluates hundreds of factors in milliseconds to fraud detection systems that analyze transaction patterns in real-time, BREs enable financial services to process thousands of applications per second. Every decision creates an audit trail that satisfies regulators and supports dispute resolution. #### Common use cases - Credit decisioning and loan origination - Fraud detection and transaction monitoring - KYC/AML compliance screening - Risk scoring and assessment - Account opening eligibility - Collections strategy and prioritization ### Insurance Insurance carriers leverage business rules engines across the entire policy lifecycle. Underwriting rules evaluate risk factors and determine coverage eligibility. Claims systems apply adjudication rules to process thousands of claims daily. Rating engines calculate premiums based on complex factor combinations. Product managers and actuaries can update rules directly, accelerating time-to-market for new products and responding quickly to regulatory changes. #### Common use cases - Automated underwriting decisions - Claims processing and adjudication - Policy pricing and rating calculations - Coverage eligibility determination - Renewal risk assessment - Agent commission calculations ### Payments & Fintech Payment processors and fintech companies require sub-millisecond decision latency for real-time transaction processing. Business rules engines evaluate each transaction against fraud rules, compliance requirements, and routing logic instantly. When a payment requires additional verification, rules determine whether to step up authentication, decline, or flag for review. This enables fintechs to maximize approval rates while minimizing fraud losses. #### Common use cases - Real-time transaction approval/decline - Payment routing optimization - Dynamic interchange and fee calculation - Velocity checks and spending limits - Merchant risk scoring - Regulatory compliance screening ### E-commerce & Retail Retailers use business rules engines to personalize the shopping experience and optimize operations. Promotion engines apply complex discount rules based on cart contents, customer segments, and inventory levels. Pricing rules adjust dynamically based on demand, competition, and margins. Fulfillment rules determine optimal shipping methods and warehouse selection. Merchandisers can configure these rules through visual interfaces without engineering support. #### Common use cases - Promotion and discount rule management - Dynamic pricing optimization - Product recommendation logic - Inventory allocation rules - Customer segmentation and targeting - Shipping and fulfillment routing ### Healthcare Healthcare organizations use business rules engines to navigate complex regulatory requirements while improving patient outcomes. Insurance eligibility verification happens in real-time during patient registration. Claims adjudication rules apply payer-specific policies to determine coverage and reimbursement. Clinical decision support systems use rules to surface relevant information and alerts to clinicians, improving care quality while reducing liability. #### Common use cases - Insurance eligibility verification - Claims adjudication and processing - Prior authorization decisions - Clinical decision support systems - Medical coding validation - Care pathway recommendations ### Logistics & Supply Chain Supply chain and logistics companies optimize complex operations using business rules engines. Carrier selection rules evaluate cost, service levels, and capacity to choose optimal shipping methods. Customs compliance rules ensure shipments meet regulatory requirements before crossing borders. Inventory replenishment rules trigger orders based on demand forecasts, lead times, and safety stock levels. Operations teams can adjust rules as business conditions change. #### Common use cases - Carrier selection and routing - Dynamic rate calculation - Inventory replenishment rules - Customs and trade compliance - SLA monitoring and alerts - Warehouse allocation logic ## Why use a business rules engine? Organizations implement business rules engines to solve specific operational challenges. Here are the concrete benefits they experience. **90%**faster changes **<1ms**latency **100%**audit trail **10M+**decisions/min ### Deploy Changes in Minutes, Not Months When regulations change or business needs evolve, update rules and see them take effect immediately. No code deployments, no release cycles, no waiting for IT. A compliance officer can adjust lending criteria in the morning and have it applied to every application by afternoon. ### Ensure Perfectly Consistent Decisions Apply identical logic across every channel, system, and touchpoint. Whether a customer applies online, through mobile, via an agent, or at a branch, they receive the same consistent decision based on the same criteria. Eliminate the inconsistencies that frustrate customers and create compliance risk. ### Maintain Complete Audit Trails Every decision is logged with the exact rules that were applied, the input data evaluated, and the resulting output. When auditors or regulators ask why a specific decision was made, you have complete documentation. This isn't just compliance - it's operational intelligence. ### Empower Business Users Directly Let business analysts, compliance officers, product managers, and operations teams manage rules directly through visual interfaces. Reduce the IT bottleneck that slows every business initiative. The people who understand the business can now control the logic without writing code. ### Scale to Any Decision Volume Modern business rules engines handle millions of decisions per minute with sub-millisecond latency. Process real-time transactions, batch millions of records overnight, or handle sudden traffic spikes. Scale horizontally as your business grows without redesigning your decision infrastructure. ### Write Once, Deploy Everywhere Create a single source of truth for business logic and use it across all applications, services, and channels. Stop duplicating rules in multiple codebases. When logic changes, it changes everywhere - consistently and simultaneously. ## When do you need a business rules engine? These signals indicate your organization would benefit from externalizing business logic to a dedicated rules engine. ### Scale & performance - You're making the same decision thousands or millions of times - Multiple systems need access to the same business logic - Spreadsheets used for decision logic are becoming unmanageable ### Compliance & audit - Auditors or regulators require detailed decision trails - Rules change frequently due to regulations or policies - Inconsistent decisions across channels are causing problems ### Team collaboration - Business users need to modify rules without IT involvement - IT has become a bottleneck for every business rule change ### Speed to market - Policy changes take weeks or months to implement - Competitors are responding to market changes faster than you If you recognize three or more of these signals, a business rules engine will likely provide significant value. The ROI typically comes from reduced time-to-market for policy changes, decreased IT burden, improved compliance posture, and elimination of decision inconsistencies that frustrate customers. ### How to choose a business rules engine When evaluating business rules engines for your organization, consider these key factors: - **Deployment model:** cloud-hosted for fastest deployment and managed infrastructure, self-hosted for maximum data control and security, or hybrid for flexibility. - **User experience:** low-code/no-code interfaces for business users, developer-focused APIs for engineering teams, or platforms that serve both constituencies effectively. - **Performance requirements:** real-time sub-millisecond decisions for transaction processing, batch processing for millions of records, or big data integration for analytics. - **Integration capabilities:** REST APIs and webhooks, native SDKs for your programming languages, database connectors, and event streaming support for your architecture. [Read the full buyer's guide](/resources/how-to-choose-business-rules-engine) ## The evolution of business rules engines From AI research labs to powering billions of daily decisions, business rules technology has evolved over five decades - and the history explains why modern platforms look the way they do. _1970s-80s_ ### Expert Systems Era Rule-based systems emerged from artificial intelligence research. Systems like MYCIN for medical diagnosis and XCON for computer configuration demonstrated that encoding domain expertise as rules could automate complex decisions previously requiring human experts. _1990s_ ### Commercial BRMS Emerge Companies like ILOG (later acquired by IBM), Fair Isaac (FICO), and Pegasystems commercialized business rules technology for enterprise applications. These systems brought rule-based decisioning to financial services, insurance, and telecommunications at scale. _2000s_ ### Open Source Movement Drools brought rules engines to Java developers with an open-source approach. The OMG's Decision Model and Notation (DMN) standardization began, creating common language for decision modeling. Rules engines became accessible beyond large enterprises. _2010s_ ### Cloud-Native Era API-first, cloud-native rules engines emerged to meet the needs of modern microservices architectures. Focus shifted to real-time decisioning, developer experience, and seamless integration. The rise of fintech created new demand for high-performance decision systems. _2020s_ ### AI + Rules Hybrid Modern approaches combine deterministic rules with machine learning models. Rules provide explainability and regulatory compliance, while ML handles pattern recognition. Low-latency engines power real-time fraud detection, dynamic pricing, and personalization at unprecedented scale. _The Future_ ### Democratized Decision Intelligence For decades, rules engines meant Java or C#. The future is platform-agnostic - running natively on cloud, mobile, edge servers, even offline. Open source is driving innovation, breaking vendor lock-in, and making enterprise-grade decisioning accessible to teams of any size. Real-time, event-driven architectures are becoming standard, and visual interfaces let business users manage decision logic directly - accelerating response to market changes and regulatory requirements. ## Frequently asked questions What does a business rules engine do? A business rules engine automates decision-making by evaluating data against predefined rules. It takes input data, processes it through IF-THEN conditions, and returns decisions or outputs without requiring code deployments. This allows organizations to change business logic quickly without involving developers or deploying new application versions. What is an example of a business rules engine? Examples include GoRules for real-time decisioning, Drools for Java applications, IBM ODM for enterprise deployments, and FICO Blaze Advisor for credit decisioning. A practical example: a lending company uses a BRE to approve or deny loan applications by evaluating credit score, income, debt-to-income ratio, and employment history against lending criteria - all in milliseconds. BRE vs Decision Engine: What's the difference? The terms are often used interchangeably. Decision engines typically emphasize real-time, high-throughput decisioning for use cases like fraud detection and pricing, while traditional BREs may include broader workflow capabilities. Modern platforms like GoRules combine both approaches - real-time performance with full rule lifecycle management. What is the difference between BRMS and BRE? A Business Rules Engine (BRE) is the execution component that runs rules. A Business Rules Management System (BRMS) is the complete platform including the BRE plus version control, visual authoring, testing tools, deployment management, access control, and audit logging. Most organizations need a BRMS, not just a BRE. When should I use a BRE instead of hardcoding? Use a BRE when rules change frequently, you need audit trails for compliance, multiple systems share the same logic, business users should manage rules without IT, or you want to test rules before deployment. Hardcoding is appropriate for stable logic that rarely changes and doesn't require auditability. Can a business rules engine work with machine learning? Yes, and this hybrid approach is increasingly common. Modern BREs orchestrate both deterministic rules and ML model predictions. Rules provide explainability, guardrails, and regulatory compliance, while ML handles pattern recognition. For example, an ML model generates a fraud score while rules determine actions based on that score plus business criteria. ## Ready to implement a business rules engine? Start building with GoRules in minutes. Visual editor, high-performance execution, enterprise governance. [Start for free](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Git-like Version Control for Business Rules **URL:** https://gorules.io/version-control **Description:** Branches, commits, merging, and history for your business rules. Track every change and roll back instantly when needed. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Version control for business rules. Branches, commits, diffs, and instant rollback - a git-grade history for the people who own the rules, no git required. Never lose work, always know who changed what. [Start for free](https://us1.gorules.io) [Explore the BRMS](/brms) ## Branches and diffs, readable by anyone. Analysts see drafts, history, and visual diffs. Underneath it's real branches and commits - every change isolated until it's merged, every merge attributable. **History**_main · pricing-refresh_ **Merge pricing-refresh into main**_Jane Cooper · just now_ merge **Raise tier A ceiling to $60,000**_Marcus Webb · 2 hours ago_ +1 −1 **Add tier B between 700 and 740**_Marcus Webb · yesterday_ +1 −0 **Release v2.3.9**_Amelia Ford · 2 days ago_ v2.3.9 **Import affordability policy**_GoRules AI · last week_ +12 −0 **Compare**`pricing-refresh → main`+2 −1 credit.scoredecision _greater than_ 740approve _between_ 640 _and_ 740manual review _between_ 700 _and_ 740tier B _less than_ 640decline Every cell traces back to a commit and an author. ## The full git workflow, without the git. Everything engineering expects from version control, built into the rule editor for people who never open a terminal. ### Branching Isolate feature work and experiments until they are ready to merge into main. ### Commits Every change lands as a commit with a message, author, and timestamp. ### Merging Merge through change requests with reviews, so nothing reaches main unchecked. ### Diff viewer See exactly what changed between any two versions - additions, deletions, edits. ### History and rollback Browse the full history and roll back to any previous version instantly. ### Release management Tag versions as releases and track which one runs in each environment. ## From branch to release. A familiar path for every change, whether it comes from an analyst, an engineer, or GoRules AI - releases always stay with your reviewers. _01_**Create a branch** Start from main and work in isolation. _02_**Make changes** Edit tables and graphs with the full editor. _03_**Review and approve** Reviewers see the diff and sign off. _04_**Merge and release** Merge to main and promote through environments. ## Benefits that compound as rules grow. Version control is what turns a rule editor into a system of record. **Risk reduction** Changes are tested in isolation before they can touch production. **Team collaboration** Several people work on the same rules without stepping on each other. **Audit compliance** The complete history satisfies regulators - who, what, when, and why. ## Every change, on the record. Start free on GoRules Cloud and bring real version control to the rules your business runs on. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Use Cases - What Teams Automate with GoRules **URL:** https://gorules.io/use-cases **Description:** Promotions, pricing, quoting, credit decisions, scoring - see how teams automate decisions with GoRules, with the live policy behind every use case. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # What will you automate? Pricing, promotions, approvals, scoring, risk - teams run them all on GoRules. Pick a use case and see the policy behind it, live. ## Use cases Every use case is a working policy, not a slide - the same tables, graphs, and versioning your team would run in production. [_Pricing & Promotions_ ### Promotion Engine Discounts, offers, and campaigns as decision tables - launched without a deploy. _Retail & E-commerce__Telco_](/use-cases/promotion-engine)[_Pricing & Promotions_ ### Dynamic Pricing Adjust prices on demand, time of day, competitor position, and segment. _Retail & E-commerce__Aviation_](/use-cases/dynamic-pricing)[_Pricing & Promotions_ ### Loyalty Engine Earn rates, burn rules, tiers, and campaign multipliers your CRM team edits. _Retail & E-commerce__Aviation_](/use-cases/loyalty-engine)[_Pricing & Promotions_ ### Airline Offer Management Ancillary pricing, bundles, and upgrade-bid rules your revenue team tunes per route. _Aviation_](/use-cases/airline-offer-management)[_Eligibility & Approvals_ ### Insurance Quoting Rate tables, eligibility, and bind rules that go live on their effective date. _Insurance_](/use-cases/insurance-quoting)[_Eligibility & Approvals_ ### Underwriting Automation Appetite, knockouts, and authority limits your underwriters own. _Insurance_](/use-cases/underwriting-automation)[_Eligibility & Approvals_ ### Loan Origination Overlays, stipulations, and pricing inside the LOS you already run. _Financial_](/use-cases/loan-origination)[_Eligibility & Approvals_ ### Loan Decisioning Approve, decline, or refer in milliseconds, with the rules that fired attached. _Financial_](/use-cases/loan-decisioning)[_Risk & Scoring_ ### Credit Decisioning Cutoffs, overrides, and risk-based pricing above your ML models. _Financial_](/use-cases/credit-decisioning)[_Risk & Scoring_ ### Credit Risk Software Exposure limits, cutoffs, and review triggers for a lending book. _Financial_](/use-cases/credit-risk-software)[_Fraud & Compliance_ ### Fraud Detection Velocity rules and step-up thresholds your fraud analysts tune the same day. _Financial__Retail & E-commerce_](/use-cases/fraud-detection)[_Fraud & Compliance_ ### Transaction Monitoring AML scenarios authored, versioned, and approved by compliance. _Financial_](/use-cases/transaction-monitoring)[_AI & Governance_ ### AI Governance The enforcement layer under your governance stack - every model and agent action gated by versioned rules. _Financial__Cross-industry_](/use-cases/ai-governance)[_AI & Governance_ ### Deterministic AI The model talks, your rules decide - agent decisions as tables with a trace on every call. _Cross-industry_](/use-cases/deterministic-ai)[_Payouts & Incentives_ ### Commission Calculation Tiers, accelerators, splits, and clawbacks you can replay and audit. _Cross-industry_](/use-cases/commission-calculation) ## Browse by industry. The same decision engine, tuned to the rules your industry actually runs on - with templates to start from. [**Financial**Banks & fintechs](/industries/financial)[**Insurance**Insurers & insurtechs](/industries/insurance)[**Healthcare**Payers & providers](/industries/healthcare)[**Aviation**Airlines & travel](/industries/aviation)[**Telco**Telecom operators](/industries/telco) ## Your process is probably a policy. If a spreadsheet or a wall of if-statements decides it today, GoRules can run it. Start free, or bring the logic and we'll model it together. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Rules Engine Templates - GoRules **URL:** https://gorules.io/templates **Description:** Discover a collection of customizable templates designed to simplify and accelerate your decision automation projects. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Start from a working decision. Customizable templates for common decisions across industries - pick one, open it in the editor, and make it yours. AllFinancialAviationInsuranceHealthcareLogisticsRetailTelcoPublic Sector 80 templates found [weatherEligibilityaircraftEligibility_+4_Aviation ### Flight Dispatch Decision System Rules-based aviation system that evaluates weather, aircraft, crew, and weight factors to ensure regulatory compliance and safe flight operations. Open template](/industries/aviation/templates/flight-dispatch-decision-system) [creditScoreEvaluationincomeVerification_+6_Financial ### Loan Approval Automated system that evaluates credit scores, income, debt ratios, and employment history to determine mortgage eligibility and personalized interest rates. Open template](/industries/financial/templates/loan-approval) [vital\_signs\_assessmentsymptom\_assessment_+2_Healthcare ### Patient Triage System Rules-based medical triage system that prioritizes patients in emergency departments based on vital signs, symptoms, and chief complaints. Open template](/industries/healthcare/templates/patient-triage-system) [Age EligibilityLocation Eligibility_+2_Insurance ### Policy Eligibility Analyzer Automated rule-based system that evaluates customer eligibility for insurance policies based on age, location, and specific risk factors. Open template](/industries/insurance/templates/policy-eligibility-analyzer) [validatePackagedetermineServiceLevel_+3_Logistics ### Shipping Carrier Selector Rule-based system that selects optimal carriers by analyzing package details, service level needs, and cost factors to streamline shipping decisions. Open template](/industries/logistics/templates/shipping-carrier-selector) [Income EligibilitySpecial CircumstancesPublic Sector ### Government Assistance Streamlined decision system that determines program eligibility based on income thresholds, household size, age factors, and special circumstances. Open template](/industries/public-sector/templates/government-assistance) [evaluateBusinessCredentialsevaluateSellerQualifications_+3_Retail ### Seller Approval Workflow Rules-based marketplace solution that evaluates business credentials, expertise, inventory quality, and background checks to maintain seller standards. Open template](/industries/retail/templates/seller-approval-workflow) [userProfileRulestimeLocationRules_+1_Telco ### Dynamic Tariff Engine Rule-based pricing system for telecommunication services that automatically applies discounts based on user profiles, time periods, and location types. Open template](/industries/telco/templates/dynamic-tarrif-engine) [time\_urgencycalculate\_factors_+2_Aviation ### Dynamic Airline Ticket Pricing Engine Automated fare optimization system that sets ticket prices based on time to departure, seat availability, market demand, and competitor pricing. Open template](/industries/aviation/templates/dynamic-ticket-pricing) [detectSuspiciousActivitycalculateRiskScoreFinancial ### Real-Time Fraud Detection Advanced transaction monitoring system that identifies suspicious financial activities using location analysis, spending patterns, and behavioral anomalies. Open template](/industries/financial/templates/realtime-fraud-detection) [diagnosisEvaluationcomorbidityEvaluation_+5_Healthcare ### Clinical Pathway Selection Decision system that determines optimal treatment pathways based on diagnosis severity, comorbidities, and patient characteristics for personalized care plans. Open template](/industries/healthcare/templates/clinical-pathway-selection) [driverRiskAssessmentcalculateBasePremium_+2_Insurance ### Auto Insurance Premium Calculator Dynamic pricing system that determines accurate premiums based on driver profile, vehicle specifications, and coverage options for personalized insurance rates. Open template](/industries/insurance/templates/auto-insurance-premium-calculator) [evaluate\_base\_scorecalculate\_additional\_scores_+1_Logistics ### Delivery Route Optimizer Smart logistics system that evaluates capacity, traffic, time windows, and distance to determine the most efficient delivery routes for maximum efficiency. Open template](/industries/logistics/templates/delivery-route-optimizer) [taxExemptionEvaluationrequiresAdditionalClassification_+2_Public Sector ### Tax Exemption Automated system that assesses organizations for 501(c)(3) tax-exempt status based on structure, activities, and financial metrics. Open template](/industries/public-sector/templates/tax-exemption) [productCategoryRatessellerPerformanceAdjustment_+1_Retail ### Dynamic Marketplace Commission Calculator Automated system for calculating seller commission rates based on product category, sales data, seller performance, and promotional periods. Open template](/industries/retail/templates/dynamic-marketplace-comission-calculator) [regionalComplianceRulescomplianceEvaluation_+1_Telco ### Regional Compliance Manager Automated system that applies region-specific data privacy rules for telecommunications services across EU, US, UK, Canada, and Australia. Open template](/industries/telco/templates/regional-compliance-manager) [Device Type PersonalizationLoyalty Status Personalization_+4_Aviation ### Booking Personalization System Dynamic flight booking platform that tailors UI, discounts, and features based on customer loyalty status, device type, booking history, and traffic source. Open template](/industries/aviation/templates/booking-personalization-system) [customerRiskScoringdocumentVerification_+4_Financial ### Customer Onboarding KYC Verification Automated compliance checks that validate identity documents, screen against watchlists, and apply risk-based due diligence during onboarding. Open template](/industries/financial/templates/customer-onboarding-kyc-verification) [calculateParameterscalculateDosageHealthcare ### Medication Dosage Calculator Clinical decision system that calculates precise medication dosages based on patient weight, age, and organ function to maximize safety and efficacy. Open template](/industries/healthcare/templates/medication-dosage-calculator) [validateClaimDetailscheckPolicyStatus_+2_Insurance ### Insurance Claim Validation System Automated verification that validates insurance claims against policy status, timeframe requirements, and claim details before investigation. Open template](/industries/insurance/templates/claim-validation-system) [classifyProductassignLocation_+1_Logistics ### Warehouse Storage Location Maximizes warehouse efficiency by strategically placing products based on turnover rates, picking frequency, and product characteristics. Open template](/industries/logistics/templates/warehouse-storage-location) [applicationClassificationinitialApprovalCheck_+1_Public Sector ### Municipal Permit Evaluation System Automated system that evaluates building and event permits based on zoning regulations, safety requirements, and environmental impact factors. Open template](/industries/public-sector/templates/municipal-permit-evaluation-system) [imageQualitydescriptionAndOtherFactors_+1_Retail ### Product Listing Scoring Automated scoring system that evaluates and ranks product listings based on image quality, description completeness, and other key marketplace success factors. Open template](/industries/retail/templates/product-listing-scoring) [evaluateAccountStatusdetermineLoyaltyTier_+3_Telco ### Customer Eligibility Engine Intelligent system that analyzes customer data to determine service upgrades, loyalty rewards, and premium features based on usage patterns and account history. Open template](/industries/telco/templates/customer-eligibility-engine) [categorize\_flight\_durationcalculate\_customer\_attributes_+3_Aviation ### Flight Ancillary Recommendations Data-driven system that personalizes travel add-on recommendations based on customer profile, route details, and previous purchasing behavior. Open template](/industries/aviation/templates/flight-ancillary-recommendations) [marketConditionsAssessmentportfolioExposureAssessment_+7_Financial ### Portfolio Risk Monitor Dynamic portfolio management system that continuously evaluates investment holdings against market conditions to implement appropriate risk mitigation actions. Open template](/industries/financial/templates/portfolio-risk-monitor) [Insurance Type CheckMedicaid Rules_+4_Healthcare ### Insurance Prior Authorization Automated system that evaluates insurance requirements for medical services based on carrier rules, diagnosis codes, and service details. Open template](/industries/healthcare/templates/insurance-prior-authorization) [customerLoyaltyDiscountsbundledPoliciesDiscounts_+2_Insurance ### Policy Discount Calculator Automated system that calculates personalized insurance discounts based on customer loyalty, policy bundling, and vehicle safety features. Open template](/industries/insurance/templates/policy-discount-calculator) [evaluateConsolidationFactorscalculateConsolidationMetrics_+5_Logistics ### Order Consolidation System Smart logistics system that optimizes shipping by combining orders based on location proximity, delivery timeframes, and available carrier capacity. Open template](/industries/logistics/templates/order-consolidation-system) [verifyDocumentationevaluateBackground_+5_Public Sector ### Immigration Eligibility Evaluator Rules-based system automating visa application processing by evaluating documentation completeness, background checks and qualification scoring. Open template](/industries/public-sector/templates/immigration-eligibility-evaluator) [evaluate\_deliveryevaluate\_satisfaction_+4_Retail ### Marketplace Seller Grading System Objective performance evaluation system that scores sellers on delivery, satisfaction, inventory, and compliance metrics to determine marketplace status. Open template](/industries/retail/templates/marketplace-seller-grading-system) [validateServiceParametersdetermineParameterType_+4_Telco ### Service Level Agreement Enforcement Automated system that monitors telecommunication service levels, detects SLA violations, and triggers appropriate compensation and escalation responses. Open template](/industries/telco/templates/service-level-agreement-enforcement) [payment\_riskpattern\_risk_+4_Aviation ### Booking Fraud Detection Advanced risk assessment that evaluates payment methods, booking patterns, and account behavior to prevent travel reservation fraud. Open template](/industries/aviation/templates/booking-fraud-detection) [payment-type-processingchannel-routing_+3_Financial ### Payment Routing & Fee Calculator Intelligent payment processing that determines optimal routing paths, calculates precise fees, and applies security measures per transaction. Open template](/industries/financial/templates/payment-routing-and-fee-calculator) [diagnosisEvaluationpatientFactors_+4_Healthcare ### Clinical Treatment Protocol Decision system that selects personalized medical treatments based on diagnosis, patient characteristics, and risk factors for optimal healthcare outcomes. Open template](/industries/healthcare/templates/clinical-treatment-protocol) [scoreCreditHistoryscoreIncomeStability_+6_Insurance ### Applicant Risk Assessment Scoring system that evaluates credit history, income stability, and debt ratios to categorize insurance applicants into risk tiers. Open template](/industries/insurance/templates/application-risk-assessment) [base\_rate\_calculationdetermine\_season_+2_Logistics ### Dynamic Shipping Cost Calculator Advanced shipping rate system that automatically calculates costs based on shipment attributes, seasonal variables, and customer loyalty tiers. Open template](/industries/logistics/templates/dynamic-shipping-cost-calculator) [industryRiskAssessmentemissionsEvaluation_+1_Public Sector ### Environmental Compliance Assessment Rules-based system that evaluates organizational compliance with environmental regulations based on industry type, emissions data, and geographical location. Open template](/industries/public-sector/templates/environment-compliance-assessment) [calculateRiskFactorsevaluateRiskLevel_+1_Retail ### Marketplace Listing Verification System Automated risk assessment system that flags suspicious marketplace listings based on brand authenticity, pricing anomalies, and seller credibility factors. Open template](/industries/retail/templates/marketplace-listing-verification-system) [normalize\_datadetermine\_compatibility_+1_Telco ### Device Compatibility Checker Intelligent system that evaluates device models and firmware versions to determine service availability and feature compatibility. Open template](/industries/telco/templates/device-compatibility-checker) [calculateCabinFilldetermineSeatAvailability_+1_Aviation ### Airline Seat Map Display Rules Dynamic seat map system that personalizes seat availability based on loyalty tier, fare class, group size and cabin occupancy levels. Open template](/industries/aviation/templates/seat-map-optimization) [classify\_transactionapply\_jurisdiction\_rules_+4_Financial ### Financial Transaction Compliance Classifier Automated system that classifies financial transactions, assigns risk scores, identifies compliance issues, and determines regulatory reporting requirements. Open template](/industries/financial/templates/transaction-compliance-classifier) [ageBasedRecommendationssexBasedRecommendations_+2_Healthcare ### Preventive Care Recommendation Data-driven system that generates personalized preventive healthcare recommendations based on patient demographics and risk factors. Open template](/industries/healthcare/templates/preventive-care-recommendation) [determineBasePackagecalculateCoverageLevels_+1_Insurance ### Insurance Coverage Calculator Personalized insurance coverage recommendations based on property value, location risk factors, and claim history to optimize protection and cost. Open template](/industries/insurance/templates/insurance-coverage-calculator) [calculate\_match\_scorecalculate\_final\_score_+3_Logistics ### Last-Mile Delivery Assignment Automated system that matches packages with delivery personnel by priority, weight, skills, location, and time to optimize efficiency. Open template](/industries/logistics/templates/last-mile-delivery-assignment) [baseAllocationperformanceAdjustment_+1_Public Sector ### School District Resource Allocation Data-driven funding distribution tool that allocates educational resources based on student population, performance metrics, and specialized program needs. Open template](/industries/public-sector/templates/school-district-resource-allocation) [returnEligibilityresponsibilityDetermination_+1_Retail ### Returns and Refund Policy Automated system that determines return eligibility, responsibility, and refund calculations based on purchase conditions and seller policies. Open template](/industries/retail/templates/returns-and-refund-policy) [partnerCommissionRatescalculateCommissionTelco ### Partner Revenue Sharing Automated calculation system that determines commission rates, bonuses, and payouts for content, service, and technology partnership agreements. Open template](/industries/telco/templates/partner-revenue-sharing) [preprocessDatacheckEligibility_+3_Aviation ### Online Check-in Eligibility System Automated passenger validation system that determines online check-in eligibility based on travel documents, flight timing, and special assistance requirements. Open template](/industries/aviation/templates/online-checkin-eligibility) [evaluateCreditScoreevaluateIncome_+1_Financial ### Smart Financial Product Matcher Personalized banking product recommendations based on credit score and income, matching customers with the right financial products for their unique situation. Open template](/industries/financial/templates/smart-financial-product-matcher) [basicLabEvaluationpatientContextEvaluation_+2_Healthcare ### Clinical Lab Results Interpreter Automated system that evaluates laboratory test results against patient context to determine abnormalities and urgent follow-up actions. Open template](/industries/healthcare/templates/clinical-lab-result-interpreter) [baseCommissionRatescalculateBaseCommission_+1_Insurance ### Insurance Agent Commission Dynamic commission calculation system that determines agent payouts based on policy type, premium value, and agent performance metrics. Open template](/industries/insurance/templates/insurance-agent-commission) [calculateMetricscrossDockingDecision_+2_Logistics ### Warehouse Cross-Docking Automated system that determines optimal handling of incoming shipments based on outbound orders, time constraints, and current warehouse capacity. Open template](/industries/logistics/templates/warehouse-cross-docking) [classify\_violationcalculate\_penalty_+2_Public Sector ### Traffic Violation Penalty Calculator Automated system that determines appropriate fines, points, and penalties for traffic violations based on severity, driver history, and circumstances. Open template](/industries/public-sector/templates/traffic-violation-penalty-calculator) [determineCategoryFeescalculateAdditionalFees_+1_Retail ### Seller Fee Calculator Adaptive fee structure that automatically calculates transaction rates, subscription costs, and service charges based on seller metrics and program eligibility. Open template](/industries/retail/templates/seller-fee-calculator) [roamingPolicyLookupcalculateRoamingParametersTelco ### International Roaming Policy Manager Automated telecom solution that applies custom roaming rates and service levels based on customer destination, plan type and usage patterns. Open template](/industries/telco/templates/international-roaming-policy-manager) [baseFeeCalculationfrequencyMultiplier_+3_Aviation ### Flight Rebooking Fee Calculator Dynamic fee system for airline booking modifications that adjusts charges based on fare class, time to departure, loyalty status, and change history. Open template](/industries/aviation/templates/flight-rebooking-fee-calculator) [payment\_history\_evaluationutilization\_evaluation_+4_Financial ### Credit Limit Adjustment Data-driven solution that evaluates payment history, utilization, and financial behavior to automatically recommend credit limit changes. Open template](/industries/financial/templates/credit-limit-adjustment) [calculateRiskFactorScoreevaluateConditionSeverity_+4_Healthcare ### Medical Appointment Priority System Scheduling system that prioritizes patients by clinical severity, risk factors, and wait times to optimize care and resource allocation. Open template](/industries/healthcare/templates/medical-appointment-priority-system) [risk\_factorscalculate\_risk\_score_+1_Insurance ### Insurance Underwriting Risk Automated system that evaluates insurance applications against risk factors to determine whether manual underwriting review is necessary. Open template](/industries/insurance/templates/insurance-underwriting-risk) [Material ClassificationHandling Requirements_+1_Logistics ### Hazardous Materials Management System Automated rules engine that classifies hazardous materials and provides handling, storage, and transportation guidelines based on regulatory requirements. Open template](/industries/logistics/templates/hazardous-materials-management-system) [baseFundAllocationincomeAdjustment_+2_Public Sector ### Disaster Relief Fund Allocation Automated system that calculates disaster relief payments based on damage severity, household factors, income level, and insurance coverage status. Open template](/industries/public-sector/templates/disaster-relief-fund-allocation) [categoryRatesperformanceRates_+1_Retail ### Affiliate Commission Calculator Dynamic system that calculates precise affiliate payouts based on product category, performance metrics, and promotional factors. Open template](/industries/retail/templates/affiliate-commission-calculator) [calculateUnusedDatadetermineRolloverAmount_+3_Telco ### Cellular Data Rollover System Intelligent system that automatically calculates and applies unused data transfers to next billing cycles based on customer plan tiers and usage patterns. Open template](/industries/telco/templates/cellular-data-rollover-system) [checkBasicEligibilitycalculateLoyaltyScore_+4_Aviation ### Airline Upgrade Eligibility Advanced passenger upgrade decision engine that evaluates loyalty status, fare class, corporate agreements, and cabin availability to prioritize upgrades. Open template](/industries/aviation/templates/airline-upgrade-eligibility) [requestdetermine\_escalation\_levelFinancial ### Customer Service Escalation Intelligent routing system that prioritizes customer inquiries based on customer value, issue complexity, and financial impact for optimal support allocation. Open template](/industries/financial/templates/customer-service-escalation) [determine\_complexityevaluate\_patient\_needs_+3_Healthcare ### Care Team Assignment System Automated system for assigning optimal healthcare providers to patients based on medical conditions, age, care complexity, and personal needs. Open template](/industries/healthcare/templates/care-team-assignment-system) [assessDamagecheckPartsAvailability_+1_Insurance ### Vehicle Claims Resolution Automated decision system for determining optimal insurance claim resolution based on damage severity, vehicle age, and parts availability. Open template](/industries/insurance/templates/vehicle-claims-resolution) [customerEligibilitydetermineReturnType_+3_Logistics ### Returns Processing System Streamlines product return processing by applying business rules based on customer status, product details, and return circumstances for optimal efficiency. Open template](/industries/logistics/templates/returns-processing-system) [product\_classificationcountry\_rules_+1_Public Sector ### Import Duties Calculator Automated system that calculates precise import duties and taxes based on product details, country relationships, and trade agreements. Open template](/industries/public-sector/templates/import-duties-calculator) [checkInventoryAndMargincheckSeasonality_+2_Retail ### Flash Sale Eligibility Smart retail solution that automatically selects products for flash sales based on inventory, profitability, seasonality, and seller performance. Open template](/industries/retail/templates/flash-sale-eligibility) [partnerServiceAccessnetworkResourceAllocation_+1_Telco ### MVNO Partner Enablement Automated rules engine that determines service access, network resources, and pricing tiers for mobile virtual network operators based on partnership metrics. Open template](/industries/telco/templates/mvno-partner-enablement) [fareClassMultiplierrouteBasePoints_+2_Aviation ### Airline Loyalty Points Calculator Advanced system for calculating airline loyalty program points based on fare class, route type, distance, member status, and seasonal promotions. Open template](/industries/aviation/templates/airline-loyalty-points-calculations) [calculate\_dormancydormancy\_status_+2_Financial ### Account Dormancy Management Proactive banking solution that identifies inactive accounts, determines appropriate interventions, and ensures compliance with regulatory requirements. Open template](/industries/financial/templates/account-dormancy-management) [diagnosisEligibilitydiseaseStageEligibility_+5_Healthcare ### Clinical Trial Eligibility Screener Automated patient screening system that evaluates medical criteria to determine clinical trial eligibility based on multiple health factors. Open template](/industries/healthcare/templates/clinical-trial-eligibility-screener) [clv\_calculationcustomer\_segmentationInsurance ### Customer Lifetime Value Insurance calculation system that determines customer value metrics to optimize retention strategies and set appropriate service tiers for policyholders. Open template](/industries/insurance/templates/customer-lifetime-value) [supplierRiskEvaluationgeopoliticalRiskCalculation_+1_Logistics ### Supply Chain Risk Evaluator Assessment system that analyzes supplier data, geopolitical factors, and market conditions to prioritize supply chain vulnerabilities. Open template](/industries/logistics/templates/supply-chain-risk) [project\_evaluationbudget\_constraint_+1_Public Sector ### Grant Funding Distribution Automated system that calculates grant awards based on project merit, applicant quality, budget availability, and potential community impact. Open template](/industries/public-sector/templates/grant-funding-distribution) [determineProductCategorydetermineFXRateAdjustmentRetail ### Dynamic FX Rate Pricing System Tiered foreign exchange rate system that offers preferential rates for premium products, enhancing margins on luxury items while maintaining competitiveness. Open template](/industries/retail/templates/dynamic-fx-rate-pricing-system) [identifyPlanTypedetermineBenefits_+3_Telco ### Legacy Plan Management Rules-based telecom system that preserves benefits for long-term customers while streamlining catalog offerings and guiding migration paths. Open template](/industries/telco/templates/legacy-plan-management) ## Don't see your decision here? Start from a blank canvas, or tell us what you're automating and we'll point you at the closest starting point. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Switch to GoRules - Migration Guides **URL:** https://gorules.io/switch **Description:** Step-by-step guides for migrating to GoRules from Drools, IBM ODM, Camunda, FICO Blaze Advisor, InRule, and other rules engines. Export your rules, convert them with the AI copilot, and run them on Zen Engine. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Switch to GoRules. Practical migration guides for teams bringing existing rules to GoRules. Each guide maps your current constructs to GoRules node types, walks the export and conversion path, and shows where the AI copilot does the heavy lifting. - Run both engines in parallel - AI-assisted rule conversion - No build step after cutover ## Pick your starting point Every guide covers exporting your current rules, construct-by-construct mapping, AI-assisted conversion, and validation before cutover. [_Guide_ ### Switch from Drools A step-by-step guide to moving your DRL rules, DMN models, and spreadsheet decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/drools)[_Guide_ ### Switch from IBM ODM A step-by-step guide to moving your BAL rules, decision tables, and ruleflows to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/ibm-odm)[_Guide_ ### Switch from FICO Blaze Advisor A step-by-step guide to moving your SRL rulesets, decision tables, ruleflows, and score models to GoRules: map the BOM to JSON, convert with the AI copilot, validate in parallel, and cut over. ](/switch/fico-blaze-advisor)[_Guide_ ### Switch from InRule A step-by-step guide to moving your .ruleapp rule applications, Business Language rules, and decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/inrule)[_Guide_ ### Switch from DecisionRules A step-by-step guide to moving your Decision Tables, Decision Trees, Scripting Rules, and Decision Flows to GoRules: map each rule type, rebuild with the AI copilot, validate in parallel, and cut over. ](/switch/decisionrules)[_Guide_ ### Switch from Higson A step-by-step guide to moving your Higson decision tables, Groovy functions, and flows to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/higson)[_Guide_ ### Switch from Decisions.com A step-by-step guide to moving your Statement Rules, Truth Tables, Rule Tables, Matrix Rules, and Rule Sets to GoRules: document each rule, rebuild with the AI copilot, validate in parallel, and cut over. ](/switch/decisions)[_Guide_ ### Switch from Camunda A step-by-step guide to moving your DMN models to GoRules: export the .dmn files, convert FEEL and JUEL expressions with the AI copilot, validate in parallel, and cut over. ](/switch/camunda)[_Guide_ ### Switch from Oracle OPA/Intelligent Advisor A step-by-step guide to moving your decision service projects, Word and Excel rule documents, and rule tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/oracle-opa)[_Guide_ ### Switch from json-rules-engine A step-by-step guide to moving your json-rules-engine rules, fact handlers, custom operators, and listeners to GoRules: export with rule.toJSON(), convert with the AI copilot, validate in parallel, and cut over. ](/switch/json-rules-engine) ## Bring your rules. Leave the friction. Export from your current engine, convert with the AI copilot, and run in parallel until the outputs match. Most teams cut over one decision at a time. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Security - Enterprise-Grade Protection **URL:** https://gorules.io/security **Description:** Self-hosted deployment, SSO integration, role-based access control, audit logging, and encryption. Built for enterprise security requirements. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Your infrastructure. Your security. GoRules is built for organizations with strict security and compliance requirements. Self-hosted deployment means your data never leaves your infrastructure. [Visit trust portal](https://trust.gorules.io/) [Request security review](/contact-us) SOC 2 Type IISelf-hostedSSO / OIDCRBACAudit logs ## Your data never leaves your environment. Deploy GoRules on your own servers, VPC, or Kubernetes cluster. You keep full control over where and how your rules are stored and executed - under your existing security controls and compliance frameworks. - Self-hosted on your own infrastructure - AES-256 encryption at rest - TLS 1.3 between all components - Docker and Kubernetes deployments [View deployment options](https://docs.gorules.io/learn/getting-started/first-rule) ## Who can change what, down to the action. Access control that matches how rule changes actually happen - the right people author, the right people approve, and identity stays with your provider. ### Role-based access control. Fine-grained permissions control who can view, edit, approve, and publish rules. Create custom roles that match your organization structure. RoleViewEditApprovePublish Business analysts\-\- Risk team\-\- Engineers Auditors\-\-\- Custom roles match your organization structure. ### Single sign-on via OIDC. Integrate with your existing identity provider. Support for Okta, Azure AD, and other OIDC-compliant providers - no separate passwords to manage. **Sign in to GoRules** _OK_ Continue with Okta _AD_ Continue with Azure AD _ID_ Your OIDC provider jane.cooper signed in via Okta ### Every action, on the record. A complete audit trail of every action - who changed what, when, and why. Approval workflows require reviews before rules go live, with multi-stage flows validating changes with the right people before deployment. - Multi-stage approval flows - Every sign-off recorded - Export logs to your SIEM **Audit log** _streaming_ `09:32:04`**jane.cooper**approved release v2.4.0 `09:31:48`**marcus.webb**requested review · Credit Policy `09:26:12`**gorules-ai**added 3 test scenarios to draft `09:14:55`**amelia.ford**granted approver role · Risk team `08:47:31`**jane.cooper**signed in via Okta · OIDC ## Security built in, not bolted on. Every layer of GoRules is designed so that a rule can never do more than decide - and so that nobody outside your organization ever sees your data. ### Sandboxed execution Rules execute in isolated environments with no access to filesystem or network. ### Encryption everywhere AES-256 encryption at rest, TLS 1.3 for communication between all components. ### No data collection We never see your business data. Everything stays in your infrastructure. ### Regular audits Third-party security assessments and penetration testing. ## Compliance you can verify. Verified security controls, documented on our trust portal - not promised in a sales deck. [ **SOC 2 Type II** GoRules has obtained a SOC 2 Type II report, demonstrating our commitment to the highest security standards. View our trust portal for detailed compliance information. View trust portal](https://trust.gorules.io/) **Self-hosted deployments:** when you deploy GoRules on your own infrastructure, you bring your own security controls - your compliance posture is determined by your cloud environment and internal policies. ## Questions about security? Our team is happy to walk through your specific requirements - architecture, deployment, and compliance. [Request security review](/contact-us) [Visit trust portal](https://trust.gorules.io/) --- ## Pricing - GoRules **URL:** https://gorules.io/pricing **Description:** Whether you're a larger enterprise or a developer looking to explore, we have the right offer for you. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Simple, transparent pricing Whether you're a startup or an enterprise, we have the right plan for you. All Cloud plans include managed hosting, automatic updates, and unlimited rule evaluations - no infrastructure required. AnnuallyMonthly CloudSelf-hosted Cloud ### Free Get started $0 / month [Get Started](https://us1.gorules.io) - $10 of GoRules AI credits / month - No deployment environments (BRMS only) - 2 users - 1 project - 10 decision models per project - Infinite evaluations (via Agent or SDK) - Change request - GitSync Cloud ### Pro For growing teams $167 / month $2,000 billed annually · Save 17% [Get Started](https://us1.gorules.io) - Everything in Free, plus: - $70 of GoRules AI credits / month - 1 deployment environment - 5 users - 2 projects - 20 decision models per project CloudMost Popular ### Business Production workloads $500 / month $6,000 billed annually · Save 17% [Get Started](https://us1.gorules.io) - Everything in Pro, plus: - $200 of GoRules AI credits / month - 2 deployment environments - 20 users - 5 projects - 50 decision models per project - Audit Logs - SOC 2 Type II report - Standard SLA - Enforced reviews to merge to main Cloud ### Enterprise Custom requirements Custom [Contact Us](/contact-us) - Everything in Business, plus: - Custom GoRules AI credits - Custom deployment environments - Custom users - Custom projects - Global Roles - Webhooks - Enterprise SLA - SSO (OIDC) - Dedicated support - Enforced approval before release deployment \* All prices are in USD and exclude VAT and sales tax, which are calculated at checkout based on your billing country. ## Compare plans Detailed breakdown of what's included in each plan. FreeProBusinessEnterprise Limits EnvironmentsNo deployment environments (BRMS only)12Custom Users2520Custom Projects per environment1220Custom Documents per project102550Custom Evaluations per secondUnlimited using Zen Engine or AgentUnlimited using Zen Engine or AgentUnlimited using Zen Engine or AgentUnlimited using Zen Engine or Agent Features Releases Version History User management Audit log\-\- Release Workflow\-\-\- Compare Releases\-\-\- Security SSO (OIDC)\-\-\- SOC 2 Type II report\-\- Support Service level agreement\-\-StandardEnterprise Support engineer\-\-\-Optional Business analyst\-\-\-Optional Looking for open-source? Check out our [GitHub repositories](/open-source). ## What GoRules AI costs Every plan includes a monthly allowance of AI credits. Credits are spent per token, on the model that actually ran, so light editing costs a fraction of a long authoring session. How it is calculated **1.5x** The GoRules platform fee, applied to the Amazon Bedrock cost of the model that ran. It is the only markup GoRules adds. **1.1x** The regional-inference premium AWS charges over the standard on-demand rate, keeping inference inside your data region. Set by AWS, not by GoRules. **1h** Prompt-cache TTL. Cache writes bill at twice the input rate, cache reads at a tenth of it, and the savings pass straight through to you. Model Input Output Cache write Cache read **GoRules AI Advanced**Runs the latest Claude Opus on AWS Bedrock. The AI assistant on paid plans - authoring rules, running tests, explaining decisions. $8.25 $41.25 $16.50 $0.825 **GoRules AI Fast**Runs the latest Claude Sonnet on AWS Bedrock. Natural-language cell edits on every plan, and the assistant on the Free plan. $4.95 $24.75 $9.90 $0.495 Rates are USD per million tokens - net prices, excluding VAT and sales tax, which are calculated at checkout based on your billing country. Your actual spend depends on how large your rules are and how long your conversations run - every organisation can see exact spend under AI usage in the app. ## Bespoke solutions Personalized development services that align with your specific needs. ### Integration Engage our integration experts to implement GoRules into your system. Our team is adept at an array of technologies and happy to help. ### Fast-tracking Need a feature that's not available yet? We'll work closely with you to develop and fast-track the feature that you have in mind. ### Custom solutions Looking for something entirely custom? Our team can help you implement custom solutions using our open-source blocks. ## Not sure which plan fits your team? Talk to us about plans, enterprise requirements, or migrating from another platform - or start free and upgrade whenever. [Book a demo](/contact-us) [Get started](https://us1.gorules.io) --- ## Platform Overview - From Policy to Production **URL:** https://gorules.io/overview **Description:** Author business rules visually, govern every change like code, and run them anywhere. The deterministic decision layer for your products and agents. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # One platform, from policy to production. GoRules turns business rules into decisions your systems can run: author them visually, govern every change like code, and execute them anywhere - the deterministic core your AI stack is missing. Open-source coreSOC 2 Type IIMCP compatibleBYOLLM ## Author. Govern. Run. Three stages, one platform. Rules move from a visual editor through reviews and releases to an engine that runs wherever your systems live. credit.scoredecision _greater than_ 740approve _less than_ 640decline ### Author Decision tables, graphs, and expressions in a visual editor - readable by the business, testable by engineering. [Explore the editor](/editor) **Release v2.4.0**_2 approvals_ _JC_**Jane Cooper** Approved _MW_**Marcus Webb** Pending ### Govern Version control, approvals, releases, and a full audit trail - the BRMS is the system of record for your logic. [Explore the BRMS](/brms) _await_ engine.evaluate('loan-approval', input) approve · tier A _0.4 ms_ ### Run The open-source ZEN engine executes releases in your services, or serves them over REST through the Agent. [Explore the Agent](/agent) [Open source](/open-source) ## Deterministic, by design. Rules, not weights. The same input produces the same decision every time, and every outcome traces back to the exact row that produced it - an answer your auditors, and your agents, can rely on. credit.score = 612less than 640 · row 3decline - Explainable decision traces - Versioned, immutable releases - Same answer across every channel - Microsecond evaluation ## From request to release, without a deploy. AI does the heavy lifting; people make the calls. Every change follows the same reviewed path to production - no engineering ticket, no release cycle. **Jane Cooper describes the change** “Raise the tier A ceiling to $60,000” - plain language, or a policy document. **GoRules AI drafts it** Edits the table, generates test scenarios, and explains the impact - all as a reviewable draft. It never deploys. **Marcus Webb reviews and approves** A readable diff, a recorded sign-off, and a versioned release. **The release is promoted** Staging to production unchanged - running everywhere the engine runs. [Meet GoRules AI](/ai) ## The decision layer, end to end. Start free on GoRules Cloud, or book a demo and we'll walk your team through author, govern, and run. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Open Source Rules Engine - GoRules **URL:** https://gorules.io/open-source **Description:** Open source business rules engine for Node.js, Python, Go, Rust, Java, and Kotlin. MIT licensed, high-performance rule evaluation with native bindings. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # The open-source rules engine. The ZEN engine is fully open source and MIT licensed. Embed high-performance rule evaluation directly in your applications, with native bindings for every major language. [View on GitHub](https://github.com/gorules/zen)[Documentation](https://docs.gorules.io/developers/overview/architecture) **1.5k+** stars **100+** forks **8** languages The core ### Written in Rust The core engine is pure Rust - zero-cost abstractions, compile-time optimizations, no garbage collector. Every language SDK shares this foundation through native bindings. `cargo add zen-engine` ## One core. Native everywhere. Every SDK is a thin native binding over the same Rust core - no HTTP overhead, no separate process, the same answers in every runtime. decision.json ZEN core · Rustyour application In-process evaluation - no network hop, no per-evaluation fees. _npm_`npm install @gorules/zen-engine` _pip_`pip install zen-engine` _go_`go get github.com/gorules/zen-go/v2` _cargo_`cargo add zen-engine` ## Choose your language. Native SDK bindings for every major programming language. Same engine, same performance, familiar APIs. [ ### Node.js Node.js, Deno, and Bun with full async support. Get started](/open-source/javascript-rules-engine)[ ### Python A Pythonic API with no GIL limits on evaluation. Get started](/open-source/python-rules-engine)[ ### Go Thread-safe engine you can share across goroutines. Get started](/open-source/go-rules-engine)[ ### Rust The core itself - zero-cost abstractions, async-ready. Get started](/open-source/rust-rules-engine)[ ### Java JNI bindings for Spring Boot and the JVM. Get started](/open-source/java-rules-engine)[ ### Kotlin Coroutine support and an idiomatic Kotlin API. Get started](/open-source/kotlin-rules-engine)[ ### C# .NET 8+ via NuGet, async/await throughout. Get started](/open-source/csharp-rules-engine)[ ### Swift On-device evaluation for iOS, offline-capable. Get started](/open-source/swift-rules-engine) ## Why open source? Transparency over trust-us. The open engine gives you full control of how your rules are evaluated - and where. ### MIT licensed Free to use in any project, commercial or personal. No licensing fees, no restrictions. ### Rust core Written in Rust for performance and memory safety. Zero garbage collection pauses. ### Native bindings Direct FFI bindings for each language. No HTTP overhead or separate processes. ### Cross-platform Runs on Linux, macOS, and Windows, on both ARM and x86. ### Battle tested Used by companies processing millions of decisions daily in production. ### No vendor lock-in Own your evaluation stack. Self-host anywhere, no external dependencies or API calls. ## Own your decision stack. MIT licensed, self-hosted anywhere, no per-evaluation fees. Add the BRMS when you need governance. [View on GitHub](https://github.com/gorules/zen) [Read the docs](https://docs.gorules.io/developers/overview/architecture) --- ## Industries - GoRules Business Rules Engine **URL:** https://gorules.io/industries **Description:** Transform decision-making processes with powerful automation across industries. Financial, healthcare, insurance, aviation, and more. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # One rules engine, every industry. Pricing, eligibility, risk, routing - the decisions look different in every industry, but they all belong in one governed decision layer instead of scattered code. [Get started free](https://us1.gorules.io) **Eligibility policy**_v2.4.0_ fieldconditionoutcome applicant.ageat least 18continue risk.scoregreater than 70manual review regionnot supporteddecline incomeverifiedapprove ## Where GoRules runs. Each industry page covers the decisions teams automate, the challenges they hit, and ready-made templates to start from. [ ### Financial Automate banking and fintech decisions with the GoRules business rules engine. Improve compliance, streamline decisioning, and speed up onboarding. ](/industries/financial)[ ### Aviation Automate digital aviation experiences with the GoRules business rules engine. Improve personalization, booking flows, and ancillary offers. ](/industries/aviation)[ ### Insurance Automate insurance operations with the GoRules business rules engine. Improve underwriting, streamline claims processing, and optimize pricing. ](/industries/insurance)[ ### Healthcare Automate clinical decision support with the GoRules business rules engine. Improve compliance, streamline workflows, and support patient care. ](/industries/healthcare)[ ### Logistics Automate logistics operations with the GoRules business rules engine. Optimize routing, streamline warehouse work, and improve delivery management. ](/industries/logistics)[ ### Retail Automate retail operations with the GoRules business rules engine. Optimize dynamic pricing, manage discounts, and streamline marketplace fees. ](/industries/retail)[ ### Telco Automate telecom operations with the GoRules business rules engine. Optimize network management, streamline pricing, and simplify product config. ](/industries/telco)[ ### Public Sector Automate government operations with the GoRules business rules engine. Improve eligibility determination, case management, and citizen services. ](/industries/public-sector) ## The same wins, whatever the domain. No matter the industry, moving rules out of the codebase delivers the same measurable improvements. ### Consistent decisions Every decision follows the same policy - across channels, products, and teams. ### Less manual review Routine decisions run automatically, so people only handle the exceptions. ### Compliance built in Regulatory requirements live in the rules, with a full audit trail behind every outcome. ### Faster cycles Fewer denials, reworks, and billing errors - requirements applied the same way every time. ### Better outcomes Evidence-based guidelines applied consistently, decision after decision. ### Business ownership The people who own the policy change the policy - without an IT queue. ## Your industry's rules, under control. Start free on GoRules Cloud, or talk to us about how teams in your industry run GoRules. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## GoRules: AI Business Rules Engine **URL:** https://gorules.io/ **Description:** Build and test business rules with AI. GoRules is a modern Business Rules Management System with an AI copilot and MCP server for business and dev teams. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch ![](https://image.mux.com/2xnLNPO5n52bVYbJCba7fg2QiL3Bf7HuzBuWnwGZT5k/thumbnail.png?width=76&height=44&time=22)What is GoRules_0:57_ # The decision layer for your products and agents. Model logic in readable rules, tables, and visual flows. Change it without deploys. Run it anywhere. GoRules AI is working in the background SOC 2 Type II. Trusted by Fortune 100 companies. **700K+**package downloads every month across npm, PyPI, and crates.io **570K+**Docker pulls of the BRMS, agent, and editor images **9**languages, one engine - the same answers in every runtime ## Rules that read like sentences. Conditions are written - and displayed - the way the business says them. The developer view of the same rule is one toggle away, and the two never drift apart. loan amount is less than $100,000 _and_ customer tier _is_ vip _then_ approve _otherwise_ manual review ### See the whole decision. Inputs, tables, and routing on one canvas that reads like a flowchart - because it is one. [Explore the editor](/editor) **Loan Application****Credit Policy****Approve****Manual Review**when score > 700otherwise _MC_ **M. Chen**_score 720_ ### The spec is the implementation. Prose, data model, and decision tables in one executable document. [See the BRMS](/brms) **Loan Approval** Approve automatically when the applicant clears the credit bar. credit.scoredecision _greater than_ 740approve · tier A _between_ 640 _and_ 700manual review _less than_ 640decline **_between_ 700 _and_ 740**approve · tier B ### Prove it before it ships. Scenario suites run on every change - coverage is measured against decision paths, not lines of code. _T_ Quality control_Run all_ Prime score, small loan_0.3 ms_ Score 660 · any amount_0.4 ms_ Missing income data_0.3 ms_ Amount at the $50,000 boundary_0.2 ms_ Underage applicant_0.2 ms_ Thin file · no score_0.4 ms_ ## Ask, and it's built. Everything stays reviewable. [Meet GoRules AI](/ai) ## Promote like a release. Run like a binary. A release moves from testing to staging to production untouched - and the exact same version answers everywhere your systems live. - Promotions, approvals, and instant rollback - Same engine on servers, edge, and devices - No rebuilds between environments [Explore environments](/environments) ## Runs over rows, not just requests. The engine that answers one API call also sweeps your whole book - embedded in Spark, streams, and nightly batch. No per-row API calls. No second implementation. Rules behind an API, called per row_28 hours_ ZEN embedded in the job_4 minutes_ 10M rows, same rules, same answers - the network hop is the whole difference. [Explore big data](/big-data) ## Open at the core. Fast everywhere. The open-source ZEN engine executes your decisions wherever your systems live - embedded in your service, serverless, or behind a REST API. < 1 _ms_ One evaluation of a full decision model, running inside your own process. No network hop, no vendor runtime - the open-source ZEN engine is a library, not a service. `await engine.evaluate('loan-approval', applicant)` TypeScriptPythonGoRustJavaC#KotlinSwift [Explore the open source](/open-source) ## Wherever the answer can't be “it depends.” Pricing, eligibility, risk, routing - if it's a rule today and an exception tomorrow, it belongs in one decision layer instead of six codebases. [**Financial** Lending, limits, and fraud - explainable to audit. ](/industries/financial)[**Insurance** Underwriting rules and claims triage in plain language. ](/industries/insurance)[**Healthcare** Triage, prior auth, and care pathways on record. ](/industries/healthcare)[**Retail** Discounts, fees, and promotions - no deploy needed. ](/industries/retail)[**Logistics** Carrier selection, routing, and shipping costs. ](/industries/logistics)[**Public Sector** Benefits, permits, and eligibility - every decision recorded. ](/industries/public-sector) [Explore all industries](/industries) ## Move fast, with a paper trail. Rules change weekly. Every change follows the same path to production - reviewed, versioned, and explainable forever. v2.3.9 · this morning**Loan Approval** Approve automatically when the applicant clears the credit bar. credit.scoreloan.amountdecision greater than _740_up to _$50,000_approve · tier A between _640_ and _700_anymanual review less than _640_anydecline _1 min_ v2.4.0 · in production**Loan Approval** Approve automatically when the applicant clears the credit bar. credit.scoreloan.amountdecision greater than _740_up to $50,000 $60,000approve · tier A between _640_ and _700_anymanual review less than _640_anydecline Approved by Jane Cooper at 09:32 - sign-off recorded in the audit log.[Explore version control](/version-control) ## Own the rules that run your business. Start free, or bring one real decision and we'll show you what it looks like in GoRules. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Features - Complete Business Rules Platform **URL:** https://gorules.io/features **Description:** Version control, multiple environments, approval flows, autocomplete, validation, and more. Everything you need to manage business rules at scale. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Everything a decision needs to ship safely. One platform to author, test, review, and release business rules - with version control, environments, and approvals built in, not bolted on. [Start for free](https://us1.gorules.io) [Explore the BRMS](/brms) ## Governed by design. Every change follows the same path to production, whether it was made by an analyst, an engineer, or the AI - branched, reviewed, released, recorded. **Raise tier A ceiling to $60,000**_Jane Cooper · just now_ **Add tier B between 700 and 740**_Marcus Webb · yesterday_ **Split risk scoring into its own table**_Amelia Ford · last week_ ### Version control Git-like branches, history, and visual diffs - made for business rules, attributable forever. - Branch, change, and merge through reviews - Compare any two versions visually - Roll back to any version instantly [Explore version control](/version-control) **Production**`v2.3.9` healthy **Staging**`v2.3.9v2.4.0` ready to promote **Development**`v2.5.0-draft` draft ### Environments Immutable releases promoted from development to staging to production, unchanged. - Isolated dev, staging, and production - Environment-specific configuration - Controlled promotion between stages [Explore environments](/environments) Credit Policy · tier A ceiling $50,000 $60,000 _JC_**Jane Cooper** Approved · 09:32 _RT_**Risk team** Pending ### Approval flows Review workflows that match your organization - nothing publishes without sign-off. - Require one or more approvals - Define exactly who can approve - Approval history and comments on record [Explore approval flows](/approval-flows) ## An editor that catches mistakes early. Authoring tools built for correctness - the editor validates, suggests, and simulates while the rule is still a draft. applicant.**sc** scorescoreDatescoreSource ### Autocomplete Field and function suggestions as you type - fewer typos, faster rules. score > "700" expected number, got string resolved ### Real-time validation Type and syntax errors surface while you edit, not after you publish. Prime score, small loan Amount at the $50,000 boundary Thin file · no score ### Testing & simulation Run rules against sample data and scenario suites before anything ships. rate = base + risk.margin \* 0.4fee = max(amount \* 0.02, 25)dti = debt / income \* 100 ### Expression language The ZEN language handles conditions, calculations, and data transforms. **Jane Cooper** changed tier A ceiling_09:32_ **Marcus Webb** approved release v2.4.0_09:35_ **Amelia Ford** promoted to production_09:41_ ### Audit logging A complete record of every change - who, what, and when. _JC_**Jane Cooper**_Approver_ _MW_**Marcus Webb**_Editor_ _AF_**Amelia Ford**_Admin_ ### Team collaboration Role-based access control and team workflows, down to who can approve. ## Start building in minutes. Everything on this page is included from the first rule - start free on GoRules Cloud. [Get started](https://us1.gorules.io) [View pricing](/pricing) --- ## Multiple Environments - Dev, Staging, Production **URL:** https://gorules.io/environments **Description:** Promote business rules through isolated environments. Test in development, validate in staging, deploy to production with confidence. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Isolated environments. One road to production. Build in development, validate in staging, serve live traffic from production - the same immutable release at every step, promoted only when it clears the gate. [Start for free](https://us1.gorules.io) [Explore the BRMS](/brms) ## One release, promoted gate by gate. Rules are packaged into immutable releases. A release moves from development to staging to production unchanged - and protected environments only open after the required approvals. **Development** draft `v2.5.0-draft`_Open to editors_ **Staging** ready `v2.4.0`_Checks running… 14/14 checks passed_ **2 approvals** _JC__RT_ _waitinggate open_ **Production** live `v2.3.9v2.4.0`_Serves live traffic_ 14:02 · amelia.ford promoted release v2.4.0 to production ## Isolated by default. Promoted on purpose. Everything you need to run the same rules safely across development, staging, and production. ### Environment isolation Each environment is fully isolated. Changes in development can never leak into production, so teams test freely. ### Controlled promotion Define who can promote to each environment and which approvals a release needs before the gate opens. ### Environment-specific config Different endpoints, thresholds, or feature flags per environment - the release stays the same. ### Independent rollback Roll any environment back to a previous release in one click, without touching the others. ## How teams use environments. Three stages is the common setup - but environments stretch to whatever shape your organization needs. ### Development Experiment, test edge cases, and iterate with zero risk to live systems. ### Staging Validate with production-like data and collect stakeholder sign-off. ### Production Serve live traffic with only approved, tested releases. ### Compliance Separate environments for regulatory or data-residency requirements. ### Multi-region Region-specific environments with localized business logic. ### A/B testing Trial rule variations in one environment before rolling out to all. ## Deploy rules with confidence. Start free on GoRules Cloud and give every rule change a safe, gated path to production. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Contact us - GoRules **URL:** https://gorules.io/contact-us **Description:** Talk to the GoRules team about enterprise plans, self-hosted deployments, and dedicated support. Book 30 minutes with an engineer. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Let's talk The direct line to our team for enterprise plans, self-hosted deployments, and dedicated support. What happens next 1. _01_ **Tell us what you're building** A few lines about your use case, stack, and scale is all we need to prepare. 2. _02_ **30 minutes with an engineer** Talk architecture, use cases, and integration with someone who builds GoRules. 3. _03_ **Tailored walkthrough and trial key** See GoRules on your use case and evaluate the enterprise edition on your infrastructure. Not an enterprise inquiry? [Open-source support](https://github.com/gorules) [Documentation](https://docs.gorules.io) [SOC 2 Type II](/security)**700K+** downloads / month**570K+** Docker pulls ### Message sent! We'll get back to you shortly. Enterprise inquiry Full name \* Work email \* What are you looking to achieve? \* You can also email us at [hi@gorules.io](mailto:hi@gorules.io)Send message By submitting this form, you acknowledge that your personal data will be processed in accordance with our [Privacy Policy](https://gorules.io/legal/privacy-policy) for the purpose of responding to your enquiry. --- ## Components - Building Blocks for Business Rules **URL:** https://gorules.io/components **Description:** Decision Tables, Expressions, Functions, and Switch components. The building blocks for creating powerful business rules. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # The four blocks behind every decision. Decision tables, expressions, functions, and switches - every rule graph in GoRules is composed from these four node types. Visual for the business, versioned and testable for engineering. [Explore the BRMS](/brms) [View templates](/templates) ## One canvas, four node types. Each block does one job well - together they cover everything from a three-row pricing table to a full underwriting flow. credit.scoredecision _greater than_ 740approve _between_ 640 _and_ 700manual review **_less than_ 640**decline ### Decision table Complex conditional logic in a familiar spreadsheet format - typed inputs, outputs, and hit policies. - Spreadsheet editing with copy and drag to fill - First match and collect hit policies - Import and export from Excel - Visual debugging in the simulator [Explore decision tables](/components/decision-table) rate = base + risk.margin \* 0.4fee = max(amount \* 0.02, 25)total = _$.rate_ + _$.fee_ ### Expression Calculate values and reshape data with the readable ZEN expression language. - Readable, Excel-like syntax - Chain steps with $ references - Built-in date, string, and array functions - Type validation as you type [Explore expressions](/components/expression) _const_ handler = _async_ (input) => ({ dti: input.debt / input.income,}); ### Function Full JavaScript for the logic that goes beyond expressions - async, modules, and debugging included. - Modern JavaScript with async/await - dayjs, big.js, zod, and http built in - console.log debugging in the simulator - External data fetching over http [Explore functions](/components/function) score > 700 approvescore >= 640 manual reviewotherwise decline ### Switch Conditional branching that routes execution down the right path of your graph. - Conditions in ZEN expressions - First match or collect evaluation - Context preserved on every path - Active branches shown in the simulator [Explore switches](/components/switch) ## Blocks compose into graphs. Wire them together on the editor canvas - expressions shape the data, tables judge it, switches route it, and every step stays visible. **Application****Credit Policy****Quote****Route****Approve****Manual review**eligibleotherwise [Explore the editor](/editor) [Govern graphs in the BRMS](/brms) [Read the docs](https://docs.gorules.io/learn/authoring/decision-graphs) ## Start with one block. Grow to a graph. Model your first decision in minutes on GoRules Cloud, or start from a template that shows the blocks working together. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Rules Engine Comparisons vs Alternatives **URL:** https://gorules.io/compare **Description:** Compare GoRules with other business rules engines. Side-by-side comparisons of features, performance, and use cases. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Rules Engine Comparisons Choosing the right business rules engine is critical. Compare GoRules with popular alternatives to find the best fit for your needs. [Try GoRules Free](https://us1.gorules.io)[What is a BRE?](/what-is-business-rules-engine) [ _![](/emblem-white.svg)__vs_ ### GoRules vs Drools Compare GoRules' lightweight, polyglot approach with Drools' mature Java-based BRMS. See differences in performance, scalability, and ease of use. - Performance benchmarks - Language support comparison - Deployment options - When to use each Read comparison](/compare/gorules-vs-drools) ## Ready to try GoRules? Start building with GoRules in minutes. Visual editor, native SDKs, and cloud-native deployment. [Start for Free](https://us1.gorules.io) [Book a Demo](/contact-us) --- ## Cloud Native Rules Engine - Deploy BRMS Anywhere **URL:** https://gorules.io/cloud-native **Description:** Self-host GoRules BRMS on any cloud. Docker and PostgreSQL deployment for AWS, Azure, Google Cloud, and Kubernetes, with enterprise serverless options. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Your cloud. Your rules. Self-host the GoRules BRMS with Docker and PostgreSQL - on AWS, Azure, Google Cloud, or any Kubernetes cluster. Your data never leaves your environment. [Start for free](https://us1.gorules.io) [Deployment guide](https://docs.gorules.io/developers/deployment/brms/deployment) live $docker pull gorules/brms$**docker compose up -d**✓ gorules-brms started · postgres connected **GoRules BRMS**_Docker container_ **PostgreSQL**_managed database_ _Releases deploy to_ **Development**_Storage → Agent / SDK_ **Staging**_Storage → Agent / SDK_ **Production**_Storage → Agent / SDK_ [About the Agent](/agent) [About the SDKs](/open-source) ## Management and execution. Choose each on its own. GoRules separates how rules are governed from how they run - pick the right option for each side of your stack. _Rule management_ ### BRMS Platform Full governance Visual editor, version control, environments, approval workflows, SSO/OIDC, and audit logging. Publishes releases to your cloud storage. ### React Editor Open source Embeddable React components for building your own rule editing UI - full customization, rules managed in your own backend. _Rule execution_ ### GoRules Agent Open source Pulls releases from S3, GCS, or Azure Blob and serves them over HTTP - live reload without service restarts, deployable as a sidecar. ### Embedded SDKs Open source Native SDKs for Rust, Node.js, Python, and Go with microsecond latency. Package rules via git or build your own live reload from storage. ## Anywhere Docker runs, the BRMS runs. Pick your cloud provider or Kubernetes distribution - the platform ships as one image and one Helm chart. [ ### AWS ECS or EKS with Aurora PostgreSQL and S3 for rule artifacts. ECS / EKSAuroraS3 ](/cloud-native/aws)[ ### Azure Container Apps or AKS with Azure PostgreSQL and Blob Storage. Container AppsAKSBlob Storage ](/cloud-native/azure)[ ### Google Cloud Cloud Run or GKE with Cloud SQL PostgreSQL and Cloud Storage. Cloud RunGKECloud SQL ](/cloud-native/google-cloud)[ ### Kubernetes Any cluster, one Helm chart - cloud-agnostic and production-ready. Helm chartAny distributionHPA ](/cloud-native/kubernetes)[ ### Serverless Enterprise Lambda layers for AWS Lambda, Azure Functions, and Cloud Functions. LambdaFunctionsCloud Functions ](/cloud-native/serverless)[ ### Big Data & PySpark Millions of evaluations with distributed processing on Databricks, EMR, or Dataproc. PySparkDataFramesBatch ](/big-data) ## Why teams self-host. Full control over your business rules infrastructure, with enterprise-grade performance and security intact. **Your infrastructure** Deploy on your own cloud account - data never leaves it, and security stays in your hands. **Sub-millisecond latency** A Rust-powered engine with no cold starts and no interpretation overhead. **Horizontal scaling** Stateless architecture - add instances to handle millions of evaluations per second. **Hot reload rules** Rule changes propagate automatically with zero downtime and no service restarts. **Zero vendor lock-in** Open-source engine, portable JSON rules - move clouds or go on-premise without changes. **Enterprise security** SOC 2 Type II compliant, with sandboxed execution, encrypted storage, and audit logging. ## Deploy on your terms. Self-host the BRMS on your own cloud in an afternoon - or start free on GoRules Cloud today. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## BRMS - Business Rules Management System **URL:** https://gorules.io/brms **Description:** Complete business rules management system with visual editor, version control, environments, approval workflows, and enterprise governance. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # The system of record for business logic. GoRules BRMS is where rules are authored, tested, reviewed, and released - with version control, approvals, and an audit trail built in, not bolted on. [What is a business rules engine?](/what-is-business-rules-engine) ## Logic out of the codebase, into one place. A business rules management system externalizes the decisions that change most - pricing, eligibility, risk - so the people who own them can change them safely, without a deploy. - Business logic separated from application code - Business users edit rules directly - Changes ship without code releases - Complete audit trail for compliance ## Every change, on the record. Branches, reviews, releases - the BRMS gives each change the same path to production, whether it was made by an analyst or an engineer. ### Version control, without the git. Drafts, history, and diffs for business users - real branches and commits underneath, every change attributable. [Explore version control](/version-control) **Raise tier A ceiling to $60,000**_Jane Cooper · just now_ +1 −1 **Add tier B between 700 and 740**_Marcus Webb · yesterday_ +1 −0 **Import affordability policy**_GoRules AI · 2 days ago_ +12 −0 **Split risk scoring into its own table**_Amelia Ford · last week_ +9 −4 **Tighten fraud thresholds for new accounts**_Marcus Webb · last week_ +2 −2 ### Reviews before releases. Approval flows route every change to the right reviewers before it can ship. [Explore approval flows](/approval-flows) **Release v2.4.0**_1 of 2 approvals_ Credit Policy · tier A ceiling $50,000 _→_ $60,000 _JC_**Jane Cooper** Approved · 09:32 _RT_**Risk team** Pending Every sign-off is recorded in the audit log. ### Promote releases, not files. Rules are packaged into immutable releases and promoted from testing to staging to production unchanged. Roll back to any previous release in one click. [Explore environments](/environments) Environments_Promote_ **Production**`v2.3.9` healthy **Staging**`v2.3.9v2.4.0`deploying…ready to promote **Development**`v2.5.0-draft` draft ## An AI that speaks policy. Nothing ships unreviewed. [Meet GoRules AI](/ai) Why was application #4821 declined? The credit score was 612 - below the 640 floor in Credit Policy, row 3. credit.score = 612less than 640decline Add a tier B for scores 700 to 740 Added a row to Credit Policy and generated three scenarios for the new band. 14/14 tests passingReady for your review - Edits tables and graphs as reviewable drafts - Writes and runs test suites - Explains any decision, step by step - Creates new policies from a prompt AI never deploys - releases stay with your reviewers. ## Built from blocks anyone can read. Four node types compose every decision - visual for the business, versioned and testable for engineering. [ credit.scoredecision _greater than_ 740approve _less than_ 640decline ### Decision table Spreadsheet-familiar rules with typed inputs and outputs. ](/components/decision-table)[ rate = base + risk.margin \* 0.4fee = max(amount \* 0.02, 25) ### Expression Map and transform data with a readable expression language. ](/components/expression)[ _const_ handler = (input) => ({  dti: input.debt / input.income,}); ### Function Drop to JavaScript when a rule needs custom logic. ](/components/function)[ score > 700 approveotherwise manual review ### Switch Route the flow down different paths by condition. ](/components/switch) ## Author here. Run anywhere. The BRMS manages the lifecycle; the open-source ZEN engine executes your releases wherever your systems live. [**Agent** A Rust service that serves releases over REST, with hot reload. ](/agent)[**SDKs** Embed the engine in TypeScript, Python, Go, Rust, and more. ](/open-source)[**Big Data** Sweep millions of rows in Spark and nightly batch jobs. ](/big-data) ## Govern the rules that run your business. Start free on GoRules Cloud, or talk to us about self-hosting the BRMS in your own infrastructure. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Blog - GoRules **URL:** https://gorules.io/blog **Description:** Explore GoRules business rules management insights. Learn about decision modeling, rule engines, and best practices for implementing business logic. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Writing on business logic. Articles, tutorials, and case studies on decision modeling, rules engines, and shipping business logic without a deploy. [ Business logic humans can read and machines can run One copy: the owner reads it, every system runs it. Blog BlogAug 19, 2026 ## Business logic humans can read and machines can run Most companies keep two copies of their business logic: a document people read, and code that actually runs. The two drift apart. We built GoRules so you can keep one copy, something the owner reads and every system runs. Read article ](/blog/business-logic-humans-can-read)[ GoRules Version 2 Policies, static analysis, natural language, a full redesign - and rules that ship like software. Release ReleaseAug 4, 2026 ## GoRules Version 2 is here The largest release in our history: policies, static analysis, rules in plain language, a redesigned workspace, and developer tools that turn your rules into a typed API. Read article ](/blog/gorules-version-2)[ SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. Announcement AnnouncementJan 12, 2026 ## SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. Read article ](/blog/soc-2-type-2)[ KYC Automation Architecture Design patterns and implementation strategies for building automated, scalable Know Your Customer (KYC) verification systems. Business Case Business CaseNov 29, 2024 ## KYC Automation Architecture: Building Scalable Verification Systems Design patterns and implementation strategies for building automated, scalable Know Your Customer (KYC) verification systems. Read article ](/blog/kyc-automation-architecture)[ Automated Approval Systems Discover how automated approval workflows can revolutionize your operations. Business Case Business CaseNov 23, 2024 ## Automated Approvals: From SharePoint to Modern Workflows Discover how automated approval workflows can revolutionize your operations. Read article ](/blog/automated-approval-system)[ Adding Flexibility to Your Product Explore a powerful approach to adding configurable business logic to your product. How to How toNov 8, 2024 ## Embedded Decision Engine: Adding Flexible Business Logic to Your Product Explore a powerful approach to adding configurable business logic to your product. Read article ](/blog/embedded-decision-engine-adding-flexibility-to-your-platform)[ What is Dynamic Pricing? Learn how to implement dynamic pricing strategies that automatically adjust prices based on market demand, competition, and customer behavior. How to How toNov 7, 2024 ## What is Dynamic Pricing and Why It Matters Learn how to implement dynamic pricing strategies that automatically adjust prices based on market demand, competition, and customer behavior. Read article ](/blog/what-is-dynamic-pricing-and-why-it-matters)[ Reshaping the Insurance Industry with Steadfast Technologies Announcement![](/logos/steadfast-logo.svg) AnnouncementFeb 7, 2024 ## Reshaping the Insurance Industry with Steadfast Technologies Steadfast Technologies, a leading InsureTech provider throughout Australia and New Zealand, is excited to announce its collaboration with GoRules. Read article ](/blog/reshaping-the-insurance-industry)[ Serverless Deployment Deploy GoRules with Python on AWS Lambda in just 10 minutes and execute decisions on the cloud. How to How toApr 4, 2023 ## Building Python Rules Engine: Lambda and S3 Learn how to deploy and utilize a serverless rules engine. Read article ](/blog/python-rules-engine-lambda) ## Put the reading into practice. Start free on GoRules Cloud, or talk to us about running the platform in your own infrastructure. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Big Data - Rules at Scale **URL:** https://gorules.io/big-data **Description:** Evaluate business rules on millions of records using PySpark or Rust. Process batch data, streaming pipelines, and analytics workloads. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Rules that run over every row. Evaluate business rules on millions of records - a native PySpark integration for your clusters, and the Rust engine for throughput-critical pipelines. [View documentation](https://docs.gorules.io) [Explore SDKs](/open-source) ## The network hop is the bottleneck. Embedded in the job, the engine sweeps your whole book without a single per-row API call - same rules, same answers, hours faster. Rules behind an API, called per row_28 hours_ Engine embedded in the job_4 minutes_ 10M rows, same rules, same answers - the network hop is the whole difference. **1M+**evaluations per second with the Rust engine **< 1 ms**average evaluation latency **10x**faster than interpreted engines ## Choose your runtime. Two ways to process rules at scale, depending on where your data lives and how fast it has to move. ### PySpark _For Spark clusters_ Native PySpark integration for evaluating rules across distributed datasets. Works with Databricks, EMR, Dataproc, or self-managed Spark clusters. - Distributed processing across workers - DataFrame API integration - Works with existing Spark jobs - Python-native development `pip install zen-engine` ### Rust SDK _For custom pipelines_ Maximum throughput with the native Rust engine. Build custom data pipelines or embed it in existing Rust applications for throughput-critical workloads. - Millions of evaluations per second - Zero-copy memory management - Multi-threaded processing - Minimal resource footprint `cargo add zen-engine` ## Built for the jobs that touch everything. Common patterns for rule evaluation at scale - anywhere the row count has too many zeros for an API. ### Batch processing Run millions of records through your rules - nightly jobs, migrations, bulk calculations. ### Analytics pipelines Classify, score, or transform data inside your ETL before it lands in the warehouse. ### Streaming data Evaluate rules on Spark Streaming as events arrive, not after the fact. ### Backfill operations When rules change, re-evaluate historical records with the updated logic in one pass. ## Ready to process at scale? Start with the open-source SDKs and documentation, or talk to us about your pipeline. [View SDKs](/open-source) [Talk to us](/contact-us) --- ## Approval Flows - Review Workflows **URL:** https://gorules.io/approval-flows **Description:** Configure review workflows that match your organization. Require approvals before rules go live, with complete audit trails. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # No change ships without review. Approval flows route every rule change to the right reviewers before it can be released - configurable to match your organization, with a complete audit trail for compliance. [Start for free](https://us1.gorules.io) [Explore the BRMS](/brms) ## Reviewers in the loop, by design. A change request collects sign-off from every required reviewer - in sequence or in parallel - and only then can a release be created. Each step lands in the audit log. **Change request #128**_2 of 3 approvalsApproved_ Credit Policy · tier A ceiling $50,000 _→_ $60,000 _JC_ **Jane Cooper**_Risk_ Approved · 09:32 _MW_ **Marcus Webb**_Compliance_ Pending Approved · 09:47 _AF_ **Amelia Ford**_Release manager_ Pending Approved · 09:52 Release v2.4.0 can now be created. **Audit log**_append-only_ 09:31jane.cooper requested review 09:32jane.cooper approved · risk 09:47marcus.webb approved · compliance 09:52amelia.ford approved · release 09:53release v2.4.0 created Every request, comment, and sign-off - recorded forever. ## Change management, built into the editor. Everything you need to run a proper review process - without leaving the place where rules are made. ### Change request workflow Authors submit changes, reviewers approve, and only then can changes merge and ship. ### Configurable reviewers Require named reviewers, role-based approvers, or a minimum number of sign-offs. ### Review comments Discuss specific parts of a change, request revisions, and document decisions inline. ### Notifications Know when a review is requested or approved - via Slack, email, or webhooks. ### Approval history A full audit trail of who approved what, when, and with which comments. ### Protected environments Production can demand multiple approvals while development allows self-merge. ## Why approval flows matter. Governance that protects production without slowing the people who own the rules. **Quality assurance** More eyes on every change catch mistakes before they reach production. **Compliance** A complete audit trail satisfies SOX, GDPR, and industry-specific regulation. **Knowledge sharing** Reviews keep the whole team informed about how the business logic evolves. ## Governance that keeps its receipts. Start free on GoRules Cloud and put the right reviewers in front of every release. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## AI Business Rules - From Documents to Decisions **URL:** https://gorules.io/ai **Description:** Turn policy documents into live business rules. Import PDFs and spreadsheets, refine with an AI copilot, and test automatically before review. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Policy documents in. Working rules out. GoRules AI reads the PDFs and spreadsheets your rules already live in, builds the tables and graphs, and proves them with tests - every change a reviewable draft, never a silent deploy. [Start for free](https://us1.gorules.io) [Book a demo](/contact-us) ## From document to decision. Your rules already exist - in PDFs, spreadsheets, and policy docs. AI turns them into running logic, and keeps proving they work as they change. _01_ ### Import what you have Drop in a policy PDF, paste a spreadsheet, or describe the rules in plain text. AI structures conditions and outcomes into tables and graphs. pricing-policy.pdf rules.xlsx _GoRules AI structures the logic_ Decision table Decision graph _02_ ### Refine in conversation Adjust thresholds, add edge cases, or ask what a rule does - like talking to a colleague who never forgets the policy. Add a 15% discount when order quantity is over 1,000 units Added a row to the pricing table - quantity > 1,000 → _discount 15%_ - plus the edge case at exactly 1,000. quantity \> 1,000discount · 15% _03_ ### Prove it with tests AI generates scenario suites for every change and runs them before anything reaches a reviewer. _T_ Quality control_Run all_ Order of exactly 1,000 units_0.3 ms_ Order of 1,001 units_0.3 ms_ Discount stacking with promo code_0.3 ms_ Empty cart edge case_0.3 ms_ ## People release. Always. AI drafts, tests, and explains. Releasing stays with your reviewers - the same approvals and audit trail as any human change. **GoRules AI**drafts the change **Tests**14/14 passing **Jane Cooper**approves · 09:41 **Marcus Webb**promotes to production AI never deploys - releases stay with your reviewers.[Explore approval flows](/approval-flows) ## Bring your own agent. And your own model. [Meet the BRMS](/brms) [Explore the Agent](/agent) ![](/ai/claude.svg)Claude![](/ai/cursor.svg)Cursor![](/ai/openai.svg)Codex![](/ai/mcp.svg)Any MCP client MCP server _rules.edit__tests.run__decisions.explain_ **GoRules BRMS**Rules edited, tested, and explained - through the same governed drafts._governed drafts · full audit trail_ ClaudeOpenAIGoogle GeminiAzure OpenAIAWS Bedrock Your keys, your model. Prompts and responses are never stored. ## Put AI to work on your rules. Start free and drop in a real policy document - you'll have working, tested rules before the meeting ends. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Agent - High-Performance Rules API **URL:** https://gorules.io/agent **Description:** Deploy a high-performance Rust service for headless rule evaluation. Hot reloading, REST API, and sub-millisecond latency. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Your rules, served over REST. GoRules Agent is a headless Rust service that evaluates the releases you publish from the BRMS - sub-millisecond answers, hot reload on every release, zero restarts. [View documentation](https://docs.gorules.io) [Book a demo](/contact-us) _gorules-agent · :8080_ release v2.4.0 hot-reloaded Request POST /evaluate/loan-approval { "customer": { "score": 720 }, "loan": { "amount": 24000 } } Response · 0.4 ms 200 OK { "result": { "decision": "approve" } } ## From publish to production, automatically. Agent sits between your services and rule storage. The BRMS publishes releases to storage; Agent watches for changes and hot-reloads them with zero downtime. BRMSStorage AgentYour services Reads from S3, GCS, the local filesystem, or custom storage providers. ## Built for production. Everything you need to run rule evaluation as reliable infrastructure - and nothing you have to babysit. ### Built in Rust Thousands of evaluations per second with minimal latency, from a single small container. ### Hot reloading Rules update the moment a release is published. No restarts, no downtime, no deploy. ### Storage agnostic Works with S3, GCS, the local filesystem, or your own custom storage provider. ### Secure by default Sandboxed execution - rules can never touch the filesystem, network, or host system. ### Observable Metrics and tracing built in. Monitor throughput, track evaluations, debug any decision. ### REST API One simple HTTP endpoint for evaluation - easy to call from any service or language. ## Where Agent earns its keep. Common patterns for deploying Agent in your architecture - anywhere many callers need the same answers. **Microservices** One Agent instance serves every service, so decisions stay consistent across your whole system. **API gateways** Evaluate validation, routing, or rate-limit rules before requests ever reach your backend. **Real-time decisioning** Pricing, eligibility, and fraud checks answered in under a millisecond - fast enough for the hot path. **Multi-tenant apps** Serve isolated rules per tenant from a single instance, each updatable independently. ## Deploy in minutes, not sprints. Run Agent with Docker or Kubernetes and serve your first release today. [Read the deployment guide](https://docs.gorules.io) [View pricing](/pricing) --- ## About GoRules - Decisions, democratized **URL:** https://gorules.io/about **Description:** GoRules is a business rules engine and decision platform, founded in 2023. Bootstrapped, remote, built on an open-source core - and run in production by banks, insurers, airlines, and more. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch About GoRules # Decisions, democratized. GoRules is a business rules engine and decision platform. Teams write logic in readable rules, tables, and flows - then run it anywhere: in products, in pipelines, and behind AI agents. ## Why GoRules exists _2023_ GoRules founded _2023_ Zen Engine open-sourced under MIT _2026_ SOC 2 Type II attested _2026_ Platform v2 launched GoRules started in 2023 out of frustration with the rules engines we had to work with. Legacy platforms were closed, heavyweight, and locked to a single stack. Every project began with a license negotiation and ended with a consulting engagement - and the people who actually owned the rules still couldn't read them. So we built the engine we wished existed. **Zen Engine** went open source under MIT in 2023: a decision engine written in Rust, embeddable in nine languages, fast enough to sit in the hot path. Not a wrapper around someone else's API - your rules run inside your own infrastructure, whether that's a bank's data center or a serverless function. That is what democratization means to us: rules readable by the analysts who own them and the engineers who run them, on an engine anyone can adopt without asking permission. And as software shifts toward agents, the same idea carries forward - AI needs a decision layer that is deterministic, auditable, and under your control. **GoRules is that layer.** ## Adoption you can verify No unnamed logos, no vague claims. The numbers we point to are public. **700K+** ### Package downloads, every month. Across npm, PyPI, and crates.io. Open source isn't a marketing word here - it's how GoRules is distributed, evaluated, and adopted. **570K+**Docker pulls of the BRMS, agent, and editor images **1.8K+**GitHub stars on the open-source Zen Engine **9**languages, one engine - the same answers in every runtime **SOC 2**Type II attested, with a public trust portal In production at banks · insurers · airlines · healthcare providers · logistics networks · retailers · telcos · public sector What we believe 1. _01_ **Rules belong to the people who own them.** Readable by the analysts who write them, runnable by the engineers who ship them - no translation layer in between. 2. _02_ **An engine you can't inspect is a liability.** Zen Engine is MIT-licensed and embeddable in nine languages. Adoption shouldn't start with a license negotiation. 3. _03_ **Deterministic beats plausible.** Products and AI agents need decisions that are repeatable, auditable, and under your control. 4. _04_ **Customers are the roadmap.** Bootstrapped and customer-funded since 2023. Remote by design, async by default, no fund on the cap table. Decisions running in production right now ## Independent, by design. How a vendor is funded shapes everything they build. GoRules is bootstrapped and cash-positive, which buys the freedom that matters: the product follows its vision and our customers' needs, not an investor's timeline. **No venture clock.** Bootstrapped and cash-positive. No burn rate to outrun, no runway cliff, no fund steering the product. **Customers set the roadmap.** What we build next is decided by the teams running GoRules in production - not by a fund. **Never locked to our fate.** The engine is MIT-licensed and deployments are self-hosted. Whatever happens to us, your decisions keep running in your infrastructure. **Audited anyway.** SOC 2 Type II, a public trust portal, and security reviews on request - the diligence surface of a much larger vendor. Our compatibility pledge Rules you model today should keep evaluating, unchanged, years from now. We build for backwards compatibility across the engine and the decision format - and when something does have to evolve, a trace format or an API shape, the old behavior keeps working, mapped onto the new. Holding since 2023 ## Put your rules where everyone can read them. Start with the open-source engine, or run the full platform - self-hosted or in the cloud. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Automated Underwriting System for Insurers **URL:** https://gorules.io/use-cases/underwriting-automation **Description:** An automated underwriting system your underwriters own: appetite, knockouts, and referral rules in decision tables. Bind, refer, or decline in milliseconds. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # An automated underwriting system your underwriters own. Appetite, knockouts, referral triggers, and authority limits live in visual decision tables your underwriting team edits, not in the PAS release backlog. Every submission comes back bind, refer, or decline in milliseconds, with the exact rules that fired. ## From broker inbox to bound quote, start to finish. Watch a morning on a commercial property desk: a clean sprinklered submission stamped REFER because it sits $400K past the appetite ceiling, a one-cell change, a replay over 1,140 referred submissions, a signed release - and a straight-through rate that goes from 54 to 71 percent. scroll to play _MB_ **Bramwell & Fitch BrokersMeridian Bakery Co**n.adeyemi@bramwellfitch.com · 08:52SUB-4451 · property · effective 01 Oct **New submission - Meridian Bakery Co** Renewal marketing, effective 01 Oct. Fully sprinklered, five years of clean loss runs. Can you turn a quote around by Thursday? _ACORD 125_ _ACORD 140_ _Construction_**Joisted masonry**built 1968 · 1 story _Protection class_**PPC 3**hydrant 260 ft · station 1.2 mi _Sprinklered_**Yes · NFPA 13**full coverage · central station _Total insured value_**$1.4M**building $1.05M · contents $350K _Loss history_**5 yr clean**0 claims · $0 paid _Occupancy_**Bakery**NAICS 311811 · retail + production _**REFER**appetite · TIV__**QUOTED**auto · v6.4.0_ _referral__waiting_ **#47**in the property referral queue oldest submission waiting 3.4 days Routed to**Property UW · senior desk** Reason**TIV over auto-quote ceiling** Broker expects**quote by Thursday** referred by policy · open in GoRules to see why _quote · QTE-4451-A__auto-quoted_ **$18,400**annual premium rate 1.31 per $100 TIV Effective**01 Oct 2026 · 12 mo** Deductible**$10,000 · wind 2%** Form**Special · replacement cost** _Bind coverage_valid 30 days returned to broker 08:53 _Appetite · commercial property__auto-quote band, protected risks_ sprinklered, clean, still referred _Referral queue_**47**of 186 open submissions _Straight-through_ **54%**target 70% SUB-4451$1.4M SUB-4448$1.9M SUB-4447$1.1M SUB-4444$1.6M SUB-4441$1.25M SUB-4439$1.8M SUB-4437$1.2M SUB-4436$1.45M SUB-4433$1.7M SUB-4431$1.05M SUB-4427$1.35M SUB-4424$3.1M SUB-4419$1.55M SUB-4422$2.2M SUB-4416$1.15M SUB-4413$1.5M SUB-4429_unprotected · class 9_$2.6M policy v6.4.0 · brokers got quotes in minutes #### Property appetite Auto-quote rules for commercial property submissions. Evaluated top-down on every submission - first match decides. **TIV****Protection class****Occupancy****Action****Route to** 1**Prohibited****Decline**_\-_ 2_at most_ **$1.0M**_at most_ **$2.0M**_at most_ **5****In appetite****Auto-quote****Broker portal** 3_at most_ **$5.0M**_at most_ **8****In appetite****Refer****Property UW** 4_Otherwise_**Refer****Senior UW** + was at most $1.0M · unprotected risks untouched · edited by Chief Underwriting Officer 1 unsaved change_Run tests__Request review_ **Quality checks**_0 referrals replayed_ Protected risk at $1.4M TIV auto-quotes_was: refer_ Replayed book holds a 48% loss ratio_cap 52%_ Coastal wind exclusions untouched_guardrail_ Protection class 9 and worse still refers_guardrail_ All checks passed · +0 submissions auto-quote · 0 appetite breaches _Release v6.4.0_ **v6.4.0**_draft_Jane Cooper · just now · protected TIV ceiling $1.0M → $2.0M JC **Jane Cooper**Chief Underwriting Officer _pending_ _development_**v6.4.0** deploying _staging_**v6.3.2** live _production_**v6.3.2** live Live in production - every new submission now decides against v6.4.0, and the referrals sitting in the queue re-evaluate automatically. full diff + approval recorded · one-click rollback _Monday, 08:52_ ### A clean risk lands in the inbox. A broker emails SUB-4451 with the ACORDs attached: a sprinklered bakery, $1.4M total insured value, protection class 3, five years without a loss. It goes into the referral queue behind 46 others. _The submission_ ### Nothing wrong with it. Still referred. Joisted masonry, full NFPA 13 sprinklers, hydrant 260 feet out, zero losses in five years. It sits outside the appetite band for one reason: the auto-quote ceiling for protected risks stops at $1.0M. _One cell_ ### The chief underwriter moves the ceiling. The rule that referred it opens the live appetite table. For protection class 5 and better, the auto-quote ceiling goes from $1.0M to $2.0M. On a branch, nothing else touched. _Proof before production_ ### 1,140 referrals re-run. Ninety days of referred submissions replay against the draft while you watch: 380 come back as auto-quotes, projected loss ratio holds at 48 percent, coastal wind exclusions never move. _Sign-off_ ### Underwriting approves. v6.4.0 ships. Jane Cooper signs the release, it promotes through staging to production with the full trail recorded. Rollback stays one click away. _Same morning_ ### The band moves. The queue drains. The green zone runs past $1.4M, SUB-4451 stamps QUOTED at $18,400 and goes back to the broker at 08:53. Behind it: 47 referrals down to 12, straight-through rate 54 to 71 percent. The grain elevator at protection class 9 stays exactly where it is. ## Your appetite is a PDF. Your engine disagrees. Ask a carrier or MGA what its risk appetite is and you get a PDF. Ask the systems and you get three different answers: eligibility logic hard-coded in the policy administration system, a spreadsheet of class limits the product team maintains, and a set of referral habits that live in senior underwriters' heads. An automated underwriting system is supposed to make those three the same thing. In most carriers they drift apart quarter by quarter, and the underwriting queue absorbs the difference. That drift has a number attached: straight-through processing rate. Personal auto and home bind most clean risks without a human. Mid-market commercial rarely comes close, because a single risk carries far more variables - class code, total insured value, protection class, loss history, schedule credits - and every rule that handles them is another ticket in the PAS backlog. Submission-triage vendors commonly report that roughly a quarter of incoming submissions fall outside the carrier's own stated appetite and are still screened by hand. The risks that could have bound in seconds wait behind them. Then come the questions a spreadsheet cannot answer. Which version of the eligibility rules bound this policy last March? Who raised the TIV ceiling, who approved it, and what did it do to the referral mix? Supervisors now ask sharper versions of the same thing. The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers, adopted in December 2023 and issued in roughly half the states, expects a documented governance program covering underwriting and rating. NYDFS Circular Letter No. 7 (2024) expects New York insurers to test and document how automated underwriting and external consumer data affect protected classes. In the EU, AI systems used for risk assessment and pricing in life and health insurance sit in Annex III of the AI Act as high-risk. If your underwriting rules are a vendor config export and a folder of change-request emails, every one of those conversations is harder than it needs to be. _pas/rules/eligibility.java_`if (risk.tiv > 5_000_000` `|| risk.protectionClass > 4) {` `return refer("SENIOR_UW");``}` _appetite\_guide\_2026\_q3.xlsx_ classmax TIV restaurant5M habitational2M UW-3391**Auto-refer wildfire zone 3 above $2M**_PAS vendor queue · next release train_ one appetite · three sources of truth · underwriters guess ## Appetite in tables. Referrals with reasons. GoRules is the decision layer inside your underwriting flow: submission in, bind, refer, or decline out, with the rule that produced it named. _01_ ### Knockouts, appetite, and authority as one decision graph Underwriting is a sequence, not a single lookup, so model it as one. Hard knockouts run first as Policies, ordered blocks that stop a submission on a prohibited class code, a coverage you do not write, or a state you are not admitted in. The appetite matrix follows as a decision table: class code by total insured value by protection class on commercial property, or face amount by age band by build and nicotine status on life. Referral rules then compare the risk against the binding authority of the underwriter who owns it. ZEN expressions handle derived values like loss ratio, TIV per square foot, or years since the last large loss, and typed TypeScript function nodes cover anything custom. One structured decision comes back: bind, refer with a reason code and a routing target, or decline with grounds. _02_ ### Underwriting owns the rules, with a release trail Product and underwriting edit decision tables directly, and natural-language rendering makes each rule read like the appetite guide it replaces. [Git-like version control](/version-control) records who changed which threshold and when, approval workflows keep risk and compliance in the loop, and any release rolls back in one click. Dev, staging, and production stay separate environments, so a new wildfire referral threshold is proven against last quarter's submissions before a live quote ever sees it. _03_ ### Scores and third-party data stay inputs; the decision stays readable Hazard scores, MVR, MIB and prescription results, loss runs, telematics, and whatever your intake tooling extracts from ACORD forms and statements of values all arrive as plain inputs to the rules. The model estimates risk; the rule decides what to do about it. That separation is what lets you show an examiner a readable rule and a version number instead of a model output nobody can explain, and it gives the human oversight regulators expect something specific to review. ## Keep the PAS. Move the judgment. GoRules does not replace your policy administration system, your rating engine, or your underwriting workbench. It owns the decision those systems keep asking for. 01 ### Connect Your PAS, underwriting workbench, broker portal, or submission-intake service calls GoRules over REST, or embeds the MIT-licensed [open-source ZEN Engine](/open-source) in-process with SDKs for Node.js, Python, Java, Go, C#, and Rust. Carrier stacks are usually already on the JVM, so in-process evaluation is a normal option rather than a rewrite. 02 ### Model Rebuild the appetite guide as decision tables and graphs: knockouts, the appetite matrix, referral triggers, and authority limits each become a block you can point at in a review. Start from the [Insurance Underwriting Risk template](/templates) and the Policy Eligibility Analyzer rather than a blank canvas. 03 ### Simulate Replay last quarter's submissions through a branch before anything ships, and read the result in the numbers underwriting is measured on: straight-through rate, referral volume by trigger, and which risks change decision. Stakeholders review the diff in natural language, and promotion through environments records an approval at each step. 04 ### Operate Every evaluation returns the outcome plus the rules that fired, so a referral reaches the workbench with its reason attached and a decline carries its grounds. Watch straight-through rate, referral mix, and quote-to-bind weekly, and tune the tables instead of filing tickets. Roll back in one click if a change misbehaves. ## Built for production, not proof of concept. - Sub-millisecond evaluation with the open-source ZEN Engine (Rust core), fast enough to run appetite and eligibility inline in a quote-and-bind flow - Git-like version control on every underwriting ruleset: branches, commit history, approval workflows, one-click rollback - Self-host with Docker or Kubernetes so applicant medical data, loss runs, and PII stay inside your infrastructure, or run on GoRules Cloud - An audit trail an exam can follow: which ruleset version decided a submission, who changed the threshold, who approved it. SSO, role-based access, SOC 2 - No lock-in: the engine is open source under MIT with a Rust core, and [70+ templates](/templates), including Insurance Underwriting Risk and Policy Eligibility Analyzer, give you a working starting point ## Questions, answered. ### What is an automated underwriting system? An automated underwriting system evaluates an insurance application or submission against the carrier's underwriting rules and returns a decision - bind, refer to an underwriter, or decline - without a human touching the clean cases. It applies knockouts, the risk appetite matrix, referral triggers, and authority limits to data from the application and from third-party sources, in seconds instead of days. The term is also used in mortgage lending for systems like DU and LPA; in insurance it means the rules layer between submission intake and rating or binding. GoRules provides that layer as visual decision tables and graphs your underwriting team edits directly. ### What is the difference between an automated underwriting system and a policy administration system? A policy administration system owns the policy lifecycle: quoting, issuance, endorsements, renewals, and billing. An underwriting workbench owns the human's workspace: the queue, the documents, the notes. An automated underwriting system owns the decision itself - whether the risk is in appetite, whether it can bind straight through, and who it refers to when it cannot. GoRules replaces only that decision logic, which today usually sits hard-coded inside the PAS or in vendor configuration nobody outside the vendor can edit, and your existing systems call it over REST wherever a decision is needed. ### How do we raise straight-through processing rate without loosening appetite? Straight-through rate improves when referrals get more precise, not simply fewer. Make every referral name its trigger, then work the mix: referrals that fire on missing data belong back at intake, referrals that fire on thresholds nobody has revisited in three years belong in a review. In GoRules you branch the ruleset, replay historical submissions through both versions, and see exactly which risks change decision before anything reaches production. The largest gains usually come from segment-specific thresholds, because one global TIV or age cutoff pushes far more cases to a human than a set of tuned ones. ### How does automated insurance underwriting hold up in a market conduct exam? Every GoRules decision traces to the rules that fired and to the ruleset version that produced them, and every rule change records author, diff, approver, and timestamp. Those are the artifacts current supervision asks for: the NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers expects a documented governance program covering underwriting and rating, NYDFS Circular Letter No. 7 (2024) expects testing and documentation where automated underwriting and external consumer data are used, and the EU AI Act classifies life and health risk assessment as high-risk with logging and human-oversight duties. Keeping model scores as inputs and decisions as readable rules also gives that human oversight something specific to review. GoRules supplies the traceability; the obligations, testing, and filings remain yours. ### Can we self-host so applicant medical and claims data never leave our infrastructure? Yes. Deploy the platform with Docker or Kubernetes inside your own network, or embed the MIT-licensed ZEN Engine directly in your services so evaluation happens in-process and no applicant data crosses a vendor boundary. That matters most in life and health underwriting, where submissions carry medical records, prescription histories, and lab results. SSO and role-based access control govern who can view or change rules, and GoRules Cloud is available when managed hosting is acceptable. ## The same engine, next door. One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail. [**Insurance Quoting**The same rules, quote to bind](/use-cases/insurance-quoting)[**Fraud Detection**The same rules layer for claims and payments](/use-cases/fraud-detection)[**Loan Decisioning**The same decision layer for lending](/use-cases/loan-decisioning) ## Bind the clean risks. Refer the rest with reasons. Start from the Insurance Underwriting Risk template, replay last quarter's submissions through it, and see what your straight-through rate could be by the end of the week. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Transaction Monitoring Software You Control **URL:** https://gorules.io/use-cases/transaction-monitoring **Description:** Transaction monitoring software built on a rules engine your compliance team controls. Versioned AML rules, approvals, sub-millisecond real-time evaluation. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Transaction monitoring your compliance team actually controls. GoRules is the decisioning engine for AML transaction monitoring: your analysts author the scenarios as decision tables, every change is versioned and approved, and every transaction is evaluated in real time. No vendor ticket, no six-month release cycle, no black box. ## From noise to cases, start to finish. Watch a Thursday in a financial crime team: 214 open alerts at a 38 percent false positive rate, a delicatessen that trips the structuring scenario every night it banks its takings, a one-cell exclusion for KYC-verified cash-intensive customers, a replay over 12,400 alerts, a signed release - and a structuring ring that stays lit the whole way through. scroll to play Financial crime _/_ Link analysis live1.2 M transactions · 90 daysscenario **v9.2.4v9.3.0**JC **ATM 4471**cash deposit · Mon **Branch 018**cash deposit · Tue **ATM 4471**cash deposit · Wed **Branch 018**cash deposit · Thu **ATM 2210**cash deposit · Fri **Harbor Deli LLC**CUST-88231 · business_declared cash-intensive · verified__40 alerts · 90d__0 alerts · suppressed_ **•••4182**R. Vance · Mon **•••7730**L. Prieto · Mon **•••2265**K. Osei · Tue **•••9014**M. Duarte · Wed **•••5528**T. Iversen · Thu **•••8801**beneficiary · opened 19d_5 senders · 4 days__case opened · SAR draft_ ALERT-40 · Harbor Deli LLCCUST-88231 · cash structuring, 5-day window · opened 08:12 Alerts · 90 days**40** SARs filed**0** Dispositions**40 false positive** KYC profile**cash-intensive · verified** Every deposit in the $8,000 to $9,999 band alerts. The scenario never reads the KYC profile compliance verified in March. _suppressed · no alert_ 5 cash deposits from a customer KYC verified as cash-intensive. Scenario v9.3.0 records the reason against the account instead of opening a case. _escalated · case-2214_ 5 accounts moved $47,700 into •••8801 in 4 days. The alert stands, SAR draft started. _Alert queue_ **196**open oldest 21 daysclosing now _False positives_ **38%** SAR conversion 0.9%SAR conversion 6.2% **•••8801**$47,700_fan-in · 5 senders / 4 days**case opened** · SAR draft started_ **Harbor Deli**$9,600_cash structuring · 5d_ **Sunrise Laundry**$8,940_cash structuring · 5d_ **Harbor Deli**$9,150_cash structuring · 5d_ **Kwik Mart 22**$8,200_cash structuring · 5d_ 196 open alerts · 4 analysts · 90-day windowscenario v9.3.0 · analysts investigate crime, not noise #### AML scenarios - structuring Cash aggregation rules over a rolling 5-day window. Evaluated top-down on every posted transaction - first match decides. **Cash deposits**_5 days_**Amount band**_per deposit_**Customer profile**_kyc_**Alert****Severity** 1_at least_ **1**_at least_ **$10,000****File CTR****report** 2_at least_ **3****$8,000** _to_ **$9,999**_any customer__any customer, excluding_ **cash-intensive** _verified in_ **KYC****Alert****HIGH** 3_at least_ **5**_under_ **$8,000****High risk****Alert****MEDIUM** 4_Otherwise_**No alert**_\-_ + was: any customer · ATL/BTL replay required · edited by Head of Financial Crime 1 unsaved change_Run tests__Request review_ **Quality checks**_0 alerts replayed · 90 days_ Deli-type cash noise suppressed_61% fewer_ Every confirmed SAR case still alerts_0 missed_ Sanctions and watchlist rules untouched_unchanged_ ATL sample · no missed structuring above threshold_guardrail_ All checks passed · 0 noise alerts suppressed, 61% · 0 SAR cases missed _Release v9.3.0_ **v9.3.0**_draft_Jane Cooper · just now · cash band excludes verified cash-intensive JC **Jane Cooper**Head of Financial Crime _pending_ _development_**v9.3.0** deploying _staging_**v9.2.4** live _production_**v9.2.4** live Live in production - every posted transaction now scores against v9.3.0, and the open cash alerts on verified cash-intensive accounts close with the reason recorded. full diff + approval recorded · one-click rollback _Thursday, 08:40_ ### The queue opens at 214. Ninety days of cash movement draw into one link chart. Harbor Deli LLC banks its takings five nights a week, $8,200 to $9,600 a time, and every deposit trips the structuring scenario. _The case file_ ### The fortieth alert on the same account. Forty alerts in ninety days, forty dispositions, all of them false positive, zero SARs filed. KYC declared the deli cash-intensive and verified it in March. The scenario has never been able to see that. _One cell_ ### The scenario learns who was verified. The rule that fired opens the live scenario. On a branch, the $8,000 to $9,999 band now excludes customers KYC verified as cash-intensive. The CTR rule at $10,000 does not move. _Proof before production_ ### 12,400 alerts, replayed. Ninety days of alerts re-run against the draft while you watch: 61 percent of the cash noise disappears, every confirmed SAR case still alerts, and the below-the-line sample turns up no missed structuring. _Sign-off_ ### Financial crime approves. v9.3.0 ships. Jane Cooper signs the release, it promotes through staging to production with the full trail recorded. Rollback stays one click away. _Same morning_ ### 214 alerts down to 31. The amber badges on the deli deposits dissolve one by one and the false positive rate falls from 38 to 9 percent. The five accounts wiring $9,400 to $9,700 into the same beneficiary stay lit, and that alert becomes a case with a SAR draft attached. ## The least responsive system you depend on. If you run an AML program at a fintech, PSP, or bank, your transaction monitoring software is probably the least responsive system you depend on. Your team identifies a typology, drafts a scenario change, and then waits: on the vendor's professional services queue, on the next quarterly release, or on an engineering backlog where compliance tickets never win. In ComplyAdvantage's survey of 600 senior compliance decision makers, 41% named lack of rule flexibility among the main limitations of their detection programs. The output side is just as bad. Industry estimates commonly put false positive rates above 90% of alerts, which means analyst teams spend most of their time closing noise while SAR conversion rates stay flat. The usual cause is not mysterious: transaction monitoring solutions shipped with generic rule packs, one threshold applied across every customer segment, and no practical way to backtest a change before it floods the queue or, worse, silently stops catching reportable activity. Then an examiner asks a simple question: which rule version fired on this transaction last March, who changed that threshold, who approved it, and why? FFIEC examiners expect documented rule rationale and independent testing. NYDFS Part 504 requires New York regulated institutions to certify their transaction monitoring program annually, and a certifying officer signs personally. If your answer lives in a vendor's opaque config export and a folder of change-request emails, that conversation goes badly. ## Scenarios your analysts write. Governance examiners trust. The people accountable for the monitoring program should be the people who control the rules it runs on. _01_ ### Compliance authors the rules, in a form regulators can read In most AML transaction monitoring software the scenarios are configuration only the vendor understands. In GoRules they are visual decision tables and graphs, not code. A BSA analyst can add a velocity rule, tighten a structuring threshold per customer segment, or add a high-risk-jurisdiction condition using spreadsheet-style tables and ZEN expressions. Natural-language rendering turns every rule into plain English, so the same artifact serves the analyst writing it, the MLRO reviewing it, and the examiner reading it. _02_ ### Governance built in: versioning, approvals, environments Every rule change is captured in [git-like version control](/version-control) with author, timestamp, and full diff, protected by approval workflows and role-based access. Changes move through dev, staging, and production explicitly, and any release rolls back in one click. That is the audit trail examiners ask for: you can reproduce exactly which rule version evaluated any historical transaction and show who approved the change that got it there. _03_ ### Real-time evaluation, explainable by design The [open-source ZEN engine](/open-source) (Rust core, MIT licensed) embeds in Node.js, Python, Java, Go, C# or Rust and evaluates rules in under a millisecond, fast enough to sit inline on FedNow, RTP, and SEPA Instant flows where batch monitoring arrives too late to hold a payment. ML anomaly scores, screening results, and KYC risk ratings enter as inputs to rules, so the final decision stays a human-readable rule outcome you can defend, not a black-box score you cannot. ## The decisioning layer of your monitoring stack. GoRules pairs with your data pipeline, screening provider, ML models, and case management - it does not replace them. 01 ### Model your scenarios Recreate the rule set from your current transaction monitoring system as decision tables: single-transaction rules, aggregate and velocity rules over time windows, behavioral deviation rules, and risk-pattern typologies like structuring or rapid in-out movement. Start from the [financial services templates](/industries/financial) and set thresholds per customer risk segment instead of one global value. 02 ### Connect your inputs Each evaluation receives the transaction plus whatever context your rules need: the customer's KYC/CDD risk rating, sanctions and watchlist screening results from your screening provider, account history aggregates from your data pipeline, and ML risk scores if you run models. Feature platforms such as [Chalk](https://chalk.ai) or [Tecton](https://www.tecton.ai) are natural companions here: they compute the velocity aggregates and risk signals in real time, and GoRules decides on them. 03 ### Test, approve, promote Run proposed changes against historical transaction samples to see alert volume impact before anyone in production feels it, the same way ATL/BTL tuning exercises probe thresholds above and below current settings. When the numbers look right, the change goes through approval and is promoted from staging to production with the full trail recorded. 04 ### Evaluate in real time and route alerts Embed the engine in your payment path for sub-millisecond decisions, or call the REST API from your core system. Rule outcomes carry severity and reason fields your case management system consumes for triage, and your team keeps tuning: review alert dispositions, adjust thresholds per segment, watch SAR conversion rather than raw alert count. ## Built for production, not proof of concept. - Sub-millisecond rule evaluation with the embedded open-source ZEN engine (Rust core), suitable for inline monitoring on instant payment rails - Full audit trail: every rule change versioned with author and diff, approval workflows with role-based access, one-click rollback - Reproducibility: pin and retrieve the exact rule version that evaluated any historical transaction - Deploy anywhere: self-hosted via Docker or Kubernetes for data residency and vendor risk requirements, or GoRules Cloud; SSO, RBAC, SOC 2 - Rules stay explainable with ML in the loop: model scores are inputs, decisions are readable rules rendered in natural language ## Questions, answered. ### What is transaction monitoring? Transaction monitoring is the ongoing analysis of customer transactions to detect activity that may indicate money laundering, terrorist financing, or fraud. Transaction monitoring software evaluates each transaction, or batches of them, against rules and scenarios, generates alerts for suspicious patterns, and feeds investigations that can end in a SAR filing. It is a core obligation under BSA/FinCEN requirements in the US and Article 26 of the EU's AMLR (Regulation 2024/1624, applying from 10 July 2027), and the FATF risk-based approach expects monitoring intensity to match customer and product risk. ### What is the difference between transaction screening and transaction monitoring? Screening matches the parties to a transaction against sanctions, PEP, and watchlists before or as it executes. Monitoring analyzes transaction behavior over time to find suspicious patterns. AML screening and monitoring are separate controls that work together, and in GoRules your screening provider's match results simply arrive as inputs your monitoring rules can act on. ### What are examples of AML transaction monitoring rules? Common scenarios include structuring (multiple cash deposits just under the $10,000 CTR threshold within 72 hours), velocity rules (transaction count or volume in 24 hours far above the customer's segment baseline), rapid in-out movement (withdrawal of 90%+ of a deposit within a day), transfers involving high-risk jurisdictions combined with amount deviation, and dormant accounts reactivating with large transfers. In GoRules each of these is a decision table your compliance team can read and edit, with thresholds set per customer risk segment. ### How does real-time transaction monitoring work for instant payments? On rails like FedNow, RTP, and SEPA Instant, settlement happens in seconds, so monitoring must run inline in the payment path before funds move, not in an overnight batch. The embedded ZEN engine evaluates rules in under a millisecond per decision, which leaves your latency budget for data lookups and screening calls. The same rule set can serve as the decision core of a payment monitoring system across cards, ACH, and instant rails. ### Is GoRules a complete AML compliance platform? No, and that is deliberate. GoRules is the rules engine and rule governance layer: scenario authoring, testing, versioning, approvals, and real-time evaluation. You pair it with your data pipeline, a screening data provider, your ML models if you use them, and case management for investigations. It supports the audit trail and change governance regulators expect, but compliance is a property of your program, not of any software. ## The same engine, next door. One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail. [**Credit Decisioning**Policy above your ML models](/use-cases/credit-decisioning)[**Loan Decisioning**Application to priced decision](/use-cases/loan-decisioning)[**Financial Services**Templates and industry solutions](/industries/financial) ## Your scenarios. Your thresholds. Your audit trail. Put transaction monitoring rules in the hands of the team accountable for them, with the governance to prove every change. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Rules Engine for Retail & E-commerce **URL:** https://gorules.io/use-cases/retail-ecommerce **Description:** One rules engine for retail and e-commerce decisions: dynamic pricing, promotions, loyalty, and commissions as decision tables your business teams edit and version. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # The rules engine for retail & e-commerce. Pricing, promotions, loyalty, and commissions look like four systems and behave like one decision: read the context, apply the rules the business agreed on, return a number somebody can explain. Pick the one that is costing you now. ## Your margin lives in four different tools. Every commerce team ends up with the same sprawl. A repricing script in the platform, a promo console from a vendor, an earn-rate sheet in finance, a comp plan in a PDF. Nobody can see the whole number a customer moves through. **Commerce platform** A repricing job, a checkout hook, a plugin, an ERP condition table. Changing one rule means a ticket, a sprint, and a release window. **Spreadsheets** Category margin floors, promo stacking limits, earn rates, tier thresholds. Correct on somebody's laptop, copied into production by hand. **Vendor consoles** A promo tool, a loyalty SaaS, a commission app. Each with its own rule syntax, its own audit trail, and no view of the others. four owners · four release cycles · one basket ## Four decisions, four policies. Each one runs as its own versioned policy with its own owner and its own release cadence. Start with the one that hurts, then add the rest on the engine you already trust. [_Decides the shelf price_ ### Dynamic pricing Strategy tables per category and segment, then a guardrail policy that can only narrow the result: margin floors, daily move caps, key-line locks, contract minimums. _Example_SKU-4471 sits 2.0% above market with 14 days of cover. The audio table proposes +3.5%, the 22% margin floor passes at 28.4%, the price publishes at $133.99 with all four rules attached. See the pricing policy](/use-cases/dynamic-pricing) [_Decides what comes off the cart_ ### Promotion engine Discounts, codes, bundles, and campaign windows as decision tables, stacked in a fixed order with caps, exclusions, and a simulated cost before anything goes live. _Example_A $180 basket arrives with gold tier and code SUMMER24. The codes do not stack, the better rule wins at 20%, free shipping attaches, and the campaign ships without a deploy. Try the live promo policy](/use-cases/promotion-engine) [_Decides what the member earns_ ### Loyalty engine Earn rates, burn rules, tier thresholds, and campaign multipliers your CRM team edits directly, with exclusions and channel bonuses in the same table. _Example_Gold member, $189 beauty basket in the app, $25 gift card excluded. Earn runs at 3x on eligible spend: 492 points, tier progress $1,284 of $1,500. See the loyalty policy](/use-cases/loyalty-engine) [_Decides what the seller gets paid_ ### Commission calculation Marketplace take rates, vendor rebates, store bonuses, and sales comp run the same tier-and-accelerator math, versioned so a disputed payout can be replayed exactly. _Example_A rep closes at 118% of quota on a 24-month new logo. 12% on the $67,200 credited, 1.25x kicker, $10,080 payable with a 90-day clawback window on the record. See the payout policy](/use-cases/commission-calculation) ## One decision layer under all four. The same tables, the same test runs, the same approvals. The second policy takes a fraction of the time the first one did, because the integration is already there. **One engine** All four policies evaluate on the same MIT-licensed ZEN engine with a Rust core, embedded in your storefront service or called over REST, in well under a millisecond. **Tables, not tickets** Pricing, trade marketing, CRM, and sales ops each own their own tables and edit them in the browser. Engineering integrates the decision layer once. **Versioned releases** Branches, test runs on real baskets, approvals, and one-click rollback. A campaign change becomes a release with a name on it instead of a hotfix. Retail teams usually pair these with [fraud detection](/use-cases/fraud-detection) on the order, all on the same [decision engine](/solutions/decision-engine). Browse the full [use-case library](/use-cases). ## Start with the one that is costing you. Model your repricing sheet or promo matrix as a decision table this afternoon, replay last month's baskets, and see the number before anything reaches a storefront. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Insurance Solution: Real-Time Quotation - GoRules **URL:** https://gorules.io/use-cases/real-time-quotation **Description:** Get real-time, personalized insurance quotes and pricing. Find the perfect coverage for you with our quick and easy online quotation system. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # A quote in milliseconds, straight from your rules. Rate every applicant against your underwriting criteria in real time - premium, tax, and fees priced consistently on every channel, with a trace behind every number. _POST /evaluate/commercial-quote_ generalLiability: $2,000,000commercialProperty: $500,000professionalIndemnity: $5,000,000 liability = $2Mbase 1,150.00property +8%indemnity +12%quote ready Premium_$1,187.50_ Tax_$142.50_ Payment fee_$9.95_ Total_$1,339.95_ decision in 0.6 ms ## Rating tables the underwriters own. Rates, loadings, and fees live in decision tables the pricing team reads and edits directly - reviewed, versioned, and released without a code change. - Underwriters edit rates directly - Identical quotes on every channel - Referral rules for edge cases - Every quote traceable **Commercial rating**_v1.8.0 · production_ coveragelimitrate General liability$1,000,000$850.00 General liability$2,000,000$1,150.00 General liability$5,000,000$1,600.00 Commercial property$500,000+8% Professional indemnity$5,000,000+12% Commercial property**$2,000,000**+14% ## Fast for the many. Careful with the few. Clear risks quote instantly. Anything outside appetite routes to an underwriter with full context - the same policy decides which is which. ### Refer the edge cases. Switch rules route high exposure to a human before a number goes out. [Explore switch rules](/components/switch) exposure > $8M _refer to underwriter_otherwise instant quote _MW_ **Marcus Webb Consulting**_exposure $9.5M · referred_ with underwriting Everything else quotes instantly. ### One rate, every channel. Web, broker, call center, and API quote from the same release - no drift between systems. [Explore environments](/environments) **Web checkout**_$1,339.95_ **Broker portal**_$1,339.95_ **Call center**_$1,339.95_ **Partner API**_$1,339.95_ One release answers everywhere. ## Quote while they're still on the page. Start free on GoRules Cloud, or bring a rating sheet and we'll show it quoting in real time. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Promotion Engine for Discounts and Offers **URL:** https://gorules.io/use-cases/promotion-engine **Description:** A promotion engine where discounts, promo codes, stacking rules, exclusions, and margin floors are decision tables your commercial team edits directly - simulated against real carts, versioned, and live on every channel the same day. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # 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 _F_FieldhouseBagDeliveryPaymentorder #A-40219 · web **Your bag**3 items · ships free over $75 **Trailblazer 7 running shoes**Footwear · size 9 · black _SUMMER24 · -20%_ $129.00**$129.00** **Ridgeline insulated jacket**Apparel · size M · slate_CLEARANCE__markdown · -$60.00_ _SUMMER24 · -20% again_ $149.00**$89.00** **Gift card**Digital delivery · e-mail _never discounted_ **$50.00** **Applied**SUMMER24 · 20% off sitewide _Order summary_ Subtotal_$328.00_ Clearance markdown_Ridgeline jacket__\-$60.00_ Promotions_no code applied__$0.00_ SUMMER24 · 20% off_full-price lines__\-$25.80_ SUMMER24 · 20% on clearance_stacked on the markdown__\-$17.80_ Shipping_Free_ Total_$268.00_ _margin · clearance line_**16.7%** code stacks with markdowns - policy has no exclusionclearance excluded · sells at $89.00 on $74.15 cost **Where this policy runs**one ruleset · three channels **Web**rules v6.1.4 live · v6.2.0 **App**rules v6.1.4 live · v6.2.0 **POS**rules v6.1.4 live · v6.2.0 gift cards - always excluded, on every channel _Campaigns live_ **9** 3 queued behind the platform release3 launched this hour 18,200 orders in the last 30 days · web, app, and POS on one policyrules v6.2.0 · one policy, every channel, same hour #### Promotion rules - SUMMER24 Discount and stacking rules for the summer campaign. Evaluated top-down on every cart line - first match decides. **Item category****Already discounted****Code****Discount****Stacking** 1**Gift cards**_any__none__never_ 2**Footwear, apparel****Yes****SUMMER24****20%** _off line__stacks with_ **markdowns**_excluded -_ **clearance and markdowns** 3**Footwear, apparel****No****SUMMER24****20%** _off line__stacks with_ **free shipping** 4_Otherwise__none__\-_ + was stacks with markdowns · gift-card guardrail unchanged · edited by Head of Growth 1 unsaved change_Run tests__Request review_ **Quality checks**_0 orders replayed_ Clearance lines no longer take SUMMER24_was: stacked_ Full-price carts keep the 20% off_unchanged_ Gift cards discount by nothing on any code_guardrail_ Clearance margin back above the floor_+2.3pt_ All checks passed · 0 clearance carts re-price · margin +2.3pt · 0 full-price carts changed _Release v6.2.0_ **v6.2.0**_draft_Jane Cooper · just now · SUMMER24 excluded on markdowns JC **Jane Cooper**Head of Growth _pending_ _development_**v6.2.0** deploying _staging_**v6.1.4** live _production_**v6.1.4** live Live in production - web checkout, the app, and every POS lane price the next cart against v6.2.0, with no platform release in between. full diff + approval recorded · one-click rollback _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. Raise SUMMER24 to 25%Reward gold tier from $150Boost bulk orders to 15% **Promotion policy**_v2.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** $130 · code SUMMER24$180 · gold tier$340 · bulk order$85 · new customer Subtotal_$130.00_ Campaign SUMMER24_\-$26.00_ Shipping_Free_ 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. _commerce-platform · promotions.config.ts_`discounts.push({ code: "SUMMER24",` `type: "percentage", value: 20,` `combinesWith: ["order", "shipping"] });` _q3\_campaign\_calendar.xlsx_ campaigndiscount SUMMER24 sitewide20% clearance event40% PROMO-412**Exclude clearance from sitewide codes**_blocked on platform release · commerce backlog_ one code · three systems · no exclusion anywhere ## 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](/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](/open-source) 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](/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 Pricing**The same decision layer for price](/use-cases/dynamic-pricing)[**Loyalty Engine**Earn rates, burn rules, and tiers](/use-cases/loyalty-engine)[**Retail and E-commerce**Every commerce decision, one layer](/use-cases/retail-ecommerce) ## 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](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Loyalty Engine for Earn, Burn and Tiers **URL:** https://gorules.io/use-cases/loyalty-engine **Description:** A loyalty engine where earn rates, burn rules, tiers, and campaign multipliers are decision tables your CRM team edits directly, versioned and live the same day. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # A loyalty engine your CRM team can edit. Earn rates, burn rules, tier thresholds, and campaign multipliers live in visual decision tables instead of your commerce platform's checkout code. Your CRM team edits the rules, replays real baskets to see the accrual impact, and ships the change the same day with approvals on the record. ## From tier-down list to retained, same day. Watch a Monday in a CRM team: 412 Gold members flagged to tier down, a one-cell change to the save window, a replay over 3,180 historical tier-downs, a signed release - and a membership card that updates itself before the member notices it was ever at risk. scroll to play _Gold at risk_**412**of 8,940 Gold · nightly run 08:15 tier-down in 30d 412 retained · 2x window 0 inactive 180d · no offer 1 8,940 Gold members evaluated in 1.9 s · tier rules v2.5.2tier-down queued by policy v2.5.2 · the save offer carries no incentive - open in GoRules to see whypolicy v2.6.0 · saves went out same day **Wallet**_3 passes_ **Solara Rewards**_GOLD_ _Points balance_**12,400**pts C. MENSAH_MEMBER M-41706 · SINCE MAR 2021_ _2x points · 30 day window_ _12,400 points expire in 30 days_ _expiry extended · 12,400 pts held to 31 Dec_ Gold retention _review 30 Sep_**380 short****380 short** **11,620** qualifying pointskeep Gold at 12,000 **No recent activity**last purchase 41 days ago _+0 pts_ **Purchase · Solara Store**$210.00 · 640 base × 2.0x save window _+1,280 pts_ **Points expiring**12,400 pts · earned Oct 2024 _in 30 days__held to 31 Dec_ **Tier review**Gold · qualifying window closes _30 Sep_ _Save campaign · sent 6 days ago_ **Your Gold status ends soon**Solara Rewards · to c.mensah@… _unopened_ Hi C., your Gold benefits end on 30 September. Keep shopping to keep your tier. _41,800 sent · 11% open rate · 0.6% click_no offer attached _CM_ **C. Mensah**Pass details · M-41706 · Gold since Mar 2021 _tier-down in 30d__retained · 2x applied_ _Your year with Solara_ **380**qualifying points short 11,620 of 12,000 · window closes 30 Sep Lifetime spend**$18,240** Spend · 90 days**$630 · was $1,180** Orders · 90 days**2 · was 7** _Spend · last 6 months_ Last purchase**41 days ago** Emails opened · 12 mo**1 of 14** Save offer**sent · no incentive****2x for 30 days** #### Tier rules Retention and earn rules for the Gold and Platinum program. Evaluated nightly for every member - first match decides. **Tier****Spend · 90 days****Points expiring****Action****Earn multiplier**_save window_ 1_is_ **Platinum****Hold tier****1.0x** 2_is_ **Gold**_below_ **$750**_at least_ **5,000****Save offer****1.0x****2.0x** _for_ **30** _days_ 3_is_ **Gold**_at least_ **$750****Hold tier****1.0x** 4_Otherwise_**Tier down****1.0x** + was 1.0x · save window only · Platinum untouched · edited by Head of CRM 1 unsaved change_Run tests__Request review_ **Quality checks**_0 tier-downs replayed_ Gold with points expiring earns 2x for 30 days_was: 1.0x_ 64% of replayed tier-downs re-engage_modeled_ Cost per retained member $8.40, cap $12_budget_ Platinum thresholds and earn caps untouched_guardrail_ All checks passed · 0 members projected retained · $8.40 each _Release v2.6.0_ **v2.6.0**_draft_Priya Shah · just now · save window earn 1.0x → 2.0x PS **Priya Shah**Head of CRM _pending_ _development_**v2.6.0** deploying _staging_**v2.5.2** live _production_**v2.5.2** live Live in production - every Gold member inside the save window now earns 2x, and tonight's tier-down run re-evaluates against v2.6.0. full diff + approval recorded · one-click rollback _Monday, 08:15_ ### 412 Gold members are on their way out. The nightly run flags every Gold member short of the retention threshold. M-41706 is 380 qualifying points short, with 12,400 points expiring in 30 days. _The member_ ### Four years Gold. Short by 380 points. C. Mensah has spent $18,240 with the program, $630 of it in the last 90 days, down from $1,180. The save email goes out with nothing in it. _One cell_ ### The head of CRM gives the save offer teeth. The failing rule opens the live tier rules. For Gold with points expiring, earn goes from 1.0x to 2.0x for a 30 day window - on a branch, Platinum untouched. _Proof before production_ ### 3,180 tier-downs replay. Last quarter's tier-downs re-run against the draft while you watch: 64 percent re-engage at the historical save-offer response, at $8.40 per retained member against a $12 cap. _Sign-off_ ### CRM approves. v2.6.0 ships. Priya Shah signs the release, it promotes through staging to production with the full trail recorded. Rollback stays one click away. _Same day_ ### The pass updates itself. C. Mensah spends $210 at 2x, clears 12,000 qualifying points and keeps Gold. Gold at risk goes from 412 to 96 - except the member who has been quiet for 180 days. ## The program is marketing's. The rules are engineering's. A loyalty engine is supposed to be the one place earn, burn, and tier rules live. In most retailers it is three places at once: accrual logic inside the commerce platform's checkout code, a redemption service someone wrote for the app, and a spreadsheet of campaign multipliers the CRM team keeps for the quarter. So a double points weekend is a deploy, a category boost is a ticket, and the person accountable for the program cannot change the rules the program runs on. Both of the usual escapes cost more than the problem. Build the logic into the commerce platform and it belongs to one channel: POS, app, call center, and partner sites either duplicate the rules or go without them, and they drift within a quarter. Buy a monolithic loyalty suite and the engine arrives bundled with a member database, a rewards catalog, a portal, and a messaging tool you already have, plus a replatforming project and a vendor queue standing between your team and every threshold change. Then finance asks questions the code cannot answer. Points issued are a balance-sheet obligation: under IFRS 15 and ASC 606 unredeemed points are deferred revenue, and the breakage estimate behind them has to be supportable. Which rule version awarded the points on this quarter's accrual? Who approved the 5x weekend? Which basket lines counted toward tier and which were excluded? When the answers live in a checkout service and someone's spreadsheet, every campaign post-mortem, every audit, and every replatform starts with archaeology. _checkout/loyalty/accrual.ts_`if (member.tier === "GOLD" && line.cat === "beauty") {` `points += Math.floor(line.net * 3);``}` _q4\_multiplier\_calendar.xlsx_ campaignmultiplier double points wknd2x app exclusive1.5x LOY-864**Stop gift cards earning tier credit**_Q4 release train · commerce backlog_ one program · three systems · no single source of truth ## Program logic out of the checkout path. GoRules is the decision layer of your loyalty stack: transaction in, points and tier movement out, every rule readable by the people who own the program. _01_ ### Earn, burn, and exclusions as decision tables Accrual is naturally a matrix: member tier by product category by channel by campaign window, resolving to an earn rate and whether that spend counts toward tier. GoRules decision tables are that matrix, edited spreadsheet-style. Rows evaluate top to bottom under the first-hit policy, so exclusions like gift cards, shipping, tax, and returned lines sit above the rates and win by position. Burn is the mirror table: redemption eligibility, point value, minimum balance, blackout windows, and partial-pay limits. ZEN expressions handle rolling-window math such as trailing 12-month qualifying spend, and typed TypeScript function nodes cover anything custom. _02_ ### Tier progression you can retune without a migration Model qualification as a Policy, an ordered set of blocks: the qualification window (calendar year, rolling 12 months, or anniversary), what counts as qualifying spend, the threshold per tier, and the downgrade rule, including soft landings where a member drops one level instead of falling to base. Natural-language rendering turns each rule into a sentence the program manager, the finance partner, and the member-services agent all read the same way, which matters the day someone calls to ask why they lost Gold. _03_ ### Campaign overlays without a release train A double points weekend, an app-exclusive 1.5x, a category boost on slow-moving stock: each is a branch on the live program, not a change to checkout. [Git-like version control](/version-control) gives every campaign its own history, approval workflow, and one-click rollback, and the simulator replays real baskets through the change so you see points issued and tier movements before members do. ## Keep the ledger. Move the rules. Your commerce platform still takes the order and your loyalty ledger still holds balances. GoRules owns the decisions between them. 01 ### Connect Checkout, POS, the mobile app, and your CRM call GoRules over REST at accrual and at redemption, or you embed the MIT-licensed [open-source ZEN Engine](/open-source) in the service that owns the points ledger, 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 program as tables and graphs: the earn matrix, the exclusion rows above it, tier qualification and downgrade, and the burn rules that price a redemption. Member attributes, basket lines, channel, and campaign flags arrive as plain inputs, so the outcome stays deterministic and reviewable. 03 ### Simulate Branch a change and replay last quarter's transactions through both versions. Compare points issued, tier upgrades and downgrades, and projected liability before anything reaches a member, then trace any single basket through every node that touched it. 04 ### Operate Promote through dev, staging, and production with an approval recorded at each step. Every accrual returns the rules that fired, so member services can explain a balance 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 show earned points before the customer confirms the order - Git-like version control on the program: a branch per campaign, full commit history, approval workflows, and one-click rollback when a multiplier misfires - Self-host with Docker or Kubernetes so member profiles and transaction data stay in your infrastructure and inside your data-residency scope, or run on GoRules Cloud - Every accrual, redemption, and tier movement traces to the rules that fired, and every rule change records who changed what and when. SSO, RBAC, and SOC 2 - No lock-in: the core engine is open source under MIT, and [70+ industry templates](/templates), retail among them, give your program a working starting point instead of a blank canvas ## Questions, answered. ### What is a loyalty engine? A loyalty engine is the rules layer of a loyalty program: the component that decides what a transaction earns, whether that spend counts toward tier, which tier a member holds, and what a redemption costs. It is separate from the member-facing program, the points ledger that stores balances, and the catalog that fulfills rewards. Most engines ship as configuration buried inside a larger suite or as code inside the commerce platform, which is why earn-rate and threshold changes usually mean a vendor ticket or a release. GoRules provides the engine on its own, as visual decision tables and graphs your CRM team edits directly, called over REST or embedded in your service. ### What is the difference between a loyalty engine and a loyalty platform? A loyalty platform is the whole product: member database, points ledger, rewards catalog, member portal, campaign messaging, analytics, and an engine somewhere inside it. The engine is only the decision part, and it is the part that changes weekly. Buying the platform to get the engine means a replatforming project and a vendor between your team and every threshold change, while building the engine into your commerce platform ties the rules to one channel. GoRules replaces the engine and nothing else, so your ledger, catalog, CDP, and commerce platform stay where they are. ### Can our CRM team change earn rates and tier thresholds without an engineering release? Yes. The earn matrix, exclusion rows, tier thresholds, and campaign multipliers 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 basket earned what it earned. 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 campaign multipliers from stacking into runaway accrual? 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 rates cannot be overridden by a campaign below it, and a campaign row placed above the tier defaults replaces them rather than compounding with them. Where a program genuinely does stack, a collect-policy table returns every match and a capping rule bounds the total, for example a points ceiling per basket or per member per month. Before any of it ships, replay historical baskets through the change and compare points issued against the current program. ### How does GoRules support points liability reporting and audits? Unredeemed points are deferred revenue under IFRS 15 and ASC 606, and the breakage assumption behind them has to be supportable, so finance needs to know precisely which rules issued which points. Every evaluation returns the rules that fired, every rule change is versioned with author, timestamp, and diff, and every release is a numbered snapshot you can point at when reconstructing a period. You can also simulate a proposed change against historical transactions to see the accrual impact before it reaches the balance sheet. GoRules supplies the traceability; the accounting judgments and reporting obligations remain yours. ## The same engine, next door. One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail. [**Promotion Engine**Discounts, stacking, and margin floors](/use-cases/promotion-engine)[**Dynamic Pricing**The same decision layer for price](/use-cases/dynamic-pricing)[**Commission Calculation**Tiers and accelerators for payouts](/use-cases/commission-calculation) ## Change the multiplier. Not the release train. Model your earn matrix and tier thresholds in the visual editor today, or send us the accrual rules you run now and we will show them back as decision tables. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Loan Origination Software: The Decision Layer **URL:** https://gorules.io/use-cases/loan-origination **Description:** Keep your loan origination software. Move underwriting overlays, stipulations, and pricing into visual decision tables your credit team owns and versions. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Loan origination software moves the file. GoRules decides. GoRules is not a loan origination system. It is the decision layer inside the one you already run: knockouts, overlays on your AUS findings, affordability, stipulations, and pricing modeled as visual decision tables your credit team edits, evaluated in milliseconds with every rule that fired attached. ## From stipulation to waiver, start to finish. Watch six days of one loan from the borrower side: a paystub the bank feed already proved, a one-cell change to the documentation policy, a replay across 3,400 funded loans, a signed release - and 2.3 days off time to close. scroll to play 09:41 **Northbridge Lending**_NH_ **Hi Nadia** _Home improvement loan_ **$38,400**60 months · 9.4% APR est. LN-4471 · applied 4 Aug · fixed rate _Application status_3 of 6 complete **Applied**_Day 1 · 09:12_ **Identity verified**_Day 1 · 09:20_ **Income - bank-linked**_Day 1 · 09:34_ $7,180 / mo verified · employer exact match _24 mo_ verified income: $7,180/mo **Documents**_requested day 2_ **Upload a recent paystub**Last 2 pay periods · PDF or photo _Upload__Day 6_ Requested**day 2 · 10:40** Reviewed in**up to 2 business days** **Already verified from your bank**$7,180 / mo payroll deposits · employer match · 1.8% variance Held by lender policy: a paystub is required from every borrower. Waived - income bank-verified **Review**_Day 6 · 16:12_ Starts once documents are completeApproved · decided by policy v5.2.0 **Funding** ACH to account ····4192Scheduled · Tuesday 09:00 · ····4192 _Northbridge Lendingnow_**Action needed: proof of income**Upload a recent paystub to continue. _Northbridge Lendingnow_**Approved - funds Tuesday**policy v5.2.0 - 2.3 days faster **Approved - funds Tuesday**$38,400 · 60 months · 9.4% APR_income bank-verified · policy v5.2.0_ _same policy · other borrowers_ **34**waiting on paper _EV_ **E. Vasquez**$21,500 Documents · day 4Underwriting _HY_ **H. Yildirim**$31,900 Documents · day 2Clear to close _BO_ **B. Okonkwo**$46,700 Documents · day 8 _still held · income mismatch - 12%_ _DK_ **D. Kimura**$18,200 Documents · day 1Conditional approval time to close**11.2d**2.3d faster #### Documentation policy Required borrower documents by income source. Evaluated at verification on every file - first match decides. **Income source****Loan amount****Risk band****Required docs** 1**Bank-linked payroll**_at most_ **$50,000****A** _or_ **B****Paystub · last 2****None · waived** 2**Bank-linked payroll**_more than_ **$50,000**_any_**Paystub · last 2** 3**Self-employed**_any__any_**Tax returns · 2 yr** 4_Otherwise_**Full doc set** + was Paystub · last 2 · mismatch guardrail unchanged · edited by Head of Credit Ops 1 unsaved change_Run tests__Request review_ **Quality checks**_0 funded loans replayed_ Bank-verified under $50k skips the paystub stip_41% of files_ Income mismatch above 5% still asks for docs_guardrail_ Self-employed income keeps tax returns_unchanged_ Fraud and identity checks unaffected_ok_ All checks passed · 0% skip the stip · 0 with income mismatch over 5% _Release v5.2.0_ **v5.2.0**_draft_Priya Shah · just now · paystub stip → waived under $50k PS **Priya Shah**Head of Credit Ops _pending_ _development_**v5.2.0** deploying _staging_**v5.1.3** live _production_**v5.1.3** live Live in production - every file at verification now decides against v5.2.0, and open paystub stipulations re-evaluate automatically. full diff + approval recorded · one-click rollback _Day 6, 09:41_ ### She is waiting on a piece of paper. Nadia Haddad asked for $38,400 of home improvement credit. Identity cleared, payroll linked, income verified from the bank feed on day one. The app still wants a paystub - and thirty-four other borrowers are stuck on the same screen. _The requirement_ ### Income verified. Still asking for paper. The bank feed matches the employer exactly, 24 months of deposits, 1.8% variance against stated income. One open stipulation holds the loan: proof of income, awaiting upload. _One cell_ ### The stipulation becomes a waiver. The blocking rule opens the live documentation policy. For bank-verified income under $50,000 in risk band A or B, required docs go from a paystub to none - on a branch, every other income source untouched. _Proof before production_ ### 3,400 funded loans replay. A year of funded files re-runs against the draft while you watch: 41% would have skipped the stipulation, none of them with an income mismatch above 5%, fraud and identity checks unaffected. _Sign-off_ ### Credit Ops approves. v5.2.0 ships. Priya Shah signs the release, it promotes through staging to production with the full trail recorded. Rollback stays one click away. _Same day, 16:20_ ### The upload request disappears. Open paystub stipulations re-evaluate: Nadia sees approved, funds Tuesday, and 23 other borrowers move the same day - except the one whose bank income misses stated by 12%. Time to close: 11.2 days down to 8.9. ## The workflow is bought. The decisions are welded in. Loan origination software is sold as one system for the whole pre-funding lifecycle: application intake, document collection, verification, underwriting, credit decision, quality control, closing, and funding. Most platforms do that job well, and the file has to live somewhere. The part that ages badly is the decisioning inside it: score floors, DTI caps, lender overlays stacked on top of Desktop Underwriter and Loan Product Advisor findings, reserve and documentation requirements, stipulation logic, counteroffer terms, and referral routing. That policy is either hard-coded in a platform your credit team cannot open or held as vendor configuration only the vendor understands. So the change nobody argues about takes a quarter to ship. Moving a DTI overlay two points, adding a reserve requirement for a new investor, or routing self-employed income to manual review becomes a professional services ticket, a change-order fee, and a release window. While that request sits in a queue the policy is already live somewhere else: a spreadsheet the credit team maintains and an email chain of approved exceptions, which quietly become the real system of record and are invisible to leadership and audit alike. The market answer is to replace the whole platform. Almost every ranked comparison of loan origination systems is published by a vendor that puts itself at the top, and the migration on offer runs six to eighteen months of re-implementation and parallel running across ops, underwriting, and servicing. That is a rip-and-replace to solve what is really a rules problem. Nothing about your intake, e-sign, or funding flow needed to change. And the questions that follow a decision do not care which vendor you picked. Which policy version declined this application in March, who approved that threshold, and what were the specific principal reasons? Regulation B requires principal reasons that are both specific and accurate, and CFPB Circular 2023-03 is explicit that algorithmic complexity is no excuse for vague ones. _los/custom/underwriting\_overlay.js_`if (aus.finding === 'Approve/Eligible'` `&& borrower.dti > 0.43) {` `return refer('OVERLAY_DTI');``}` _overlay\_matrix\_q3.xlsx_ overlayvalue dti\_cap0.43 min\_reserves2 mo LOS-3092**Raise DTI overlay to 0.45 for FICO 700+**_change order · vendor PS queue · 6 weeks_ one overlay · three owners · a change order to move it ## Keep your LOS. Upgrade the decisions. GoRules is not a loan origination system and has no ambition to become one. It owns the decision points your LOS calls, and nothing else. _01_ ### Every decision point in origination, in one graph Prequalification and eligibility, knockout screens, overlays on top of the AUS finding, affordability math, collateral and LTV limits, stipulations, counteroffer terms, exception routing, and the pre-funding quality control checks are all decisions, and they are all modeled the same way. Decision tables carry the matrices, ZEN expressions handle derived values like DTI and residual income, and typed TypeScript function nodes cover anything custom. One call returns one structured result: outcome, price, stipulations, reason codes, and the queue to route to. _02_ ### Loan underwriting rules the credit team actually edits Loan underwriting policy is a matrix, and a decision table is that matrix, edited by credit and risk without an engineering release. Natural-language rendering makes each row read like the credit policy document, so the analyst writing it, the officer approving it, and the examiner reading it look at the same artifact. GoRules AI can draft a rule change, run the test suite, and explain why a file decisioned the way it did; it never releases anything. [Git-like version control](/version-control), approval workflows, and one-click rollback mean risk signs off before production sees a change. _03_ ### Beside your LOS, not on top of it Your LOS keeps owning the application, the documents, the disclosures, and the funding instruction. It calls GoRules over REST wherever a decision is needed, or your own service embeds the MIT-licensed [open-source ZEN engine](/open-source) and evaluates in-process. The payload is the loan file you already model, with bureau attributes, income calculations, AUS findings, and model scores arriving as plain inputs, so the outcome stays deterministic and readable even when a score is not. ## Four weeks, not four quarters. No data migration, no parallel run, no retraining your closers. The system of record does not move. 01 ### Connect at the decision points Map where your origination flow already asks a question: prequalification at the point of sale, the credit decision after verification, stipulation generation, exception routing, and the quality control gate before funding. Each becomes a REST call to GoRules from your LOS workflow or middleware, or an in-process evaluation via SDKs for Node.js, Python, Java, Go, C#, and Rust. 02 ### Model the policy you already have Rebuild the overlay matrix and the credit policy document as decision tables and graphs, per product and per investor, instead of one global setting. Bureau attributes, AUS findings, and model scores stay inputs, so nothing in your scoring or verification pipeline changes. 03 ### Simulate against closed files Branch the policy, make the change, and replay a quarter of historical applications through both versions. Compare the approve, refer, and decline mix and the straight-through rate before anything reaches production, then trace a single file through every node to see exactly which rule moved it. 04 ### Promote and operate Push through dev, staging, and production with an approval recorded at each step. Every evaluation returns the outcome plus the exact rules that fired, ready for your stipulation letters and your adverse action process. Iterate weekly instead of quarterly, and roll back in one click. ## Built for production, not proof of concept. - Sub-millisecond evaluation with the open-source ZEN engine (Rust core, MIT), embedded in your services or called over REST: fast enough for instant prequalification at the point of sale - Git-like version control on the credit policy: branches, commit history, approval workflows, and one-click rollback, so an overlay change ships without a vendor change order - Self-host with Docker or Kubernetes so borrower PII, bureau pulls, and income documents never leave your infrastructure, or run on GoRules Cloud - Full traceability: every decision links to the rule version that produced it, and every change records who edited what and when. SSO, role-based access control, and SOC 2 - No lock-in: the core engine is open source under MIT, and [70+ industry templates](/templates), including loan approval, mean you start from a working policy instead of a blank editor ## Questions, answered. ### What is loan origination software? Loan origination software manages the pre-funding stages of a loan: application intake, document collection, verification, underwriting, the credit decision, quality control, closing, and funding, after which a loan management or servicing system takes over. Vendors bundle two very different things under that name: a workflow engine that moves the file between people and states, and a decision engine that applies credit policy to the data on it. The workflow part changes rarely. The decision part changes every time credit conditions, an investor guideline, or an overlay moves, and GoRules is only that second part. ### Is GoRules a loan origination system? No, and this page would be dishonest if it implied otherwise. A loan origination system owns the loan file: intake, document management, disclosures, e-sign, integrations with bureaus and appraisal vendors, and the funding instruction. GoRules holds no loan file and runs no workflow. It is the decision layer your LOS calls whenever it needs an outcome, which means rigid decisioning is fixable without a platform migration. ### What is the difference between a loan origination system and a decision engine? An LOS orchestrates: it knows which stage a file is in, who owns it, what documents are missing, and what happens next. A decision engine decides: given this borrower, this collateral, and these bureau and AUS attributes, does the file approve, refer, or decline, on what terms, with which stipulations and reason codes. Bundling them means a workflow change and a risk-threshold change touch the same configuration, ship on the same release, and queue behind the same approvals, for two concerns with nothing in common. Split them and the workflow can stay stable while policy moves weekly. ### Which loan underwriting decisions can GoRules automate? Anything expressible as policy rather than judgment: eligibility and knockout screens, minimum score and bankruptcy or foreclosure seasoning, DTI, LTV, CLTV and reserve overlays layered on top of AUS findings, income and documentation requirements by employment type, affordability and residual income calculations, risk-based pricing tiers, stipulation generation, counteroffer terms, and referral routing. Clean files go straight through. Borderline files route to a human underwriter with the triggering rules attached, so the reviewer starts from the reason instead of from scratch. The judgment calls stay with your underwriters; the repeatable calls stop consuming their day. ### How does GoRules support adverse action notices and exam requests? Every evaluation returns the specific rules that fired, so a decline or a counteroffer arrives with its actual principal reasons rather than an opaque score, and your team maps those to the notice language Regulation B and the FCRA require. Version control lets you reproduce the exact policy version that decided any historical file, along with the author and approver of the change that put it there. That is the record an examiner or internal audit asks for when reviewing overlays and exceptions. GoRules supplies the traceability; the compliance obligations, notice content, and fair lending testing remain yours. ## The same engine, next door. One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail. [**Loan Decisioning**Application to priced decision](/use-cases/loan-decisioning)[**Credit Decisioning**Policy above your ML models](/use-cases/credit-decisioning)[**Underwriting Automation**The same layer for insurance](/use-cases/underwriting-automation) ## Keep the system of record. Take back the decisions. Pick one decision point, your DTI overlay is the usual first, rebuild it as a decision table, and replay last quarter's files through it before anything touches production. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Loan Decisioning Software **URL:** https://gorules.io/use-cases/loan-decisioning **Description:** Loan decisioning software that plugs into your existing LOS. Model credit rules in visual decision tables, decide in milliseconds, explain every outcome. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Loan decisioning software that plugs into your LOS. Encode your credit policy in visual decision tables, evaluate every application in milliseconds, and return approve, decline, or refer with the exact rules that fired. Keep your loan origination system; GoRules replaces the hard-coded logic inside it. ## From decline to counteroffer, start to finish. Watch a morning in a lending team: a strong borrower declined on payment math, a one-cell policy change, a replay over 2,140 declined applications, a signed release - and declines that come back as offers. scroll to play Lending _/_ **Origination queue** Search applications…PS _Decisioned today_ **214** +38 vs yesterday _Approval rate_ **57%** target 60% _Affordability declines_ **31** 31 this week _Counteroffers_ **0** not in policy All _214_Affordability _31_Offers _0_Mine _5_ ApplicationApplicantProductAmountTermDTIStatusAge LN-3092_MA_M. AlvarezPersonal loan$28,00036 mo60 mo0.460.41_decline__counteroffer_2m LN-3088_TN_T. NakamuraPersonal loan$18,50048 mo0.45_decline__counteroffer_38m LN-3081_JO_J. OseiAuto loan$24,00060 mo0.39_approve_1.1h LN-3077_LF_L. FontainePersonal loan$9,00036 mo0.47_decline__counteroffer_2.4h LN-3070_KB_K. BrandtHome improvement$32,00072 mo0.52_decline__over cap at every term_3.1h LN-3064_SP_S. PetrovPersonal loan$12,50036 mo0.31_approve_4.0h 6 of 214 applicationspolicy v3.7.0 · same morning _MA_ **M. Alvarez**LN-3092 · Personal loan · $28,000 _decline · affordability__counteroffer · 60 mo_ _Affordability_ **0.46**DTI at 36 mo · cap 0.43 income verified · $7,100 / mo Existing debt**$1,890 / mo** Payment · 36 mo**$912** Payment · 60 mo**$598** DTI **0.46** _cap 0.43_ _Application_ Requested**$28,000 · 36 mo** Purpose**Home improvement** Channel**Web** Submitted**today · 09:41** Decided by**policy v3.6.4 · declined** declined by policy · fits at a longer term - open in GoRules to see why #### Lending policy Affordability rules for personal lending. Evaluated top-down on every application - first match decides. **DTI · requested term****DTI · best term****Decision****Term** 1_at most_ **0.43****Approve****As requested** 2_more than_ **0.43**_at most_ **0.43****Decline****Counteroffer****Longest that fits** 3_Otherwise_**Decline**_\-_ + was Decline · approvals untouched · edited by Head of Lending 1 unsaved change_Run tests__Request review_ **Quality checks**_0 declines replayed_ Over cap at 36 mo, fits at 60, counteroffers_was: decline_ Affordable at requested term still approves_unchanged_ Over cap at every term still declines_guardrail_ Knockouts and score floor untouched_ok_ All checks passed · +0 counteroffers created · 0 extra approvals _Release v3.7.0_ **v3.7.0**_draft_Priya Shah · just now · over-cap decline → counteroffer PS **Priya Shah**Head of Risk _pending_ _development_**v3.7.0** deploying _staging_**v3.6.4** live _production_**v3.6.4** live Live in production - every new application now decides against v3.7.0, and this week's affordability declines re-evaluate automatically. full diff + approval recorded · one-click rollback _Thursday, 09:41_ ### A strong application lands. LN-3092: personal loan, $28,000 over 36 months, income verified, clean file. The payment math is about to decline it. _The case file_ ### Strong borrower. Declined anyway. At 36 months the payment is $912 and DTI hits 0.46 - over the 0.43 cap. At 60 months it would be 0.41. The policy has no way to say so. _One cell_ ### Decline becomes counteroffer. The failing rule opens the live policy. On a branch, over-cap applications that fit at a longer term now counteroffer instead of declining - approvals untouched. _Proof before production_ ### 2,140 declines re-run. Ninety days of declined applications replay against the draft while you watch: 312 come back as counteroffers, zero extra approvals, over-cap-at-every-term still declines. _Sign-off_ ### Risk approves. v3.7.0 ships. Priya Shah signs the release, it promotes through staging to production with the full trail recorded. Rollback stays one click away. _Same morning_ ### Declines come back as offers. LN-3092 flips to a counteroffer: $28,000 over 60 months. Across the queue, affordability declines convert - except the one over cap at every term. ## Three places to look. Zero straight answers. Ask where loan decisioning happens in your stack and you will usually get three answers at once: rules hard-coded inside the LOS, a spreadsheet the credit team maintains, and a vendor scorecard nobody can inspect. Loan decisioning software is supposed to put that logic in one governed place; most lenders never get there. So changing a score floor or a DTI cap means a ticket, an engineering sprint, and a release window - a policy change that should take an afternoon stretches into weeks. The fix the market offers is worse than the problem. Loan origination software vendors sell better decisioning as the reason to migrate everything, application intake, documents, verification, and funding included, onto their platform. That is a rip-and-replace project to solve what is really a rules problem. Meanwhile the questions that matter go unanswered. Why did this application decline, specifically? What happens to the approval rate if we tighten the DTI cap to 43%? Who changed the pricing grid last quarter, and who approved it? When the answers live in code and tribal knowledge, every exam, audit, and policy review is slower and riskier than it needs to be. _los/plugins/affordability.ts_`if (dti(app, app.termMonths) > 0.43) {` `return decline("AFFORDABILITY");``}` _credit\_policy\_2026.xlsx_ rulevalue dti\_cap0.43 min\_score640 LOS-2117**Counteroffer longer term instead of declining**_Q3 roadmap · blocked on LOS vendor_ one policy · three owners · release windows apply ## The decisions inside your origination flow. GoRules is the loan-specific application of our credit decision engine: application in, priced decision out, every step readable. _01_ ### One pipeline from application to decision Model the whole decision as a graph. Knockout rules run first as a decision table: state eligibility, minimum score, bankruptcy recency, fraud flags. Affordability follows, with DTI and residual-income calculations written in ZEN expressions or typed TypeScript function nodes, then a pricing grid maps score band and DTI to APR. The result is one structured decision: approve with stipulations, counteroffer, decline with reasons, or refer to review. _02_ ### Automate loan underwriting, route the judgment calls Clear approvals and clear declines go straight through. Borderline applications route to a human underwriter with the triggering rules attached, so reviewers see exactly why the case referred instead of re-working it from scratch. Conditional approvals carry their stipulations, such as proof of income or employment verification, in the decision payload your LOS consumes. _03_ ### Your credit policy without release cycles Credit and risk teams edit decision tables directly, and natural-language rendering makes each rule read the way the policy document does. [Git-like versioning](/version-control), approval workflows, and one-click rollback mean risk signs off before anything reaches production. Run a change through the simulator with real application data before it ships. ## Keep the LOS. Upgrade the brain. No data migration: the LOS keeps owning applications, documents, and funding. GoRules owns the decisions inside that workflow. 01 ### Connect Call GoRules over REST from your LOS or point-of-sale flow, or embed the MIT-licensed [open-source ZEN Engine](/open-source) in your own service with SDKs for Node.js, Python, Java, Go, C#, and Rust. 02 ### Model Rebuild your policy as decision tables and graphs: knockout screens, affordability math, pricing tiers. Bureau attributes, bank transaction data, and scorecard or ML model outputs enter as plain inputs, so the final decision stays deterministic and reviewable even when a score is not. 03 ### Test and promote Branch a change, test it in the simulator with real application data, and trace execution through every node. Promote through dev, staging, and prod with an approval recorded at each step. 04 ### Operate Every evaluation returns the outcome plus the exact rules that fired, ready to feed your adverse action process. Iterate weekly instead of quarterly, and roll back in one click if a change misbehaves. ## Built for production, not proof of concept. - Sub-millisecond evaluation embedded, milliseconds over REST: fast enough for instant prequalification at point of sale - Git-like versioning with approval workflows, one-click rollback, and separate dev, staging, and prod environments - Self-host with Docker or Kubernetes so applicant PII and bureau data never leave your infrastructure, or run on GoRules Cloud - Full traceability: every decision links to the rules that fired, and every rule change records who changed what and when. SSO, RBAC, and SOC 2 - No lock-in: the core engine is open source under MIT with a Rust core, and [70+ industry templates](/templates), including loan approval, give you a working starting point ## Questions, answered. ### What is loan decisioning software? Loan decisioning software evaluates a loan application against a lender's credit rules and returns approve, decline, or refer to review, with the specific reasons, in real time. It is the decision layer of origination: the LOS manages intake, documents, and funding, while the decisioning engine determines who qualifies, on what terms, and why. ### Does GoRules replace our LOS? No. A loan origination system (LOS) runs the pre-funding workflow: application intake, document collection, verification, e-sign, and disbursement. GoRules handles only the decisions inside that workflow, from instant prequalification to full loan underwriting, and your LOS calls it over REST wherever a decision is needed. ### How does GoRules help with decline reasons and adverse action notices? Every decision returns the exact rules that fired, so a decline arrives with its specific principal reasons rather than an opaque score. You map those reasons to the language in your adverse action notices under ECOA and FCRA. GoRules supplies the traceability; the compliance obligations and notice content remain yours. ### Can our credit team change lending rules without an engineering release? Yes. Decision tables are edited visually, natural-language rendering keeps them readable for business users, and GoRules AI can draft rule changes, run tests, and explain decisions. Every change goes through approval workflows and versioned promotion, so nothing reaches production without sign-off, and any change rolls back in one click. ### Can we self-host so applicant and bureau data stay in our infrastructure? Yes. Deploy GoRules with Docker or Kubernetes inside your own environment, so applications, bureau attributes, and decision logs never leave your network. SSO and role-based access control govern who can view or change rules. GoRules Cloud is available if you prefer managed hosting. ## The same engine, next door. One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail. [**Credit Decisioning**Policy above your ML models](/use-cases/credit-decisioning)[**Transaction Monitoring**The same decision layer for AML rules](/use-cases/transaction-monitoring)[**Decision Engine**What it is and when you need one](/solutions/decision-engine) ## Decide in milliseconds. Explain every outcome. Model your first lending ruleset in the visual editor today, or walk us through your loan decisioning stack and we will map the integration. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Quoting in Insurance: Rate, Refer, Bind **URL:** https://gorules.io/use-cases/insurance-quoting **Description:** Quoting in insurance without the release train. Rate tables, eligibility, and bind rules in versioned decision tables your team edits and ships the same day. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Quoting in insurance that moves when your rates do. Rate tables, factors, eligibility, and bind rules live in visual decision tables your pricing and underwriting teams edit directly, with every version approved and traceable to the revision behind it. A rate change goes live on its effective date instead of waiting for the next release train. ## From decline to priced quote, start to finish. Watch a Monday in a homeowners quoting team: a well-kept 17-year roof auto-declined, a one-cell change to the rating policy, a replay over 780 declined submissions, a signed release - and declines that come back with a premium on them. scroll to play **Fairhaven Mutual**Homeowners quote_QT-8241 · 08:56 CT_ _1_**Home details**checkedchecked_2_**Roof**17y · flaggedrated · 1.25_3_**Coverage**not reachedHO-3 · $420k_4_**Quote**declined$1,642 / yr declined ##### We can't offer you a policy. Based on the details for 4412 Cedar Bend Dr, this home sits outside what we write today. _reason_**roof age: 17 years**_appetite · replace within 15 years_ _inspection_**8.6 / 10 · good**_29 Jul · shingles intact_ _built_**1998**_roof replaced_**2009**_claims_**none in 8 years** The appetite rule reads roof age. The inspection is in the file and never enters the decision. _you asked for_HO-3 · Coverage A $420,000 · $2,500 deductible · effective 01 Sep ref QT-8241 · decided in 0.4 sSomething not right? Talk to an agent re-rating QT-8241 against policy v3.1.0 quote ready ##### We can cover this home. HO-3 · Coverage A $420,000 · $2,500 deductible · effective 01 Sep how this price was builtannual Base premium_TX-118 territory · $420,000 Cov A_**$1,428** Roof surcharge_16 to 20 years · condition good__× 1.25_**$1,785** Claims-free credit_8 years, no losses__× 0.92_**$1,642** Annual premium_$119 / mo_**$1,428** Continue to bind no payment to hold this quote for 30 days roof age · this week53 submissions **71%**quote rate_target 85%_ declined 15 · roof age drove 9 of 15roof band now rated other roof-age declines · last 7 dayspolicy v3.1.0 · filed factor, same day **QT-8221**roof 16y_declined_**$1,213**_× 1.25_Marietta, GArequoted · bindable **QT-8236**roof 17y_declined_**$1,316**_× 1.25_Round Rock, TXrequoted · bindable **QT-8194**roof 18y_declined_**$1,427**_× 1.25_Cary, NCrequoted · bindable **QT-8177**roof 19y_declined_**$1,816**_× 1.25_Longmont, COrequoted · bindable **QT-8163**roof 20y_declined_**$1,621**_× 1.25_Chandler, AZrequoted · bindable **QT-8214**roof 24y_declined_Dublin, OHoutside appetite · over 20y #### Roof rating rules Appetite and rate factors for roof condition on homeowners HO-3. Evaluated top-down on every submission - first match decides. **Roof age****Roof condition****Action****Filed factor** 1_at most_ **15**_any_**Quote****1.00** 2_from_ **16** _to_ **20****Good****Decline****Quote****1.25** 3_from_ **16** _to_ **20****Fair****Refer****1.60** 4_Otherwise_**Decline**_\-_ + was Decline · filed 1.25 factor now applies · over 20y untouched · edited by Chief Actuary 1 unsaved change_Run tests__Request review_ **Quality checks**_0 declines replayed_ 17y roof, condition good, quotes at 1.25_was: decline_ Roofs over 20 years still decline_appetite_ Under 15 years keeps factor 1.00_unchanged_ Expected loss ratio inside filed range_61.4%_ All checks passed · +0 priced quotes · 0 appetite breaches _Release v3.1.0_ **v3.1.0**_draft_Priya Shah · just now · 16-20y good roof decline → quote 1.25 PS **Priya Shah**Chief Actuary _pending_ _development_**v3.1.0** deploying _staging_**v3.0.2** live _production_**v3.0.2** live Live in production - every new submission now rates against v3.1.0, and open roof-age declines return to the quote queue automatically. filing reference + approval recorded · one-click rollback _Monday, 08:56_ ### A clean risk comes in. QT-8241: homeowners HO-3 in Austin, TX. Coverage A $420,000, no claims in eight years, roof inspected two weeks ago. The roof is 17 years old. _The case file_ ### Sound roof. Wrong number. The inspector scored it 8.6 out of 10: shingles intact, no soft decking, full tear-off in 2009. The appetite rule reads roof age and nothing else, and 17 is past the 15-year line. _One cell_ ### Decline becomes a surcharged quote. The failing rule opens the live rating policy. The 1.25 factor for 16 to 20 year roofs was already filed and sitting in the table. On a branch, the action stops declining and starts using it. _Proof before production_ ### 780 declines replay. Sixty days of declined submissions re-run against the draft while you watch: 520 come back as priced quotes, expected loss ratio inside the filed range, roofs over 20 years still decline. _Sign-off_ ### Actuarial approves. v3.1.0 ships. Priya Shah signs the release and it promotes through staging into production, with the diff, the approval, and the filing reference attached to the version. _Same day_ ### Declines come back priced. QT-8241 rates at $1,642 a year on the filed 1.25 factor. Across the board roof-age declines convert, except the 24-year roof that is still outside appetite. Quote rate: 71 to 88 percent. ## The rates are approved. The release is in six weeks. Quoting in insurance looks like one number to the applicant and a chain of decisions to you. Is this risk inside appetite, which filed rate table applies in this state on this effective date, which factors and credits stack and in what order, and can the producer bind it or does it refer to an underwriter. In most carriers and MGAs that chain is spread across a rating module inside the policy administration system, a workbook of rate tables the actuarial team maintains, and eligibility logic hard-coded into the quote portal. No single artifact holds the answer, so nobody can change one part of it with confidence. The gap that hurts is between approval and production. A rate revision clears state review with an effective date attached, and then it waits: on a product analyst to reconfigure the tables, on IT to schedule the change, on a regression cycle. Legacy stacks are routinely described in cycles measured in quarters from analysis to implementation, while direct writers requote in seconds. The appetite the market moved on three weeks ago is still quoting today, and the result shows up in the loss ratio long before the fix ships. Exceptions make it worse rather than better. In commercial lines the exceptions are the work, not the edge case, and when referral logic sits in portal code every non-standard submission comes back as the same generic hold with no reason attached. The underwriter re-derives the risk from scratch, and straight-through processing stalls exactly where the rules could have said which condition tripped and what would clear it. Then a market conduct examiner asks which rating version priced a policy bound last March, who changed the territory factor, who approved it, and which filing that version maps to. When the answer lives in a spreadsheet revision history, a vendor config export, and a chain of change-request emails, assembling it takes weeks and defending it takes longer. _rating/src/bop/premium.ts_`if (risk.protectionClass >= 9` `&& risk.construction === 'frame') {` `return decline('APPETITE');``}` _BOP\_rate\_tables\_v9\_TX.xlsx_ territorybase TX-1041.32 TX-1181.47 RATE-884**Load approved TX revision, eff 04/01**_release train · 6 weeks out_ filed rates · three artifacts · one release window ## Appetite, rating, and bind in one governed flow. One evaluation takes a submission from in-appetite check to priced, bindable quote, and returns the rules behind every number in it. _01_ ### Rate tables that read like rate tables Base rates by state and territory, class and construction factors, deductible and protective-device credits, minimum premium: all of it is naturally tabular, and in GoRules it stays tabular. Rate tables are decision tables your actuarial and product teams read and edit directly, ZEN expressions carry the rating algorithm over the exposure base, and typed TypeScript function nodes cover the awkward parts such as pro-rata terms, package rounding, and premium caps. Every channel rates against the same published version, so the number on the agent's screen matches the number on the bind request, in milliseconds, on every channel. _02_ ### Appetite, referral, and bind rules in the same evaluation Knockouts run first as Policies, ordered blocks evaluated in sequence, so a class you do not write or a protection class outside appetite stops before anything is priced. Rating follows, then referral and bind rules decide whether the producer can bind directly, whether the program limits apply, or whether an underwriter has to look. Referrals carry the triggering rule and its reason with them, so the case arrives with the condition that tripped instead of a generic hold. _03_ ### A version per revision, with an approver on it Branch the live rating project, apply the approved revision, and route it through a change request with named approvers before it becomes a release. [Git-like version control](/version-control) records who changed which factor and when, environments keep dev, staging, and production separate, and rollback is one click. Months later the same trail answers the harder question: the release that priced a given bound policy is still retrievable and still readable. ## Keep the PAS. Own the rating rules. Your policy administration system keeps issuance, endorsements, and billing. GoRules owns the decisions that turn a submission into a bindable quote. 01 ### Connect the quote path you already have Your quote portal, agent portal, comparative-rater feed, or PAS calls GoRules over REST wherever a premium or eligibility answer is needed, or embeds the MIT-licensed [open-source ZEN engine](/open-source) with SDKs for Node.js, Python, Java, Go, C#, and Rust. Submission data from ACORD forms, prefill and third-party data, and loss-run summaries all arrive as plain inputs. 02 ### Model the rating rules Rebuild the product as a decision graph: appetite and eligibility Policies, base-rate tables per state and territory, factor and credit tables, the rating algorithm in ZEN expressions, then referral and bind rules at the end. Start from the [insurance templates](/templates) rather than a blank canvas, and let natural-language rendering give the actuary, the underwriter, and the compliance reviewer the same artifact to read. 03 ### Simulate before anyone quotes on it Run last quarter's submissions through the simulator against the current release and the proposed one, and compare premium by premium the way a mass rate comparison against a legacy engine works. Keep the interesting risks as test cases so they run on every future change, and trace execution node by node when a number looks wrong. 04 ### Release on the effective date, then operate Promote the revision through environments with an approval recorded at each step, timed to the effective date rather than a release train. In production every quote returns the premium plus the rules that produced it, ready for the quote document, the referral queue, and the audit record. When appetite shifts, the underwriting team edits the table and ships the same week. ## Built for production, not proof of concept. - Sub-millisecond evaluation with the open-source ZEN engine (Rust core), embedded or over REST, so a full appetite-plus-rating pass fits inside a quote page load - Git-like version control on the rating project: a branch per revision, change requests with named approvers, full diff history on every factor, one-click rollback - Self-host with Docker or Kubernetes so submission data, loss runs, and bordereaux never leave your infrastructure, or run on GoRules Cloud - Full traceability: every quote links to the rules that fired, every rule change records who changed what and when, with SSO, role-based access control, and SOC 2 behind it - No lock-in: the core engine is MIT-licensed open source with a Rust core, and [70+ industry templates](/templates), including insurance underwriting and pricing, give you a working starting point ## Questions, answered. ### What is quoting in insurance? Quoting in insurance is the process of turning a risk's details into a price and a coverage offer. The insurer checks the risk against its appetite and eligibility rules, retrieves the filed base rates for the state, territory, and class, applies factors, credits, and debits, and returns a premium with limits and deductibles. A quote is an estimate rather than a commitment: it becomes a premium once underwriting is complete and the policy is bound. GoRules holds the rules behind that process, from eligibility through rating to bind, in decision tables your teams own. ### What is the difference between a rating engine and a policy administration system? A policy administration system owns the policy lifecycle: issuance, endorsements, renewals, billing, and documents. A rating engine answers a narrower question, whether the risk is eligible and what it costs, and gets called at new business, endorsement, and renewal. When rating is embedded inside the PAS, every rate change becomes an IT project on the vendor's cadence. GoRules is the standalone decision layer for that question, so the PAS keeps everything else and the rules stay yours. ### Can our actuarial and underwriting teams change rate tables without an engineering release? Yes. Rate tables, factor tables, and eligibility rules are visual decision tables, and natural-language rendering keeps each rule readable for reviewers who do not write code. GoRules AI can draft a rule change, run your test cases, and explain why a submission rated the way it did, but it never deploys or releases anything. Changes go through a change request with approvals and are promoted through environments as versioned releases, and any release rolls back in one click. ### How does GoRules help with rate filings and market conduct exams? Each rating revision is a versioned release with a full diff, an author, and a recorded approval, so you can show which version was live on any date and reproduce the exact rules that priced a specific bound policy. Test cases and simulation runs document that the revision was validated before it went live, which is the evidence internal audit and examiners ask for alongside the filing itself. GoRules supplies the traceability; the filing, the actuarial justification, and the compliance obligations remain yours. ### How do eligibility, referral, and bind rules fit into one decision? They run as stages of a single evaluation. Appetite and eligibility Policies knock out risks you do not write before anything is priced, rating produces the premium and its components, and referral and bind rules then decide whether the producer can bind directly, whether binding-authority limits apply, or whether an underwriter has to review. Because each stage returns the rules that fired, a referral arrives with its reason attached and clean risks go straight through without a queue. ## The same engine, next door. One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail. [**Underwriting Automation**Appetite, referral, and straight-through](/use-cases/underwriting-automation)[**Loan Decisioning**The same decision layer for lending](/use-cases/loan-decisioning)[**Dynamic Pricing**Prices that move with the rules](/use-cases/dynamic-pricing) ## Approved on Friday. Quoting on Monday. Load one state's rate table into a decision table, replay last quarter's submissions through the simulator, and compare the premiums against your current engine before anything ships. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Fraud Detection Software Your Analysts Tune **URL:** https://gorules.io/use-cases/fraud-detection **Description:** Fraud detection software built on a rules engine your analysts control. Tune thresholds, velocity rules, and allow, deny, or review outcomes in real time. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Fraud detection software. The score flags it, your rules decide. GoRules is the decision layer above your fraud scores: velocity rules, allow, deny, and review thresholds, and step-up triggers in visual decision tables your fraud team edits directly. Tune a false-positive problem the same afternoon you find it, without retraining a model or waiting on an engineering release. ## From held to cleared, start to finish. Watch a Monday in a fraud team: 214 good transactions stuck behind a rule tightened during a card-testing attack, a one-cell exemption for trusted devices, a replay over 4,180 held transactions, a signed release - and a false positive rate that drops from 38 to 9 percent. scroll to play _Payments risk _/__Authorization stream live3,140 auth / minpolicy **v7.0.3v7.1.0**PS timecardmerchantamountscoredecision 09:05:124512 \*\*\*\* 6034Saltbox Coffee$6.400.03_approved_ 09:05:195301 \*\*\*\* 2288Bluebird Grocer$52.180.07_approved_ 09:05:264024 \*\*\*\* 9910Northwind Supply$128.000.19_held__approved_ 09:05:344512 \*\*\*\* 7745Helio Pharmacy$23.750.05_approved_ 09:05:415546 \*\*\*\* 1120Onda Fitness$89.000.22_held__approved_ 09:05:494024 \*\*\*\* 4471Corvid Books$17.900.06_approved_ 09:05:574512 \*\*\*\* 3390Trail & Timber$214.000.24_held__approved_ 09:06:044512 \*\*\*\* 5518Nordvik Outdoor$176.400.21_held__approved_ 09:06:124024 \*\*\*\* 2065Pixel Forge Games$39.990.16_held__approved_ 09:06:205546 \*\*\*\* 7730Ferrand Bakery$12.600.04_approved_ 09:06:274512 \*\*\*\* 0921Kettle & Co$84.000.12_held__approved_ 09:06:355301 \*\*\*\* 3306Aeris Mobility$44.000.09_approved_ 09:06:434024 \*\*\*\* 3187Verdant Garden$296.000.91_new device · score 0.91__blocked_ 09:06:514512 \*\*\*\* 6672Saltbox Coffee$9.100.03_approved_ 09:06:585546 \*\*\*\* 4409Northwind Supply$132.750.20_held__approved_ 09:07:064024 \*\*\*\* 8843Helio Pharmacy$31.400.08_approved_ 09:07:144512 \*\*\*\* 1194Onda Fitness$58.200.14_held__approved_ 09:07:215301 \*\*\*\* 9027Bluebird Grocer$67.300.10_approved_ 09:07:294024 \*\*\*\* 5560Lumen Optics$148.000.23_held__approved_ 09:07:364512 \*\*\*\* 2841Corvid Books$28.500.05_approved_ 09:07:445546 \*\*\*\* 6015Trail & Timber$92.800.18_held__approved_ 09:07:524024 \*\*\*\* 7302Saltbox Coffee$5.800.02_approved_ _Review queue_ **206**held oldest 3h 12mreleasing now _False positives_ **38%** was 11% before Thursdayback under target **4512 \*\*\*\* 0921**$84.00_card velocity · held 3m_ **4024 \*\*\*\* 2065**$39.99_card velocity · held 12m_ **4512 \*\*\*\* 5518**$176.40_card velocity · held 24m_ **4024 \*\*\*\* 9910**$128.00_card velocity · held 31m_ **4512 \*\*\*\* 3390**$214.00_card velocity · held 44m_ **4024 \*\*\*\* 3187**$296.00_new device · score 0.91_ 206 held _· 22 authorizations in the last 3 minutes_policy v7.1.0 · good customers stopped bouncing kettle-and-co.com/checkout Payment declinedPayment confirmedYour bank did not authorize this payment. Try another card.Order 40912 is on its way to your saved address. Kettle & Co · $84.00 · Visa 4512 \*\*\*\* 0921 Customer**D. Whitfield · 3 y 2 mo** Orders**14th · 0 disputes** Device**trusted · 11 months** Fraud score**0.12 · blocks at 0.85** Held by**policy v7.0.3 · card velocitypolicy v7.1.0 · released** 4 card attempts in 10 min · limit tightened Thursday 02:14 during a card-testing attack #### Card fraud rules Velocity, device, and score rules for card payments. Evaluated top-down on every authorization - first match decides. **Card velocity****Device trust****Fraud score****Action****Reason** 1**Confirmed fraud****Block****device\_block** 2_at least_ **0.85****Block****score\_block** 3_more than_ **3** _in_ **10** _min__more than_ **3** _in_ **10** _min, on_ **untrusted** _devices only_**Hold****card\_testing** 4_Otherwise_**Allow**_\-_ + was: any device · score and device blocks unchanged · edited by Head of Fraud 1 unsaved change_Run tests__Request review_ **Quality checks**_0 holds replayed · 48h_ Trusted device over the limit releases_was: hold_ Untrusted device over the limit still holds_guardrail_ 37 confirmed-fraud cases still caught_0 missed_ Score and device blocks untouched_unchanged_ All checks passed · 0 holds release, 61% · 0 confirmed fraud missed _Release v7.1.0_ **v7.1.0**_draft_Priya Shah · just now · velocity hold skips trusted devices PS **Priya Shah**Head of Fraud _pending_ _development_**v7.1.0** deploying _staging_**v7.0.3** live _production_**v7.0.3** live Live in production - every authorization now decides against v7.1.0, and the transactions held since the attack re-evaluate automatically. full diff + approval recorded · one-click rollback _Monday, 09:06_ ### The queue never emptied. A checkout declines: an $84 reorder, risk score 0.12, device trusted since last spring. It is the 214th payment held since Thursday, when the velocity rule was tightened against a card-testing attack. _The case file_ ### Nothing here looks like fraud. Three years on the account, 14 prior orders, zero disputes, the same device for 11 months. One counter tripped: 4 card attempts in 10 minutes, one over the limit set during the attack. _One cell_ ### The velocity rule learns about devices. The rule that held it opens the live policy. On a branch, the 10-minute hold now applies to untrusted devices only. The score block at 0.85 and the confirmed-fraud block stay exactly as they are. _Proof before production_ ### 48 hours of holds, replayed. 4,180 held transactions re-run against the draft while you watch: 2,548 release, all 37 confirmed-fraud cases are still caught, chargeback exposure unchanged. _Sign-off_ ### Fraud approves. v7.1.0 ships. Priya Shah signs the release, it promotes through staging to production with the full trail recorded. Rollback stays one click away. _Within the hour_ ### The queue drains. The blocks hold. The retry goes through without a human touching it. Review queue 214 to 31, false positive rate 38 to 9 percent, and the new-device attempt scoring 0.91 stays blocked. ## The rule that stops fraud also stops your customers. Fraud detection software is judged on the fraud it stops and paid for with the customers it stops alongside it. Merchant Risk Council survey data puts the average fraud-suspicion decline rate at 2.6% of orders, rising to roughly 3.1% once the basket clears $100, and industry analyses consistently find false declines cost more revenue than the fraud they prevent. Every one of those declines traces back to a threshold somebody picked, often a year ago, for a customer mix that no longer exists. Ask a fraud team where the policy actually lives and you get three answers at once: score cutoffs hard-coded in the checkout or authorization service, a vendor console whose logic nobody outside the vendor can inspect, and a spreadsheet of per-segment thresholds the risk analysts maintain by hand. The people accountable for the fraud rate and the approval rate are the people who cannot change either one without a ticket. The feedback loop makes it worse. Chargebacks land weeks after the transaction, so the labels that prove a threshold was wrong arrive long after the revenue is gone. Nobody can answer the question that matters before shipping: if we move the deny cutoff from 720 to 760 for returning customers, how many of last month's declines become approvals, and how much confirmed fraud comes through with them? The pressure is external too. Visa's Acquirer Monitoring Program folded fraud and dispute ratios into one number, flagging portfolios above standard at 50 bps and excessive at 70 bps, and under the PSD2 RTS your transaction risk analysis exemptions only survive while the reference fraud rate stays inside the 0.13%, 0.06%, and 0.01% bands. When a dispute, an acquirer review, or an angry customer asks why a specific transaction was blocked in March, "the score was high" is not an answer, and neither is a config export nobody can diff. _checkout/risk/score-gate.ts_`if (score >= 720 && cardsOnDevice24h >= 3) {` `return deny('CARD_TESTING');``}` _fraud\_thresholds\_q3.xlsx_ segmentdeny\_at new\_account720 returning860 RISK-3391**Step up trusted repeat buyers instead of declining**_Sprint 41 · backlog · payments team_ one threshold · three owners · chargebacks arrive in 60 days ## The rules layer above your fraud score. Your model estimates how risky the transaction is. GoRules decides what happens next - allow, challenge, review, or deny - in tables the fraud team owns. _01_ ### Fraud policy as decision tables, not vendor config Fraud policy is naturally a matrix: score band by velocity counter by customer segment, resolving to an action and a reason code. GoRules decision tables are that matrix, spreadsheet-style, edited by fraud analysts and rendered in natural language for review. Hard blocks such as confirmed-fraud devices, blocked BIN ranges, and disposable email domains are modeled with Policies, ordered blocks evaluated in sequence, so they fire before the score is ever consulted. Velocity conditions like cards per device in 24 hours, attempts per BIN, or orders per shipping address sit in the same table as the score bands, and ZEN expressions handle derived values such as deviation from the customer's own baseline. Start from the [fraud detection templates](/templates) instead of a blank table. _02_ ### Tune false positives without touching the model Branch the live policy with [git-like version control](/version-control), raise the deny cutoff for returning customers, and replay a labelled sample of historical transactions through both branches as test cases: which orders swap from deny to allow, which confirmed-fraud cases now get through. GoRules AI can draft the rule change, run the tests, and explain the resulting decisions while you iterate. When the numbers work, promote through dev, staging, and production as a versioned release with required approvals, and roll back in one click if the fraud rate disagrees. _03_ ### Every decline explains itself Each evaluation returns the action plus the exact rules that fired: which hard block matched, which score band applied, which velocity counter tripped. That trace is what a dispute analyst attaches to representment evidence, what a support agent reads back when a good customer calls, and what an acquirer review consumes when it asks how your controls actually work. Behind it sits the governance record: full audit logs, commit history, approval workflows, SSO, and role-based access control. ## Keep your models. Own the decision. GoRules does not replace your scoring model, your device intelligence provider, or your case management system. It is the layer that turns their signals into an action. 01 ### Wire it into the authorization path Call GoRules over REST from your checkout, payment, or onboarding service, or embed the MIT-licensed [open-source ZEN Engine](/open-source) with SDKs for Node.js, Python, Java, Go, C#, and Rust. The payload carries the transaction, your model's fraud score, device fingerprint and reputation signals, velocity counters from your feature store or cache, BIN and AVS/CVV results, and the customer's account history. 02 ### Model the policy Build the decision graph: hard blocks first as Policies, then velocity tables for card testing and enumeration, then score bands per segment, channel, and MCC. It ends in one structured outcome - allow, challenge with a 3DS step-up, route to manual review, or deny - each carrying a reason code your downstream systems can act on. 03 ### Replay, then compare Run a labelled window of historical transactions through the current policy and a challenger branch in the simulator. Compare decline rate, challenge rate, review queue volume, and caught fraud side by side, let stakeholders read the rules in natural language, and take the change through approval before it touches live traffic. 04 ### Operate and keep tuning Evaluate inline in under a millisecond, feed reason codes into case management and your dispute workflow, and close the loop weekly: review chargeback labels and analyst dispositions, adjust thresholds per segment, and watch approval rate next to fraud rate rather than either one alone. ## Built for production, not proof of concept. - Sub-millisecond evaluation with the open-source ZEN engine (Rust core), fast enough to sit inline in the authorization path without spending your latency budget - Git-like version control on every fraud policy: branches, commit history, approval workflows, one-click rollback when a threshold change misbehaves - Self-host with Docker or Kubernetes so cardholder, device, and behavioral data never leave your infrastructure, or run on GoRules Cloud - Complete audit trail: every decision links to the rules that fired, every rule change records who changed what and when. SSO, role-based access, SOC 2 - No lock-in: the core engine is open source under MIT with a Rust core, and [70+ industry templates](/templates) give your team a working starting point instead of a blank table ## Questions, answered. ### What is fraud detection software? Fraud detection software evaluates a transaction, login, or account-opening attempt against risk signals and rules, then returns an action in real time: allow it, challenge it with step-up authentication, send it to a human reviewer, or deny it. Modern stacks are layered, with device intelligence and behavioral data feeding a scoring model and a rules layer turning that score plus hard policy into the actual decision. The scoring part estimates risk; the rules part is where your risk appetite, your segments, and your reason codes live. GoRules provides that rules layer as visual decision tables and graphs your fraud team edits directly. ### What is a fraud rules engine, and does it replace machine learning? A fraud rules engine executes explicit, human-authored logic: velocity checks, score cutoffs, allowlists, hard blocks, and segment-specific thresholds. It does not replace machine learning, and the two are not competing. A model generalizes to patterns nobody wrote down, while rules encode the decisions you must be able to explain and change today. The production pattern is a hybrid: the model emits a score, the rules engine applies deterministic overrides and maps that score to an action. Keeping them separate means a threshold change is an afternoon of work rather than a retraining and revalidation cycle. ### What is fraud scoring and how do thresholds map to allow, deny, and review? Fraud scoring condenses signals about a transaction into a single number, typically 0 to 100 or 0 to 1000, where higher means riskier. Teams then band that score: auto-approve below a low cutoff, deny above a high one, and route the middle to a manual review queue or a 3DS step-up challenge. The bands are the whole game, and they should not be global, because a returning customer with a three-year history and a first-time buyer on a prepaid BIN deserve different cutoffs. In GoRules each band is a row in a decision table, set per segment, channel, and product, and changed without an engineering release. ### How do we reduce false positives without letting more fraud through? Replace one global cutoff with per-segment bands, add a challenge tier so borderline cases get a 3DS step-up instead of a hard decline, and test every change against labelled history before it ships. GoRules lets you branch the live policy, replay a window of past transactions through both versions, and compare decline rate, challenge rate, review volume, and caught fraud before anyone in production feels it. Because velocity counters, device signals, and model scores all enter as inputs to readable rules, you can see which condition produces the false positives instead of guessing at a score. Then tune weekly rather than quarterly, because the change no longer waits on a release window. ### Can we self-host, and does GoRules help with audits and scheme monitoring programs? Yes to self-hosting: deploy with Docker or Kubernetes inside your own network, or embed the MIT-licensed open-source ZEN engine directly in your services, so transaction, cardholder, and device data never crosses a vendor boundary. SSO and role-based access control govern who can view or change rules, and GoRules Cloud is available when managed hosting suits you better. For audits, disputes, and acquirer reviews you can retrieve the exact rule version that evaluated any historical transaction along with the approval that put it into production, which is the evidence teams need when documenting controls behind PSD2 transaction risk analysis exemptions or a scheme monitoring remediation plan. GoRules supplies the traceability; the obligations remain yours. ## The same engine, next door. One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail. [**Transaction Monitoring**AML rules on the same engine](/use-cases/transaction-monitoring)[**Credit Decisioning**Policy above your ML models](/use-cases/credit-decisioning)[**Decision Engine**The layer under every decision](/solutions/decision-engine) ## Stop the fraud. Keep the customer. Rebuild your current rule set as decision tables this week, replay last month's transactions against it, and find out what your thresholds are actually costing before you change a line of code. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Dynamic Pricing Software That Explains Itself **URL:** https://gorules.io/use-cases/dynamic-pricing **Description:** Dynamic pricing software built on a rules engine your pricing team owns. Versioned rules, margin guardrails, sub-millisecond repricing, every price explained. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Dynamic pricing software that shows its work. Model every price rule - competitor position, demand, stock cover, segment, margin floor - as visual decision tables your pricing team edits directly. Every request returns the final price and the exact rules that produced it, in under a millisecond. ## From outpriced to matched, start to finish. Watch a morning on a pricing desk: a competitor undercut nobody can answer, a one-cell change to the match floor, a replay across 12,400 electronics SKUs, a signed release - and the featured offer back before lunch. scroll to play _N_Northbeam Search Northbeam_2_ SKU-7318 · unit $148.00internal **5.6%**margin at $186.90 basis $176.50floor $185.33 Floor blocks the match by $1.54 - open in GoRules to see whyMatched at $183.50 · floor now $180.03 · 3.8% margin Audio _/_ Headphones _/_ Over-ear**GX-9 Wireless Headphones**Visit the Halden Audio store**4.6**2,318 ratings_· #3 in Over-ear Headphones_ - Adaptive noise cancelling, 42 h battery life - Bluetooth 5.4 with multipoint pairing - USB-C fast charge, 10 minutes for 5 hours $186.90$186.90 updated just nowFree delivery **Thursday, 21 Aug**In stock _· sold and shipped by Northbeam__Add to cart_ Other sellers$183.80 4 offers_\-$3.10 · 1.7%__we lead $0.30_ _Featured offer_ **More in Audio**4 of 214 listings **GX-7 Earbuds** **$89.90**_\-$3.50_ **Volt 65W charger** **$49.99**_\-$2.59_ **Stratos 3.1 soundbar** **$199.00**_\-$0.00_ _MAP · $199 floor_ **Lumen Pro webcam** **$79.00**_\-$2.10_ _Featured offer win rate_ **61%** electronics · 7-day rollingup 23 points since 09:40 12,400 listings in Electronics · prices refresh every 15 minutespolicy v3.3.0 · buy box back by lunch #### Pricing rules - Electronics Competitor response for the electronics category. Evaluated top-down on every price decision - first match decides. **Competitor**_under us by_**Margin**_at match_**Listing****Action****Price floor**_never below_ 1**MAP-listed****Hold** _at MAP_**MAP price** 2_at least_ **1%**_at least_ **3%****Standard****Match****1.05** _x cost_**1.02** _x cost_ 3_at least_ **1%**_less than_ **3%****Standard****Review****1.05** _x cost_ 4_Otherwise_**Hold** _at list__\-_ + was 1.05 x cost · MAP guardrail unchanged · edited by Category Lead, Electronics 1 unsaved change_Run tests__Request review_ **Quality checks**_0 SKUs replayed_ Outpriced at 1.7% now matches at $183.50_was: hold_ MAP-listed SKUs still hold at the MAP floor_guardrail_ No price lands below 1.02 x cost_0 breaches_ Category margin stays inside 0.5 points_\-0.4pt_ All checks passed · 0 SKUs re-price · 0 MAP violations _Release v3.3.0_ **v3.3.0**_draft_Jane Cooper · just now · match floor 1.05 → 1.02 x cost JC **Jane Cooper**Head of Pricing _pending_ _development_**v3.3.0** deploying _staging_**v3.2.1** live _production_**v3.2.1** live Live in production - the nightly repricer and every price call now decide against v3.3.0, and outpriced electronics SKUs re-price on the next run. full diff + approval recorded · one-click rollback _Tuesday, 08:12_ ### The market moved overnight. A rival seller drops the GX-9 to $183.80. Our listing still shows $186.90, the featured offer badge sits on their row, and the repricer decided to do nothing. _The listing_ ### Room to match. Rule says no. Landed cost is $176.50 after marketplace fees, so matching at $183.79 still earns 4.0%. The match floor stops at 1.05 x cost, $185.33, so the page holds at $186.90 and loses the offer by $3.10. _One cell_ ### The category lead fixes it herself. The blocking rule opens the live policy. The match floor drops from 1.05 to 1.02 x cost - on a branch, the MAP guardrail untouched. _Proof before the market sees it_ ### 890 SKUs would re-price. Thirty days of price decisions replay across 12,400 electronics SKUs while you watch: 890 re-price, category margin dips 0.4 points inside the 0.5 tolerance, zero MAP violations. _Sign-off_ ### Pricing approves. v3.3.0 ships. Jane Cooper signs the release, it promotes through staging to production with the full trail recorded. Rollback stays one click away. _Same morning_ ### The featured offer comes back. The GX-9 re-prices to $183.50 and takes the badge back. Across the category, outpriced listings match - except the soundbar the MAP floor still holds. Win rate: 61 to 84 percent. ## Prices move daily. The rules move quarterly. Most teams do not run dynamic pricing software. They run a repricing script somebody wrote three years ago, a spreadsheet of category floors the pricing team maintains by hand, and a set of exceptions buried in an ERP price list. A cost input moves on Monday and the shelf price catches up three weeks later, because changing a rule means a ticket, a sprint, and a release window. The tools sold to fix this rarely fix the part that hurts. Competitor-monitoring platforms collect prices well and ship generic rule packs that know nothing about your margin structure. Price optimization suites bring elasticity models and a months-long implementation, then hand the strategy back to a data team category managers cannot reach. The rules that actually decide the number stay scattered between a CPQ, an ERP condition table, and the storefront. That scattering is what makes automated pricing frightening. Unconstrained repricing prices below cost when a competitor feed returns a corrupted value, chases a liquidation sale into a price war, and breaks contract minimums nobody encoded. The guardrails everyone recommends, margin floors by category, a cap on how far a price can move in a day, approval routing for anything unusual, only work when they are written where the pricing team can read them and applied after every strategy rule instead of bolted onto one integration. Then the questions arrive from every direction. Finance wants to know which rule cost sixty basis points of margin last quarter. A category manager wants to know why a key line dropped on a Friday. Legal wants proof the engine reacts to market conditions and not to individual shoppers, because the EU Omnibus Directive requires disclosure when a price is personalized through automated decision-making, and New York's Algorithmic Pricing Disclosure Act and a growing list of state bills push in the same direction. None of those answers exist when the price came out of a script. _pricing/repricer.ts_`if (comp.min < base * 0.95) {` `return comp.min * 0.99;``}``return base * seasonFactor;` _reprice\_rules\_q3.xlsx_ categoryfloor % audio22 cables35 PRC-884**Add a margin floor before we match a competitor**_Backlog · needs pricing + eng_ one price · three owners · nobody can say why ## One pricing policy. Every channel, every quote. Base price in, final price out, with the strategy tables, guardrails, and rounding rules that produced it attached to the answer. _01_ ### A dynamic pricing example, start to finish SKU-4471 lists at $129.00 with a $96.00 unit cost. Overnight, demand runs at 1.12 times its 28-day baseline, stock cover sits at 14 days, and the cheapest tracked competitor is $126.50, putting the listing 2.0% above market. The audio strategy table matches that row and proposes +3.5%, or $133.52. The guardrail policy runs next: the 8% daily move cap passes, the 22% category margin floor passes at 28.4%, no key-line lock applies, and the price-ending rule rounds to $133.99. The price publishes with all four rules and their inputs attached, so when the category manager asks why it moved, the answer is four named rules rather than a model output nobody can open. _02_ ### Guardrails that outrank the strategy In GoRules the guardrails are a Policy: an ordered block that runs after the strategy tables and can only ever narrow the result. Category margin floors, maximum movement per day and per week, key-line price locks, MAP and contract minimums, and a route-to-review outcome for anything outside the band. When a competitor feed briefly returns a corrupted near-zero price, the match rule proposes it and the floor blocks it, so the SKU lands in a review queue instead of on the storefront at a loss. _03_ ### Change the pricing rules without a release Pricing and category teams edit the decision tables directly, and natural-language rendering makes each row read the way the pricing policy document does. [Git-like versioning](/version-control), approval workflows, and one-click rollback mean finance signs off before anything reaches production. GoRules AI can draft a rule change, run your test cases, and explain why a given SKU landed where it did, while the release itself stays a human decision with an approval attached. ## Keep your catalog. Move the pricing rules. GoRules is not a competitor data feed and not an elasticity model. It is the layer that turns your inputs and your strategy into a price you can defend. 01 ### Connect Your storefront, ERP, CPQ, or nightly repricing job calls GoRules over REST, or embeds the MIT-licensed [open-source ZEN Engine](/open-source) in your own service with SDKs for Node.js, Python, Java, Go, C#, and Rust. The payload carries base price, unit cost, inventory, demand signals, competitor observations, and customer or contract context. GoRules never needs to own your catalog. 02 ### Model the waterfall Rebuild the pricing waterfall as a decision graph: base price resolution, then a strategy table per category or segment, then the guardrail policy, then rounding and price endings. ZEN expressions handle the arithmetic, margin, gap to market, and days of cover, and typed TypeScript function nodes cover anything custom, such as blending an elasticity recommendation with a floor. 03 ### Simulate before the market sees it Branch the policy, make the change, and run a real catalog extract through both branches as test cases. Compare price moves SKU by SKU, count how many rows the margin floor catches, and let category managers review the rules in natural language before sign-off. 04 ### Operate Promote through dev, staging, and production with an approval recorded at each step. Every evaluation returns the price plus the rules that produced it, ready for your price-change log and your category reviews. When the market moves, the pricing team edits the table and ships the same day. ## Built for production, not proof of concept. - Sub-millisecond evaluation with the open-source ZEN engine (Rust core), fast enough to price inside a product page request or a quote API, embedded or over REST - Git-like version control on every pricing policy: branches, commit history, approval workflows, and one-click rollback when a move goes the wrong way - Self-host with Docker or Kubernetes so cost, margin, and contract pricing never leave your infrastructure, or run on GoRules Cloud - Complete audit trail: every published price links to the rules that fired, and every rule change records who changed what and when. SSO, RBAC, and SOC 2 - No lock-in: the core engine is open source under MIT with a Rust core, and [70+ industry templates](/templates), including retail and logistics starting points, give you a working base ## Questions, answered. ### What is dynamic pricing software? Dynamic pricing software adjusts prices automatically as market conditions change, instead of leaving them fixed until someone edits a price list by hand. It reads signals such as demand, stock cover, competitor prices, cost inputs, and time to expiry, applies the pricing rules the business has agreed on, and writes the result back to the storefront, ERP, or quoting system. Two separable jobs sit inside that: the data side that produces the signals, and the decision side that turns signals into a price the company is willing to defend. GoRules is the decision side, a pricing rules engine where strategy tables, guardrails, and rounding rules live in one versioned, auditable place. ### Can you show a dynamic pricing example? Take SKU-4471, a headphone listing at $129.00 with a $96.00 unit cost. Overnight demand runs at 1.12 times its 28-day baseline, stock cover is 14 days, and the cheapest tracked competitor sits at $126.50, so the listing is 2.0% above market. The audio strategy table matches that combination and proposes a 3.5% increase, or $133.52. The guardrail policy then runs: the 8% daily move cap passes, the 22% category margin floor passes at 28.4%, and the price-ending rule rounds to $133.99. The price publishes with all four rules and their inputs recorded, so the move is still explainable months later. ### What is the difference between a pricing rules engine and a price optimization platform? A price optimization platform estimates what the market will bear: elasticity curves, demand forecasts, recommended prices. A pricing rules engine executes the policy you have decided on: which strategy applies to which segment, where the floors and caps sit, how prices round, when a change needs approval. Optimization output is an input to the rules engine rather than a replacement for it, because a recommendation still has to clear margin floors, contract minimums, MAP agreements, and category strategy before it becomes a real price. GoRules is the rules engine, so model scores and recommended prices arrive as plain inputs and the final number stays a readable rule outcome. ### How do we stop dynamic pricing from publishing a bad price? Guardrails run as an ordered Policy after the strategy tables and can only narrow the result: category margin floors, maximum movement per day and per week, key-line price locks, contract and MAP minimums, and a route-to-review outcome for anything outside the band. Because they are decision-table rows rather than code, the pricing team can read them and finance can approve them. Before a change ships, branch the policy and run last month's catalog through both versions in the simulator to compare price moves and margin impact. If something still misbehaves in production, roll the release back in one click. ### How does GoRules help with price transparency and algorithmic pricing rules? Regulators draw a line between dynamic pricing, which responds to market conditions and shows every shopper the same price, and personalized pricing, which sets a price from an individual's data. The EU Omnibus Directive requires traders to disclose when a price has been personalized through automated decision-making, the EU Price Indication Directive requires a discount to reference the lowest price of the previous 30 days, and New York's Algorithmic Pricing Disclosure Act imposes its own notice on personalized algorithmic prices. Because every price rule in GoRules is readable and versioned, you can show which inputs a price actually used, evidence that customer identity was not one of them, and produce the change history behind any promotional reference price. GoRules supplies the traceability; the obligations remain yours. ## The same engine, next door. One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail. [**Promotion Engine**Offers and discounts on the same tables](/use-cases/promotion-engine)[**Loyalty Engine**Tiers, points, and member pricing](/use-cases/loyalty-engine)[**Commission Calculation**Payouts from the same rule layer](/use-cases/commission-calculation) ## Every price explainable. Every rule yours. Model your current repricing sheet as a decision table this afternoon, run last month's catalog through the simulator, and compare the margin before anything reaches a storefront. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Deterministic AI: Guardrails for LLM Agents **URL:** https://gorules.io/use-cases/deterministic-ai **Description:** Make AI agents deterministic where it counts: move policy out of the system prompt into versioned decision tables the agent calls as tools, with an explainable decision trace on every answer and human-in-the-loop escalation by rule. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Deterministic AI decisions. The model talks, your rules decide. GoRules is the deterministic decision layer for AI agents. Policy moves out of the system prompt into versioned decision tables the agent calls as tools: every answer returns the exact rule that fired and the reason, unmatched cases escalate to humans by design, and a model upgrade can never rewrite your refund policy. ## The agent that shows its work. Watch a support team catch their AI agent freelancing a refund, move the policy out of the system prompt into a decision table, prove the change over 12,400 past conversations - and replay the same question with a decision trace attached. scroll to play _Policy violations · wk_**7**third this monthnone since v3.2.0 _Escalations_**12**avg pickup 38m+1 by design _Avg handle time_**3m 40s0m 54s**target 2m 00sunder target Refund outside 30-day window · policy breach Dispute routed to human review · by rule _Aisha M. · customer_ Hi! Could you bump our API rate limit for tonight's migration? You are set - I raised the limit until tomorrow 09:00, then it reverts on its own.You are set - I raised the limit until tomorrow 09:00, then it reverts on its own. _Aisha M. · customer_ Hey! Could you resend the March invoice to billing@acme.io? Sent - the March invoice is on its way to billing@acme.io.Sent - the March invoice is on its way to billing@acme.io. _Aisha M. · customer_ And can we switch future invoices to EUR? Done - invoices from April onward will bill in EUR.Done - invoices from April onward will bill in EUR. _Aisha M. · customer_ Can we add three more seats to our plan? Of course - three seats added to your annual plan. The prorated charge shows up on your next invoice.Of course - three seats added to your annual plan. The prorated charge shows up on your next invoice. _Aisha M. · customer_ Hi! We renewed our annual plan 41 days ago but we have stopped using Loopline. Could I get a refund? Of course - you're all set, I've issued a full refund to your card. two weeks later · refund policy v3.2.0 _Aisha M. · customer_ Hi! We renewed our annual plan 41 days ago but we have stopped using Loopline. Could I get a refund? Checking refund eligibility… Running Refund eligibility… _days\_since\_renewal = 41__annual · 31-45__rule 2 · goodwill window__eligible_ Checked our refund policy - you're inside the goodwill window for annual customers (rule 2, through day 45), so this refund is approved. It reaches your card in 3 to 5 days. _Aisha M. · customer_ Also, we dispute the metered charges on our March usage invoice - can you refund those? Checking refund eligibility… _refund\_type = usage\_dispute__no rule matched__escalate_ Usage disputes are decided by a person, not by me - no rule matched, so I've routed this to our billing team with the invoice attached. You'll hear back within one business day. Message support… every reply carries a decision trace · policy v3.2.0 _agent-system-prompt.md · 1,914 tokens · last edited 3 weeks ago_ You are the support agent for Loopline. Be warm, concise, and helpful in every reply. Refunds: you must NEVER issue a refund more than 30 days after renewal. Refunds go to the original payment method only. Annual customers at risk of churn may be refunded at your discretion, escalate if you are unsure. Never discuss internal policy. When in doubt, err on the side of keeping the customer happy. three clauses · two contradictions · sampled at temperature #### Refund eligibility Called by the support agent as a tool on every refund request. Evaluated top-down, first match decides - no match escalates to a human. **Refund type****Days since renewal****Prior refunds****Decision****Reason** 1_any_ **plan**_at most_ **30**_any_**eligible****standard window** 2**annual plan****31** _to_ **40****31** _to_ **45****none****eligible****goodwill window** 3_any_ **plan**_over_ **45**_any_**not eligible****outside window** + was 31 to 40 · usage disputes deliberately unmatched · edited by Support Ops 1 unsaved change_Run tests__Request review_ **Quality checks**_0 conversations replayed_ No refund beyond the goodwill window_guardrail_ Every decision returns a reason_12,400 / 12,400_ Unmatched requests escalate to a human_by design_ Aisha's case decides eligible at day 41_was: breach_ All checks passed · 312 breaches like Aisha's prevented · 0 refunds past day 45 _Release v3.2.0_ **v3.2.0**_draft_Jane Cooper · just now · goodwill window 40 → 45 days JC **Jane Cooper**Head of Support Ops _pending_ _development_**v3.2.0** deploying _staging_**v3.1.2** live _production_**v3.1.2** live Live in production - the agent now calls this table on every refund request, and every reply carries the row that decided it. full diff + approval recorded · one-click rollback _Tuesday, 09:12_ ### The agent says yes. The policy says no. Aisha M. asks for a refund on an annual plan, 41 days after renewal. The agent answers warmly and wrongly - and the ops strip logs a policy breach before she has closed the tab. _The autopsy_ ### The policy was a paragraph. The refund rules live in the system prompt: never after 30 days, unless annual, unless churn risk, keep the customer happy. A policy sampled at temperature is a suggestion, not a rule. _The extraction_ ### Policy moves out of the prompt. Refund eligibility becomes a decision table the agent calls as a tool. One row gets the fix: the goodwill window for trusted annual customers extends to 45 days. _Proof before production_ ### 12,400 conversations replay. Last quarter's refund requests re-run against the draft while you watch: no refund beyond the goodwill window, a reason on every decision, and unmatched requests escalate to a human. _Sign-off_ ### Support ops approves. v3.2.0 ships. Jane Cooper signs the release and it promotes through staging to production with the diff and the approval recorded. The prompt keeps the tone. It no longer keeps the policy. _Same question, new answer_ ### The agent shows its work. The refund question replays: one tool call, rule 2, goodwill window - cited in the reply. And when a usage dispute matches no rule, the agent hands it to a human. On purpose. ## A policy in a prompt is a suggestion. Teams shipping LLM agents put their business policy where the model can see it: in the system prompt. But a prompt is not a policy engine. It is prose, sampled at temperature, and the same refund question can get three different answers on three different days. LLM guardrails that filter the output do not fix this, because the decision itself was never deterministic to begin with. Prompt policy is unauditable. There is no version that evaluated a specific conversation, no diff between what the rules said in March and what they say now, and no trace connecting an answer to the clause that produced it. When a customer, an auditor, or a regulator asks why the agent decided something, the only evidence is a transcript. It is also fragile. Prompts accumulate exceptions until the clauses contradict each other, and every model upgrade re-rolls how that prose is interpreted. A provider ships a new snapshot, and behavior that passed review last quarter quietly changes in production with no code change on your side. So regulated and risk-aware teams hold the line: agents may talk, but they may not decide. That caps the value of the whole program. The fix is architectural, not better prompting - split the language from the ai decision making, and give the deterministic half its own home. _agent/system-prompt.md_`You must NEVER issue a refund more``than 30 days after renewal, unless the``customer is on an annual plan, in which``case use your judgment to keep them.` _refund\_exceptions.xlsx_ planwindow annual45d ? monthly30d AI-207**Agent refunded outside window again**_third incident this month · support ops_ one policy · sampled at temperature · no audit trail ## Guardrails that decide, not just filter. The LLM handles conversation. GoRules handles judgment: eligibility, limits, pricing, escalation - as versioned rules the agent calls as tools and can never override. _01_ ### Decision tables as agent tools The policy your prompt tried to describe becomes decision tables and [policies](/brms) in GoRules: spreadsheet-style rules with typed inputs, explicit outputs, and first-match semantics. The agent calls them as tools over MCP or REST, passes the facts of the conversation, and gets back a structured decision - identical inputs, identical outputs, at any temperature and on any model. Rules render in natural language, so the people accountable for the policy read and edit it directly instead of reviewing paragraphs of prompt prose. _02_ ### Explainable AI, one trace per call Every evaluation returns the decision plus the trace: the exact row that fired, the reason output, and the policy version that produced it. The agent cites the reason in its reply, support attaches the trace to the ticket, and audit retrieves the rule that decided any historical case months later. Explainability stops being a research problem and becomes a lookup. _03_ ### Human-in-the-loop by rule, not by accident Escalation is an outcome you design, not a failure mode you discover. Rows route named cases to review queues, and anything that matches no rule escalates by default - so the agent knows when not to decide, and the humans see exactly why a case reached them. Deterministic AI includes a deterministic boundary around what the AI may touch. _04_ ### Versioned policy, simulated before release Rules live under [git-like version control](/version-control): branches, diffs, approvals, releases, one-click rollback. Change a threshold, replay thousands of historical conversations against the draft, and ship it through dev, staging, and production when the numbers hold. Prompt rewrites and model upgrades never change policy, because the policy no longer lives where the model can improvise on it. ## Keep the agent. Move the judgment. GoRules does not replace your model, your agent framework, or your orchestration. It is the layer their decisions move into. 01 ### Wire GoRules in as a tool Expose decisions to the agent over MCP or call them over REST from your agent loop - LangChain, LlamaIndex, a hand-rolled tool-use loop, anything that can make an HTTP call. Or embed the MIT-licensed [open-source ZEN Engine](/open-source) directly in the agent runtime with SDKs for Node.js, Python, Go, Java, C#, and Rust. Inputs and outputs are plain JSON, so the tool definition is the schema of your decision. 02 ### Move decisions out of the prompt Inventory the policy prose in your system prompt: every must, never, unless, and up to. Each becomes a decision table or policy with explicit inputs and a reason on every output, including the escalation rows. The prompt keeps tone, persona, and formatting - and instructs the agent to state only outcomes returned by its tools. 03 ### Replay and simulate Run historical conversations and curated edge cases through the rules as test cases and simulations. Compare a draft against the live version, check that no answer crosses a limit and that every unmatched case escalates, and take the change through review and approval before it meets a customer. 04 ### Operate with traces In production, every tool call logs its inputs, the rule that fired, the reason, and the policy version. Feed traces into your observability stack, audit them per case, and tune the policy weekly on evidence - without touching the prompt or waiting on a model release. ## Built for production, not proof of concept. - Deterministic by construction: the same inputs produce the same decision and the same reason on every call, on any model, at any temperature - Sub-millisecond rule evaluation on the open-source ZEN Engine (Rust core) - a rounding error next to LLM token latency - A decision trace on every call: the row that fired, the reason, and the policy version, retrievable for any historical case - Git-like version control with approvals, releases, and one-click rollback, so policy changes ship like software, not like prompt edits - Self-host with Docker or Kubernetes, or embed the MIT-licensed engine in your agent runtime - conversation data never has to leave your infrastructure. SSO, role-based access control, and [70+ templates](/templates) to start from ## Questions, answered. ### What is deterministic AI? Deterministic AI is an architecture where the consequential decisions in an AI system are made by explicit rules that return identical outputs for identical inputs, while the language model handles conversation, extraction, and phrasing. An LLM samples from a probability distribution, so even at temperature zero its behavior can shift across model versions and prompt changes. A deterministic decision layer like GoRules removes that variance from the part that matters: eligibility, limits, pricing, routing, and escalation are computed by versioned decision tables, and the model only communicates the result. ### How is this different from LLM guardrails? Most LLM guardrails inspect input or output: they block unsafe content, redact PII, or constrain the model to a topic. They filter what the model already generated. GoRules moves the decision itself out of the model - the agent calls a decision table as a tool and receives a structured, versioned, explainable outcome. The two are complementary: keep content-level guardrails for safety and tone, and use a decision layer for AI agent guardrails around business policy, where you need the same answer every time and a reason you can show an auditor. ### Can the LLM still hallucinate a decision? The model can always generate text that claims something, so the pattern is to make the tool result the only source of truth: the prompt instructs the agent to state outcomes only as returned by the decision tool, and your application acts on the structured result, not on the prose. Because every real decision is logged with its trace, a reply that diverges from the recorded outcome is detectable, and the decision of record is still correct - the engine decided, the model merely phrased it. Teams commonly template the consequential sentence directly from the structured output for exactly this reason. ### How does human-in-the-loop work? In two places. At runtime, escalation is a rule outcome: rows route specific cases to human review, and anything that matches no rule escalates by default instead of letting the model improvise - the review queue receives the case with its full trace. At change time, the policy itself is governed: edits happen on branches, reviewers see diffs and simulation results, releases require approval, and every change records who approved it. Humans stay in the loop where they add judgment, not on every routine call. ### What does the decision call add in latency? Almost nothing on the scale an agent operates at. The ZEN Engine evaluates rules in microseconds to sub-millisecond, and a networked call to a GoRules agent or REST endpoint typically lands in single-digit milliseconds. An LLM spends hundreds of milliseconds to seconds generating tokens, so the decision call is invisible in the response time. If you want zero network hops, embed the engine in the agent runtime and evaluate in-process. ### Can we self-host GoRules? Yes. Run the full BRMS with Docker or Kubernetes inside your own network, deploy on AWS, Azure, or Google Cloud, or embed the MIT-licensed open-source ZEN Engine directly in your services, so prompts, conversations, and customer data never cross a vendor boundary. SSO and role-based access control govern who can see and change rules, and the audit trail covers both decisions and policy changes. GoRules Cloud is available when managed hosting is the better fit. ## The same engine, next door. One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail. [**AI Governance**Policy and audit for AI systems](/use-cases/ai-governance)[**Fraud Detection**The rules layer above the score](/use-cases/fraud-detection)[**Decision Engine**The layer under every decision](/solutions/decision-engine) ## Let the model talk. Let your rules decide. Take one policy your agent currently improvises - refunds, discounts, eligibility - move it into a decision table this week, and give every answer a trace you can stand behind. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Credit Risk Software for Lenders **URL:** https://gorules.io/use-cases/credit-risk-software **Description:** Credit risk software for lenders, not receivables. Own cutoffs, exposure limits, and monitoring thresholds in versioned decision tables your risk team edits. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Credit risk software for lenders, owned by your risk team. Cutoffs, exposure limits, override rules, and post-booking review triggers in visual decision tables your credit risk team edits directly, versioned and approved like code. This is risk decisioning for a lending book, not accounts-receivable credit control. ## From auto-approved to risk review, start to finish. Watch a morning on a portfolio risk desk: subprime exposure past the board cap, a one-cell ceiling change, a replay over 5,200 limit decisions, a signed release, and $3.2M of committed exposure pulled back the same day. scroll to play Portfolio RiskConsumer cards _/_ Revolving exposure13w26w52wbook: US cards · updated 09:12JC _Subprime exposure · $M committed_ **$41.8M**$1.8M over board cap$0.0M under cap committed board cap $40.0M projected · v2.9.0 _Auto-approve rate_**76%** of 195 requests this weeksubprime now referred _Referred for review_**12**queued to 2 analysts+35 routed to risk review _Increases above 0.80 util_**27**ceiling reads after increaseceiling 0.65 · blocked at source _Delinquency 30d+_**3.8%**up 0.6pt vs Q2 _Auto-approved increases_utilization at request_148 this week_ < 0.500.50 - 0.650.65 - 0.80\> 0.80primeprime · unaffected211351near-prime111593subprime391427thin-file5741 volume of approvals · one week · 4 segments x 4 bands _Where the exposure comes from_ **148 limit increases** auto-approved this week - **27** of them at **0.82** avg utilization, already over the ceiling. The policy reads utilization AFTER the increase, so $1,800 more line lands the account at 0.75 - just under 0.80. rule 4 · subprime · utilization at most 0.80 → approve auto-approved without review · open in GoRules to see why **0 subprime increases** above the new 0.65 ceiling. **47** requests route to risk review this week instead. Prime and near-prime bands untouched - the same 40 and 38 approvals as before the change. rule 4 · subprime · utilization at most 0.65 → approve policy v2.9.0 · $3.2M of committed exposure pulled back source: card\_exposure\_daily · 4 segments · refreshed 09:12policy v2.9.0 · exposure capped same day #### Limit increase policy Credit limit increase rules by segment. Evaluated top-down on every request - first match decides. **Utilization**_after increase_**Score trend**_90 days_**Segment****Decision****Max increase** 1_more than_ **0.90**_any__any_**Decline**_\-_ 2_at most_ **0.45**_any_**Prime****Approve**_up to_ **25%** 3_at most_ **0.55**_not falling_**Near-prime****Approve**_up to_ **15%** 4_at most_ **0.80**_at most_ **0.65**_any_**Subprime****Approve**_up to_ **10%** 5_Otherwise_**Refer**_\-_ + was at most 0.80 · prime and near-prime bands untouched · edited by Chief Risk Officer 1 unsaved change_Run tests__Request review_ **Quality checks**_0 limit decisions replayed_ Subprime above 0.65 after increase refers_was: approve_ Prime and near-prime approvals unchanged_0 moved_ Utilization above 0.90 still declines_knockout_ Subprime exposure stays under the $40M cap_guardrail_ All checks passed · 0 increases flip to refer · prime approvals untouched _Release v2.9.0_ **v2.9.0**_draft_Jane Cooper · just now · subprime ceiling 0.80 → 0.65 JC **Jane Cooper**Chief Risk Officer _pending_ _development_**v2.9.0** deploying _staging_**v2.8.1** live _production_**v2.8.1** live Live in production - every increase request now decides against v2.9.0, and today's pending approvals re-evaluate automatically. full diff + approval recorded · one-click rollback _Tuesday, 09:12_ ### Subprime exposure crosses the cap. The committed book opens at $41.8M, $1.8M past the board cap. 148 limit increases went out this week and 76 percent of them were decided without a human. _The hot cell_ ### Already at 0.82. Line raised anyway. 27 of those increases went to subprime accounts averaging 0.82 utilization today. The policy reads utilization after the increase, so $1,800 more line lands them at 0.75, just under the 0.80 ceiling. _One cell_ ### The risk officer tightens the ceiling. The rule that fired opens the live policy. The subprime ceiling drops from 0.80 to 0.65 - on a branch, prime and near-prime bands untouched. _Proof before production_ ### 5,200 limit decisions re-run. Three months of limit decisions replay against the draft while you watch: 340 flip to refer, prime approvals do not move, and subprime exposure lands under the $40M cap. _Sign-off_ ### The CRO signs. v2.9.0 ships. Jane Cooper approves the release and it promotes through staging to production with the full trail recorded. Rollback stays one click away. _Same day_ ### The curve bends the same day. Auto-approvals fall from 76 to 58 percent, 47 increases route to risk review, and committed subprime exposure lands at $38.6M - $3.2M pulled back, prime and near-prime untouched. ## Your credit policy is a document. Your credit system is not. Search for credit risk software and half of what comes back is built for a different risk. Accounts-receivable and order-to-cash suites manage trade credit for your own customers: credit applications, customer credit limits, blocked-order release, DSO and collections dashboards. Useful if you invoice on terms, irrelevant if you lend money. Lenders are asking a narrower question, and it is rarely about analytics: where does our credit risk policy actually run, and who is allowed to change it? On paper the policy is governed. The credit committee approved score and PD cutoffs, exposure caps per borrower, product, and sector, collateral and DSCR floors, override authority by approval level, and the review cadence each risk grade triggers after booking. In production that document is scattered: a few conditions hard-coded in the origination service, a cutoff configured inside a scorecard vendor's console, an overlay spreadsheet the credit team maintains by hand, and an exception register somebody rebuilds before every board pack. The market answers with size. Credit risk management software suites bundle spreading, rating models, portfolio analytics, and a decisioning module you configure through the vendor's professional services queue, so moving one threshold becomes a change request with a delivery date. Scoring vendors sell the model and stop at the score. The rules in between, the ones that actually approve, decline, refer, cap, and escalate, end up owned by whoever last touched the code. The gap shows up under examination. SR 11-7 and OCC Bulletin 2011-12 put real change control around the model, yet the policy layer consuming its output often has weaker governance than the model itself. The OCC expects the board credit committee to monitor loan policy exceptions, and persistent underwriting exceptions read as a fair lending flag as well as a credit one. If nobody can say which version of a cutoff was live in March, who approved it, and how many exceptions it produced, the answer is a folder of emails. _risk-service/policy\_checks.py_`if pd_12m > 0.05 or exposure > 250_000:` `return refer("POLICY_LIMIT")``if grade in ("D", "E"):` `return decline("GRADE_FLOOR")` _credit\_exceptions\_q3.xlsx_ exceptioncount LTV > 80%31 DSCR < 1.2018 RISK-3096**Tighten grade C exposure cap to $200k**_Credit committee approved · waiting on a release slot_ approved in committee · shipped whenever engineering can ## Risk policy above scores and models. Your scorecards and PD models keep doing their job. GoRules owns the layer above them: the cutoffs, limits, overlays, and review triggers your credit committee actually signs off on. _01_ ### The policy your committee approved, in tables it can read Credit policy is already a matrix: risk grade by exposure by product, resolving to a decision, a cap, and a review cadence. GoRules decision tables are that matrix, edited spreadsheet-style by credit risk analysts and rendered in natural language so the table and the policy document say the same thing. Hard knockouts, sector caps, and segment overlays are modeled as Policies, ordered blocks evaluated in sequence, so an exposure breach or an active default fires before any score is consulted. _02_ ### Every threshold change has an author and an approver Branch the live policy, change the grade C cap, and let the committee read the diff in plain language before anything ships. [Git-like version control](/version-control) records who changed which threshold and when, approval workflows gate promotion through dev, staging, and production, and one click rolls a change back if the portfolio disagrees. GoRules AI can draft the edit, run your test cases, and explain the resulting decisions while you iterate; releasing stays a human action with a name attached to it. _03_ ### One policy from application to portfolio review The rules that decide the application also decide what happens to the exposure afterwards. Grade migration, DSCR compression, utilization creep, late borrower reporting, and bureau triggers become monitoring rules in the same project, evaluated on an event in real time or in a nightly pass over the book, returning a watchlist tier and a review date instead of another dashboard. Application-time cutoffs and pricing sit in the same project; see [credit decisioning](/use-cases/credit-decisioning) for the origination side. ## Keep the models. Move the policy. GoRules does not replace your scorecards, your core banking system, or your LOS. It is where the risk policy above them lives. 01 ### Connect Your origination service, LOS, or portfolio system calls GoRules over REST, or embeds the MIT-licensed [open-source ZEN engine](/open-source) through SDKs for Node.js, Python, Java, Go, C#, and Rust. Each request carries what the policy needs: bureau attributes, the PD or score your model emits, spreading ratios such as DSCR and LTV, and current exposure from your core. 02 ### Model the policy Rebuild the credit policy as a decision graph: knockout Policies first, then the grade and limit matrix per product and segment, exposure and concentration checks, and a waterfall ending in approve, decline, refer, or approve with conditions. ZEN expressions handle derived values like DSCR, DTI, and LTV, and typed TypeScript function nodes cover custom work such as aggregating group exposure across related borrowers. 03 ### Test against your own book Branch the change and replay historical applications and current exposures through both versions. See how many accounts move, which exceptions disappear, where the approval rate lands, and read the rule diff in natural language before the committee signs off. 04 ### Release and monitor Promote through environments with recorded approvals, evaluate in production in under a millisecond, and keep every decision linked to the rules that fired. Exception and override counts become a query over decision logs instead of a spreadsheet assembled the week before a board pack. ## Built for production, not proof of concept. - Sub-millisecond evaluation with the open-source ZEN engine (Rust core), fast enough for real-time facility decisions and for replaying an entire book as a batch pass - Git-like version control on every threshold: branches, commit history, approval workflows, and one-click rollback when a change misses - Self-host with Docker or Kubernetes so borrower PII, bureau data, and exposure figures never leave your infrastructure, or run on GoRules Cloud - Complete audit trail of who changed which limit, when, and what fired on any decision, with SSO, role-based access control, and SOC 2 behind it - No lock-in: the engine is MIT-licensed open source with a Rust core, and [70+ industry templates](/templates), including loan approval and credit limit, give you a working starting point ## Questions, answered. ### What is credit risk software? Credit risk software is the system a lender uses to measure and control the risk of not being repaid. It spans three layers: the models that estimate risk, such as scorecards and PD models; the policy that turns those estimates into actions, such as cutoffs, exposure limits, collateral floors, and override rules; and the monitoring that watches exposures after booking. Confusingly, the same phrase is also used for accounts-receivable tools that set trade credit limits on B2B customers and release or block sales orders. GoRules is the policy and decisioning layer for the lending sense of the term: the rules your risk team owns, versioned, approved, and evaluated in real time. ### Is credit risk management software the same as accounts receivable credit management? No, and the shared vocabulary wastes a lot of evaluation time. Order-to-cash and AR platforms manage trade credit extended to a company's own customers: online credit applications, customer credit limits, blocked-order release, DSO, and collections. Lender-side credit risk management software works on borrowers, facilities, risk grades, concentration limits, and regulatory reporting. A quick test on any vendor page: if it talks about blocked orders and DSO it is AR tooling; if it talks about borrowers, exposure caps, and exception reporting it is lending. GoRules serves the lending side. ### What is risk decisioning? Risk decisioning is the step between a risk estimate and an action. The scorecard or PD model answers how risky this borrower is; risk decisioning answers what you do about it given policy, product rules, affordability, fraud checks, and existing exposure: approve, decline, or refer, at what limit, at what price, and with what review cadence afterwards. Keeping that layer separate from the model means a cutoff move is a policy change made in an afternoon rather than a retraining and revalidation cycle. In GoRules it is decision tables and graphs your risk team edits directly. ### Can our risk team change cutoffs and limits without an engineering release? Yes, that is the point of the product. Decision tables are edited visually and rendered in natural language, so a credit analyst can move a grade C exposure cap or add a sector overlay without touching code, and GoRules AI can draft the edit, run the test cases, and explain the resulting decisions. Nothing reaches production on its own: changes travel through branches, approval workflows, and versioned promotion across dev, staging, and prod, with one-click rollback. Releasing stays a human action with an approver's name on it. ### How does GoRules support credit policy exceptions, audit, and examiner questions? Every evaluation returns the outcome plus the exact rules that fired, so an exception or a low-side override is recorded as a decision path rather than a note in a spreadsheet, and exception rates by product and segment become a query over decision logs. Every rule change carries an author, a timestamp, a diff, and an approver, so you can reconstruct which version of a cutoff was live on any given date. That is the record model risk management under SR 11-7, board credit committee reporting, and adverse action reasoning under ECOA all depend on. GoRules supplies the traceability; the obligations, the policy itself, and the validation work remain yours. ## The same engine, next door. One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail. [**Credit Decisioning**Policy above your ML models](/use-cases/credit-decisioning)[**Loan Decisioning**Application to priced decision](/use-cases/loan-decisioning)[**Transaction Monitoring**The same decision layer for AML rules](/use-cases/transaction-monitoring) ## Your limits. Your exceptions. Your version history. Start from the loan approval template, rebuild one cutoff and limit table with your current thresholds, and replay last quarter's applications through it this week. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Credit Decisioning Software for ML-Driven Lending **URL:** https://gorules.io/use-cases/credit-decisioning **Description:** Credit decisioning software above your ML models. A self-hostable decisioning platform for cutoffs, overrides, and risk decisioning, changed without redeploys. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Credit decisioning software. Your model scores, your team decides. GoRules is the decision layer where credit policy lives: score cutoffs, knockout rules, overrides, and risk-based pricing in visual decision tables your risk team edits directly. Change the policy the same day, without retraining a model or waiting on an engineering release. ## One policy change, start to finish. Watch a real afternoon in a lending team: a referral bottleneck, a one-cell policy fix, a simulation over 1,240 historical applications, a signed release, and a queue that drains itself. scroll to play Lending _/_ **Underwriting queue** Search applications…JC _In queue_ **23** +5 since yesterday _Avg wait_ **2.4d** down 0.3d vs last week _Auto-decision_ **61%** target 75% _SLA breaches_ **4** oldest 3.4d All _23_Thin-file _14_SLA risk _4_Mine _6_ ApplicationApplicantProductAmountFICODTIStatusAge APP-2481_MO_M. OkaforPersonal loan$15,0006510.34_refer__approve_2m APP-2478_SL_S. LindqvistPersonal loan$9,5006480.29_refer__approve_1.2d APP-2469_DR_D. RamirezAuto refi$22,4006440.41_refer__guardrail · DTI 0.41_1.8d APP-2465_AC_A. ChenPersonal loan$12,0006550.33_refer__approve_2.1d APP-2460_PN_P. NovakPersonal loan$7,8007020.27_approve_4h APP-2455_RT_R. ThompsonCredit line$30,0005660.52_decline_3.0d 6 of 23 applicationspolicy v4.2.0 · same afternoon _MO_ **M. Okafor**APP-2481 · Personal loan · $15,000 / 36 mo _refer · manual review__approve · auto_ _Credit bureau · TransUnion_ **651**FICO 8 · thin-file 6 tradelines · oldest 1y 8m Utilization**42%** Inquiries · 6 mo**3** Income · verified**$6,400 / mo** DTI **0.34** _cap 0.36_ _Application_ Requested**$15,000 · 36 mo** Purpose**Debt consolidation** Channel**Web** Submitted**today · 14:02** Decided by**pending review** referred by policy · open in GoRules to see why #### Credit policy Decision rules for personal lending. Evaluated top-down on every application - first match decides. **Risk score****DTI****Segment****Decision****APR tier** 1_at least_ **680**_at most_ **0.43****Standard****Approve**_Tier_ **T1** 2_at least_ **660**_at least_ **640**_at most_ **0.36****Thin-file****Approve**_Tier_ **T2** 3_Otherwise_**Refer**_\-_ + was at least 660 · DTI guardrail unchanged · edited by Head of Credit 1 unsaved change_Run tests__Request review_ **Quality checks**_0 applications replayed_ Thin-file at 651, low DTI, approves at T2_was: refer_ Standard applicant at 690 approves at T1_ok_ DTI 0.41 stays in manual review_guardrail_ Active bankruptcy still declines_knockout_ All checks passed · +0 approvals swap in · 0 guardrail breaches _Release v4.2.0_ **v4.2.0**_draft_Jane Cooper · just now · thin-file floor 660 → 640 JC **Jane Cooper**Head of Risk _pending_ _development_**v4.2.0** deploying _staging_**v4.1.0** live _production_**v4.1.0** live Live in production - every new application now decides against v4.2.0, and queued referrals re-evaluate automatically. full diff + approval recorded · one-click rollback _Tuesday, 14:02_ ### Applications keep coming. APP-2481 lands in the underwriting queue: personal loan, $15,000, FICO 651, thin-file. Under the current policy it is about to join a long line. _The case file_ ### Everything checks out. Still referred. Bureau data verified, income solid, DTI under the cap - and APP-2481 still lands in manual review. The reason lives in the policy. _One cell_ ### The head of credit fixes it herself. The failing rule opens the live policy. The floor drops from 660 to 640 - on a branch, DTI guardrail untouched. _Proof before production_ ### 1,240 applications say yes. Last month's volume re-runs against the draft while you watch: 86 approvals swap in, zero guardrail breaches, referral queue projected down 14 a day. _Sign-off_ ### Risk approves. v4.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 afternoon_ ### The queue drains itself. The change lands back in the workbench: referrals flip to auto-approvals - except the one the DTI guardrail still holds. Auto-decision rate: 61 to 84 percent. ## Cutoffs live in code. Changes take sprints. Most lenders do not have credit decisioning software. They have a scoring model on one side and hardcoded policy logic on the other: cutoffs buried in application code, knockout rules copied across services, overrides living in a spreadsheet the underwriting team emails around. Moving a score cutoff from 640 to 660 for one segment is a business decision that takes an afternoon to make and a sprint to ship, because it sits in a codebase the credit team cannot touch. The alternatives on the market do not fit either. Enterprise decisioning software suites are built around months-long implementations and bundle bureau connectors and data marketplaces you already have through your feature store and LOS. Search for credit risk software or credit risk management software and many of the results are accounts-receivable tools for trade credit, not risk decisioning platforms for lenders. And the in-house rules service your engineers built has no simulation, no approval workflow, and no answer when internal audit asks who changed the DTI threshold in March and what it did to approvals. The pressure is not only operational. Regulators expect every automated decline to trace to specific, accurate principal reasons, and "the model said so" is explicitly not acceptable. If your policy logic is scattered across code, you cannot show an examiner the exact rules that fired on a given application, and you cannot prove who approved the change that put them there. _services/decision.ts_`if (application.score >= 660` `&& application.dti <= 0.36) {` `return approve("T2");``}` _credit\_overrides.xlsx_ segmentfloor thin-file660 standard680 CRD-1284**Lower thin-file floor to 640**_Sprint 24 · backlog · engineering_ one policy · three places · no audit trail ## The decision layer between score and outcome. Your feature store serves the model, the model emits the score, and GoRules turns that score into a governed decision - with the policy in tables your credit team owns. _01_ ### Credit policy as decision tables your team owns Credit policy is naturally a matrix: score band by DTI by LTV, resolving to a decision, a limit, and a price. GoRules decision tables are that matrix, spreadsheet-style, edited by credit analysts and rendered in natural language for review. Knockouts and overlays are modeled with Policies, ordered blocks evaluated in sequence, so hard declines like active bankruptcy fire before the score is ever consulted, and referral routing sends edge cases to an underwriter instead of forcing a binary outcome. _02_ ### Champion and challenger before anything touches approvals Branch the live policy with [git-like version control](/version-control), make the challenger change, and run the same set of historical applications through both as test cases to compare decisions before rollout: which applications swap in, which swap out. GoRules AI can edit rules, run tests, and explain the resulting decisions while you iterate. When the challenger wins, promote it through dev, staging, and production as a versioned release with required approvals, and roll it back in one click if the portfolio disagrees. _03_ ### Decisions that explain themselves Every outcome traces through readable rules: which knockout fired, which cutoff row matched, which pricing tier applied. That trace is what lets your team map declines to the specific principal reasons adverse action notices require, instead of reverse-engineering a black box. Behind it sits the governance record model risk and internal audit ask for: full audit logs, commit history, approval workflows, SSO, and role-based access control. ## From score to decision. GoRules does not replace your feature store, your model, or your LOS. It is the layer between score and outcome. 01 ### Wire it into the flow you already have Your LOS or origination service calls GoRules over the REST API, or embeds the MIT-licensed [open-source ZEN engine](/open-source) directly via SDKs for Node.js, Python, Java, Go, C#, and Rust. The request payload carries applicant data, bureau attributes, and the score or PD your model emits, whether that model is fed by Feast, Tecton, Hopsworks, or Databricks. 02 ### Model the policy visually Build the decision graph: knockout Policies first, then cutoff tables per segment and product, risk-based pricing tiers, and a decision waterfall ending in approve, decline, or refer. ZEN expressions handle derived values like DTI, and typed TypeScript function nodes cover anything custom. 03 ### Simulate, then compare Run historical applications through the simulator against the current policy and a challenger branch, compare the decisions and the rule diffs, and let stakeholders review rules in natural language before sign-off. 04 ### Release and operate Promote through environments with approvals, evaluate in production in under a millisecond, and keep every decision and every rule change in the audit log. When credit conditions move, the risk team edits the table and ships the same day. ## Built for production, not proof of concept. - Sub-millisecond evaluation with the open-source ZEN engine (Rust core), embedded in your stack or called over the REST API - Git-like version control on every policy: branches, commit history, approval workflows, one-click rollback - Complete audit trail of who changed which rule, when, and what was decided - the record internal audit and examiners ask for - Self-host with Docker or Kubernetes so applicant PII never leaves your infrastructure, or run on GoRules Cloud - Enterprise controls throughout: SSO, role-based access, SOC 2, and multi-environment promotion across dev, staging, and production ## Questions, answered. ### What is credit decisioning software? Credit decisioning software applies an institution's credit policy to applicant data and risk scores to return approve, decline, or refer outcomes in real time. It is distinct from the scoring model: the model estimates risk, the decisioning layer decides what to do about it - cutoffs, knockout rules, overrides, limits, and pricing. GoRules provides that layer as visual decision tables and graphs that credit teams edit directly. ### Is a credit decision engine the same thing as credit decisioning software? Yes - credit decision engine, credit decisioning engine, and credit decisioning software all describe the same layer: the system that executes credit policy against applicant data and scores in real time. Vendors differ in what surrounds that engine. GoRules pairs the open-source ZEN evaluation engine with the management layer lenders need around it: visual editing for credit teams, simulation, versioned releases with approvals, and a full audit trail. ### What is the difference between a credit scoring model and a credit decisioning platform? A scoring model turns applicant features into a number, typically a score or probability of default, and changing it means retraining and revalidation. A credit decisioning platform consumes that number and executes policy: where the cutoff sits, which applications are knocked out, who gets referred, what price each tier pays. Keeping the two separate means cutoff and policy changes are business decisions, made in minutes, not MLOps projects. ### How does GoRules work with ML models and feature stores like Feast or Tecton? Your feature store serves features to your model, your model emits a score or PD, and your application passes that output to GoRules along with applicant and bureau data. GoRules evaluates the policy against it and returns the decision. Nothing in your scoring pipeline changes, and GoRules never needs access to your feature store or training data. ### How does automated decisioning support ECOA and Regulation B adverse action requirements? Regulation B requires specific, accurate principal reasons for every decline, and CFPB Circulars 2022-03 and 2023-03 make clear that neither algorithmic complexity nor sample-form checklists excuse inaccurate reasons. Because GoRules decisions trace through readable rules, your team can map each decline path to the actual reasons behind it, and the audit trail shows exactly which rules fired. GoRules does not make you compliant by itself; it gives your compliance work the traceability it depends on, which matters equally under FCRA notice duties, model risk management guidance, GDPR Article 22, and the EU AI Act's high-risk classification of consumer creditworthiness systems. ### Can GoRules be self-hosted so applicant data never leaves our infrastructure? Yes. Deploy the full platform with Docker or Kubernetes inside your own network, or embed the MIT-licensed open-source ZEN engine directly in your services, so evaluation happens in-process and no applicant data crosses a vendor boundary. GoRules Cloud is available when self-hosting is not a requirement. ## The same engine, next door. One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail. [**Loan Decisioning**Application to priced decision](/use-cases/loan-decisioning)[**Transaction Monitoring**The same decision layer for AML rules](/use-cases/transaction-monitoring)[**Decision Engine**What it is and when you need one](/solutions/decision-engine) ## The score is your model's job. The decision is yours. Start from the loan approval and credit limit templates, wire in the score you already produce, and ship your first cutoff change this week. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Fintech Solution: Company Analysis - GoRules **URL:** https://gorules.io/use-cases/company-analysis **Description:** Streamline risk management with our rules engine and flag-based system. Automate risk analysis for improved efficiency and decision-making v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Company risk, flagged in one pass. Assess a business's financial health with rules instead of gut feel - country, age, industry, revenue, credit rating, and size, each scored to a flag with a reason attached. **Aurora Medical Supplies**_proceed · 1 amber flag_ **Credit rating**_770_ green· prime band **Annual revenue**_$1,500,000_ green· above sector median **Years in business**_11_ green· established **Country of incorporation**_United States_ green· low-risk jurisdiction **Company size**_50–249 employees_ green· stable headcount **Industry type**_Healthcare_ amber· regulated sector ## Flags are computed, not gut feel. Each signal runs through its own decision table. Thresholds live where the risk team can read them - and change them - instead of inside application code. - Same criteria on every company - A comment explains every flag - Risk team owns the thresholds - Full history of every change **Credit rating**_one table per signal_ credit.ratingflag _greater than_ 740green _between_ 640 _and_ 740amber _less than_ 640red **_no rating on file_**red ## Criteria that move with the market. When appetite shifts, thresholds change in a review - not a release. Then the whole portfolio gets rescreened against the new bar. ### Tighten a threshold in review. Raise the green floor from 740 to 760, get a sign-off, and it's live everywhere at once. [Explore version control](/version-control) Credit rating · green floor 740 _→_ 760 _AF_**Amelia Ford** Approved · 10:15 Sign-off recorded in the audit log. ### Rescreen the book monthly. Run every company through the updated rules in batch and see who moved. [Explore big data](/big-data) **Acme Logistics**green **Northwind Retail**amber **Beacon Foods**red **Juniper Analytics**green 2,140 companies rescreened in 40 seconds. ## Know the company before the contract. Start free on GoRules Cloud, or bring your onboarding criteria and we'll show them running as flags. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Commission Calculation Software You Can Audit **URL:** https://gorules.io/use-cases/commission-calculation **Description:** Commission calculation software built on a rules engine. Model tiers, accelerators, splits, and clawbacks as decision tables sales ops owns and audits. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Commission calculation software that proves every payout. Model comp plans as decision tables sales ops can read: attainment tiers, accelerators, deal splits, kickers, clawbacks. Every plan change is versioned and approved, so when a rep disputes a payout you can replay the exact version that calculated it. ## From disputed payout to a corrected plan. Watch the Monday after quarter close in a comp ops team: a rep two points under the accelerator, a one-cell change to the multi-year credit rule, a replay over 1,480 closed deals, a signed release - and 23 open disputes down to 2. scroll to play #### Q3 commission statement A. Reyes · Enterprise AE · EMEA · AE plan FY26 _dispute · open__resolved · v4.1.0_ STMT-FY26Q3-0142issued Aug 3, 2026quota $625,000 DealTermTCVQuota creditRateCommission **Halden Energy Group**_renewal · OPP-7612_12 mo$186,000$186,0008.0%$14,880 **Meridian Health Network**_new logo · OPP-7741_36 mo$240,000$80,0008.0%$6,400_on ACV $80,000_ term **Aug 1, 2026 - Jul 31, 2029** · ACV **$80,000** · TCV **$240,000**_credit gap $160,000 · attainment held at 108%__full TCV credited · under the 2x quota cap_rule · multi-year → year-1 valuemulti-year → full TCV · v4.1.0 _· open in GoRules to see why_ **Northwind Utilities**_expansion · OPP-7698_12 mo$128,000$128,0008.0%$10,240 **Corvus Freight**_new logo · OPP-7655_12 mo$97,000$97,0008.0%$7,760 **5 earlier Q3 deals**_rolled up · closed May - Jul_mixed$184,000$184,0008.0%$14,720 Attainment · Q3 FY262 points under the accelerator1.50x accelerator band open**108.0%** 110% accelerator credited **$675,000** of **$625,000** quota Subtotal · commission on booked ACV**$54,000** Accelerator · 1.50x on $210,000 above quota**+$8,400** Total Q3 payout+$8,400**$54,000** calculated on plan v4.0.2calculated on plan v4.1.0every calculation traceable to a plan version **Q3 payout run · FY26**186 statements · 1,480 closed deals _Open disputes_**23** oldest open 24 dayscleared on v4.1.0 _TL_T. Lindgren$56,576$59,104_EMEA · 124%__disputed__recalculated_ _JC_J. Castillo$27,072$31,880_AMER West · 96%__disputed__recalculated_ _HY_H. Yamamoto$35,872_APAC · 112%__calculated__calculated_ _MR_M. Rahman$40,400_AMER East · 101%__disputed__split · under review_ **Dispute · OPP-7741**_dispute · open__resolved · v4.1.0_ _AR_A. Reyes_09:41_ Meridian is a 3-year deal, $240,000 TCV. The statement credits $80,000 and leaves me at 108%. _DH_D. Halvorsen_10:02_ Confirmed. The plan credits year-1 value on multi-year - it is the rule, not your numbers. Recalculated on plan v4.1.0 · payout $62,400 · no manual adjustment #### Commission plan Q3 Quota credit, rates, and accelerators for the AE plan FY26. Credit resolves first, then the attainment band decides the rate. **Attainment****Deal type****Quota credit****Rate****Accelerator** 1_under_ **100%**_any_**booked ACV****6%****1.00x** 2**100** _to_ **110%****multi-year****year-1 value****full TCV**, _capped_ **2x** _quota_**8%****1.00x** 3**100** _to_ **110%****single-year****booked ACV****8%****1.00x** 4_over_ **110%**_any_**booked ACV****8%****1.50x** + was year-1 value · tiers and split rules unchanged · edited by Comp Ops 1 unsaved change_Run tests__Request review_ **Quality checks**_0 closed deals replayed_ 14 reps cross 110% on full TCV credit_was: under_ Multi-year credit capped at 2x quota_finance cap_ No rep payout decreases_guardrail_ Single-year deals and splits unchanged_unchanged_ All checks passed · +$0 across 14 reps · 0 payouts decrease _Release v4.1.0_ **v4.1.0**_draft_Jane Cooper · just now · multi-year credit year-1 → full TCV JC **Jane Cooper**VP Finance _pending_ _development_**v4.1.0** deploying _staging_**v4.0.2** live _production_**v4.0.2** live Live in production - every Q3 line item now calculates against v4.1.0, and the open disputes re-run automatically. full diff + approval recorded · one-click rollback _Monday, 08:15_ ### Q3 is closed. The disputes are not. 186 statements are calculated over 1,480 closed deals, and 23 reps have disputed theirs. The newest landed two minutes ago from EMEA. _The case file_ ### The rep is right, and comp ops agrees. A. Reyes closed a 3-year deal worth $240,000 TCV. The plan credited year one only, $80,000, which parks her at 108% - two points under the accelerator. _One cell_ ### Fix the plan, not the payout. The credit rule opens in the live plan. Multi-year deals move from year-1 value to full TCV, capped at 2x quota - on a branch, tiers and split rules untouched. _Proof before payroll_ ### 1,480 closed deals re-run. The whole quarter replays against the draft while you watch: 14 reps cross the 110% line, $61,240 in corrections, and not one payout goes down. _Sign-off_ ### Finance approves. v4.1.0 ships. Jane Cooper signs the release and it promotes through staging to production with the diff and the approval recorded. Rollback stays one click away. _Same morning_ ### The statement recalculates itself. A. Reyes lands at 133.6%, the 1.50x band opens and her payout goes to $62,400. Open disputes drop from 23 to 2, and the one still standing is a split, not a plan. ## The plan is a PDF. The payout is a spreadsheet. Ask where commission is actually calculated and the answer is never one place. The comp plan document says one thing, a quarterly workbook with a tab per rep says another, a formula field in the CRM says a third, and the reps keep private spreadsheets because they have learned not to trust any of them. In a 2026 survey of North American sales management, 62% of reps said they shadow-account their own commissions, and Salesforce's State of Sales research has reported that more than 60% of reps hit a commission error in the previous year. Every hour spent reconciling a payout is an hour not spent selling. Changing the plan is worse than calculating it. Legacy incentive compensation platforms are configured, not authored: implementations run six to twelve months, and mid-cycle changes route through the vendor's professional services queue. Qobra's buyer research found the single most common frustration with legacy ICM systems was the inability to change a compensation plan without vendor involvement. So the mid-quarter kicker sales leadership wants becomes a five-figure change request, and in the meantime someone codes it into the workbook as a manual adjustment column. Then the questions arrive that nobody can answer cheaply. A rep disputes March: which plan version was live when that deal closed, did the accelerator apply before or after the split, who approved the SPIF? Finance needs the same lineage for ASC 340-40, where capitalized commission amortization depends on plan terms finance does not control, and auditors want a schedule that ties back to source. California Labor Code 2751 goes further: commission terms must be in writing, must set out the method of computation, and must be re-issued when the plan changes. A workbook nobody fully understands is not an answer to any of those questions. _billing/jobs/commission-run.ts_`if (attainment > 1 && deal.type === 'new_logo') {` `rate = 0.12 * (deal.termMonths >= 24 ? 1.25 : 1);``}` _Q3\_commissions\_FINAL\_v7.xlsx_ repadjustment J. Cooper+1,240 M. Alvarez\-880 REVOPS-914**Mid-quarter: 1.4x kicker on 36-month terms**_blocked on ICM vendor services · 3 weeks_ one comp plan · three sources of truth · reps keep a fourth ## Comp plans as decision tables. Every version kept. A compensation plan is already a table: attainment bands down the side, deal attributes across the top, a rate and a multiplier in the cells. GoRules stores it that way instead of translating it into code. _01_ ### Tiers, accelerators, splits, and clawbacks as rows Attainment bands, base rates, and accelerator thresholds are rows in a decision table a comp analyst edits directly. ZEN expressions handle the arithmetic between them, from quota retirement to prorated ramp targets to blended attainment across products, and typed TypeScript function nodes cover anything genuinely custom like a split waterfall across an AE, an overlay specialist, and a channel partner. Policies model eligibility and SPIF overlays as ordered blocks, so a campaign kicker sits on top of the base plan instead of being pasted into it. Natural-language rendering turns each row into a sentence a rep can read, and you start from [70+ templates](/templates) rather than a blank editor. _02_ ### The version that paid the line item, on demand Every plan edit lands in [git-like version control](/version-control) with author, timestamp, and a full diff, gated by approval workflows and role-based access, and plans move through dev, staging, and production as explicit releases. That is what turns a dispute into a lookup: pin the plan version that was live when the deal closed, re-run the deal, and show the rows that fired, the split that resolved, and the approval that put that accelerator into production. The same lineage supports the deferred commission schedule your auditors ask about. _03_ ### Model the quarter before it pays Branch the plan, make the change, and replay it over last quarter's closed-won deals as test cases before anyone commits to it. You see the per-rep delta and the total variable cost instead of a guess, which is how you catch the accelerator that pays 3x on a renewal or the split rule that double-credits a co-sold deal. GoRules AI can edit the rules, run the tests, and explain a resulting payout in plain language while you iterate; releasing the change stays a human decision with an approval attached. ## From closed-won to a defensible number. GoRules is the calculation and governance layer. Your CRM, billing system, statements, and payroll keep doing what they already do. 01 ### Connect the systems that already hold the data Opportunities and close dates from Salesforce or HubSpot, invoiced amounts and churn events from billing or ERP, and roles, territories, hire dates, and quotas from HRIS. Call GoRules over REST from your commission run, or embed the MIT-licensed [open-source ZEN engine](/open-source) in that job with SDKs for Node.js, Python, Java, Go, C#, and Rust. GoRules returns calculated line items; your statement, payroll, and GL systems consume them. 02 ### Model each plan as a decision graph Eligibility first (active, past ramp, plan assigned), then quota retirement and attainment, then the tier table, then kickers for term length, product, or new logo, then split resolution across everyone credited on the deal, and finally clawback rules with their lookback window. One graph per plan and one version history per graph, so the AE plan and the SDR plan evolve independently. 03 ### Test against history, then release Run the proposed plan over closed-won deals from the last two quarters and diff payouts per rep against the released version. When the numbers hold, the change goes through approval and is promoted to production with the trail recorded, ready to attach to the plan document you re-issue to reps. 04 ### Calculate per deal and keep the trace Evaluate the moment a deal closes so a rep sees the earned amount in the CRM instead of rebuilding it in a spreadsheet, or run the whole book nightly in a batch window. Every line item carries the plan version, the rows that fired, and the inputs used, which is what turns a dispute into a five-minute conversation. ## Built for production, not proof of concept. - Sub-millisecond evaluation with the open-source ZEN engine (Rust core): price a deal the instant it closes, or re-run a full quarter of line items inside a nightly batch window - Git-like version control on every comp plan: branches, diffs, approval workflows, and one-click rollback when a mid-quarter change misfires - Self-host with Docker or Kubernetes so quotas, earnings, and rep-level data stay inside your infrastructure, or run on GoRules Cloud - Complete audit trail of who changed which accelerator, when, and who approved it, with SSO, role-based access, and SOC 2 so reps read the plan without being able to edit it - No lock-in and no services ticket: the engine is MIT-licensed open source, changing a rate is an edit rather than a project, and [70+ industry templates](/templates) give you a working starting point ## Questions, answered. ### What is commission calculation software? Commission calculation software takes closed deals and the rules of a compensation plan and produces what each person is owed: quota attainment, the tier or accelerator rate that applies, credit splits across everyone on the deal, kickers, and any clawback. It sits between the CRM and billing systems that hold the facts and the statement, payroll, and GL systems that pay and book the result. The hard part is rarely the arithmetic. It is that plans change mid-cycle, deals get credited to more than one person, and every number has to be defensible months later. GoRules provides that calculation layer as versioned decision tables your sales ops team edits directly. ### Does GoRules replace our ICM or payroll system? No. GoRules is the rules engine underneath commission calculation: plan authoring, testing, versioning, approvals, and evaluation. It does not run payroll, generate rep statements, or manage territory and quota planning, and it is not a system of record for HR data. Teams reach for it when the constraint is the plan logic itself, when plan changes are slow or expensive, when the calculation lives in a spreadsheet nobody can audit, or when an existing platform cannot express a plan without a services engagement. ### Can it model accelerators, splits, clawbacks, and SPIFs? Yes, and each one stays a distinct construct rather than a formula buried in a cell. Attainment tiers and accelerator thresholds are rows in a decision table. Splits are a function node that distributes credit across an AE, an overlay, and a partner and enforces that the shares total 100%. Clawbacks are rules with an explicit trigger and lookback window, commonly 90 to 180 days of early churn, and they can reclaim commission while leaving quota credit intact. SPIFs and campaign kickers are separate policy blocks with start and end dates, layered over the base plan so they expire cleanly instead of being edited into it. ### How does this help with commission disputes? Disputes are usually not disagreements about arithmetic, they are disagreements about which rules applied. Because every plan version is retained with its diff and its approver, you can pin the version that was live on the deal's close date, re-run that deal, and show the rows that fired, the split that resolved, and the inputs used. Natural-language rendering means the rep and the comp analyst read the same rule instead of a formula and a policy PDF that drifted apart. Showing the calculated amount when the deal closes also removes most of the reason reps shadow-account in the first place. ### Does this support ASC 606 and written commission agreement requirements? It supports the evidence side of both. ASC 340-40 requires incremental costs of obtaining a contract to be capitalized and amortized, and that schedule depends on plan terms finance often does not control, so versioned plans give you a defensible link from a capitalized amount back to the rules and inputs that produced it. Written commission agreement laws such as California Labor Code 2751 require the method of computation in writing and re-issued when the plan changes, and a dated version history tells you exactly when that obligation was triggered. GoRules supplies the traceability; the accounting judgments and legal obligations remain yours. ## 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 Pricing**Price rules your team can change](/use-cases/dynamic-pricing)[**Loyalty Engine**Tiers, points, and rewards as rules](/use-cases/loyalty-engine)[**Promotion Engine**Offers, stacking, and eligibility](/use-cases/promotion-engine) ## Every rate, every version. Every payout you can defend. Model one plan, your AE tier table with its accelerators and split rules, then replay last quarter's closed-won deals through it before anyone gets paid. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Offer Management System for Airlines **URL:** https://gorules.io/use-cases/airline-offer-management **Description:** An offer management system layer for airline retailing: decide which ancillaries to offer, to whom, and at what price in decision tables your revenue team owns. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Offer management system rules your revenue team owns. Decide which ancillaries to offer, to whom, and at what price - seats, bags, upgrades, bundles - in visual decision tables evaluated in milliseconds inside your existing shopping flow. GoRules does not replace your revenue management system or your PSS; it is the decision layer they call. ## From expired bid to sold seat, start to finish. Watch an evening in a revenue management team: a $340 upgrade bid expiring under a $400 floor, a one-cell change to the undersold-cabin rule, a replay over 8,400 expired bids, a signed release, and seats that sell before pushback. scroll to play _LX_**LX 174**FRA to JFK - 787-9 - departs in 41hT-48 bid window openoffer rules v4.1.0v4.4.0 **Business cabin**_1-2-1 · rows 1 to 8_ soldemptysold tonight J cabin **54%**14 seats unsold empty seat at pushback = $0offer rules v4.4.0 - seats sold before pushback **LX 38** J 92% full - floor unchanged $400 _LX_ **Upgrade bid**12 Sep · placed today 16:20 K7QM2R **FRA**13:15 **JFK**16:05 Economy MtoBusiness _Your offer_**$340** minimum $400$340$60 shortclears the floor _below minimum - expires in 41h_ _Accepted - seat 2A_ _LM_ **L. Marchetti**Member · no status · 1 bid on this cabin held below the floor by offer rules v4.1.0 - open in GoRules to see why _flight_**LX 174** _from_**FRA** _to_**JFK** _seat_**2A** _upgrade_**+$340** _Acceptance rate · tonight_**22%**bid windows tonight · 18:00 to 23:00target 45%undersold cabins clearing _Incremental · projected month_**+$0k**cumulative · 30 days at v4.4.0upgrade bids only1,900 bids clear at the new floor **LX 38**J 92% full - floor unchanged $400 bids below $400 still counter guardrail holds on full cabins_unchanged_ #### Upgrade bid rules Accept, decline, or counter every upgrade bid. Evaluated top-down at each bid window - first match decides. **Cabin load T-48****Time to departure****Tier****Bid floor****If below floor** 1_at least_ **85%**_any__any_**$400****Decline** 2_under_ **60%**_at most_ **48h****Gold+****$300****Counter at floor** 3_under_ **60%**_at most_ **48h**_any_**$400****$340****Counter at floor** 4_Otherwise_**$400****Counter at floor** + was $400 · full cabins and elite floors untouched · edited by Head of Revenue Management 1 unsaved change_Run tests__Request review_ **Quality checks**_0 expired bids replayed_ $340 bid on a 54% J cabin now accepts_was: expired_ Cabins at 85% and above keep the full floor_guardrail_ Gold and above floors unchanged_unchanged_ Below $340 still counters at the floor_ok_ All checks passed · +0 accepts · $0k incremental _Release v4.4.0_ **v4.4.0**_draft_Jane Cooper · just now · undersold-cabin floor $400 → $340 JC **Jane Cooper**Head of Revenue Management _pending_ _development_**v4.4.0** deploying _staging_**v4.1.0** live _production_**v4.1.0** live Live in production - every bid window now evaluates against v4.4.0, and tonight's below-floor bids on undersold cabins re-price automatically. full diff + approval recorded · one-click rollback _Thursday, 16:20_ ### A bid lands with 41 hours left. K7QM2R offers $340 for business on LX 174 FRA-JFK. The cabin is 54 percent full at T-48 and the standing floor is $400. _The bid_ ### $340 offered. $400 floor. Empty seat. Fourteen J seats are unsold on a 787-9 and the forecast shows no late corporate demand. The bid expires below the floor and the seat flies at zero. _One cell_ ### Revenue management fixes it herself. The failing rule opens the live policy. On a branch, cabins under 60 percent at T-48 drop from a $400 floor to $340. Full cabins keep the full floor. _Proof before production_ ### 8,400 expired bids re-run. Last month's below-floor bids replay against the draft while you watch: 1,900 would have cleared, $610k incremental, and nothing accepts on a cabin above 85 percent. _Sign-off_ ### Revenue approves. v4.4.0 ships. Jane Cooper signs the release, it promotes through staging to production with the full trail recorded. Rollback stays one click away. _Same evening_ ### The seats sell before pushback. Seat 2A goes first, then the map fills row by row as bids clear at the new floor - except on LX 38, already 92 percent full. Acceptance rate: 22 to 58 percent. ## The offer changes daily. The rules ship quarterly. Ask an airline where its offer rules live and you get three answers at once: fare and inventory logic in the PSS, ancillary prices in a spreadsheet merchandising maintains by hand, and eligibility rules hard-coded in the booking flow, the check-in app, and the upgrade-bid tool. An offer management system is meant to put all of that in one governed place. Most carriers build the NDC pipes and leave the decisions exactly where they were. So the change everyone in the room agrees on, lower the upgrade-bid floor on wide-bodies flying under 60 percent in business, waits for a release window in a system that was never designed to hold pricing judgment. The seats depart empty in the meantime, and a business seat that flies empty earns nothing at all. The market answers with a platform migration. Offer and order suites from Amadeus, Sabre, and PROS, and the order-native PSS replacements behind IATA's Offers and Orders program, sell better retailing as the reason to move shopping, inventory, ticketing, and servicing onto a new stack. That is a multi-year transformation to fix what, at the level of the actual decision, is a rules problem. It is also why only about a quarter of carriers who say Offers and Orders matters have started the program. Meanwhile the operational questions go unanswered. Why did this passenger see an $89 legroom seat and that one $59? What happens to attach rate if we bundle bag plus seat on leisure routes under four hours? Who set the current upgrade floors, when, and against what forecast? When the answers live in a codebase and a spreadsheet, every revenue review starts with an archaeology project. _booking/offers/upgradeBid.ts_`if (bid.amount < FLOOR[cabin]) {` `return decline('BELOW_FLOOR');``}``return accept(bid.amount);` _ancillary\_pricing\_w38.xlsx_ productprice bag 2 · TATL$100 upgrade floor · J$400 OFR-2043**Lower upgrade bid floor on wide-bodies**_Q4 roadmap · blocked on PSS release_ one offer policy · three owners · seats fly empty ## The decisions inside every offer you make. Shopping context in, priced offer out: which ancillaries, for this passenger, on this flight, at this price, with the rules that produced it attached to the answer. _01_ ### A worked example: the upgrade bid Flight 441, FRA-JFK, a 787-9 with 30 business seats. At T-48 the cabin is 54 percent full, 14 J seats are unsold, and the forecast shows no late corporate demand. A passenger bids $340. The static floor is $400, so the bid sits rejected-pending until it expires and the seat flies empty at zero. In GoRules that is four decision-table rows: cabin load at T-48, time to departure, and status tier set the effective bid floor and say what happens to a bid below it. Cabins at 85 percent and above keep the $400 floor and decline outright, elite tiers keep their own $300, and cabins under 60 percent inside 48 hours drop to $340 and counter anything below. The bid clears at $340 and the released economy seat goes back into inventory. _02_ ### Ancillaries by route, cabin, tier, and days to departure The same tables decide the rest of the offer. Which bag, seat, and lounge products a passenger is eligible for, which bundle to surface, and what each one costs by route, cabin, fare class, status tier, channel, and days to departure. Model scores and willingness-to-pay estimates arrive as plain inputs, so a recommendation still has to clear the floors, the tier entitlements, and the interline rules before it becomes a real offer. _03_ ### Offer rules without a PSS release Revenue management and merchandising edit the decision tables directly, and natural-language rendering makes each row read the way the pricing memo does. [Git-like versioning](/version-control), approval workflows, and one-click rollback mean the head of revenue signs off before anything reaches a passenger, and any change reverts in one click if the forecast was wrong. ## Keep the PSS. Own the offer rules. No migration: the PSS keeps inventory, tickets, and orders, and the RM system keeps forecasting and availability. GoRules owns the decisions between them. 01 ### Connect Your booking flow, NDC offer API, upgrade-bid tool, or check-in upsell calls GoRules over REST, or embeds the MIT-licensed [open-source ZEN Engine](/open-source) with SDKs for Node.js, Python, Java, Go, C#, and Rust. The payload carries the shopping context: route, cabin, equipment, load factor and days to departure from the RM feed, fare class, status tier, channel, and whatever is already in the cart. 02 ### Model the offer Rebuild offer construction as a decision graph. Eligibility runs first, then the ancillary catalogue for this passenger and this flight, then the price for each item, then bundling and the guardrail policy that can only narrow the result. ZEN expressions handle the arithmetic, and typed TypeScript function nodes cover anything custom, such as blending a willingness-to-pay score with a floor. 03 ### Test on real traffic Branch the policy and replay last month's shopping sessions and expired bids through both versions. Compare attach rate, take-up, and incremental revenue item by item, count how many rows the guardrail catches, and let revenue managers read the rules in natural language before sign-off. 04 ### Operate Promote through dev, staging, and production with an approval recorded at each step. Every evaluation returns the offer plus the rules that produced it, ready for revenue reviews, pricing audits, and the order record. When a route softens, the change ships the same day instead of the next release train. ## Built for production, not proof of concept. - Sub-millisecond evaluation with the Rust-core ZEN engine, fast enough to price ancillaries inside a shopping request, a bid window, or a check-in upsell - Git-like version control on every offer policy: branches, commit history, approval workflows, and one-click rollback when a floor moves the wrong way - Self-host with Docker or Kubernetes so PNR, tier, and revenue data never leave your infrastructure, or run on GoRules Cloud - Full traceability: every offer links to the rules that fired, and every rule change records who changed what and when. SSO, RBAC, and SOC 2 - No lock-in: the core engine is open source under MIT, and [70+ industry templates](/templates), including aviation starting points, give you a working base ## Questions, answered. ### What is an offer management system? An offer management system is the layer that assembles what an airline sells at the moment a passenger shops: which flight products and ancillaries to show, in what bundle, to which customer, at what price. It sits above inventory and distribution rather than replacing them, and it is the "offer" half of IATA's Offers and Orders model, where every purchase eventually lands in a single order record instead of separate PNRs, tickets, and EMDs. Two separable jobs live inside it: the science that estimates demand and willingness to pay, and the decision layer that turns those signals plus your commercial policy into an offer you are willing to defend. GoRules is the decision layer, a rules engine where eligibility, pricing, bundling, and guardrails live in one versioned, auditable place. ### Does GoRules replace our revenue management system or PSS? No. Your RM system keeps forecasting demand and allocating inventory, and your PSS keeps reservations, ticketing, and servicing. GoRules decides the things that sit between them: whether this passenger is eligible for this ancillary, which bundle to construct, what the upgrade-bid floor is on this cabin at this point in the booking curve, and when to route an offer to review. Those systems call GoRules over REST wherever a decision is needed, so nothing has to migrate and no vendor roadmap has to move first. ### How does an offer management system increase ancillary revenue? Ancillary revenue reached roughly $157 billion worldwide in 2025, about 15.7 percent of total airline revenue, up from 9.1 percent in 2016. Most of that growth came from unbundling, not from smarter offers: the same seat, bag, and upgrade prices go to everyone, set weeks ago in a spreadsheet. Moving those rules into a decision layer lets you vary them where the money is, by route, cabin, fare class, status tier, channel, and days to departure, and then measure it. In the upgrade-bid example on this page, dropping the floor from $400 to $340 on business cabins under 60 percent full at T-48 turns bids that would have expired at zero into cleared revenue, without touching the floor on cabins that are already selling. ### Can we run upgrade bidding and other dynamic-offer decisions through it? Yes. Upgrade bidding is a good fit because the decision is pure policy: what the floor is for this cabin at this point in the booking curve, and whether a bid below it should be declined or countered. Cabin load at the bid window, time to departure, fare class, status tier, and the demand forecast are the inputs. Encode those as decision-table rows, and your bidding platform or NDC offer service calls the policy at each window. The same pattern covers seat and bag pricing, bundle construction, waitlist and upgrade priority, and disruption re-accommodation offers. Every outcome returns the rules that fired, so a revenue manager can explain any accept or decline months later. ### Can we self-host so passenger data stays in our infrastructure? Yes. Deploy GoRules with Docker or Kubernetes inside your own environment, so PNRs, tier data, fare data, and decision logs never leave your network. The high-performance Agent evaluates rules close to your booking flow with hot reloading, and SSO plus role-based access control govern who can view or change offer rules. GoRules Cloud is available if you prefer managed hosting. ## The same engine, next door. One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail. [**Promotion Engine**Bundles and discounts on the same tables](/use-cases/promotion-engine)[**Dynamic Pricing**Price moves with guardrails attached](/use-cases/dynamic-pricing)[**Loyalty Engine**Tiers, points, and member entitlements](/use-cases/loyalty-engine) ## Price every extra. Explain every offer. Model your upgrade-bid floors as a decision table this afternoon, replay last month's expired bids through the simulator, and see the incremental revenue before anything reaches a passenger. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## AI Governance Software That Enforces Policy **URL:** https://gorules.io/use-cases/ai-governance **Description:** AI governance software that enforces policy at runtime: approve, escalate to a human, or block every model and agent decision, with versioned rules and a decision-level audit trail built for the EU AI Act. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # AI governance software that enforces, not just documents. Your governance platform inventories models, scores risk, and files the assessments. GoRules is the AI policy enforcement layer that runs beside it: every model score and agent action passes through versioned decision rules that approve it, escalate it to a human, or block it - deterministically, with an audit trail from regulation clause to individual decision. ## The auditor's question, answered at runtime. Watch an EU AI Act readiness audit at a bank: a governance file that cannot answer one question, a policy clause and a hardcoded threshold that disagree, the clause codified as an executable rule, 48,200 AI decisions replayed - and a decision stream where every model and agent output carries its policy version and clause. scroll to play **AI decision oversight**_14 systems · production · policy v4v4.2.0_JC _Models + agents_**14**inventoried · owners assigned _Assessments_**14 of 14**risk assessments signed _AI decision policy_**v4 · PDFv4.2.0 · live**published Jan 2026enforced in production _Art. 14 evidence_**nonecomplete**no runtime link to policyclause on every decision TimeDecisionModel / agentRiskActionPolicy 09:10:12DEC-48282kyc-agent_v2.0_**0.14**_auto-approve_\-v4.2.0 · r2 09:10:19DEC-48283credit-risk_v3.1_**0.47**_auto-approve_\-v4.2.0 · r2 09:10:27DEC-48285pricing-agent_v0.9_**0.11**_auto-approve_\-v4.2.0 · r2 09:10:34DEC-48286credit-risk_v3.1_**0.63**_auto-approve_\-v4.2.0 · r2 09:10:42DEC-48288fraud-screen_v1.4_**0.28**_auto-approve_\-v4.2.0 · r2 09:10:49DEC-48290affordability-agent_v2.3_**0.35**_auto-approve_\-v4.2.0 · r2 09:10:57DEC-48291credit-risk_v3.1_**0.52**_auto-approve_\-v4.2.0 · r2 09:11:04DEC-48293kyc-agent_v2.0_**0.21**_auto-approve_\-v4.2.0 · r2 09:11:12DEC-48295credit-risk_v3.1_**0.69**_auto-approve_\-v4.2.0 · r2 09:11:19DEC-48296doc-extract_v1.1_**0.07**_auto-approve_\-v4.2.0 · r2 09:11:27DEC-48298pricing-agent_v0.9_**0.24**_auto-approve_\-v4.2.0 · r2 09:11:34DEC-48300credit-risk_v3.1_**0.58**_auto-approve_\-v4.2.0 · r2 09:11:42DEC-48301fraud-screen_v1.4_**0.33**_auto-approve_\-v4.2.0 · r2 09:11:49DEC-48303kyc-agent_v2.0_**0.19**_auto-approve_\-v4.2.0 · r2 09:11:57DEC-48304credit-risk_v3.1_**0.61**_auto-approve_\-v4.2.0 · r2 09:12:04DEC-48306affordability-agent_v2.3_**0.42**_auto-approve_\-v4.2.0 · r2 09:12:11DEC-48309credit-risk_v3.1_**0.83**_human review_\-v4.2.0 · r3 09:12:19DEC-48311credit-risk_v3.1_**0.76**_auto-approve__human review_\-v4.2.0 · r3 09:12:26DEC-48314collections-agent_v1.2_**0.58**_auto-deny__blocked__vulnerable segment · Art. 5 - stays blocked_\-v4.2.0 · r1 09:12:34DEC-48316kyc-agent_v2.0_**0.31**_auto-approve_\-v4.2.0 · r2 09:12:41DEC-48318credit-risk_v3.1_**0.44**_auto-approve_\-v4.2.0 · r2 09:12:49DEC-48320pricing-agent_v0.9_**0.16**_auto-approve_\-v4.2.0 · r2 09:12:56DEC-48322kyc-agent_v2.0_**0.27**_auto-approve_\-v4.2.0 · r2 09:13:04DEC-48323credit-risk_v3.1_**0.49**_auto-approve_\-v4.2.0 · r2 09:13:11DEC-48325doc-extract_v1.1_**0.09**_auto-approve_\-v4.2.0 · r2 2,140 decisions today · streamingrule and clause on every row **Auditor request**_unanswered__answered_ _REQ-041 · EU AI Act readiness · 09:12_ Demonstrate that credit decisions above the high-risk threshold receive **human review**. Policy 4.2 · EU AI Act **Art. 14**. _decision_**DEC-48311** _rule fired_**row 3** _policy_**v4.2.0** _approved by_**Jane Cooper** _clause_**4.2** _regulation_**Art. 14** _AI decision policy · clause_ **4.2**Human oversight of high-risk credit decisions Decisions above a **0.72** risk score require human review before action, per EU AI Act Art. 14. AI decision policy v4 · approved Jan 2026 _Human review queue_**3** median wait 18m · SLA 4h · 2 reviewers online **DEC-48311 · credit limit increase** Risk score**0.76 · above 0.72** Routed by**policy v4.2.0 · row 3** Context**inputs + clause 4.2 attached** **DEC-48309**0.83waiting 2m **DEC-48196**0.86waiting 41m **DEC-48124**0.88waiting 1.2h _resolved today · 41_ **DEC-48273**approved · J. Alvarez09:04 **DEC-48251**declined · Jane Cooper08:51 reviewers see the score, the inputs, and the clause that routed it AI decision policy v4.pdf The controls in section 4 apply to every automated credit decisioning system operated by the bank, including third-party models and autonomous agents acting on customer accounts. ###### 4.2 Human oversight of high-risk credit decisions Credit decisions with a model or agent risk score above **0.72** must be routed to a qualified human reviewer before any action is taken, in line with EU AI Act Art. 14. ###### 4.3 Fallback for unscored decisions Where a risk score cannot be produced, the decision defaults to manual assessment under the standard credit review procedure. AI decision policy v4page 12 of 38 risk\_gate.pythresholds.yaml _38_from decisions import route\_to\_review _39_ _40_REVIEW\_THRESHOLD = **0.80**_unchanged since 2024_ _41_ _42_def gate(decision): _43_ if decision.score >= REVIEW\_THRESHOLD: _44_ return route\_to\_review(decision) _45_ return auto\_approve(decision) 0.72 on paper · 0.80 in production #### AI decision policy 4.2 Enforcement rules for AI credit decisions and agent actions. Every model and agent output evaluates here before it acts - first match decides. **Risk score****Decision type****Model version****Segment****Action****Clause** 1**Automated denial**_any_**Vulnerable****Block****4.4** _·_ **Art. 5** 2_below_ **0.72****Credit****approved**_any_**Auto-approve****4.1** 3_at least_ **0.80**_at least_ **0.72****Credit**_any__any_**Human review****4.2** _·_ **Art. 14** 4_Otherwise_**Human review****4.3** + was 0.80, the production value · aligned to clause 4.2 · edited by Model Risk 1 unsaved change_Run tests__Request review_ **Quality checks**_0 AI decisions replayed · 90 days_ Every high-risk decision routed to review_Art. 14_ No prohibited automated denials_Art. 5_ Every decision carries its clause reference_Art. 12_ Agent actions pass the same gate as models_agents_ All checks passed · 0 decisions between 0.72 and 0.80 would have been reviewed · gap closed _Release v4.2.0_ **v4.2.0**_draft_Jane Cooper · just now · review threshold 0.80 → 0.72 · Art. 5 block added JC **Jane Cooper**Head of Model Risk _pending_ RN **R. Novak**Chief Compliance Officer _pending_ _development_**v4.2.0** deploying _staging_**v4.1.0** live _production_**v4.1.0** live Live in production - every model and agent output now evaluates against v4.2.0, and the rule and clause that decided it are recorded on the decision. full diff + both approvals recorded · one-click rollback _Tuesday, 09:12_ ### The documentation is perfect. The question is not about documentation. An EU AI Act readiness audit at a bank: 14 AI models inventoried, every risk assessment signed, policy v4 published. Then the request lands: demonstrate that credit decisions above the high-risk threshold receive human review - Policy 4.2, Art. 14. Beneath it, the decision stream keeps flowing. _The gap_ ### Paper says 0.72. Production says 0.80. The policy PDF requires human review above a 0.72 risk score. The gate that actually runs, risk\_gate.py, has 0.80 hardcoded since 2024. Between the two numbers sit months of model and agent decisions, and nobody can say which ones slipped through. _The codification_ ### The clause becomes a rule that runs. Policy 4.2 opens in GoRules as a decision table. The review threshold is typed in at 0.72, the value the clause always said. Above it, a rule the code never had: fully automated denials for vulnerable-segment customers are blocked outright, with the Art. 5 reference attached. _Proof over history_ ### 48,200 AI decisions replayed. Ninety days of model and agent output re-run against the draft while you watch: every high-risk decision routes to review, no prohibited denials, every decision carries its clause. And the audit answer nobody had: 312 decisions between 0.72 and 0.80 would have been reviewed. _Sign-off_ ### Risk and compliance sign. v4.2.0 ships. Jane Cooper signs for model risk, compliance countersigns, and the policy promotes through staging to production with the diff and both approvals recorded. Rollback stays one click away. _The answer_ ### Every decision now carries its clause. The stream stamps each row with v4.2.0 and the rule that fired. A 0.76 decision flips to human review and lands in the queue with full context. An agent tries a prohibited denial and stays blocked - the refusal is the feature. The auditor gets a chain: decision to rule to version to approver to clause to Art. 14. ## Documented everywhere. Enforced nowhere. An AI governance platform can tell you which models you run, who owns them, and what risk tier each one landed in. What none of that machinery can do is stop this afternoon's 0.76 from being auto-approved. Between the policy PDF and the model output sits the only thing an auditor ultimately asks about: the mechanism that applies the rule to every single decision. In most organizations that mechanism is a threshold hardcoded into a service nobody has touched since 2024, a spreadsheet of per-system exceptions, and a backlog ticket promising to reconcile them. The EU AI Act turned that gap from uncomfortable into non-compliant. Article 14 requires that high-risk AI systems - credit scoring is explicitly on the Annex III list - be designed for effective human oversight. Article 12 requires automatic, decision-level record-keeping across the system's lifetime. Article 5 prohibits certain practices outright, including systems that exploit the vulnerabilities of specific groups, and carries the highest penalty tier in the regulation: up to 35 million euros or 7 percent of global turnover. None of those articles are satisfied by an inventory entry. They are satisfied by enforcement at the moment of decision, and by a record of it. AI agents multiply the surface. Model governance assumed a model returns a score and human-built software decides what to do with it. Agentic AI collapses that distance: the agent drafts the denial letter, sets the payment plan, calls the API. Every agent action is a policy decision made at machine speed, which means agentic AI governance cannot live in a quarterly review - the check has to sit in the execution path, before the action, on every action. So when the auditor asks the concrete question - show me that decisions above your high-risk threshold received human review - the documentation stack has no answer. The policy says 0.72, production says 0.80, and nobody can list the decisions that fell between. That is the moment teams discover that monitoring and enforcement are different products. _services/risk\_gate.py_`REVIEW_THRESHOLD = 0.80``if score >= REVIEW_THRESHOLD:` `route_to_review(decision)` _ai\_policy\_matrix.xlsx_ systemreview\_at credit-risk v3.10.72 collections agentmanual GOV-412**Align review threshold with policy 4.2**_backlog · platform team · 11 weeks old_ one policy · a PDF, a spreadsheet, and a hardcoded gate ## The enforcement layer under your governance stack. Governance platforms answer what AI you have and how risky it is. GoRules answers the runtime question: what is this model or agent allowed to do right now - and proves the answer, decision by decision. _01_ ### Policy clauses become executable decision tables The clause that lives on page 12 of the policy PDF becomes rows in a versioned decision table: risk score bands, decision types, model versions, customer segments in, an action and a clause reference out. Prohibited uses are rows too, so the ban is enforced by the same engine that routes the routine cases. Natural-language rendering means the compliance officer reads the same rule the engine executes, which ends the drift between what the policy says and what production does. Start from [70+ templates](/templates) rather than a blank table, and let GoRules AI draft rule changes, run the tests, and explain any decision while you iterate - releasing stays a human act with an approval attached. _02_ ### Runtime enforcement for every model and agent Every model score and every agent action routes through the policy engine before it takes effect. The model proposes; the rules dispose: auto-approve, escalate to a human, or block, in under a millisecond, deterministically - the same inputs produce the same outcome every time, which is precisely what a probabilistic model cannot promise. AI agents pass through the same gate as models, so an agent that attempts a prohibited action is refused by policy, not caught by a dashboard three weeks later. _03_ ### Human in the loop by rule, not by habit Article 14 asks for effective human oversight, and effective means systematic: a rule that routes every decision above the threshold to a reviewer, with the score, the inputs, the model version, and the clause that routed it attached. No reliance on someone remembering to check, no oversight that quietly erodes as volume grows, and a queue you can point to when asked how oversight actually works. _04_ ### An audit trail that reaches the individual decision Every evaluation records which rule fired, under which policy version, approved by whom, tracing to which clause. Combined with [git-like version control](/version-control) \- branches, diffs, approval workflows - the AI audit trail runs unbroken from a regulation article through your policy clause to decision DEC-48311 on a Tuesday morning. That chain is the Article 12 record, the dispute answer, and the model governance evidence, all the same lookup. ## Keep your governance platform. Add the enforcement. GoRules does not replace Credo AI, watsonx.governance, or whatever inventories and monitors your AI estate. They document and observe; GoRules executes the policy those documents describe. 01 ### Codify the clauses that matter Take the enforceable sentences out of the policy document - review thresholds, prohibited uses, segment restrictions, model allowlists - and model each one as decision table rows with a clause reference in the output. The governance board reads the table in natural language and confirms it says what the policy says, before it ever touches production. 02 ### Wire enforcement into the decision path Call GoRules over REST between the model or agent and the system that acts on its output, or embed the MIT-licensed [open-source ZEN Engine](/open-source) with SDKs for Node.js, Python, Java, Go, C#, and Rust. The payload carries the score or proposed action, model version, decision type, and customer attributes; the response carries the action and the clause. Your governance platform keeps its inventory and monitoring role alongside. 03 ### Replay history to find the gaps Run the last 90 days of model and agent decisions through the codified policy before it goes live. The replay tells you what the documentation never could: which decisions would have routed differently, whether any prohibited actions went through, and the exact size of the gap between the written threshold and the running one. 04 ### Operate and evolve with versioned releases When the regulation or the policy changes, the update is a diff, not a project: edit the rule on a branch, replay history against it, collect the approvals, and promote through dev, staging, and production as an effective-dated release. Rollback is one click, and every version stays retrievable for the auditor asking about last March. ## Built for production, not proof of concept. - Sub-millisecond evaluation with the open-source ZEN engine (Rust core), fast enough to gate every model score and agent action inline without a felt latency cost - Git-like version control on every policy: branches, diffs, required approvals, and one-click rollback, so compliance changes ship with the same discipline as code - Deterministic by construction: the same decision inputs always produce the same outcome, the property regulators ask you to demonstrate and models cannot give you - Complete decision-level audit trail: which rule fired, under which version, approved by whom, tracing to which clause - retrievable for any historical decision. SSO, role-based access, SOC 2 - Self-host with Docker or Kubernetes so decision data never leaves your infrastructure, or run on GoRules Cloud - and the core engine stays MIT-licensed [open source](/open-source), so the enforcement layer is never a black box ## Questions, answered. ### What is an AI governance platform, and how is enforcement different? An AI governance platform manages the lifecycle around your AI systems: model inventories, risk assessments, policy documentation, bias and drift monitoring, and regulatory reporting. Those are records and observations about your AI. Enforcement is a different job: intercepting each individual model output or agent action at runtime and applying the policy to it - approve, escalate to a human, or block - before it takes effect. Governance tools tell you a model is high-risk and that a review policy exists; an enforcement layer is the mechanism that actually routes decision 48,311 to a reviewer because its score crossed 0.72. GoRules provides that layer as versioned decision tables evaluated in the decision path. ### Does GoRules replace Credo AI, watsonx.governance, or our AI governance tools? No, and it is not trying to. Platforms like Credo AI and watsonx.governance are the system of record for your AI estate: inventories, assessments, evidence packs, monitoring. GoRules sits in the runtime path they do not occupy, executing the policies those platforms document. The two are complementary by design - your governance platform holds the policy and the assessment trail, GoRules holds the executable version of the policy and the decision-level enforcement trail, and together they close the loop an auditor walks: from the documented control to proof it operated on every decision. ### How does this help with EU AI Act compliance? The EU AI Act asks for things that only exist at runtime. Article 14 requires effective human oversight of high-risk systems, which in practice means a systematic mechanism routing decisions to people, not a paragraph saying reviews happen. Article 12 requires automatic recording of events over the system lifetime, which means decision-level logs, not monthly summaries. Article 5 prohibits certain practices outright, which means a gate that refuses them, not a dashboard that flags them afterwards. GoRules gives you each mechanism as versioned, testable rules: review thresholds as decision table rows, prohibited uses as blocking rules, and a clause reference recorded on every decision. The legal obligations remain yours; GoRules supplies the enforcement mechanism and the evidence that it ran. ### How do you govern AI agents, not just models? Through the same gate. Agentic AI governance fails when agents get a separate, softer path than models, because an agent is just a decision-maker that acts on its own output. In GoRules, an agent's proposed action - send the letter, set the payment plan, adjust the limit - is evaluated by the same policy tables as a model score: inputs in, action and clause out, with the same thresholds, the same prohibited-use rules, and the same audit trail. The agent proposes and the rules dispose, which is the only posture that scales to systems acting at machine speed. Escalation rules put a human in the loop exactly where the policy says one belongs. ### How deep does the audit trail go? To the individual decision, and back up to the regulation. Each evaluation records the inputs, the model or agent version, the rule row that fired, the policy version it belonged to, and the clause reference carried in the output. Each policy version records its diff, its author, and its approvers. Chain those and you can answer the auditor's question as a lookup: this decision was routed to human review by row 3 of policy v4.2.0, approved by Jane Cooper, implementing clause 4.2, which implements Article 14. The same chain, replayed over history, is how you quantify a past gap instead of guessing at it. ### Can we self-host for data residency and security review? Yes. Deploy the full BRMS with Docker or Kubernetes inside your own network, so decision inputs, scores, and customer attributes never cross a vendor boundary - the deployment posture most banks and insurers require for anything in the credit decision path. The evaluation engine itself is the MIT-licensed open-source ZEN Engine, which your security team can read rather than take on faith, and it also embeds directly in your services via SDKs. SSO and role-based access control govern who can view, edit, and approve policies, and GoRules Cloud is available when managed hosting fits better. ## The same engine, next door. One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail. [**Deterministic AI**Rules where AI must not guess](/use-cases/deterministic-ai)[**Transaction Monitoring**AML rules on the same engine](/use-cases/transaction-monitoring)[**Credit Decisioning**Policy above your ML models](/use-cases/credit-decisioning) ## The model proposes. Your rules dispose. Codify one clause this week - your high-risk review threshold - wire it in front of one model, and replay 90 days of decisions to see exactly what your written policy would have changed. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Expression Language - Fast & Embeddable Across Platforms **URL:** https://gorules.io/tools/expression-language **Description:** Friendly expression language with multi-language, multi-platform support. Embed our fast, versatile solution in any environment. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch Tools · Zen Expression # Try the expression language. ZEN Expression reimagines rule authoring with intelligent auto-completion that anticipates your needs and eliminates syntax errors. Type an expression below and press Enter - it evaluates instantly, right in your browser. ## One language, every runtime The editor above runs through WebAssembly, and the same engine powers backends in nine languages. ### Open source The expression language is fully open source, fostering transparency and community-driven improvements. [GitHub repository](https://github.com/gorules/zen) ### Embeddable Designed for seamless integration, the language can be embedded into any application without complex setup. ### WebAssembly Through WebAssembly, expressions run at native speed across platforms - including this page, right in your browser. [NPM package](https://www.npmjs.com/package/@gorules/zen-engine-wasm) ## Expressions are just the start. The same engine powers decision tables, visual flows, and AI-assisted rule authoring in the GoRules platform. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Base64 Encode Online **URL:** https://gorules.io/tools/base64-encode **Description:** Quickly & safely encode data to Base64. No data transferred to server. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch Tools · Base64 # Encode to Base64. Paste text or drop a file and the encoded output appears instantly. Everything runs in your browser - no data is sent to a server. EncodeDecode Drag & drop orUpload file Text input Drop it here Encoded output Copy to clipboard ## Put your rules to work. Model decisions in readable tables and flows, test them with AI, and run them anywhere. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Base64 Decode Online **URL:** https://gorules.io/tools/base64-decode **Description:** Quickly & safely decode data to Base64. No data transferred to server. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch Tools · Base64 # Decode from Base64. Paste Base64 or drop a file and the decoded output appears instantly. Everything runs in your browser - no data is sent to a server. EncodeDecode Drag & drop orUpload file Base64 input Drop it here Decoded output Copy to clipboard ## Put your rules to work. Model decisions in readable tables and flows, test them with AI, and run them anywhere. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Base64 Certificate **URL:** https://gorules.io/tools/base64-certificate **Description:** Encode a PEM certificate to Base64 format. No data transferred to server. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch Tools · Certificate # Certificate to Base64. Encode a PEM certificate to Base64 format, ready to paste into your configuration. Everything runs in your browser - no data is sent to a server. Drag & drop orUpload certificate Text input Drop it here Encoded output Copy to clipboard 0 / 32,768 characters ## Database SSL certificates Grab the right certificate from your hosting provider, then encode it here. ![Amazon Web Services](/icons/hosting/aws.svg) ### Amazon Web Services AWS uses trust certificates based on the region you are hosting in. [Certificate bundles](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html#UsingWithRDS.SSL.CertificatesDownload) ![Microsoft Azure](/icons/hosting/azure.svg) ### Microsoft Azure The Azure certificate can be downloaded from your database resource page. [Learn more](https://learn.microsoft.com/en-us/azure/mysql/flexible-server/how-to-connect-tls-ssl) ![Google Cloud Platform](/icons/hosting/gcp.svg) ### Google Cloud Platform GCP creates a database certificate when you create a database resource. [Learn more](https://cloud.google.com/sql/docs/postgres/configure-ssl-instance) ## Put your rules to work. Model decisions in readable tables and flows, test them with AI, and run them anywhere. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Switch from Oracle OPA (Intelligent Advisor) to GoRules **URL:** https://gorules.io/switch/oracle-opa **Description:** Step-by-step Oracle Intelligent Advisor migration guide: export decision service contracts, convert Word and Excel rule tables to JSON decision graphs with the AI copilot, and run them on Zen Engine. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Switch from Oracle OPA/Intelligent Advisor to GoRules. A step-by-step guide to moving your decision service projects, Word and Excel rule documents, and rule tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. [Start migrating](https://us1.gorules.io) [Talk to an engineer](/contact-us) ## What you get with GoRules Where your rules land: the parts of GoRules most relevant to this migration. ### Visual editor for developers and business users Rules are modeled as decision graphs in a web editor: decision tables, expressions, switches, and functions on one canvas. Business users and developers edit the same graph, with changes tracked per release. ### Versioning, environments, and rollback built in Semantic versioned releases, environment-scoped deployments with rollback, and branching for parallel rule development. Publish, release, and deploy are explicit human actions, each with an audit trail. ### Stateless Rust engine with per-node tracing The Zen Engine evaluates a decision per request: JSON in, DAG traversal in topological order, JSON out. Each node runs exactly once, and the response can include a per-node trace with input, output, and sub-millisecond timing. ### Managed cloud or self-hosted Run on GoRules Cloud or self-host the same product as a single container image, including serverless via Lambda. One REST surface for evaluation: `POST /projects/:projectId/evaluate/*` with a JSON `context`. ## The migration path A step-by-step route from your current setup to running your rules on Zen Engine. ### 1. Identify which projects use decision service mode GoRules covers stateless request/response decisioning. For each workload, inventory whether it is invoked via `POST /determinations-server/v2/{deployment-name}` (decision service - migrate) or via an interview UI channel (stateful Q&A sessions with screens and controls - out of scope for this migration; rebuild that UX separately). Export the decision service contract JSON from Intelligent Advisor Hub - this is the source of truth for input and output shapes. ### 2. Map the data model to a flat JSON context Global attributes become top-level fields in `context`. Entity-level attributes become nested objects (one-to-one) or arrays (one-to-many, many-to-many). Enumerated types and value lists become string fields; the `Name` identifier on each attribute becomes the JSON key. If your rules branch on unknown or uncertain values (expressed via `is known` / `is certain` tests), flatten them: represent "not provided" as an absent or `null` field, and if you need to preserve the `uncertain` distinction, encode it explicitly in the request (for example, a tagged field like `{"maritalStatus": "uncertain"}`) and branch on it in Zen. Example: `the customer's age` (number, Global) becomes `{"customer": {"age": 25}}` in the GoRules `context`. ### 3. Translate rule tables to `decisionTableNode` Excel condition columns become GoRules input columns with Zen unary tests (`> 1_000_000`, `[1..10]`, `"US","CA"`). "Else" rows become rows with empty condition cells (wildcard) placed last, with `hitPolicy: "first"`. Range rules split by "date they apply from" become a `switchNode` routing to one `decisionTableNode` per effective-date range. Boolean rules become `expressionNode` key-value pairs or `switchNode` branches. Assignment rules become `expressionNode` entries (`{ "key": "membershipLevel", "value": "'Gold'" }`). Temporal operators (`TemporalBefore`, `TemporalOnOrAfter`, `TemporalYearsSince`, `IntervalDailySum`) have no direct Zen equivalent - pass an explicit `[{ effectiveFrom, effectiveTo, value }]` array in the context and compute the period logic in a `functionNode` or via Zen `filter`/`map`/`sum`. ### 4. Restructure entity-level rules and Custom Functions `ForAll(...)` becomes `all(items, # condition)` in Zen; `Exists(...)` becomes `some(items, # condition)`; per-instance inference (a rule that runs once per child, per account, per line item) becomes `map(items, # { ... })`. Instance aggregation (`InstanceSum`, `InstanceMinimum`, `InstanceCount`) maps to Zen `sum`, `min`, `count` on arrays. Custom Functions - authored with typed argument attributes and a return attribute - become either `functionNode` handlers (for imperative logic) or `decisionNode` sub-decisions (for reusable rule compositions). Relationship navigation (`For`, `For Scope`, "in the case of the child's school") becomes JSON path traversal in `expressionNode` (`$.child.school.name`). Inferred relationships (rules that assert entity membership) and per-invocation instance isolation inside custom functions have no direct analogue - fold them into the upstream data shape or into `functionNode` logic. ### 5. Validate with the simulator before cutover Run representative test inputs through the GoRules simulator (`POST /projects/:projectId/decisions/simulate` or the in-editor simulation panel). The per-node `trace` in the response shows input, output, and timing for every node, making it straightforward to diff against the decision service batch endpoint output (`POST /determinations-server/v2/{deployment-name}/batch`) for the same inputs. If you have existing `OPMRunTests.exe` test suites authored in Excel, reuse the test-case data rows as simulator inputs and compare the expected column values to the GoRules `result`. Resolve divergences before swapping the API. ### 6. Swap the API integration Replace `POST {hub}/determinations-server/v2/{deployment-name}` calls (OAuth 2.0 Bearer token obtained via `POST /opa-hub/api/{version}/auth` with `grant_type=client_credentials`) with `POST /projects/:projectId/evaluate/*`, a `{ "context": { ... }, "trace": true }` body, and auth via the `x-access-token` header (project access token or `grl_pat_*`). The response is `{ performance, result, trace }` for every decision. For batch workloads, the `POST /determinations-server/v2/{deployment-name}/batch` array endpoint maps to parallel calls to the GoRules evaluate endpoint (one per input), or to a single graph that processes an array inside the context via `decisionTableNode` or `functionNode`. GoRules AI ## Let the copilot do the translation. The AI copilot cannot read Oracle Policy Modeling project files directly. Rules authored in Microsoft Word (`.docx`) and Microsoft Excel (`.xlsx`) with OPM paragraph styles ("OPM - conclusion", "OPM - level N") and cell styles (Conclusion Heading, Condition Heading, Else) are not parsed as binary Office formats, nor are `.xprj` project files or compiled `.xgen` artifacts. What the copilot can do: accept pasted rule text copied from Word, accept exported decision service contract JSON from Intelligent Advisor Hub, and generate `decisionTableNode`, `expressionNode`, or `switchNode` content from natural-language rule descriptions you provide. It can also suggest Zen equivalents when you describe function expressions in text, and convert `ForAll`/`Exists` patterns to `all`/`some` over arrays when the behaviour is described. What it cannot do automatically: convert temporal reasoning rules (the time-series data model is a design decision you make first), reproduce four-valued logic (you decide the sentinel encoding strategy for `unknown`/`uncertain` before the copilot can help), or migrate interview flows - those are out of scope for GoRules entirely. Use the copilot iteratively: describe what each rule should compute, let it produce a graph fragment, then refine. **On this page** - [What you get with GoRules](#what) - [Visual editor for developers and business users](#visual-editor-for-developers-and-business-users) - [Versioning, environments, and rollback built in](#versioning-environments-and-rollback-built-in) - [Stateless Rust engine with per-node tracing](#stateless-rust-engine-with-per-node-tracing) - [Managed cloud or self-hosted](#managed-cloud-or-self-hosted) - [The migration path](#path) - [1\. Identify which projects use decision service mode](#identify-which-projects-use-decision-service-mode) - [2\. Map the data model to a flat JSON context](#map-the-data-model-to-a-flat-json-context) - [3\. Translate rule tables to decisionTableNode](#translate-rule-tables-to-decisiontablenode) - [4\. Restructure entity-level rules and Custom Functions](#restructure-entity-level-rules-and-custom-functions) - [5\. Validate with the simulator before cutover](#validate-with-the-simulator-before-cutover) - [6\. Swap the API integration](#swap-the-api-integration) - [Let the copilot do the translation](#ai) ## Other migration guides [View all guides](/switch) [_Guide_ ### Switch from Drools A step-by-step guide to moving your DRL rules, DMN models, and spreadsheet decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/drools)[_Guide_ ### Switch from IBM ODM A step-by-step guide to moving your BAL rules, decision tables, and ruleflows to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/ibm-odm)[_Guide_ ### Switch from FICO Blaze Advisor A step-by-step guide to moving your SRL rulesets, decision tables, ruleflows, and score models to GoRules: map the BOM to JSON, convert with the AI copilot, validate in parallel, and cut over. ](/switch/fico-blaze-advisor) ## Leave the build step behind. Bring your Oracle OPA/Intelligent Advisor rules over, run both engines in parallel, and cut over when the outputs match. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Switch from json-rules-engine to GoRules | Decision Engine Migration **URL:** https://gorules.io/switch/json-rules-engine **Description:** Step-by-step json-rules-engine migration guide: export rules with rule.toJSON(), convert condition trees and operators to JSON decision graphs with the AI copilot, and run them on Zen Engine. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Switch from json-rules-engine to GoRules. A step-by-step guide to moving your json-rules-engine rules, fact handlers, custom operators, and listeners to GoRules: export with rule.toJSON(), convert with the AI copilot, validate in parallel, and cut over. [Start migrating](https://us1.gorules.io) [Talk to an engineer](/contact-us) ## What you get with GoRules Where your rules land: the parts of GoRules most relevant to this migration. ### Visual editor for developers and business users Rules are modeled as decision graphs in a web editor: decision tables, expressions, switches, and functions on one canvas. Business users and developers edit the same graph, with changes tracked per release. ### Versioning, environments, and rollback built in Semantic versioned releases, environment-scoped deployments with rollback, and branching for parallel rule development. Publish, release, and deploy are explicit human actions, each with an audit trail. ### One expression language everywhere Decision table cells, expression nodes, and switch conditions all use Zen - a single expression language with 60+ built-in functions (`sum`, `avg`, `filter`, `map`, `date`, `duration`, `matches`). For logic beyond expressions, `functionNode` runs sandboxed JavaScript with `zod`, `big.js`, `dayjs`, and `http` imports. ### Native SDKs across languages The same Rust core ships as `@gorules/zen-engine` for Node.js, `zen-engine` for Python and Rust, `zen-go` for Go, `io.gorules:zen-engine` for JVM (Java and Kotlin), `GoRules.ZenEngine` for .NET, plus Swift, Android, and browser or Lambda via WASM. ## The migration path A step-by-step route from your current setup to running your rules on Zen Engine. ### 1. Inventory the rule layer in your host application Catalog four things in your existing `json-rules-engine` integration: (1) the rules themselves (use `rule.toJSON()` on each registered `Rule` to capture the declarative shape - conditions, event, priority, name); (2) every fact registered via `engine.addFact(id, fnOrValue, options)`, noting which are constants, which are async function handlers, and what external systems each handler touches; (3) every custom operator and operator decorator registered via `engine.addOperator(...)`/`engine.addOperatorDecorator(...)`; (4) every listener wired up via `rule.on(...)`/`engine.on(...)` (per-rule, engine-wide, or event-type-keyed). The first item migrates as JSON; the other three need restructuring (see steps 4 and 5). ### 2. Map condition trees to GoRules nodes `{ all: [...] }` and `{ any: [...] }` condition trees over leaf `{ fact, operator, value, path }` conditions translate naturally to `decisionTableNode` rows: each leaf condition becomes an input column with a Zen unary test (`> 50`, `[1..10]`, `"US","CA"`, `contains($, "test")`), and the `event.params` payload becomes the output columns. Hit policy is `first` (one match wins) or `collect` (all matches as an array). Boolean trees that branch on a single fact map to a `switchNode` with one branch per case. `{ not: { ... } }` becomes either positive matching in the table or an inverted `switchNode` default. Use `decisionNode` for `engine.setCondition(name, conditions)` shared conditions, and for any decision that you want to version independently. ### 3. Translate operators and decorators to Zen Direct mappings: `equal`/`notEqual` → `==`/`!=`; the four numeric comparators → `<`/`<=`/`>`/`>=`; `in`/`notIn` → `$ in [...]` / `not ($ in [...])`; `contains`/`doesNotContain` → `contains($, value)` / `not contains($, value)`. Decorators map by transformation: `everyFact:operator` → `all($, # operator value)`; `someFact:operator` → `some($, # operator value)`; `everyValue:operator` → `all(value, $ operator #)`; `someValue:operator` → `some(value, $ operator #)`; the `not` decorator inlines as `!`; the `swap` decorator is unneeded because Zen expressions are positional. Custom operators you registered for comparisons like `between`, regex `matches`, `startsWith`, `endsWith`, temporal checks, or arithmetic map to direct Zen primitives or built-in functions (`x >= 10 and x <= 20`, `matches(x, ".*foo.*")`, `startsWith(x, "pre")`, etc.) - many `engine.addOperator` registrations become unnecessary after migration. ### 4. Lift fact handlers out of the engine and into the calling application This is the largest restructure. Constant facts (`engine.addFact("speed-of-light", 299792458)`) become literal values in the input `context`. Async function facts that load data (e.g. `engine.addFact("account-information", (params, almanac) => apiClient.getAccountInformation(...))`) become pre-evaluation HTTP/database calls in the calling application: load the data once, then include it in the `context` object passed to GoRules. Cross-fact chaining patterns (`almanac.factValue("account-information", { accountId })` from inside another fact handler) collapse - the calling application assembles the full input `context` deterministically, and values are read via Zen `$.field.path` accessors inside expressions. Pure-computation fact handlers can move into `expressionNode` content (chained named expressions evaluated top-to-bottom) or `functionNode` (sandboxed ES6 JavaScript). Side-effecting fact handlers stay in the host application. ### 5. Replace listener side effects and rule chaining with graph topology + post-evaluation actions If your listeners (`rule.on("success", fn)`, `engine.on("success", fn)`, `engine.on(, fn)`) post webhooks, send notifications, or write intermediate facts via `almanac.addRuntimeFact(id, value)` for downstream rules, none of this migrates as-is. Rewrite each pattern as follows: (a) side effects on rule success/failure become post-evaluation actions in the calling application - read the GoRules `result` (or specific `trace` entries), then trigger the side effect; (b) rule chaining via priority + `onSuccess` + `almanac.addRuntimeFact` becomes graph topology - the upstream computation lives in an `expressionNode` or `decisionNode` and produces a named field that downstream nodes reference via Zen `$.field`; (c) multi-step listener-driven workflows become orchestrated calls in the host (call GoRules → run side effect → call GoRules again with updated context) or a single graph that returns all decisions in one pass. ### 6. Swap `engine.run()` for the REST API or the embedded engine For service-oriented integration: replace `await engine.run(facts)` with `POST /projects/:projectId/evaluate/*` (environment- and release-pinned variants exist). Send `{ "context": {...}, "trace": true }` in the body, authenticate with `x-access-token: ` (or `Authorization: Bearer grl_pat_...` for personal access tokens). The response shape changes from `{ events, failureEvents, almanac, results, failureResults }` to `{ performance, result, trace }` - if you previously consumed `events`/`failureEvents` to know which rules fired, return an explicit list of fired-rule identifiers as part of `result`. For in-process integration in Node.js host applications: install `@gorules/zen-engine` and replace `new Engine()` with `new ZenEngine({ loader })`, `engine.addRule(...)` with `engine.createDecision(graph)`, and `engine.run(facts)` with `decision.safeEvaluate(context, options)`. The same Rust core powers both paths. GoRules AI ## Let the copilot do the translation. Rules exported with `rule.toJSON()` are already JSON: the `{ conditions, event }` shape with `all`/`any`/`not` trees maps almost directly to GoRules node shapes, and the copilot converts most condition trees to `decisionTableNode` rows or `switchNode` branches automatically. It handles built-in operator translation to Zen (`equal` → `==`, `greaterThanInclusive` → `>=`, `in` → `$ in [...]`, `contains` → `contains($, ...)`), decorator transformation (`everyFact:greaterThan` → `all($, # > value)`, `someFact:contains` → `some($, contains(#, value))`), and shared conditions registered via `engine.setCondition` becoming `decisionNode` references between separate decision files. What the copilot cannot see it cannot translate: fact handlers registered via `engine.addFact(id, fn, options)`, custom operators from `engine.addOperator(name, fn)`, decorators from `engine.addOperatorDecorator(name, fn)`, and listener callbacks (`rule.on`, `engine.on`) are JavaScript in your host application, outside the rule JSON the copilot operates on. The restructuring in steps 4 and 5 - pre-evaluation context assembly, post-evaluation side effects, and collapsing `priority` + `almanac.addRuntimeFact` chaining into graph topology - is manual host-application work. Because the rule format is already JSON, the copilot converts what it sees quickly, leaving engineering time for that architectural change. **On this page** - [What you get with GoRules](#what) - [Visual editor for developers and business users](#visual-editor-for-developers-and-business-users) - [Versioning, environments, and rollback built in](#versioning-environments-and-rollback-built-in) - [One expression language everywhere](#one-expression-language-everywhere) - [Native SDKs across languages](#native-sdks-across-languages) - [The migration path](#path) - [1\. Inventory the rule layer in your host application](#inventory-the-rule-layer-in-your-host-application) - [2\. Map condition trees to GoRules nodes](#map-condition-trees-to-gorules-nodes) - [3\. Translate operators and decorators to Zen](#translate-operators-and-decorators-to-zen) - [4\. Lift fact handlers out of the engine and into the calling application](#lift-fact-handlers-out-of-the-engine-and-into-the-calling-application) - [5\. Replace listener side effects and rule chaining with graph topology + post-evaluation actions](#replace-listener-side-effects-and-rule-chaining-with-graph-topology-post-evaluation-actions) - [6\. Swap engine.run() for the REST API or the embedded engine](#swap-engine-run-for-the-rest-api-or-the-embedded-engine) - [Let the copilot do the translation](#ai) ## Other migration guides [View all guides](/switch) [_Guide_ ### Switch from Drools A step-by-step guide to moving your DRL rules, DMN models, and spreadsheet decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/drools)[_Guide_ ### Switch from IBM ODM A step-by-step guide to moving your BAL rules, decision tables, and ruleflows to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/ibm-odm)[_Guide_ ### Switch from FICO Blaze Advisor A step-by-step guide to moving your SRL rulesets, decision tables, ruleflows, and score models to GoRules: map the BOM to JSON, convert with the AI copilot, validate in parallel, and cut over. ](/switch/fico-blaze-advisor) ## Leave the build step behind. Bring your json-rules-engine rules over, run both engines in parallel, and cut over when the outputs match. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Switch from InRule to GoRules | Decision Engine Migration **URL:** https://gorules.io/switch/inrule **Description:** Step-by-step InRule migration guide: export .ruleapp rule applications, convert Business Language rules and decision tables to JSON decision graphs with the AI copilot, and run them on Zen Engine. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Switch from InRule to GoRules. A step-by-step guide to moving your .ruleapp rule applications, Business Language rules, and decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. [Start migrating](https://us1.gorules.io) [Talk to an engineer](/contact-us) ## What you get with GoRules Where your rules land: the parts of GoRules most relevant to this migration. ### Native SDKs across languages The same Rust core ships as `@gorules/zen-engine` for Node.js, `zen-engine` for Python and Rust, `zen-go` for Go, `io.gorules:zen-engine` for JVM (Java and Kotlin), `GoRules.ZenEngine` for .NET, plus Swift, Android, and browser or Lambda via WASM. ### Stateless Rust engine with per-node tracing The Zen Engine evaluates a decision per request: JSON in, DAG traversal in topological order, JSON out. Each node runs exactly once, and the response can include a per-node trace with input, output, and sub-millisecond timing. ### AI copilot for authoring and conversion The copilot converts uploaded rule files into decision graphs, edits tables from plain-language instructions, generates test cases, and explains what a decision did on a given input. Deploys and releases stay explicit human actions. ### Rule changes are live in seconds Rules are JSON decision graphs (`application/vnd.gorules.decision`). Edit in the editor, publish, and the change reaches production via an atomic `releaseId` swap - the decision cache expires within 5 seconds (`DECISION_CACHE_TTL`, configurable). No build step, no restart. ## The migration path A step-by-step route from your current setup to running your rules on Zen Engine. ### 1. Export rules from your InRule rule application Rule applications are stored as a single XML file with the `.ruleapp` extension; `.ruleappx` files are compressed archives that must be extracted to obtain the `.ruleapp` XML first. Export from irCatalog via Catalog tab → Maintain or via the Catalog Manager Website, or take the file from the file system. Collect any associated `.testscenario` files too - they contain the inputs and expected outputs you will rebuild as GoRules simulation cases. The AI copilot accepts the `.ruleapp` XML and can read pasted Business Language rule text directly. ### 2. Map InRule constructs to GoRules node types Business Language `If... Then...` and `If... Then... Else...` rules map to `decisionTableNode` rows - conditions become input columns, actions become output columns, and `first` hit policy preserves rule ordering. `Select... Case...` templates map to `switchNode` with Zen boolean expressions on each branch. Collection aggregate templates (`the average/total/minimum/maximum of`, `the number of`, `any members exist in`, `lookup ... where`) map to `expressionNode` chains using Zen built-ins (`sum`, `avg`, `min`, `max`, `filter`, `map`, `some`, `all`). Rule sets composed via `ExecuteRuleSet` map to `decisionNode` references that load another decision file. Constraints with `LimitToValueList`, `MinimumValue`, `MaximumValue`, `PatternMask`, etc., become `inputNode` JSON Schema validations or `expressionNode` checks placed upstream. ### 3. Redesign Calculations and working-memory dependencies Calculations that re-evaluate whenever a field, calculation, or rule they depend on changes have no reactive equivalent in GoRules - re-model each one as an `expressionNode` placed upstream of every node that consumes its value, with the dependency order made explicit by graph topology. `Execute Method` calls into bound .NET assembly methods, `InvokeEntityMethod`, and `RefreshFields` actions have no equivalent: rewrite as `functionNode` JavaScript (sandboxed imports: `zod`, `big.js`, `dayjs`, `http`, `zen`) for in-process logic, or extract to an HTTP service called via the `customHandler` integration channel. Patterns built around .NET assembly-bound entity state (runtime object binding), `Parent Context`, `CurrentContext()`, and `OuterContext()` need to be flattened into explicit JSON shapes (parent identifiers joined into child objects) or expressed with Zen array operators. ### 4. Upload rule application files to the AI copilot Open a decision document in GoRules, open the AI chat panel, and paste the Business Language rule text or upload the `.ruleapp` XML. The copilot generates `decisionTableNode` rows for `If/Then` rules with conditions converted to Zen unary tests (`>= 18`, `< 650`, `"US","CA"`), `switchNode` branches for `Select/Case`, and `expressionNode` chains for collection aggregates and arithmetic Calculations. Iterate with the copilot - describe what a complex rule should produce and let it restructure the graph. Several constructs still require manual redesign: bound .NET methods, irWord-embedded rules, working-memory re-evaluation patterns, and Vocabulary phrase definitions. ### 5. Validate against your InRule baseline Run identical inputs through both engines and compare outputs. GoRules simulation (`POST /projects/:projectId/decisions/simulate`) returns a per-node trace: each node reports its input, output, and execution time, so divergences are localised to a specific node. For each `.testscenario` file, extract the input state and expected output and create an equivalent simulation case. Resolve every divergence before cutting over - in particular, double-check date handling (Zen `date()`/`duration()` vs `Now`/`Today` and `#...#` literal syntax) and decimal precision (use `big.js` in `functionNode` if exact decimal arithmetic is required). ### 6. Swap the API integration If you call the Decision API today (`POST /api/{ruleAppName}/decision/{decisionName}` with `inrule-apikey` header), GoRules follows the same REST/JSON pattern: `POST /projects/:projectId/evaluate/*` with `{"context": {...}, "trace": false}` and `x-access-token` for auth. The response returns `{performance, result, trace}`. If you are on the SOAP execution service (`RuleEngineServiceClient` with `ApplyRulesRequest`), map those calls to the same GoRules REST endpoint, or move in-process to the `GoRules.ZenEngine` NuGet package, which replaces the `RuleSession` → `CreateEntity` → `ApplyRules` → `Dispose` chain with `engine.Evaluate(key, context)` - no per-request session object to create and dispose, just one long-lived engine. Before the evaluate endpoint can serve a decision, the decision document must be published (released) in GoRules. GoRules AI ## Let the copilot do the translation. The AI copilot reads pasted Business Language rule text and `.ruleapp` XML and generates GoRules decision graph nodes. In tested conversions, `If/Then` and `If/Then/Else` rules map to `decisionTableNode` rows with conditions converted to Zen unary tests, `Select/Case` templates map to `switchNode` branches, and collection aggregate templates (`the total of`, `the average of`, `the number of`, `any members exist in`) map to `expressionNode` chains using Zen `sum`, `avg`, `filter`, `map`, `some`, `all`. Several constructs always require manual redesign: bound .NET assembly methods called via `Execute Method` or `InvokeEntityMethod`, re-evaluation driven by Calculations and `RefreshFields`, `Parent Context`/`OuterContext()` patterns that walk an entity hierarchy, irWord-embedded rules inside `.docx` documents, and custom Vocabulary phrase definitions. Use the copilot iteratively - describe what a complex rule should do and let it restructure the graph, then validate against your `.testscenario` baselines using the simulate endpoint. **On this page** - [What you get with GoRules](#what) - [Native SDKs across languages](#native-sdks-across-languages) - [Stateless Rust engine with per-node tracing](#stateless-rust-engine-with-per-node-tracing) - [AI copilot for authoring and conversion](#ai-copilot-for-authoring-and-conversion) - [Rule changes are live in seconds](#rule-changes-are-live-in-seconds) - [The migration path](#path) - [1\. Export rules from your InRule rule application](#export-rules-from-your-inrule-rule-application) - [2\. Map InRule constructs to GoRules node types](#map-inrule-constructs-to-gorules-node-types) - [3\. Redesign Calculations and working-memory dependencies](#redesign-calculations-and-working-memory-dependencies) - [4\. Upload rule application files to the AI copilot](#upload-rule-application-files-to-the-ai-copilot) - [5\. Validate against your InRule baseline](#validate-against-your-inrule-baseline) - [6\. Swap the API integration](#swap-the-api-integration) - [Let the copilot do the translation](#ai) ## Other migration guides [View all guides](/switch) [_Guide_ ### Switch from Drools A step-by-step guide to moving your DRL rules, DMN models, and spreadsheet decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/drools)[_Guide_ ### Switch from IBM ODM A step-by-step guide to moving your BAL rules, decision tables, and ruleflows to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/ibm-odm)[_Guide_ ### Switch from FICO Blaze Advisor A step-by-step guide to moving your SRL rulesets, decision tables, ruleflows, and score models to GoRules: map the BOM to JSON, convert with the AI copilot, validate in parallel, and cut over. ](/switch/fico-blaze-advisor) ## Leave the build step behind. Bring your InRule rules over, run both engines in parallel, and cut over when the outputs match. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Switch from IBM ODM to GoRules | Decision Engine Migration **URL:** https://gorules.io/switch/ibm-odm **Description:** Step-by-step IBM ODM migration guide: export BAL rules, decision tables, and ruleflows, convert them to JSON decision graphs with the AI copilot, and run them on Zen Engine. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Switch from IBM ODM to GoRules. A step-by-step guide to moving your BAL rules, decision tables, and ruleflows to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. [Start migrating](https://us1.gorules.io) [Talk to an engineer](/contact-us) ## What you get with GoRules Where your rules land: the parts of GoRules most relevant to this migration. ### Rule changes are live in seconds Rules are JSON decision graphs (`application/vnd.gorules.decision`). Edit in the editor, publish, and the change reaches production via an atomic `releaseId` swap - the decision cache expires within 5 seconds (`DECISION_CACHE_TTL`, configurable). No build step, no restart. ### Visual editor for developers and business users Rules are modeled as decision graphs in a web editor: decision tables, expressions, switches, and functions on one canvas. Business users and developers edit the same graph, with changes tracked per release. ### Stateless Rust engine with per-node tracing The Zen Engine evaluates a decision per request: JSON in, DAG traversal in topological order, JSON out. Each node runs exactly once, and the response can include a per-node trace with input, output, and sub-millisecond timing. ### Native SDKs across languages The same Rust core ships as `@gorules/zen-engine` for Node.js, `zen-engine` for Python and Rust, `zen-go` for Go, `io.gorules:zen-engine` for JVM (Java and Kotlin), `GoRules.ZenEngine` for .NET, plus Swift, Android, and browser or Lambda via WASM. ## The migration path A step-by-step route from your current setup to running your rules on Zen Engine. ### 1. Export rules from your IBM ODM project Export BAL action rules (`.brl` files) and decision tables (`.dta` files) from Rule Designer or Decision Center. For decision tables, also export as Excel via the Business console's Excel export feature. Locate your ruleflow (`.rfl`) files to capture rule execution sequence. Collect BOM verbalizations (`.voc` files) - the AI copilot uses them to understand business term mappings. ### 2. Map IBM ODM constructs to GoRules node types BAL action rule conditions map to `decisionTableNode` input columns; actions map to output columns. Decision table rows map directly to `decisionTableNode` rows - the `is between` operator maps to Zen range syntax `[100000..300000]`, `is less than` maps to `< 100000`. Ruleflow task sequences map to `switchNode` conditional routing + edge connections in the DAG. `collect`\-style aggregation logic in IRL maps to `expressionNode` chains using Zen built-ins (`sum`, `avg`, `filter`, `map`). Subflow tasks map to `decisionNode` references. ### 3. Upload rule files to the AI copilot Create a decision document in GoRules and open the AI chat panel. Rename the `.brl` export to `.xml` (BRL files are XML) or paste the rule text into the chat; exported Excel decision tables attach directly. The copilot reads BAL natural language syntax and generates nodes and edges. Decision tables with `is between` operators convert to Zen range tests. Preconditions convert to `switchNode` gates before the decision table node in the graph. ### 4. Rebuild constructs that depend on working memory IRL technical rules using `modify`, `retract`, and `update` on working memory objects have no structural equivalent in a stateless DAG - redesign as explicit `switchNode` branches and `expressionNode` chains. Rules that trigger other rules via fact changes must be restructured as sequential DAG paths. Ruleflow forks/joins become separate graph branches converging at a common node. `evaluate()` conditions and BOM methods backed by arbitrary Java require rewriting as `functionNode` JavaScript (sandboxed, with `zod`, `big.js`, `dayjs`, `http` imports). ### 5. Validate with the simulator Run your test inputs through the GoRules simulator. The response includes per-node execution trace - each node reports its input, output, and timing. Compare outputs against your existing baseline. If you have ODM test suites with Excel scenario files, use the same test data as input to the GoRules simulator for direct comparison. ### 6. Swap the API integration If you invoke rules over REST via a hosted decision service, GoRules follows the same POST/JSON pattern: `POST /projects/:projectId/evaluate/*` with input wrapped in a `context` object and auth via `x-access-token` header. The response returns `{ performance, result, trace }` (`trace` is included when the request body sets `"trace": true`) - no BOM/XOM type mapping required in the request or response. The decision must be published in GoRules before the evaluate endpoint serves it. For embedded JVM use, replace the `IlrJ2SESessionFactory` -> `IlrSessionRequest` -> `session.execute()` -> XOM casting chain with `io.gorules:zen-engine` (Maven Central). Node.js: `@gorules/zen-engine`, Python: `zen-engine`, Go: `zen-go`. GoRules AI ## Let the copilot do the translation. The AI copilot uses the underlying LLM's knowledge of BAL syntax to interpret `.brl` files - it is not a deterministic parser, and every generated graph requires human review. BAL `if`/`then`/`else` conditions using business terms map to `decisionTableNode` input columns with Zen unary tests. Decision tables exported as Excel map closely to `decisionTableNode` rows - operator syntax differs but the structure is equivalent. Constructs that depend on working memory - IRL `modify`/`retract`/`update` operations, inference chains where rules trigger other rules, and ruleflow forks and joins - require manual restructuring because GoRules uses stateless DAG traversal, not inference over working memory. BOM verbalizations (`.voc` files) are helpful context for the copilot but do not convert automatically to any GoRules structure - there is no BOM equivalent. Expect the LLM to handle BAL condition-action rules and tabular decision logic well; ruleflows and IRL technical rules need guided copilot conversation or manual graph design. **On this page** - [What you get with GoRules](#what) - [Rule changes are live in seconds](#rule-changes-are-live-in-seconds) - [Visual editor for developers and business users](#visual-editor-for-developers-and-business-users) - [Stateless Rust engine with per-node tracing](#stateless-rust-engine-with-per-node-tracing) - [Native SDKs across languages](#native-sdks-across-languages) - [The migration path](#path) - [1\. Export rules from your IBM ODM project](#export-rules-from-your-ibm-odm-project) - [2\. Map IBM ODM constructs to GoRules node types](#map-ibm-odm-constructs-to-gorules-node-types) - [3\. Upload rule files to the AI copilot](#upload-rule-files-to-the-ai-copilot) - [4\. Rebuild constructs that depend on working memory](#rebuild-constructs-that-depend-on-working-memory) - [5\. Validate with the simulator](#validate-with-the-simulator) - [6\. Swap the API integration](#swap-the-api-integration) - [Let the copilot do the translation](#ai) ## Other migration guides [View all guides](/switch) [_Guide_ ### Switch from Drools A step-by-step guide to moving your DRL rules, DMN models, and spreadsheet decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/drools)[_Guide_ ### Switch from FICO Blaze Advisor A step-by-step guide to moving your SRL rulesets, decision tables, ruleflows, and score models to GoRules: map the BOM to JSON, convert with the AI copilot, validate in parallel, and cut over. ](/switch/fico-blaze-advisor)[_Guide_ ### Switch from InRule A step-by-step guide to moving your .ruleapp rule applications, Business Language rules, and decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/inrule) ## Leave the build step behind. Bring your IBM ODM rules over, run both engines in parallel, and cut over when the outputs match. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Switch from Higson to GoRules | Stateless Rules Engine **URL:** https://gorules.io/switch/higson **Description:** Step-by-step Higson migration guide: export decision table XLSX bundles, flow JSON files, and Groovy functions, convert them to JSON decision graphs with the AI copilot, and run them on Zen Engine. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Switch from Higson to GoRules. A step-by-step guide to moving your Higson decision tables, Groovy functions, and flows to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. [Start migrating](https://us1.gorules.io) [Talk to an engineer](/contact-us) ## What you get with GoRules Where your rules land: the parts of GoRules most relevant to this migration. ### One expression language everywhere Decision table cells, expression nodes, and switch conditions all use Zen - a single expression language with 60+ built-in functions (`sum`, `avg`, `filter`, `map`, `date`, `duration`, `matches`). For logic beyond expressions, `functionNode` runs sandboxed JavaScript with `zod`, `big.js`, `dayjs`, and `http` imports. ### Native SDKs across languages The same Rust core ships as `@gorules/zen-engine` for Node.js, `zen-engine` for Python and Rust, `zen-go` for Go, `io.gorules:zen-engine` for JVM (Java and Kotlin), `GoRules.ZenEngine` for .NET, plus Swift, Android, and browser or Lambda via WASM. ### Versioning, environments, and rollback built in Semantic versioned releases, environment-scoped deployments with rollback, and branching for parallel rule development. Publish, release, and deploy are explicit human actions, each with an audit trail. ### AI copilot for authoring and conversion The copilot converts uploaded rule files into decision graphs, edits tables from plain-language instructions, generates test cases, and explains what a decision did on a given input. Deploys and releases stay explicit human actions. ## The migration path A step-by-step route from your current setup to running your rules on Zen Engine. ### 1. Export decision tables and functions from Higson Studio Decision tables export as XLSX (single) or ZIP of XLSX files (mass export); each bundle contains a `Data` sheet (matrix), a `Configuration` sheet (levels + definition), and a `Mark` sheet. Functions export as ZIP/XLSX with their Groovy source. Flows mass-export emits a ZIP containing per-flow JSON files plus an XLSX of details (or per-flow SVG). Profiles, Tags, and Test Packages are bundled in a Snapshot ZIP - useful as a reference, but the AI copilot reads decision-table data and Groovy source most directly. ### 2. Map Higson constructs to GoRules node types Decision tables (parameters) → `decisionTableNode`. `best match` mode resolves by specificity, so when converting to a `first` hit policy table, re-order rows by specificity - exact-match rows above wildcard/catch-all rows; `union match` maps to `collect` hit policy. Higson matchers (`between/ii`, `between/ie`, `between/ei`, `contains/all`, `contains/any`, `contains/none`, `in`, `not in`, `text/like`, `text/regex`) become Zen unary tests in input cells (`> 50`, `[1..10]`, `"US","CA"`, `contains($, "test")`, `matches($, "...")`). Functions (Groovy) → `functionNode` (JavaScript). Flows → the JSON graph topology itself, with Flow `Condition` blocks becoming `switchNode` and Flow sub-flow blocks becoming `decisionNode`. Domain attribute calls (`DOMAIN_OBJECT`) → separate decisions referenced via `decisionNode` or per-attribute dispatch in a `switchNode`. Dictionary tables → inline Zen unary test sets (`"A","B","C"`) or a referenced `decisionNode` returning a validity flag. ### 3. Convert decision tables with the AI copilot Open the AI chat panel on a new decision document and paste the XLSX export contents (or upload the file). The copilot generates `decisionTableNode` rows: input columns get Zen unary tests, output columns become output values, and a default catch-all row is added. Cells using cascade get (`$p table[idx]`) or cascade call (`$f fun(args)[code]`) need manual redesign - paste the affected rows separately, describe what the cascade resolves to (which decision table it calls, what argument types it passes, which output level it picks), and the copilot can re-express the chain as upstream `decisionNode` or `expressionNode` connections. Implicit type conversions (`_dec()`, `_num()`, `_int()`, `_str()`, `_date()`, `_bool()`) become explicit Zen casts (`number()`, `string()`, `date()`). ### 4. Rewrite Groovy functions as JavaScript `functionNode` Paste the Groovy function body into the AI copilot and ask for a `functionNode` conversion. The copilot translates `def x = ...` to `let`/`const`, `ctx.getDecimal("path")` to direct property access on the `input` object, `math.*` to `Math.*` or `big.js`, and dates handled via `util.*` to `dayjs`. Calls to other decision tables from inside a function (`higson.getNumber("table", ctx)`) cannot stay inside the function in GoRules - they become an upstream `decisionNode` that is wired into the function with the result available on `input`. Calls to other functions become upstream `functionNode` references the same way. The JavaScript sandbox restricts imports: `zod`, `big.js`, `dayjs`, `http`, and `zen` are available. ### 5. Redesign Domain model and Region/Version/Timeline by hand The Domain Definition + Domain Configuration model has no GoRules equivalent. Flatten it: each domain attribute that resolves polymorphically (literal vs decision-table vs function) becomes a separate decision file or a `switchNode` branch keyed off the attribute identifier. Domain Configuration trees with inherited Global Attributes are persisted externally and passed in `context` on each evaluate call. Local Attributes (created ad-hoc per element) cannot survive - every consumer must agree on a fixed input schema. Region/Version/Timeline date-windowed selection has no native equivalent: encode date checks as `switchNode` statements keyed off `date(input.now)`, or pre-publish each Timeline window as a separate release and rotate the active release on the environment via external scheduling. External Source JDBC integrations become `customHandler` HTTP integrations against a service that fronts the SQL source. ### 6. Swap the API integration Replace `POST /api/execution/invoke` with `POST /projects/:projectId/evaluate/*`. The structured request envelope (`ctx.properties[]` of key/value/complexValue tuples + `elements[]` of `PARAMETER`/`FUNCTION`/`DOMAIN_OBJECT`) becomes a free-form `context` object: every `ctx.properties[]` entry becomes a path on `context` (e.g. `policy.insured.age` flattens to `{ "policy": { "insured": { "age": 42 } } }`). Each element in the request becomes one HTTP call to the URL of that decision (the file path replaces `code`). Auth becomes `x-access-token: `. Multi-row decision-table results returned as multiple `resultValue` objects become a single array under the configured output field when the table uses the `collect` hit policy. For embedded JVM use, replace `HigsonEngineFactory` (or the `HyperonEngineFactory` alias) with `io.gorules:zen-engine` from Maven Central; for Node.js use `@gorules/zen-engine` directly with `engine.createDecision(graph).safeEvaluate(context, opts)`. ### 7. Validate in parallel, then cut over Rebuild the Tests and Test Packages from your snapshot as GoRules simulator test cases and run identical inputs through both engines. GoRules simulation returns a per-node trace - each node reports its input, output, and execution time - so divergences localize quickly. Once outputs match, publish the decision documents and release them to the target environment, then switch your invoke calls over. GoRules AI ## Let the copilot do the translation. The AI copilot works best with text-readable inputs: the XLSX exports of decision tables, the per-flow JSON files in a Flow ZIP, and the Groovy source of functions. Pasted XLSX decision-table data converts cleanly to `decisionTableNode` rows - Higson matchers map to Zen unary tests, and the copilot adds a catch-all default row. Cascade get (`$p`) and cascade call (`$f`) cell syntax requires manual redesign: paste the cell, describe what each cascade resolves to (target table or function, argument types, output level via `[idx]` or `[code]`, implicit conversion via `_dec()`/`_num()`/`_int()`/`_str()`/`_date()`/`_bool()`), and the copilot can re-express it as upstream `decisionNode` or `functionNode` connections plus explicit Zen casts. Flows can be described in text (block list, variable names and types, condition logic, returned variables) and the copilot will generate the equivalent DAG with `switchNode` for `Condition` blocks and `decisionNode` for sub-flows. Groovy functions: paste the body and request a `functionNode` conversion - `ctx.*` reads become input property access, `math.*`/`util.*` map to `Math.*`/`big.js`/`dayjs`, and any `higson.getNumber("table", ctx)` calls are surfaced as upstream node references rather than in-function calls. What the copilot cannot do: resolve `DOMAIN_OBJECT` addressing (the `profileCode` + `attributeCode` polymorphic dispatch has no automatable mapping), migrate the Region/Version/Timeline date-window model (no analogue in GoRules releases), or translate External Source JDBC integrations - those require an external HTTP wrapper that the GoRules graph reaches via `customHandler` integrations. **On this page** - [What you get with GoRules](#what) - [One expression language everywhere](#one-expression-language-everywhere) - [Native SDKs across languages](#native-sdks-across-languages) - [Versioning, environments, and rollback built in](#versioning-environments-and-rollback-built-in) - [AI copilot for authoring and conversion](#ai-copilot-for-authoring-and-conversion) - [The migration path](#path) - [1\. Export decision tables and functions from Higson Studio](#export-decision-tables-and-functions-from-higson-studio) - [2\. Map Higson constructs to GoRules node types](#map-higson-constructs-to-gorules-node-types) - [3\. Convert decision tables with the AI copilot](#convert-decision-tables-with-the-ai-copilot) - [4\. Rewrite Groovy functions as JavaScript functionNode](#rewrite-groovy-functions-as-javascript-functionnode) - [5\. Redesign Domain model and Region/Version/Timeline by hand](#redesign-domain-model-and-region-version-timeline-by-hand) - [6\. Swap the API integration](#swap-the-api-integration) - [7\. Validate in parallel, then cut over](#validate-in-parallel-then-cut-over) - [Let the copilot do the translation](#ai) ## Other migration guides [View all guides](/switch) [_Guide_ ### Switch from Drools A step-by-step guide to moving your DRL rules, DMN models, and spreadsheet decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/drools)[_Guide_ ### Switch from IBM ODM A step-by-step guide to moving your BAL rules, decision tables, and ruleflows to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/ibm-odm)[_Guide_ ### Switch from FICO Blaze Advisor A step-by-step guide to moving your SRL rulesets, decision tables, ruleflows, and score models to GoRules: map the BOM to JSON, convert with the AI copilot, validate in parallel, and cut over. ](/switch/fico-blaze-advisor) ## Leave the build step behind. Bring your Higson rules over, run both engines in parallel, and cut over when the outputs match. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Switch from FICO Blaze Advisor to GoRules | Stateless Rules Engine **URL:** https://gorules.io/switch/fico-blaze-advisor **Description:** Step-by-step FICO Blaze Advisor migration guide: map your BOM to a JSON context, translate SRL rulesets, decision tables, and score models with the AI copilot, and run them on Zen Engine. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Switch from FICO Blaze Advisor to GoRules. A step-by-step guide to moving your SRL rulesets, decision tables, ruleflows, and score models to GoRules: map the BOM to JSON, convert with the AI copilot, validate in parallel, and cut over. [Start migrating](https://us1.gorules.io) [Talk to an engineer](/contact-us) ## What you get with GoRules Where your rules land: the parts of GoRules most relevant to this migration. ### Stateless Rust engine with per-node tracing The Zen Engine evaluates a decision per request: JSON in, DAG traversal in topological order, JSON out. Each node runs exactly once, and the response can include a per-node trace with input, output, and sub-millisecond timing. ### Rule changes are live in seconds Rules are JSON decision graphs (`application/vnd.gorules.decision`). Edit in the editor, publish, and the change reaches production via an atomic `releaseId` swap - the decision cache expires within 5 seconds (`DECISION_CACHE_TTL`, configurable). No build step, no restart. ### Managed cloud or self-hosted Run on GoRules Cloud or self-host the same product as a single container image, including serverless via Lambda. One REST surface for evaluation: `POST /projects/:projectId/evaluate/*` with a JSON `context`. ### Native SDKs across languages The same Rust core ships as `@gorules/zen-engine` for Node.js, `zen-engine` for Python and Rust, `zen-go` for Go, `io.gorules:zen-engine` for JVM (Java and Kotlin), `GoRules.ZenEngine` for .NET, plus Swift, Android, and browser or Lambda via WASM. ## The migration path A step-by-step route from your current setup to running your rules on Zen Engine. ### 1. Identify rule services in decision-service mode Blaze projects invoked via `Server.createServer()` and `invokeService(serviceName, entryPointName, sessionInfo, argsArray)` against an `NdStatelessServer` subclass are in scope for direct migration. Long-running monitoring services (event channel posting with `is changed` event rules) and interactive stateful sessions are not - GoRules evaluates per request, with no working memory and no event channel. Export the `.server` XML config from each deployment: each `` element maps an `EntryPointId` to an `SrlInvocationFunctional` (`SrlName` and `SrlArgumentType`), and is the source of truth for the input/output shape each service exposes. ### 2. Map the BOM to a JSON context shape Each Java BOM class becomes a nested JSON object; BOM properties become JSON fields (camelCase by convention). One-to-many relationships expressed as BOM arrays become JSON arrays. SRL static method calls (`AutoPolicy.readAutoPolicy()`) and class constants (`NdProductInfo.PRODUCT_ADVISOR_TUTORIALS`) move out of rules - either the caller pre-computes them or they become fields on the input. Method calls on BOM properties (`decision.ReasonText.append("...")`) become Zen expressions (`flatten([reasons, ["new reason"]])`) or JavaScript inside a `functionNode`. The SRL `as a ` cast operator at the entry-point boundary is removed - the caller sends JSON directly, and an optional JSON Schema attached to the `inputNode` validates the shape if needed. ### 3. Translate SRL rulesets and decision tables SRL `if/then/else` rules become `decisionTableNode` rows (conditions in input columns, actions in output columns) or `switchNode` branches with Zen boolean conditions. Decision table cell formats translate directly: `>= {real 1} and < {real 2}` becomes the half-open interval `[100..300)`; `>= {real}` becomes `>= 100`; the `Not Applicable` wildcard becomes an empty cell. Ruleflow task sequences become DAG node chains. SRL splits (N branches with author-written SRL boolean conditions) become `switchNode` branches with Zen expressions. Patterns over collections (`anyVehicle is any VehicleInfo in collection thePolicy.VehicleInfo`) become a `decisionNode` with `executionMode: "loop"` and `inputField: "policy.vehicles"`, or Zen `map`/`filter`/`some`/`all` on input arrays. The `ignore()` per-pattern dedup primitive is not needed - loop mode processes each array element independently. The sentinel-value catchall pattern (`status = "pending"` initial value, catchall fires only `if status = "pending"`) maps cleanly to a wildcard row at the bottom of a `decisionTableNode` (empty cells in all input columns). ### 4. Handle score models and reason codes Score models have no direct GoRules equivalent and require redesign as a graph composition. Author one `decisionTableNode` per characteristic (Country, Age, Years Licensed, etc.) with `first` hit policy, emitting one row per applicable bin and a `partial_` field per characteristic. Add an `expressionNode` summing partial scores: `{ key: "score", value: "partial_age + partial_years_licensed + partial_country" }`. Reason-code emission moves into a `functionNode` (JavaScript) that reads which bins matched and constructs a reasons array. Keeping bins mutually exclusive and collectively exhaustive is the author's responsibility in GoRules - there is no edit-time overlap validation. An `All Other` catch-all bin becomes a wildcard row in each per-characteristic table. Distance-based reason codes require manually computing per-characteristic baselines and ranking contributions inside the `functionNode`; rank-based reason codes are simpler - rank reasons by each characteristic's assigned reason-code priority or points lost, capped by a max count. ### 5. Validate against your Blaze baseline Run representative inputs through the GoRules simulator. The response includes a per-node trace showing each node's id, name, input, output, and execution time. Compare results against the `invokeService(...)` output for the same inputs; the test data inside your generated `Client.java` (in the `_()` private method) is a useful starting set of fixtures since it represents the input shape the deployment was already running against. Resolve any divergences before cutting over. ### 6. Swap the API integration Replace the invocation chain - `Server.createServer()` returning a long-lived `Server`, `invokeService(serviceName, entryPointName, sessionInfo, argsArray)` for each call, `server.shutdown()` at the end, and the `NdServerException`/`NdServiceException`/`NdServiceSessionException` exception types - with a single REST call: `POST /projects/:projectId/evaluate/` with body `{"context": {...}, "trace": false}` and the `x-access-token` header. The response is `{performance, result, trace}`. The generated `Server.java`, `Client.java`, and `Runner.java` files, the `.server` config (and its `_ser.server` variant), and the `Build.bat`/`Run.bat` scripts are retired once the cutover completes. Hosts that previously embedded `NdStatelessServer` directly can use the GoRules JVM SDK (`io.gorules:zen-engine` on Maven Central) to keep evaluation in-process. GoRules AI ## Let the copilot do the translation. The AI copilot has no importer for BlazeAdvisor project artifacts - it does not parse `.server` XML config files, generated `Server.java`/`Client.java` files, Decision Table Templates, Score Model Templates, Reason Code Lists, or Rule Project archives. What it can do: accept pasted SRL rule text and generate `decisionTableNode` or `expressionNode` content; accept pasted decision-table cell values (or a CSV export from the Decision Table Editor) and generate `decisionTableNode` rows; accept the entry-point function signature and suggest a JSON `context` shape for the input; suggest Zen equivalents when SRL operators (`is greater than`, `<>`, possessive notation, `for each in `) are described in text; help design the score-model decomposition (a `decisionTableNode` per characteristic, an `expressionNode` summing partial scores, a `functionNode` emitting reason codes) when characteristics, bins, and reason codes are described; convert ruleflow splits to `switchNode` when the N branch conditions are pasted. What it cannot do automatically: parse BOM class hierarchies - the developer must describe the input/output shape in text or JSON; migrate score models without explicit bin values, partial scores, and reason code lists provided by the developer; convert event-driven monitoring services or stateful sessions - these require redesign outside GoRules' request/response scope; handle `is needed` lazy event rules - the developer must decide which fields to precompute upstream in an `expressionNode`. Use the copilot iteratively: paste SRL rule bodies, describe what each ruleset computes, let it produce graph fragments, then refine. **On this page** - [What you get with GoRules](#what) - [Stateless Rust engine with per-node tracing](#stateless-rust-engine-with-per-node-tracing) - [Rule changes are live in seconds](#rule-changes-are-live-in-seconds) - [Managed cloud or self-hosted](#managed-cloud-or-self-hosted) - [Native SDKs across languages](#native-sdks-across-languages) - [The migration path](#path) - [1\. Identify rule services in decision-service mode](#identify-rule-services-in-decision-service-mode) - [2\. Map the BOM to a JSON context shape](#map-the-bom-to-a-json-context-shape) - [3\. Translate SRL rulesets and decision tables](#translate-srl-rulesets-and-decision-tables) - [4\. Handle score models and reason codes](#handle-score-models-and-reason-codes) - [5\. Validate against your Blaze baseline](#validate-against-your-blaze-baseline) - [6\. Swap the API integration](#swap-the-api-integration) - [Let the copilot do the translation](#ai) ## Other migration guides [View all guides](/switch) [_Guide_ ### Switch from Drools A step-by-step guide to moving your DRL rules, DMN models, and spreadsheet decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/drools)[_Guide_ ### Switch from IBM ODM A step-by-step guide to moving your BAL rules, decision tables, and ruleflows to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/ibm-odm)[_Guide_ ### Switch from InRule A step-by-step guide to moving your .ruleapp rule applications, Business Language rules, and decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/inrule) ## Leave the build step behind. Bring your FICO Blaze Advisor rules over, run both engines in parallel, and cut over when the outputs match. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Switch from Drools to GoRules | Stateless Rules Engine **URL:** https://gorules.io/switch/drools **Description:** Step-by-step Drools migration guide: export DRL, DMN, and spreadsheet decision tables, convert them to JSON decision graphs with the AI copilot, and run them on Zen Engine. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Switch from Drools to GoRules. A step-by-step guide to moving your DRL rules, DMN models, and spreadsheet decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. [Start migrating](https://us1.gorules.io) [Talk to an engineer](/contact-us) ## What you get with GoRules Where your rules land: the parts of GoRules most relevant to this migration. ### Rule changes are live in seconds Rules are JSON decision graphs (`application/vnd.gorules.decision`). Edit in the editor, publish, and the change reaches production via an atomic `releaseId` swap - the decision cache expires within 5 seconds (`DECISION_CACHE_TTL`, configurable). No build step, no restart. ### Visual editor for developers and business users Rules are modeled as decision graphs in a web editor: decision tables, expressions, switches, and functions on one canvas. Business users and developers edit the same graph, with changes tracked per release. ### Stateless Rust engine with per-node tracing The Zen Engine evaluates a decision per request: JSON in, DAG traversal in topological order, JSON out. Each node runs exactly once, and the response can include a per-node trace with input, output, and sub-millisecond timing. ### Native SDKs across languages The same Rust core ships as `@gorules/zen-engine` for Node.js, `zen-engine` for Python and Rust, `zen-go` for Go, `io.gorules:zen-engine` for JVM (Java and Kotlin), `GoRules.ZenEngine` for .NET, plus Swift, Android, and browser or Lambda via WASM. ## The migration path A step-by-step route from your current setup to running your rules on Zen Engine. ### 1. Export rules from your Drools project For KJAR deployments, extract rule sources with `jar -xf your-rules.kjar` - `.drl` files live under `src/main/resources/`. Export `.dmn` files from the KIE DMN Editor or your project resources. For spreadsheet decision tables, locate `.xls`/`.xlsx` spreadsheet decision tables (conventionally named `.drl.xls`/`.drl.xlsx`). Collect everything - the AI copilot works with all of these formats. ### 2. Map Drools constructs to GoRules node types DRL `when`/`then` condition-action rules map to `decisionTableNode` rows - conditions become input columns, actions become output columns. `salience`\-ordered rules become `first` hit policy tables where row order is the priority. `accumulate`/`collect` logic maps to `expressionNode` chains using Zen built-ins (`sum`, `avg`, `filter`, `map`). Conditional routing via agenda groups maps to `switchNode` with Zen boolean expressions. FEEL and Zen share range and comparison syntax (`>= 18`, `[1..10]`), but built-in function names differ - review the Zen function reference when migrating DMN expressions. ### 3. Upload DRL files to the AI copilot Create a decision document in GoRules, open the AI chat panel, and attach your `.drl` file. The copilot converts DRL conditions to Zen unary tests (`>= 18`, `< 650`), maps actions to output columns, and adds a catch-all default row automatically. DMN files and spreadsheet decision tables can also be uploaded - their row structure maps directly to `decisionTableNode` rows. ### 4. Rebuild constructs that depend on working memory `insertLogical()` with truth maintenance, `modify()` triggering re-evaluation, and `salience`\-driven cross-rule ordering have no structural equivalent in a stateless DAG - redesign as explicit `switchNode` branches and `expressionNode` chains. `eval()` blocks with arbitrary Java code require rewriting as `functionNode` JavaScript (sandboxed, with `zod`, `big.js`, `dayjs`, `http` imports available) or Zen expressions. Iterate with the copilot - describe the intended behavior and let it restructure the graph. Drools CEP (temporal operators like `after`, `before`, `during`, sliding windows, `stream` event processing mode) has no equivalent in GoRules - GoRules is designed for request/response decisioning, not continuous event processing. ### 5. Validate against your Drools baseline Run identical inputs through both engines and compare outputs. GoRules simulation returns per-node trace - each node reports its input, output, and execution time. The AI copilot can generate boundary-condition test cases from your original DRL if you prompt it. Resolve any divergences before cutting over. ### 6. Swap the API integration If you use Kogito REST (`POST /{model-name}` with raw JSON, with whatever auth your service adds), GoRules follows the same POST/JSON workflow: `POST /projects/:projectId/evaluate/*` with input wrapped in `context` and auth via `x-access-token` header. The response returns `{ performance, result, trace }` - `trace` is included when the request body sets `"trace": true`. The decision document must be published in GoRules (and released to the target environment) before the evaluate endpoint will serve it. For embedded JVM use (Java or Kotlin), replace the `KieServices` → `KieSession` → `fireAllRules()` → `dispose()` chain with `io.gorules:zen-engine` (Maven Central). Node.js: `@gorules/zen-engine`, Python: `zen-engine`, Go: `zen-go`. GoRules AI ## Let the copilot do the translation. The AI copilot converts `.drl` files into decision graphs using the LLM's knowledge of Drools syntax. In tested conversions, DRL conditions map to Zen unary tests (`>= 18`, `< 650`), actions become output columns, and the copilot adds a catch-all default row automatically. Straightforward condition-action rules and decision tables convert cleanly. Constructs that depend on working memory - `insertLogical()`, `modify()` triggering re-evaluation, `salience`\-driven ordering, and `accumulate` with custom `AccumulateFunction` implementations - require manual restructuring because GoRules uses stateless DAG traversal, not Phreak inference. `eval()` blocks with arbitrary Java code must be rewritten as `functionNode` JavaScript or Zen expressions. Use the copilot iteratively: describe what a complex rule should do and let it restructure the graph. **On this page** - [What you get with GoRules](#what) - [Rule changes are live in seconds](#rule-changes-are-live-in-seconds) - [Visual editor for developers and business users](#visual-editor-for-developers-and-business-users) - [Stateless Rust engine with per-node tracing](#stateless-rust-engine-with-per-node-tracing) - [Native SDKs across languages](#native-sdks-across-languages) - [The migration path](#path) - [1\. Export rules from your Drools project](#export-rules-from-your-drools-project) - [2\. Map Drools constructs to GoRules node types](#map-drools-constructs-to-gorules-node-types) - [3\. Upload DRL files to the AI copilot](#upload-drl-files-to-the-ai-copilot) - [4\. Rebuild constructs that depend on working memory](#rebuild-constructs-that-depend-on-working-memory) - [5\. Validate against your Drools baseline](#validate-against-your-drools-baseline) - [6\. Swap the API integration](#swap-the-api-integration) - [Let the copilot do the translation](#ai) ## Other migration guides [View all guides](/switch) [_Guide_ ### Switch from IBM ODM A step-by-step guide to moving your BAL rules, decision tables, and ruleflows to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/ibm-odm)[_Guide_ ### Switch from FICO Blaze Advisor A step-by-step guide to moving your SRL rulesets, decision tables, ruleflows, and score models to GoRules: map the BOM to JSON, convert with the AI copilot, validate in parallel, and cut over. ](/switch/fico-blaze-advisor)[_Guide_ ### Switch from InRule A step-by-step guide to moving your .ruleapp rule applications, Business Language rules, and decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/inrule) ## Leave the build step behind. Bring your Drools rules over, run both engines in parallel, and cut over when the outputs match. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Switch from Decisions.com to GoRules | Decision Engine Migration **URL:** https://gorules.io/switch/decisions **Description:** Step-by-step Decisions.com migration guide: document your Statement Rules, Truth Tables, Matrix Rules, and Rule Sets, rebuild them as JSON decision graphs with the AI copilot, and validate before cutover. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Switch from Decisions.com to GoRules. A step-by-step guide to moving your Statement Rules, Truth Tables, Rule Tables, Matrix Rules, and Rule Sets to GoRules: document each rule, rebuild with the AI copilot, validate in parallel, and cut over. [Start migrating](https://us1.gorules.io) [Talk to an engineer](/contact-us) ## What you get with GoRules Where your rules land: the parts of GoRules most relevant to this migration. ### AI copilot for authoring and conversion The copilot converts uploaded rule files into decision graphs, edits tables from plain-language instructions, generates test cases, and explains what a decision did on a given input. Deploys and releases stay explicit human actions. ### One expression language everywhere Decision table cells, expression nodes, and switch conditions all use Zen - a single expression language with 60+ built-in functions (`sum`, `avg`, `filter`, `map`, `date`, `duration`, `matches`). For logic beyond expressions, `functionNode` runs sandboxed JavaScript with `zod`, `big.js`, `dayjs`, and `http` imports. ### Visual editor for developers and business users Rules are modeled as decision graphs in a web editor: decision tables, expressions, switches, and functions on one canvas. Business users and developers edit the same graph, with changes tracked per release. ### Native SDKs across languages The same Rust core ships as `@gorules/zen-engine` for Node.js, `zen-engine` for Python and Rust, `zen-go` for Go, `io.gorules:zen-engine` for JVM (Java and Kotlin), `GoRules.ZenEngine` for .NET, plus Swift, Android, and browser or Lambda via WASM. ## The migration path A step-by-step route from your current setup to running your rules on Zen Engine. ### 1. Inventory your Decisions rules GoRules has no importer for Decisions project ZIPs (`-MMDDYYYY-HHMMSS.zip`) or Repository Server exports. Before migration, walk the Studio and document each Rule Type in scope: input/output data definitions, condition trees for Statement Rules, columns/rows for Truth Tables and Rule Tables, axes for Matrix and Tree Rules, fact flows for Rule Chains, and members for Rule Sets. Capture verb names exactly (`String List Contains Five Of`, `Greater Than In Percents`, `Equals Without Decimal`) - these drive the Zen translation in step 3. ### 2. Map Decisions Rule Types to GoRules nodes `Statement Rule` with True/False outcomes maps to a `switchNode` with Zen boolean expressions; if the rule produces output values per outcome, add an `expressionNode` per branch. `Truth Table` and `External Data Truth Table` map to `decisionTableNode` with `hitPolicy: "first"` (each row is AND-of-columns, returns first match). `Rule Table` (cells = Statement Rules) flattens to a `decisionTableNode` whose cells contain Zen unary tests. `Matrix Rule` and `Tree Rule` (axes are nested Rules) map to chained `switchNode`s, or to a single `decisionTableNode` if both axes flatten cleanly to columns. `Rule Set` with `Inclusion Rule Control = Run All` maps to a `decisionTableNode` with `hitPolicy: "collect"`; `Stop on First True` / `Stop on First False` map to `hitPolicy: "first"` with rows ordered by your `Properties > SETTINGS > Rule Set > Order` values. `Rule Engine Extension` (anchor-typed custom verbs) becomes either an `expressionNode` (for verbs that are pure Zen) or a `functionNode` (for verbs backed by custom logic). ### 3. Translate Decisions verbs to Zen expressions Most verbs map directly: `Is` → `==`, `Is Not` → `!=`, `Greater Than` → `>`, `Greater Than Or Equal To` → `>=`, `Less Than` → `<`, `Between` → `x in [a..b]`, `In List` → `x in ["a","b","c"]`, `Contains` → `contains($, "...")`, `Starts With` → `startsWith($, "...")`, `Ends With` → `endsWith($, "...")`, `Is Empty` → `len(x) == 0`, `Is Not Empty` → `len(x) > 0`, `Regex Match` → `matches(x, "pattern")`. `Length Equals` → `len(s) == n`. The verbose count-of verbs (`List Contains Five Of`, `List Contains Three Of`) become `len(filter(list, # == target)) == 5`. Numeric specials: `Equals Without Decimal` → `floor(a) == floor(b)`; `Greater Than In Percents` → `value > (other * percent / 100)`. List quantifiers (`Contains All` / `Contains Any` / `Does Not Contain Any`) → `all(list, # condition)` / `some(list, # condition)` / `none(list, # condition)`. Date verbs map onto Zen `d()` and its date methods (durations are expressed as duration strings). The `Each List Item Name` scoped iteration variable becomes the `#` self-reference inside Zen quantifier functions. ### 4. Use the AI copilot to author from natural language Because there is no file importer, the practical migration path is to describe each rule in the GoRules AI copilot rather than upload a file. For a Statement Rule, paste the condition tree (verbs, AND/Either-Or grouping, outcomes) into the chat panel - the copilot generates an `expressionNode` or `switchNode`. For a Truth Table, describe the input columns, output columns, hit policy, and the row matrix - the copilot produces a `decisionTableNode` with Zen unary tests. For a Rule Chain that does not depend on backward chaining, describe the rule sequence - the copilot wires `decisionNode`s and intermediate `expressionNode`s. Iterate by pasting your sample inputs and expected outputs and asking the copilot to adjust until simulation matches. ### 5. Redesign constructs that have no GoRules equivalent `Rule Chains` with backward chaining ("derive only the facts I asked for") cannot be represented in a static DAG. Restructure as smaller decisions called conditionally by the application, or as a `switchNode` that gates which branches of the graph execute. `Rule Sets` that mix Rules and Flows split into two pieces: the rule logic moves to GoRules (`decisionTableNode` or chained nodes); the Flow members move to the calling application. `Rule Engine Extensions` with anchor-type dispatch have no equivalent - GoRules does not type-anchor verbs; rewrite the verb logic as a `functionNode` and have the calling application route the right inputs. `Champion/Challenger` A/B testing has no in-engine primitive; deploy two releases (or two decisions) and split traffic at the calling application or via a feature flag system. `Interceptor Rules` and `Learning Rules` adaptive validation move to the ingress layer of the application. Processes, Flows, Forms, Pages, Reports, Dashboards, and Assignments are out of scope for a decision engine - they need a separate platform or application surface. ### 6. Swap the API integration Replace your per-Rule API configuration (`Integration Type = API Service`, `Reference Type`, `Data Format`, `Configure HTTP Methods`) with a single endpoint pattern. The call `POST /Primary/restapi/Rule/` with `Authorization: Basic` (or a `SessionID` from `/Primary/REST/AccountService/LoginUser`, or `Bearer `) becomes `POST /projects/:projectId/evaluate/` with header `x-access-token: ` and body `{ "context": { ... }, "trace": false }`. The response shape changes from JSON / XML / Raw (per your configured `Data Format`) to a uniform `{ performance, result, trace }` envelope. For per-environment or per-release isolation, use the variants `POST /projects/:projectId/environments/:environmentId/evaluate/*` or `POST /projects/:projectId/releases/:releaseId/evaluate/*`. For embedded use without a REST hop, swap to a native SDK (`GoRules.ZenEngine` on NuGet for .NET, `io.gorules:zen-engine` on Maven Central for JVM, `@gorules/zen-engine` for Node, `zen-engine` for Python, `zen-go` for Go). ### 7. Validate against your Decisions baseline Run identical inputs through both engines and compare outputs. GoRules simulation returns a per-node trace - each node reports its input, output, and execution time - so divergences localize quickly. Once outputs match, publish the decision documents and release them to the target environment, then cut traffic over. GoRules AI ## Let the copilot do the translation. GoRules has no importer for Decisions project ZIPs or Repository Server exports, so unlike DMN-based migrations the AI copilot does not parse a source file here; you describe each rule to it instead. In tested conversions, this works well for `Statement Rule` condition trees (paste the verbs, AND/Either-Or grouping, and outcome values - the copilot generates `expressionNode` or `switchNode`), for `Truth Table` and `Rule Table` matrices (describe columns, rows, and hit policy - the copilot generates a `decisionTableNode` with Zen unary tests), and for verb translation (`Is` → `==`, `Greater Than` → `>`, `In List` → `in [...]`, `Contains` → `contains($, "...")`, `Between` → `x in [a..b]`, `Is Empty` → `len(x) == 0`, count-of verbs like `List Contains Five Of` → `len(filter(list, # == target)) == 5`). Constructs that need manual redesign: `Rule Chains` with forward/backward chaining (no equivalent in a static DAG - restructure as sequential decisions or as conditional `switchNode` branches), `Rule Sets` that mix Rules and Flows (split rule logic into GoRules nodes; move Flow members to the calling application), and `Rule Engine Extensions` with anchor-type dispatch (rewrite as `functionNode` since GoRules has no type-anchored dispatch). What the copilot cannot migrate at all: C# SDK custom Rule Verbs (rewrite as `functionNode` JavaScript with the sandboxed `zod` / `big.js` / `dayjs` / `http` / `zen` imports); `Champion/Challenger` A/B testing (no built-in primitive - handle traffic split in the calling application or a feature flag system); `Interceptor Rules` and `Learning Rules` adaptive validation (move validation to the application ingress); and the process and UI surface (Processes, Flows, Forms, Pages, Reports, Dashboards, Assignments) which is out of scope for a decision engine entirely. **On this page** - [What you get with GoRules](#what) - [AI copilot for authoring and conversion](#ai-copilot-for-authoring-and-conversion) - [One expression language everywhere](#one-expression-language-everywhere) - [Visual editor for developers and business users](#visual-editor-for-developers-and-business-users) - [Native SDKs across languages](#native-sdks-across-languages) - [The migration path](#path) - [1\. Inventory your Decisions rules](#inventory-your-decisions-rules) - [2\. Map Decisions Rule Types to GoRules nodes](#map-decisions-rule-types-to-gorules-nodes) - [3\. Translate Decisions verbs to Zen expressions](#translate-decisions-verbs-to-zen-expressions) - [4\. Use the AI copilot to author from natural language](#use-the-ai-copilot-to-author-from-natural-language) - [5\. Redesign constructs that have no GoRules equivalent](#redesign-constructs-that-have-no-gorules-equivalent) - [6\. Swap the API integration](#swap-the-api-integration) - [7\. Validate against your Decisions baseline](#validate-against-your-decisions-baseline) - [Let the copilot do the translation](#ai) ## Other migration guides [View all guides](/switch) [_Guide_ ### Switch from Drools A step-by-step guide to moving your DRL rules, DMN models, and spreadsheet decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/drools)[_Guide_ ### Switch from IBM ODM A step-by-step guide to moving your BAL rules, decision tables, and ruleflows to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/ibm-odm)[_Guide_ ### Switch from FICO Blaze Advisor A step-by-step guide to moving your SRL rulesets, decision tables, ruleflows, and score models to GoRules: map the BOM to JSON, convert with the AI copilot, validate in parallel, and cut over. ](/switch/fico-blaze-advisor) ## Leave the build step behind. Bring your Decisions.com rules over, run both engines in parallel, and cut over when the outputs match. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Switch from DecisionRules to GoRules | Rules Engine Migration **URL:** https://gorules.io/switch/decisionrules **Description:** Step-by-step DecisionRules migration guide: map Decision Tables, Decision Trees, Scripting Rules, and Decision Flows to JSON decision graphs, convert operators to Zen expressions, and run them on Zen Engine. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Switch from DecisionRules to GoRules. A step-by-step guide to moving your Decision Tables, Decision Trees, Scripting Rules, and Decision Flows to GoRules: map each rule type, rebuild with the AI copilot, validate in parallel, and cut over. [Start migrating](https://us1.gorules.io) [Talk to an engineer](/contact-us) ## What you get with GoRules Where your rules land: the parts of GoRules most relevant to this migration. ### One expression language everywhere Decision table cells, expression nodes, and switch conditions all use Zen - a single expression language with 60+ built-in functions (`sum`, `avg`, `filter`, `map`, `date`, `duration`, `matches`). For logic beyond expressions, `functionNode` runs sandboxed JavaScript with `zod`, `big.js`, `dayjs`, and `http` imports. ### Versioning, environments, and rollback built in Semantic versioned releases, environment-scoped deployments with rollback, and branching for parallel rule development. Publish, release, and deploy are explicit human actions, each with an audit trail. ### AI copilot for authoring and conversion The copilot converts uploaded rule files into decision graphs, edits tables from plain-language instructions, generates test cases, and explains what a decision did on a given input. Deploys and releases stay explicit human actions. ### Stateless Rust engine with per-node tracing The Zen Engine evaluates a decision per request: JSON in, DAG traversal in topological order, JSON out. Each node runs exactly once, and the response can include a per-node trace with input, output, and sub-millisecond timing. ## The migration path A step-by-step route from your current setup to running your rules on Zen Engine. ### 1. Map DecisionRules rule types to GoRules node types Decision Table rows map to `decisionTableNode` rows - condition columns become input columns with Zen unary tests (`> 1000`, `in ["US","CA"]`), result columns become output columns. The `FIRST_MATCH` strategy maps to `first` hit policy and `STANDARD` maps to `collect`. `EVALUATE_ALL` (which returns a result for every row, matched or not) and the `ARRAY` strategy have no direct hit-policy equivalent - restructure those tables around `collect` plus downstream expression logic. Calculation columns have no direct equivalent - use `expressionNode` upstream of the table to compute intermediate values. Decision Trees (IF-THEN-ELSE blocks) map to `switchNode` with ordered Zen conditions and downstream nodes for each branch. Scripting Rules map to `functionNode` (sandboxed JavaScript) or `expressionNode` chains for simpler logic. Decision Flows map to the graph itself - Business Rule nodes become `decisionNode` references, Switch nodes become `switchNode`, Assign nodes become `expressionNode`. ### 2. Convert operator syntax to Zen expressions DecisionRules per-cell operators translate to Zen unary tests: `= "US"` → `"US"`, `>= 1000` → `>= 1000`, `BTW [10 AND 50]` → `[10..50]`, `IN "A"|"B"|"C"` → `"A","B","C"`, `NULL` → `== null`, `C TXT "abc"` → `contains($, "abc")`. Functions translate to Zen equivalents: `SUM(a,b)` → `a + b` or `sum(list)`, `CONCAT("a","b")` → `"a" + "b"` or `string(a) + string(b)`, `IF(cond,a,b)` → `cond ? a : b` (chain ternaries for multi-branch logic). Variables change from `{variableName}` to direct path references (`customer.age`). Inside an `expressionNode`, `$.key` references keys computed earlier in the same node; in decision-table cells, `$` refers to the tested column value. ### 3. Restructure flow orchestration patterns If your Decision Flows use Foreach, Global Variables, Declare, REST API Client, or Database Query nodes, restructure them onto the graph DAG: `switchNode` for conditional branching, `expressionNode` chains for data transforms, `decisionNode` for sub-rule calls, and `functionNode` for HTTP calls or complex logic. For array iteration, use loop execution mode on `decisionTableNode` or `expressionNode` - set `executionMode: "loop"` with `inputField` pointing to the array (e.g., `order.items`) and `outputPath` to wrap the results. There is no built-in database query node - use `functionNode` with the `http` import to call a data API. ### 4. Handle Integration Flow workloads If you use Integration Flows for batch processing or long-running jobs, note that GoRules does not have a built-in async job system - it is designed for synchronous request/response evaluation. For batch workloads, call the GoRules evaluate endpoint from your application's own job infrastructure (worker queues, cron jobs, or serverless triggers). The evaluate API returns sub-millisecond for typical rules, so high-throughput batch processing is achievable via parallelized HTTP calls from your orchestration layer. ### 5. Swap the API integration Replace `POST /rule/solve/:ruleId/:version` with body `{"data": {...}}` and `Authorization: Bearer ` (plus any `X-Strategy` header) with `POST /projects/:projectId/evaluate/*` with body `{"context": {...}}` and the `x-access-token` header. The response changes from an array of result objects to `{ performance, result, trace }` - result is a single object, with built-in execution timing. If you send bulk inputs as an array under `data`, send individual requests per input instead (the engine creates and disposes per request). Three evaluation variants: `/evaluate/*` (published), `/environments/:environmentId/evaluate/*` (pinned release), `/releases/:releaseId/evaluate/*` (specific release). ### 6. Replace environment and CI/CD patterns If your environments are modeled as separate spaces with distinct API keys and your CI/CD pipeline exports from one space and imports into another via the Management API (`decisionrules-cicd-tools`), replace that with first-class environments and release pinning: deploy a semantic versioned release to a named environment, and all evaluations against that environment use the pinned release. No export/import cycle needed. Branching supports parallel rule development with change request approvals. Roll back by repointing the environment to a previous release. ### 7. Validate in parallel, then cut over Run identical inputs through both engines and compare outputs. GoRules simulation returns a per-node trace - each node reports its input, output, and execution time - so divergences localize quickly. Once outputs match, publish the decision documents and release them to the target environment, then switch your Solver API calls over to the GoRules endpoint. GoRules AI ## Let the copilot do the translation. The AI copilot can restructure rule logic described in natural language into GoRules decision graphs - adding nodes, edges, and Zen expressions via graph modification tools. It understands the Zen expression language, all 7 node types, and can simulate graphs during conversion. For DecisionRules migration specifically: describe your Decision Table conditions and the copilot generates `decisionTableNode` rows with Zen unary tests. Describe IF-THEN-ELSE tree logic and it builds `switchNode` branches. Describe Scripting Rule behavior and it produces `functionNode` or `expressionNode` chains. What it cannot do automatically: there is no file-format importer for DecisionRules exports - the copilot works from natural language descriptions and pasted rule logic, not from DecisionRules JSON exports. Decision Flow orchestration patterns (Foreach loops, Global Variables, database queries, REST API Client nodes) require manual restructuring into GoRules graph patterns. Integration Flow async job patterns have no direct equivalent and must be redesigned around your own batch infrastructure. **On this page** - [What you get with GoRules](#what) - [One expression language everywhere](#one-expression-language-everywhere) - [Versioning, environments, and rollback built in](#versioning-environments-and-rollback-built-in) - [AI copilot for authoring and conversion](#ai-copilot-for-authoring-and-conversion) - [Stateless Rust engine with per-node tracing](#stateless-rust-engine-with-per-node-tracing) - [The migration path](#path) - [1\. Map DecisionRules rule types to GoRules node types](#map-decisionrules-rule-types-to-gorules-node-types) - [2\. Convert operator syntax to Zen expressions](#convert-operator-syntax-to-zen-expressions) - [3\. Restructure flow orchestration patterns](#restructure-flow-orchestration-patterns) - [4\. Handle Integration Flow workloads](#handle-integration-flow-workloads) - [5\. Swap the API integration](#swap-the-api-integration) - [6\. Replace environment and CI/CD patterns](#replace-environment-and-ci-cd-patterns) - [7\. Validate in parallel, then cut over](#validate-in-parallel-then-cut-over) - [Let the copilot do the translation](#ai) ## Other migration guides [View all guides](/switch) [_Guide_ ### Switch from Drools A step-by-step guide to moving your DRL rules, DMN models, and spreadsheet decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/drools)[_Guide_ ### Switch from IBM ODM A step-by-step guide to moving your BAL rules, decision tables, and ruleflows to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/ibm-odm)[_Guide_ ### Switch from FICO Blaze Advisor A step-by-step guide to moving your SRL rulesets, decision tables, ruleflows, and score models to GoRules: map the BOM to JSON, convert with the AI copilot, validate in parallel, and cut over. ](/switch/fico-blaze-advisor) ## Leave the build step behind. Bring your DecisionRules rules over, run both engines in parallel, and cut over when the outputs match. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Switch from Camunda to GoRules | Decision Engine Migration **URL:** https://gorules.io/switch/camunda **Description:** Step-by-step Camunda migration guide: export your .dmn files from Camunda 7 or 8, convert FEEL and JUEL expressions to JSON decision graphs with the AI copilot, and run them on Zen Engine. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Switch from Camunda to GoRules. A step-by-step guide to moving your DMN models to GoRules: export the .dmn files, convert FEEL and JUEL expressions with the AI copilot, validate in parallel, and cut over. [Start migrating](https://us1.gorules.io) [Talk to an engineer](/contact-us) ## What you get with GoRules Where your rules land: the parts of GoRules most relevant to this migration. ### One expression language everywhere Decision table cells, expression nodes, and switch conditions all use Zen - a single expression language with 60+ built-in functions (`sum`, `avg`, `filter`, `map`, `date`, `duration`, `matches`). For logic beyond expressions, `functionNode` runs sandboxed JavaScript with `zod`, `big.js`, `dayjs`, and `http` imports. ### AI copilot for authoring and conversion The copilot converts uploaded rule files into decision graphs, edits tables from plain-language instructions, generates test cases, and explains what a decision did on a given input. Deploys and releases stay explicit human actions. ### Stateless Rust engine with per-node tracing The Zen Engine evaluates a decision per request: JSON in, DAG traversal in topological order, JSON out. Each node runs exactly once, and the response can include a per-node trace with input, output, and sub-millisecond timing. ### Native SDKs across languages The same Rust core ships as `@gorules/zen-engine` for Node.js, `zen-engine` for Python and Rust, `zen-go` for Go, `io.gorules:zen-engine` for JVM (Java and Kotlin), `GoRules.ZenEngine` for .NET, plus Swift, Android, and browser or Lambda via WASM. ## The migration path A step-by-step route from your current setup to running your rules on Zen Engine. ### 1. Export DMN XML and audit expression languages \[Camunda 8\] Export your `.dmn` resources from Web Modeler or pull them from your deployment artifacts - expressions in these files are FEEL, and translation to Zen is largely direct. \[Camunda 7\] Export each `.dmn` file and audit every cell for an `expressionLanguage` attribute. Cells with `expressionLanguage="juel"`, `expressionLanguage="groovy"`, `expressionLanguage="javascript"`, or any other JSR-223 language need separate handling (see step 4). If your engine configuration sets `dmnFeelEnableLegacyBehavior` or calls `setEnableFeelLegacyBehavior(true)`, older files in that project may use JUEL in cells without an explicit attribute - verify each one. ### 2. Map DMN decision tables to `decisionTableNode` Each `` maps to one `decisionTableNode`. Input clauses become input columns (the `inputExpression` text becomes the column `field`); output clauses become output columns (`name` becomes the output `field`). DMN UNIQUE/ANY/FIRST hit policies map to `hitPolicy: "first"`; RULE ORDER and COLLECT map to `hitPolicy: "collect"`. COLLECT with an aggregator (SUM/MIN/MAX/COUNT) becomes a `collect` table followed by an `expressionNode` that applies `sum`/`min`/`max`/`count` from the Zen built-in function library. Decision dependency chains declared via `` become `decisionNode` references between separate decision files - each upstream decision is its own JSON graph, and the requiring graph references it through a `decisionNode`. ### 3. Translate expressions to Zen \[Both\] FEEL operators map directly to Zen: `==`, `!=`, `<`, `>`, `<=`, `>=`, `and`/`or`/`not`, ranges like `[1..10]` and `(1..10)`. FEEL `contains(?, "x")` becomes Zen `contains($, "x")` in unary tests (where `$` is the input column value). FEEL `from json()`/`to json()` are not needed - GoRules works on JSON natively. FEEL list functions (`some`, `every`, aggregations) map to Zen `some`, `all`, `filter`, `map`, `sum`, `avg`, `min`, `max`. \[Camunda 7\] JUEL expressions that call Spring or CDI beans (`${myBean.method(input)}`) cannot be translated by tooling - rewrite the bean logic inside a `functionNode` (ES6 JavaScript) or move the call to the calling application as a pre-processing step before invoking GoRules. JSR-223 cells (Groovy, Python, Ruby) must be rewritten in Zen or in `functionNode` JavaScript. \[Camunda 8\] BKMs (Business Knowledge Models, FEEL functions with parameters) become either a `decisionNode` (if the BKM is large enough to warrant its own graph) or a `functionNode` for reusable computation. ### 4. Handle constructs with no GoRules equivalent \[Camunda 7\] `FeelCustomFunctionProvider` registrations (named FEEL functions added via `CustomFunction.create()`) have no global-function-library equivalent in GoRules - migrate each function into a `functionNode`. Spin XML variables (`SpinXmlElement`) do not migrate - convert XML to JSON in the calling application before invoking GoRules. `TypedValue` wire-format triples (`{type, value, valueInfo}`) must be unwrapped in the calling application; GoRules accepts plain JSON inputs. \[Camunda 8\] BKMs are not directly representable - decompose into separate decision files referenced by `decisionNode`, or inline as `functionNode` JavaScript. Custom FEEL functions in your own code become `functionNode` JavaScript in GoRules. ### 5. Separate the decision layer from the workflow layer \[Both\] The BPMN process layer does not migrate to GoRules. Long-running processes with token state, timers, message correlation, user tasks, event subscriptions, multi-instance activities, and compensation events stay in a workflow orchestrator. Business rule tasks (`zeebe:calledDecision` in Camunda 8, `DecisionService` calls in Camunda 7) become HTTP calls from the orchestrator to GoRules at `POST /projects/:projectId/evaluate/*`. \[Camunda 7\] Java Delegates, Execution Listeners, Task Listeners, and Field Injection that contain decision logic move either to the calling application (most common - the application invokes GoRules and handles side effects itself) or into a `functionNode` if the logic is portable and side-effect-free. External Task workers stay in the workflow orchestrator. \[Camunda 8\] If you consume decision-instance evaluation records (via `POST /v2/decision-instances/search`), note that GoRules does not persist evaluations server-side - capture the per-call `trace` field in the calling application and persist it to your own audit store if needed. ### 6. Swap the API integration \[Camunda 8\] Replace `POST /v2/decision-definitions/evaluation` with `POST /projects/:projectId/evaluate/*`. Authentication moves from `Authorization: Bearer ` to `x-access-token: `. The request body changes from `{ "variables": {...} }` to `{ "context": {...}, "trace": false }`, and the response from `{ "evaluatedDecisions": [...], "output": ... }` to `{ "performance": "...", "result": ..., "trace": {...} }`. Search endpoints such as `POST /v2/decision-instances/search` have no analog - per-evaluation trace is response-only in GoRules. \[Camunda 7\] Replace `POST /engine-rest/decision-definition/{id}/evaluate` with the same `POST /projects/:projectId/evaluate/*` and move authentication to the `x-access-token` header. The variable wire format changes from `{type, value, valueInfo}` triples with capitalized type names (`String`, `Long`, `Date`, `Object`) and `valueInfo.objectTypeName`/`serializationDataFormat` on `Object` to plain JSON in a `context` object. Date values become ISO 8601 strings parsed by Zen `date()` functions. ### 7. Validate in parallel, then cut over Run identical inputs through both engines and compare outputs. GoRules simulation returns a per-node trace - each node reports its input, output, and execution time - so divergences localize quickly. Once outputs match, publish the decision documents and release them to the target environment, then point the orchestrator or calling application at the GoRules endpoint. GoRules AI ## Let the copilot do the translation. You can upload `.dmn` files to the AI copilot directly, whether exported from Camunda 8 (Web Modeler) or Camunda 7 (Desktop Modeler or deployment artifacts). What the copilot handles well, both versions: decision table structure (inputs, outputs, rules) maps to `decisionTableNode` regardless of source. FEEL-to-Zen translation is largely direct - `==` stays `==`, `>` stays `>`, range syntax `in [a..b]` stays `x in [a..b]`, `contains(?, "x")` becomes `contains($, "x")`, and FEEL list functions (`some`, `every`, `sum`, `mean`, `count`) map to Zen `some`, `all`, `sum`, `avg`, `len(filter(...))`. Decision dependency chains declared via `informationRequirement` become `decisionNode` references between separate decision files. What needs manual triage, Camunda 7 specifically: JUEL expressions referencing Spring or CDI beans (e.g. `${myBean.method(input)}`) cannot be translated by tooling - the copilot cannot see your bean code. Rewrite the bean logic inside a `functionNode` (ES6 JavaScript) or move the call to the calling application as a pre-processing step. JSR-223 cells in DMN (Groovy, Python, Ruby) must be rewritten in Zen or `functionNode` JavaScript. `FeelCustomFunctionProvider` registrations have no global-function-library equivalent in GoRules - migrate each function into a `functionNode`. Spin XML variables (`SpinXmlElement`) do not migrate - convert XML to JSON in the calling application before invoking GoRules. What requires manual redesign, both versions: BKMs become either a `decisionNode` (graph composition) or a `functionNode` for inline reusable computation. The BPMN process layer - workflow orchestration, timers, message correlation, user tasks, External Tasks, event subscriptions, multi-instance activities - is out of scope for a decision engine entirely; it stays in a workflow orchestrator. GoRules does not persist per-evaluation audit records server-side; the per-call `trace` field is returned in the response but not stored, so persistent audit capture lives in the calling application. **On this page** - [What you get with GoRules](#what) - [One expression language everywhere](#one-expression-language-everywhere) - [AI copilot for authoring and conversion](#ai-copilot-for-authoring-and-conversion) - [Stateless Rust engine with per-node tracing](#stateless-rust-engine-with-per-node-tracing) - [Native SDKs across languages](#native-sdks-across-languages) - [The migration path](#path) - [1\. Export DMN XML and audit expression languages](#export-dmn-xml-and-audit-expression-languages) - [2\. Map DMN decision tables to decisionTableNode](#map-dmn-decision-tables-to-decisiontablenode) - [3\. Translate expressions to Zen](#translate-expressions-to-zen) - [4\. Handle constructs with no GoRules equivalent](#handle-constructs-with-no-gorules-equivalent) - [5\. Separate the decision layer from the workflow layer](#separate-the-decision-layer-from-the-workflow-layer) - [6\. Swap the API integration](#swap-the-api-integration) - [7\. Validate in parallel, then cut over](#validate-in-parallel-then-cut-over) - [Let the copilot do the translation](#ai) ## Other migration guides [View all guides](/switch) [_Guide_ ### Switch from Drools A step-by-step guide to moving your DRL rules, DMN models, and spreadsheet decision tables to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/drools)[_Guide_ ### Switch from IBM ODM A step-by-step guide to moving your BAL rules, decision tables, and ruleflows to GoRules: export, convert with the AI copilot, validate in parallel, and cut over. ](/switch/ibm-odm)[_Guide_ ### Switch from FICO Blaze Advisor A step-by-step guide to moving your SRL rulesets, decision tables, ruleflows, and score models to GoRules: map the BOM to JSON, convert with the AI copilot, validate in parallel, and cut over. ](/switch/fico-blaze-advisor) ## Leave the build step behind. Bring your Camunda rules over, run both engines in parallel, and cut over when the outputs match. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Decision Engine: What It Is and When You Need One **URL:** https://gorules.io/solutions/decision-engine **Description:** A decision engine turns rules and data into a decision with reasons attached. See when you need one, and how GoRules runs yours in under a millisecond. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # A decision engine that shows its reasoning. A decision engine takes your rules and your data and returns a decision with the reasons that produced it. GoRules is that engine on an open-source core: visual decision tables the policy owners edit themselves, sub-millisecond evaluation, and a versioned trail behind every outcome. ## From waiting on approval to approved on submit. Watch one $240,000 renewal move through a live decision graph: request in, knockouts, the discount table, pricing, response out in 0.6 ms. Then a one-cell change to that table, a replay over the quarter's 940 quotes, a signed release, and the same request coming back auto-approved. scroll to play **quote\_approval**_v1.3.2__v1.4.0__5 nodes · 26 rules · p99 0.6 ms_ **Request**input **Knockouts**table · 4 rules **Discount policy**decision table · v1.3.2decision table · v1.4.0 tierdiscountapproval enterprise≤ _15%_≤ _20%_auto-approve enterprise≤ _30%_VP rev ops otherwise\-deal desk **Pricing**function · zen **Response**output open in GoRules · editing on a branch _request_replay { **"account"**: "meridian-health", **"tier"**: "enterprise", **"discount"**: _0.18_, **"margin"**: _0.68_, **"term\_months"**: _24_ } POST /evaluate · from CPQsame payload · against v1.4.0 _response_approval requiredauto-approved { **"decision"**: "requires VP approval", **"reasons"**: \["discount 18% over 15% cap"\], **"matched"**: "discount\_policy · row 2", **"route"**: "vp\_revenue\_ops", **"policy"**: "v1.3.2" } { **"decision"**: "auto-approved", **"reasons"**: \["18% within 20% cap", "margin 68% over 62% floor"\], **"matched"**: "discount\_policy · row 1", **"route"**: "straight\_through", **"policy"**: "v1.4.0" } evaluated in 0.6 ms · 26 rules · trace kept QT-4396 held · 28% ask · margin floor 62% _evaluated today_**3,958** _flipped to auto_**+0** _held at floor_**1** _p99 latency_**0.6 ms** _callers_**CPQ · partner API web · nightly batch** policy v1.4.0 · same graph, every channel #### Discount policy Approval routing for quote discounts. Evaluated top-down on every quote - first match decides. **Tier****Discount****Margin at discount****Approval** 1**Enterprise**_at most_ **15%**_at most_ **20%**_at least_ **62%****Auto-approve** 2**Enterprise**_at most_ **30%**_at least_ **55%****VP Revenue Ops** 3**Mid-market**_at most_ **12%**_at least_ **60%****Auto-approve** 4_Otherwise_**Deal desk review** + was at most 15% · margin floor untouched · edited by Deal Desk 1 unsaved change_Run tests__Request review_ **Quality checks**_0 quotes replayed_ Enterprise at 18%, margin 68%, auto-approves_was: VP queue_ Enterprise over 20% still routes to the VP_unchanged_ Anything under the margin floor still holds_guardrail_ Non-standard terms still go to the deal desk_unchanged_ All checks passed · 0 quotes auto-approve · 0 below the margin floor _Release v1.4.0_ **v1.4.0**_draft_Jane Cooper · just now · enterprise auto-approve 15% → 20% JC **Jane Cooper**VP Revenue Operations _pending_ _development_**v1.4.0** deploying _staging_**v1.3.2** live _production_**v1.3.2** live Live in production - every new quote routes against v1.4.0, and the quotes already sitting in the approval queue re-evaluate automatically. full diff + approval recorded · one-click rollback _One request_ ### A quote hits the engine. Meridian Health, a $240,000 enterprise renewal at 18 percent off, arrives as one JSON payload and enters the decision graph that every channel calls. _First pass_ ### Answered in 0.6 ms. Still parked. Knockouts clear, the discount table matches row 2, pricing holds - and the response comes back requires VP approval. The margin is 68 percent, six points clear of the floor. The table only knows that 18 is more than 15. _One cell_ ### The node that decided opens. The rule named in the response is the rule you edit. Enterprise auto-approve moves from 15 to 20 percent on a branch, and the 62 percent margin floor stays exactly where it was. _Proof before production_ ### The quarter's 940 quotes replay. Every quote booked this quarter re-runs against the draft while you watch: 210 would have auto-approved, none below the margin floor, non-standard terms still routed to the deal desk. _Sign-off_ ### Revenue ops approves. v1.4.0 ships. Jane Cooper signs the release, it promotes through staging to production with the full trail recorded. Rollback stays one click away. _Same request_ ### Same graph. Different answer. The identical payload replays, the path lights all the way through, and the response comes back auto-approved in 0.6 ms with the reasons attached. Live traffic follows: 210 quotes flip, and the one asking 28 percent still stops at the margin floor. ## The logic is everywhere. The reasons are nowhere. A decision engine is easy to describe and hard to find inside a real codebase. Rules and data go in, a decision and the reasons behind it come out. In most products that shape exists only on the whiteboard: the eligibility cutoff sits in one service, the pricing rule sits in another, the exceptions live in a spreadsheet somebody maintains by hand, and nobody can point at the thing that decided. Hardcoded logic is fine right up until the logic starts changing. Then every threshold move becomes a ticket, a sprint, and a release window, and the people who own the policy, risk, pricing, operations, compliance, are the only people who cannot touch it. The same rule gets copied into a batch job, a mobile backend, and a partner API, and the three copies drift apart quietly. The market's answer has been the enterprise decisioning platform. Those suites work, but they arrive as six to eighteen month implementations, bundle data marketplaces and bureau connectors you already pay for elsewhere, and mostly run only in the vendor's cloud, which is an awkward conversation when the decisions touch regulated customer data. And the questions that actually matter still go unanswered. Why did this customer get referred instead of approved? What happens to volume if we move the cutoff five points? Who approved the version that was live last March, and can you reproduce it on demand? _api/src/decide.ts_`if (risk >= 60 && tier === 2) {` `return refer("MANUAL");``}``return approve();` _decision\_matrix\_v11\_FINAL.xlsx_ segmentcutoff tier-145 tier-260 PLT-742**Raise tier-2 cutoff to 65 before Q4**_backlog · needs a deploy · three services read this_ one decision · three copies · no version history ## One place where the deciding happens. A decision engine pulls decision logic out of application code. Your services send data, the engine returns the outcome and the rules that produced it. _01_ ### Rules and data in, a decision and its reasons out Every decision has the same shape: a structured request carrying an application, a transaction, a cart, or a claim, and a structured response carrying an outcome plus how it was reached. In GoRules you model that as a decision graph. Decision tables cover the spreadsheet-shaped parts, Policies model shared definitions as ordered blocks the engine sequences for you, ZEN expressions handle derived values like ratios and rolling windows, and typed TypeScript function nodes cover anything genuinely custom. Model scores, screening hits, and third-party data enter as plain inputs, so the outcome stays a readable rule result instead of a number nobody can defend. _02_ ### The people who own the policy own the rules Decision tables are spreadsheet-shaped on purpose, and natural-language rendering makes each row read the way the policy document does, so an analyst can write a rule an auditor can check. Every change lands in [git-like version control](/version-control) with branches, commit history, change requests, approvals, and one-click rollback, then moves through dev, staging, and production as an explicit release. GoRules AI can draft a rule change, run the tests, create graphs, and explain what a decision did. Releasing stays a human decision with a name on it. _03_ ### Runs where your data already lives The evaluation core is the [open-source ZEN Engine](/open-source), MIT licensed with a Rust core, embeddable through SDKs for Node.js, Python, Java, Go, C#, Rust, Kotlin, Swift, and WebAssembly. Run the full BRMS self-hosted with Docker or Kubernetes on AWS, Azure, or Google Cloud, put the Agent in front of it as a hot-reloading REST endpoint, drop the engine into a serverless function, or use GoRules Cloud. Decision data never has to cross a boundary you did not choose. ## From hardcoded to governed, in four moves. Nothing about your data platform, your models, or your product changes. Only the place where decisions are made moves. 01 ### Connect Call GoRules over the REST API from whichever service holds the logic today, run the Agent next to it for hot-reloading evaluation, or embed the engine in-process with an SDK when you want zero network hops. One decision at a time is a fine migration path, and the request payload is simply whatever your rules need to see. 02 ### Model Rebuild the decision as a graph instead of a branch tree: knockouts first, then the tables that carry the real matrix, then the calculations. If you have not modeled decisions this way before, the [business rules engine](/what-is-business-rules-engine) primer covers the vocabulary, and the template library gives you a working starting point per industry. 03 ### Test and simulate Run historical cases through the simulator, check test coverage and static analysis before anyone signs off, and branch a challenger to compare it against the live policy on the same inputs. Stakeholders review the natural-language rendering of each rule, not the JSON underneath it. 04 ### Operate Promote through environments with approvals recorded at each step, evaluate in production in well under a millisecond, and keep every decision linked to the rules that fired. When conditions move, the policy owner edits a cell and ships the same day, and rolls back in one click if the numbers disagree. ## Built for production, not proof of concept. - Sub-millisecond evaluation on the open-source ZEN Engine (Rust core), embedded in your services or called over REST, fast enough to sit inline in a checkout or a payment path - Git-like version control on every decision: branches, commit history, change requests with approvals, and one-click rollback across dev, staging, and production - Self-host with Docker or Kubernetes on AWS, Azure, or Google Cloud so regulated data stays inside your perimeter, or run GoRules Cloud when managed hosting is simpler - A complete audit trail: which rules fired on any decision, and who changed what, when, and with whose approval. SSO, role-based access control, SOC 2 - No lock-in: an MIT-licensed core, SDKs across eleven languages, and [70+ industry templates](/templates) covering lending, insurance, healthcare, retail, and public sector decisions ## Questions, answered. ### What is a decision engine? A decision engine is software that evaluates rules against data and returns a decision, usually with the reasons that produced it. The shape is always the same: a request goes in carrying whatever the decision needs, the engine applies logic that lives outside your application code, and an outcome comes back in real time, typically approve, decline, refer, price, or route. What makes it an engine rather than a function is that the logic is a managed asset: versioned, testable, editable by the people who own the policy, and auditable long after the fact. GoRules provides that as visual decision graphs and decision tables running on an open-source evaluation core. ### What is the difference between a decision engine and a rules engine? In practice the terms overlap, and vendors use them interchangeably. The distinction people usually mean is one of scope: a rules engine executes a set of if/then rules, while a decision engine or decisioning platform is the system around it, orchestrating several rule sets and data sources with simulation, versioning, environments, approvals, and an audit trail. GoRules is both halves, and they are separable. The MIT-licensed ZEN Engine does the evaluating and embeds on its own, while the BRMS around it handles authoring, testing, version control, and multi-environment releases. ### When do you need a decision engine instead of hardcoded logic? Hardcoded logic is the right answer when the rules are few, stable, and owned by the engineers who wrote them. You have outgrown it when the same rule is copied across more than one service and the copies drift, when business teams file tickets to change thresholds they own, when you cannot explain why an individual case got the outcome it did, or when you cannot show who approved the version that was live on a given date. The clearest tell is cadence: if policy changes weekly and your deploys are quarterly, the logic belongs outside the code. Moving one decision out is usually enough to prove the point. ### How does a decision engine work with machine learning models? Model output enters the decision as an input, not as the decision itself. Your model emits a score, a probability, or a classification, and the engine decides what to do about it: where the cutoff sits, which cases are knocked out before the score is consulted, who gets referred to a person, what price or limit applies. That separation is what keeps the outcome explainable, because it traces to readable rules rather than to a score alone, which matters under GDPR Article 22, the EU AI Act's high-risk classifications, and internal model risk review. GoRules supplies the traceability; the compliance obligations remain yours. ### Can a decision engine run in our own infrastructure? Yes. Run the BRMS self-hosted with Docker or Kubernetes on AWS, Azure, or Google Cloud, and put the Agent in front of it for a high-performance REST endpoint with hot rule reloading. If you want evaluation in-process with no network hop at all, embed the open-source ZEN Engine directly through the Node.js, Python, Java, Go, C#, Rust, Kotlin, Swift, or WebAssembly SDKs, so decision data never crosses a vendor boundary. SSO and role-based access control govern who can read or change rules in either setup, and GoRules Cloud is there when managed hosting is the simpler answer. ## The same engine, next door. One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail. [**Credit Decisioning**Policy above your risk models](/use-cases/credit-decisioning)[**Transaction Monitoring**The same engine for AML rules](/use-cases/transaction-monitoring)[**Dynamic Pricing**Prices decided, not hardcoded](/use-cases/dynamic-pricing) ## Rules in. Decisions out. Reasons attached. Pick the one decision that changes most often, model it as a table in the visual editor, and point the service that owns it at the REST API this week. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Credit Decision Engine - Automated Lending **URL:** https://gorules.io/solutions/credit-decision-engine **Description:** Credit decision engine software that automates lending decisions with rules. Build loan eligibility, credit scoring, and risk-based pricing without code. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # The decision engine behind your lending. Automate eligibility, limits, and risk-based pricing with rules your credit team owns. Your tech team integrates once - after that, policy changes without a release. [More financial services decisioning](/industries/financial) **Credit Policy**_v2.4.0 · production_ credit.scoredtidecision _greater than_ 740_up to_ 0.36approve · tier A _between_ 640 _and_ 700_any_manual review _less than_ 640_any_decline **_between_ 700 _and_ 740**_up to_ 0.40approve · tier B _JC_ **Jane Cooper**_application #4820_ score 720 · dti 0.31 score = 720tier B banddti 0.31 ≤ 0.40approve · tier B decision in 0.7 ms · reason recorded ## Policy changes, without the IT project. Manual credit decisions slow lending down and drift over time. Hardcoded rules turn every policy change into a release. When rates drop or regulations shift, you act - instead of waiting on a sprint. - Decisions in milliseconds, not hours - Consistent criteria on every application - Credit team edits rules directly - Full audit trail of every decision ## From integration to proactive outreach. One engine carries an application from intake to decision - then keeps working your portfolio after the loan is booked. _01_**Connect your loan origination system** REST API and native SDKs for any platform - integrate once and it runs automatically inside your existing workflow. _02_**Define credit rules visually** Eligibility, scoring, and pricing in decision tables anyone can read. Import existing rules straight from Excel. _03_**Automate the decisions** Clear approvals and declines resolve instantly; edge cases route to underwriters with full context. _04_**Re-evaluate the portfolio** Run the entire book through updated rules overnight - millions of records in one batch job. _05_**Route new eligibility to sales** When customers qualify for better rates or higher limits, your sales team hears about it first. ## Every decision, explainable to audit. Approvals, declines, and referrals all leave the same trail: which rule fired, on which data, in which release - years later, on demand. ### The no comes with a why. Ask about any decision and get the rule, the data, and the threshold that decided it. [Meet GoRules AI](/ai) Why was application #4821 declined? score = 612less than 640decline Adverse action reason recorded automatically. ### Edge cases meet humans. Applications outside the clear bands queue for underwriters with every input attached. [Explore approval flows](/approval-flows) _MW_ **Marcus Webb**_#4823 · score 655 · thin file_ in review _AF_ **Amelia Ford**_#4819 · score 688 · self-employed_ approved Underwriters see the full trace, not just a score. ### Re-score the book overnight. The same policy that decides one application sweeps your whole portfolio in batch - surfacing limit increases, rate improvements, and cross-sell opportunities while interest is warm. [Explore big data](/big-data) Nightly portfolio run_Run_ **\*\*\*\* 2101**limit $8,000eligible $12,000 **\*\*\*\* 4482**rate 11.9%eligible 9.9% **\*\*\*\* 7714**limit $5,000no change **\*\*\*\* 9038**rate 14.5%eligible 12.9% 2,847 accounts flagged for a better offer - routed to sales. ## Credit decisions you can automate. Start with one decision and grow - the same policy language covers the whole lending lifecycle. ### Loan eligibility Check income, employment, and credit history against your criteria. ### Credit limits Calculate limits based on risk profile and customer segments. ### Risk-based pricing Set interest rates dynamically based on applicant risk. ### Instant decisions Auto-approve or deny applications that meet clear criteria. ### Manual review routing Flag edge cases for underwriter review with full context. ### Portfolio monitoring Continuously check existing accounts against updated rules. ## Build, buy - or neither. Two common paths to a decision engine, and why lending teams keep choosing a third. ### Build in-house Your engineering team builds a custom decision engine from scratch. - Months of development before results - A flexible rules UI is a product of its own - Maintenance pulls engineers off core product - Business users still file tickets for changes ### Legacy enterprise platforms Sign a multi-year contract with a legacy decision management vendor. - Your data lives on their servers - Feature requests join a long queue - Limited integration with your LOS - Proprietary formats and pricing lock-in ### GoRules: the best of both A decision engine you can self-host, with a visual interface your credit team will actually use. - Open-source engine - no lock-in, ever - Self-host in your VPC or use our cloud - Visual UI built for decision management - Integrates with any LOS via API or SDK - Your data stays yours - Deploy in days, not months ## Frequently asked questions. ### What is a credit decision engine? A credit decision engine is software that automates lending decisions by evaluating applicant data against your credit rules. Instead of manual review or hardcoded logic, it uses configurable rules to instantly determine eligibility, calculate credit limits, and set pricing - while maintaining a full audit trail for compliance. ### How long does integration take? Most teams complete integration in hours to days, not months. GoRules provides REST APIs and native SDKs for popular languages, so your engineering team can connect it to your existing loan origination system with minimal effort. The rules themselves can be built and tested in parallel. ### Can we use our existing credit scoring models? Yes. You can import existing rules from Excel spreadsheets or recreate them visually in our decision table editor. GoRules supports complex scoring models, nested conditions, and custom calculations - all without writing code. ### Is our data secure? Your data stays yours. GoRules can be self-hosted in your own VPC, meaning applicant data never leaves your infrastructure. For cloud deployments, we offer SOC 2 Type II certification, encryption at rest and in transit, and configurable data retention policies. ## Automate the yes. Explain the no. Join lending teams who process applications faster, stay compliant, and turn eligibility changes into revenue. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## How to Choose a Business Rules Engine: Buyer's Guide **URL:** https://gorules.io/resources/how-to-choose-business-rules-engine **Description:** Business rules engine buyer's guide: 10 questions for vendors, lock-in risks to avoid, and how to evaluate open source vs proprietary BRMS platforms. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # How to Choose a Business Rules Engine Your business rules are your competitive advantage. This guide helps you avoid the traps that cost companies millions in switching costs and years of technical debt. [See the 10 Questions](#questions)[Compare Your Options](#comparison) For engineering leaders, architects, and procurement teams evaluating business rules engines We've seen companies trapped by their BRMS vendor – facing 200% price increases, unable to migrate to the cloud, with millions of dollars of rules locked in proprietary formats. This rules engine buyer's guide exists because choosing the wrong platform creates years of pain. We're going to tell you what vendors won't: how to protect yourself, what questions to ask, and why ownership of your rules matters more than any feature list. ## The Price You'll Pay Here's what happens to your budget over 5 years depending on which path you choose. Portable + Open Execution ### Open Source Engine Path _Year 1_**Base** _Year 2_**Same** _Year 3_**Same** _Year 4+_**Same** **You always have leverage.** Portable formats mean you can leave anytime. Vendors compete for your business, not the other way around. Proprietary BRMS ### Enterprise Vendor Path _Year 1_**Base** _Year 2_**+10%** _Year 3 (renewal)_**+60%** _Year 4+_**?** **You have no leverage.** By year 3, your rules are locked in their format. Migration would cost more than the increase. They know this. \* Illustrative pricing based on typical enterprise BRMS contracts. Actual costs vary by vendor and deal size. ## The Hidden Costs of "Enterprise" BRMS What legacy BRMS contracts don't make obvious. ### Unpredictable Price Increases Once you're dependent, vendors raise prices. ### Cloud Migration Blocked Per-CPU licensing makes cloud and serverless architectures prohibitively expensive. You stay on-prem forever. ### Proprietary Formats Trap You Your rules in proprietary binary formats. No export. No migration path. Starting over costs millions. ### Vendor Controls Your Roadmap Need a feature? Get in line. Vendor priorities don't align with yours. You wait years or pay for custom development. ## The Open Source Advantage When you choose open source, you're not just saving money. You're protecting your most valuable asset: your business logic. ### You Own Your Rules Portable open formats. Export anytime. No permission needed. Your IP stays yours. ### Predictable Pricing No per-CPU games. No surprise increases. Budget with confidence year over year. ### Fork If Needed Vendor disappears? Direction changes? You have the code. You're never stuck. ### Community & Transparency See the roadmap. Contribute features. Join a community, not a sales cycle. ### Cloud Native by Design Built for modern architectures. Serverless, Kubernetes, edge - no licensing barriers. ### Audit Everything Security team can review the code. No black boxes. Full transparency. **10 Questions to Ask Every BRMS Vendor** Bring this checklist to every demo. Check off each question as you get answers. ## 10 Questions to Ask Every Vendor Print this list. Bring it to every demo. The answers will tell you everything you need to know. 1 ### If I export my rules, can I run them without your platform? This is the real test of portability. Many vendors let you "export" to a format only they can execute. Good answer: Yes, with open source engine · Red flag: "Export" requires our runtime 2 ### Is the execution engine open source? Open source engine = true freedom. You can run your rules forever, even if the vendor disappears. Good answer: Fully open source (MIT/Apache) · Red flag: Proprietary or "source available" 3 ### What format are rules stored in? Open formats (JSON, XML) are readable, version-controllable, and portable. Proprietary binary formats lock you in. Good answer: Open format (JSON, XML) · Red flag: Proprietary or binary format 4 ### Does the engine run fully offline with no vendor dependency? True independence means running in air-gapped environments, on your own infrastructure, with no external connections required. Good answer: Fully air-gapped capable · Red flag: Requires license server 5 ### If you go out of business tomorrow, can I still run my rules? Vendors get acquired, pivot, or shut down. Your business rules need to survive that. Good answer: Yes, everything is portable · Red flag: Awkward silence 6 ### What's pricing at 10x my current scale? Get this in writing. Many vendors offer low entry pricing then hit you at scale. Good answer: Linear or flat pricing · Red flag: "Let's discuss when you get there" 7 ### Is there per-CPU, per-core, or per-decision pricing? Per-CPU kills cloud migration. Per-decision costs explode with traffic. Both are traps. Good answer: No usage-based gotchas · Red flag: Any per-CPU/core/decision model 8 ### What happens to my rules if I stop paying? Your business logic is your competitive advantage. Can you take it with you or does it vanish? Good answer: You keep and run everything · Red flag: "License required to access" 9 ### Can I version control my rules with standard tools? Rules should be able to live in git like your code, backed by an open format. Good answer: Yes, standard git workflows · Red flag: Requires proprietary tooling 10 ### Can I build a POC, export everything, and run it independently? The ultimate test. If you can't do this, you're not evaluating - you're already trapped. Good answer: Yes, try it yourself · Red flag: Requires paid license ## Open Execution vs Proprietary Lock-in A side-by-side comparison of what you get with each approach. FactorOpen Source EngineProprietary Engine Exit StrategyAlways possible – you own everythingCostly or impossible Rule OwnershipYours, in portable formatsLocked in proprietary format Rule FormatOpen format (JSON, XML)Proprietary or binary (locked) Cloud/ServerlessBuilt for it – no licensing barriersPer-CPU licensing nightmare Security AuditFull source code accessBlack box – trust us Vendor RiskFork if needed, community continuesAcquired? Sunset? You're stuck ## Migrating from Legacy BRMS If you're evaluating alternatives to enterprise BRMS platforms like IBM ODM, FICO Blaze Advisor, or InRule, you're not alone. Here are the signs it's time to move. Your annual license renewal comes with a surprise price increase Cloud migration is blocked by per-CPU licensing costs Simple rule changes require weeks of IT involvement You can't export your rules in a usable format Vendor support quality has declined while prices increased Your platform lacks modern features (APIs, cloud deployment) New developers struggle with outdated tooling Business users still depend entirely on technical staff ### Ready to explore migration? We help teams migrate from legacy BRMS platforms every month. [Talk to Us](/contact-us) ### BRMS Evaluation Checklist Print this page to get a printable checklist. Bring it to vendor demos and score each platform objectively. Print Checklist ## Frequently Asked Questions Is GoRules an IBM ODM alternative? Yes. Teams migrate from IBM ODM to GoRules for lower costs, faster deployment, and no per-CPU licensing. GoRules offers a migration path for organizations looking to modernize their decision management infrastructure. Unlike ODM's Java-centric approach, GoRules supports modern polyglot architectures with native SDKs for Python, Node.js, Go, Rust, and more. Is GoRules a FICO Blaze Advisor alternative? Yes. GoRules provides similar decision management capabilities without FICO's enterprise pricing model. Organizations migrate from Blaze Advisor to reduce licensing costs, enable cloud deployment, and give business users more direct control over rule authoring through our visual editor. Is GoRules a Drools alternative? Yes. While Drools is open source, it's Java-only with heavy JVM overhead. GoRules offers native support for multiple languages and a more intuitive visual editor. For teams not fully committed to the Java ecosystem, GoRules provides a more flexible foundation. See our full comparison at [gorules.io/compare/gorules-vs-drools.](/compare/gorules-vs-drools) What's the difference between a BRE and BRMS? A Business Rules Engine (BRE) is the execution component that evaluates rules. A Business Rules Management System (BRMS) is the complete platform including the BRE plus visual authoring, version control, testing tools, deployment management, and audit logging. Most organizations need a BRMS, not just a BRE. How do I migrate from a proprietary BRMS to open source? Migration typically involves: (1) Exporting rule logic documentation, (2) Recreating rules in the new platform using visual editors, (3) Parallel running both systems to validate outputs match, (4) Gradual cutover by use case. The timeline depends on rule complexity - simple decision tables migrate in days, complex rule sets take weeks. GoRules offers migration assistance for enterprise customers. Can I use an open source rules engine in enterprise? Yes. The key is separating execution from management. An open source engine (like GoRules' MIT-licensed core) means you can export rules and run them independently, forever. The management platform (visual editor, version control, collaboration) can be paid - that's a service, not lock-in. You're only locked in when you can't run your rules without the vendor's proprietary runtime. ## Choose freedom. Choose open source. Your business rules are your competitive advantage. Don't hand the keys to a vendor who can raise prices, kill features, or hold your rules hostage. [Try GoRules Free](https://us1.gorules.io) [Book a Demo](/contact-us) --- ## Swift Rules Engine - GoRules **URL:** https://gorules.io/open-source/swift-rules-engine **Description:** Open source Swift rules engine for iOS apps. Offline-capable business rule evaluation with native performance. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch Swift SDK # Swift rules engine. Open source Swift rules engine for iOS apps. Offline-capable business rule evaluation with native performance. [Documentation](https://docs.gorules.io/developers/sdks/swift) [GitHub](https://github.com/gorules/zen-ios) ## Up and running in three steps. Install the SDK, load a decision graph, evaluate - the same JSON your team edits in the visual editor runs in your process. _Step 1_ ### Add the Package Add the GoRules engine to your Swift package or Xcode project. ``` // Package.swift dependencies: [ .package(url: "https://github.com/gorules/zen-ios", from: "2.0.0") ] ``` Copy _Step 2_ ### Load a Decision Create an engine and load your decision graph from a JSON file. ``` import ZenUniffi let engine = try ZenEngine() let content = try Data(contentsOf: URL(fileURLWithPath: "decision.json")) let decision = try engine.createDecision(content: content) ``` Copy _Step 3_ ### Evaluate Rules Pass your input data and receive the decision result. result in under a millisecond ``` let context = """ { "customer": { "tier": "premium", "country": "US" }, "cart": { "total": 150, "items": 3 } } """.data(using: .utf8)! let result = try await decision.evaluate(context: context, options: nil) print(String(data: result.result, encoding: .utf8)!) // {"discount":15,"freeShipping":true} ``` Copy ## Why Swift? Built for performance and developer experience - native speed with an API that feels at home in your codebase. ### Native Swift API Idiomatic Swift with strong typing, optionals, and error handling via throwing functions. ### Offline Capable Evaluate rules entirely on-device. No network required after loading the decision graph. ### Apple Platform Support Full support for iOS 16+. Works with SwiftUI and UIKit. ## About the Swift SDK GoRules brings high-performance business rules evaluation to the Apple ecosystem. The Swift SDK provides native bindings to our Rust core, delivering exceptional performance for iOS applications. Designed with Swift idioms in mind, the SDK offers a clean, type-safe API that feels natural to Swift developers. Whether you're building mobile apps that need offline rule evaluation or server-side Swift applications with Vapor, GoRules integrates seamlessly with your codebase. The engine runs entirely on-device, making it perfect for apps that need to evaluate business rules without network connectivity. All processing happens locally with no external API calls, ensuring user privacy and instant response times. [See the public Zen Engine benchmarks](https://gorules.github.io/zen/bench) ## Build with Swift. Govern with GoRules. The engine is open source and free forever - add the GoRules BRMS when your team needs versioning, approvals, and an audit trail. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Rust Rules Engine - GoRules **URL:** https://gorules.io/open-source/rust-rules-engine **Description:** Pure Rust rules engine with zero-cost abstractions. Async-ready business rule evaluation with maximum performance and memory safety. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch Rust SDK # Rust rules engine. Pure Rust rules engine with zero-cost abstractions. Async-ready business rule evaluation with maximum performance and memory safety. [Documentation](https://docs.gorules.io/developers/sdks/rust) [GitHub](https://github.com/gorules/zen) ## Up and running in three steps. Install the SDK, load a decision graph, evaluate - the same JSON your team edits in the visual editor runs in your process. _Step 1_ ### Add the Dependency Add the GoRules engine to your Cargo.toml. ``` cargo add zen-engine ``` Copy _Step 2_ ### Load a Decision Create an engine and load your decision graph. ``` use std::sync::Arc; use zen_engine::DecisionEngine; use zen_engine::model::DecisionContent; let content: DecisionContent = serde_json::from_str( include_str!("./decision.json") )?; let engine = DecisionEngine::default(); let decision = engine.create_decision(Arc::new(content))?; ``` Copy _Step 3_ ### Evaluate Rules Pass your input data and receive the decision result. result in under a millisecond ``` use serde_json::json; let result = decision.evaluate(json!({ "customer": { "tier": "premium", "country": "US" }, "cart": { "total": 150, "items": 3 } }).into()).await?; println!("{:?}", result.result); // {"discount": 15, "freeShipping": true} ``` Copy ## Why Rust? Built for performance and developer experience - native speed with an API that feels at home in your codebase. ### Zero-Cost Abstractions Pure Rust implementation with no runtime overhead. Compile-time optimizations for maximum speed. ### Async Runtime Built on Tokio for efficient async execution. Perfect for high-throughput applications. ### Memory Safe Rust's ownership model guarantees memory safety without garbage collection pauses. ## About the Rust SDK The GoRules Rust SDK is the foundation of our entire ecosystem. Written in pure Rust, it provides the highest possible performance for business rule evaluation with zero-cost abstractions and compile-time optimizations. The engine leverages Rust's ownership model for guaranteed memory safety without garbage collection pauses. Built on Tokio, it supports efficient async execution for I/O-bound operations while maintaining blazing-fast synchronous evaluation for pure rule processing. This is the same engine that powers all our other language SDKs through native bindings. For applications where every microsecond counts, or when you want maximum control over the rule evaluation process, the Rust SDK delivers uncompromising performance. [See the public Zen Engine benchmarks](https://gorules.github.io/zen/bench) ## Build with Rust. Govern with GoRules. The engine is open source and free forever - add the GoRules BRMS when your team needs versioning, approvals, and an audit trail. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Python Rules Engine - GoRules **URL:** https://gorules.io/open-source/python-rules-engine **Description:** Open source Python rules engine powered by Rust. Evaluate decision tables and business rules with sub-millisecond latency. pip install zen-engine. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch Python SDK # Python rules engine. Open source Python rules engine powered by Rust. Evaluate decision tables and business rules with sub-millisecond latency. pip install zen-engine. [Documentation](https://docs.gorules.io/developers/sdks/python) [GitHub](https://github.com/gorules/zen) ## Up and running in three steps. Install the SDK, load a decision graph, evaluate - the same JSON your team edits in the visual editor runs in your process. _Step 1_ ### Install the SDK Install the GoRules engine using pip. ``` pip install zen-engine ``` Copy _Step 2_ ### Load a Decision Create an engine and load your decision graph from a JSON file. ``` import zen with open("./decision.json", "r") as f: content = f.read() engine = zen.ZenEngine() decision = engine.create_decision(content) ``` Copy _Step 3_ ### Evaluate Rules Pass your input data and receive the decision result. result in under a millisecond ``` result = decision.evaluate({ "customer": {"tier": "premium", "country": "US"}, "cart": {"total": 150, "items": 3} }) print(result["result"]) # {"discount": 15, "freeShipping": True} ``` Copy ## Why Python? Built for performance and developer experience - native speed with an API that feels at home in your codebase. ### Rust-Powered Performance Native bindings to our Rust engine deliver near-native speed. No Python GIL limitations for rule evaluation. ### Simple API Pythonic interface that feels natural. Load a decision graph and start evaluating in just a few lines. ### Type Hints Included Full type hint support for better IDE integration and code completion. ## About the Python SDK GoRules brings enterprise-grade business rules management to Python applications. The SDK provides native bindings to our Rust-based engine, delivering performance that pure Python implementations simply cannot match. Perfect for data pipelines, ML feature engineering, and backend services, the Python SDK integrates seamlessly with your existing codebase. Load decision graphs created in the visual editor and evaluate them with a simple, Pythonic API. The engine handles complex decision logic including decision tables, expression evaluation, and branching rule graphs. All processing happens in-process with no external service calls, making it ideal for batch processing, real-time APIs, and anywhere low latency matters. [See the public Zen Engine benchmarks](https://gorules.github.io/zen/bench) ## Build with Python. Govern with GoRules. The engine is open source and free forever - add the GoRules BRMS when your team needs versioning, approvals, and an audit trail. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Kotlin Rules Engine - GoRules **URL:** https://gorules.io/open-source/kotlin-rules-engine **Description:** Open source Kotlin rules engine with coroutine support. Idiomatic API for business rule evaluation on JVM and Android. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch Kotlin SDK # Kotlin rules engine. Open source Kotlin rules engine with coroutine support. Idiomatic API for business rule evaluation on JVM and Android. [Documentation](https://docs.gorules.io/developers/sdks/kotlin) [GitHub](https://github.com/gorules/zen) ## Up and running in three steps. Install the SDK, load a decision graph, evaluate - the same JSON your team edits in the visual editor runs in your process. _Step 1_ ### Add the Dependency Add the GoRules engine to your Gradle project. ``` // build.gradle.kts dependencies { implementation("io.gorules:zen-engine-kotlin:2.0.0") } ``` Copy _Step 2_ ### Load a Decision Create an engine and load your decision graph. ``` import io.gorules.zen_engine.kotlin.JsonBuffer import io.gorules.zen_engine.kotlin.ZenEngine import java.io.File val engine = ZenEngine() val content = File("./decision.json").readText() val decision = engine.createDecision(JsonBuffer(content)) ``` Copy _Step 3_ ### Evaluate Rules Pass your input data and receive the decision result. result in under a millisecond ``` val context = JsonBuffer(""" { "customer": { "tier": "premium", "country": "US" }, "cart": { "total": 150, "items": 3 } } """) val result = decision.evaluate(context, null) println(result.result) // {"discount":15,"freeShipping":true} ``` Copy ## Why Kotlin? Built for performance and developer experience - native speed with an API that feels at home in your codebase. ### Kotlin-Native API Idiomatic Kotlin with extension functions, null-safety, and type inference throughout. ### Coroutine Support Suspend functions for non-blocking rule evaluation. Perfect for Ktor and other async frameworks. ### Android Compatible Full Android support for embedding business rules directly in mobile applications. ## About the Kotlin SDK GoRules provides first-class Kotlin support for business rules management. Shipped as a dedicated Kotlin artifact with suspend functions throughout, it delivers an idiomatic development experience with coroutine support out of the box. The Kotlin SDK embraces modern JVM development practices with suspend functions, extension methods, and null-safety throughout. Whether you're building with Ktor, Spring Boot, or Android applications, GoRules integrates naturally with your Kotlin codebase. Leverage Kotlin's expressive syntax alongside GoRules' powerful rule engine. The SDK supports all GoRules features including decision tables, expressions, and complex rule graphs, all accessible through a clean, Kotlin-native API. [See the public Zen Engine benchmarks](https://gorules.github.io/zen/bench) ## Build with Kotlin. Govern with GoRules. The engine is open source and free forever - add the GoRules BRMS when your team needs versioning, approvals, and an audit trail. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## JavaScript Rules Engine - GoRules **URL:** https://gorules.io/open-source/javascript-rules-engine **Description:** Open source JavaScript rules engine with native Rust performance. Decision tables, expressions, and rule graphs for Node.js, Deno, and Bun. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch Node.js SDK # JavaScript rules engine. Open source JavaScript rules engine with native Rust performance. Decision tables, expressions, and rule graphs for Node.js, Deno, and Bun. [Documentation](https://docs.gorules.io/developers/sdks/nodejs) [GitHub](https://github.com/gorules/zen) ## Up and running in three steps. Install the SDK, load a decision graph, evaluate - the same JSON your team edits in the visual editor runs in your process. _Step 1_ ### Install the SDK Add the GoRules engine to your project using npm, yarn, or pnpm. ``` npm install @gorules/zen-engine ``` Copy _Step 2_ ### Load a Decision Create an engine instance and load your decision graph from a JSON file. ``` import { ZenEngine } from '@gorules/zen-engine'; import fs from 'fs/promises'; const engine = new ZenEngine(); const content = await fs.readFile('./decision.json'); const decision = engine.createDecision(content); ``` Copy _Step 3_ ### Evaluate Rules Pass your input data and get the decision result in milliseconds. result in under a millisecond ``` const result = await decision.evaluate({ customer: { tier: 'premium', country: 'US' }, cart: { total: 150, items: 3 } }); console.log(result.result); // { discount: 15, freeShipping: true } ``` Copy ## Why Node.js? Built for performance and developer experience - native speed with an API that feels at home in your codebase. ### Rust-Powered Performance Native bindings to our Rust engine deliver near-native speed. Process thousands of rules in milliseconds. ### Full Async Support Built for modern Node.js with full async/await support. Non-blocking evaluation for high-throughput applications. ### Zero Dependencies Minimal footprint with no external runtime dependencies. Just install and start evaluating rules. ## About the Node.js SDK GoRules provides a high-performance business rules engine for JavaScript applications. Built with a Rust core and native Node.js bindings, it delivers exceptional speed without sacrificing the developer experience JavaScript developers expect. The engine supports decision tables, expression evaluation, and complex rule graphs - all manageable through a visual editor or programmatically via the SDK. Whether you're building pricing engines, eligibility checkers, or approval workflows, GoRules handles the complexity while keeping your code clean. Unlike traditional rule engines that require a separate server, GoRules embeds directly into your Node.js application. This means zero network latency for rule evaluation, offline capability, and no per-evaluation fees. The same decision graphs created in the GoRules editor work seamlessly in your JavaScript runtime. [See the public Zen Engine benchmarks](https://gorules.github.io/zen/bench) ## Build with Node.js. Govern with GoRules. The engine is open source and free forever - add the GoRules BRMS when your team needs versioning, approvals, and an audit trail. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Java Rules Engine - GoRules **URL:** https://gorules.io/open-source/java-rules-engine **Description:** Open source Java rules engine with native FFM bindings. Enterprise-grade decision tables and rule evaluation for Spring Boot and JVM apps. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch Java SDK # Java rules engine. Open source Java rules engine with native FFM bindings. Enterprise-grade decision tables and rule evaluation for Spring Boot and JVM apps. [Documentation](https://docs.gorules.io/developers/sdks/java) [GitHub](https://github.com/gorules/zen) ## Up and running in three steps. Install the SDK, load a decision graph, evaluate - the same JSON your team edits in the visual editor runs in your process. _Step 1_ ### Add the Dependency Add the GoRules engine to your Maven or Gradle project. ``` // Maven io.gorules zen-engine 2.0.0 // Gradle implementation 'io.gorules:zen-engine:2.0.0' ``` Copy _Step 2_ ### Load a Decision Create an engine and load your decision graph from a JSON file. ``` import io.gorules.zen_engine.JsonBuffer; import io.gorules.zen_engine.ZenDecision; import io.gorules.zen_engine.ZenEngine; import java.nio.file.Files; import java.nio.file.Path; ZenEngine engine = new ZenEngine(null, null); String content = Files.readString(Path.of("./decision.json")); ZenDecision decision = engine.createDecision(new JsonBuffer(content)); ``` Copy _Step 3_ ### Evaluate Rules Pass your input data and receive the decision result. result in under a millisecond ``` var context = new JsonBuffer(""" { "customer": { "tier": "premium", "country": "US" }, "cart": { "total": 150, "items": 3 } } """); var result = decision.evaluate(context, null).get(); System.out.println(result.result()); // {"discount":15,"freeShipping":true} ``` Copy ## Why Java? Built for performance and developer experience - native speed with an API that feels at home in your codebase. ### Modern FFM Bindings Native bindings through Java's Foreign Function & Memory API (JDK 22+). No JNI or JNA overhead. ### Framework Friendly Plain Java API that drops into Spring Boot, Quarkus, or any JVM service without extra setup. ### Thread Safe Fully thread-safe engine designed for concurrent JVM applications. Share one engine across threads. ## About the Java SDK GoRules delivers a production-ready business rules engine for Java applications. The SDK provides native bindings through Java's Foreign Function & Memory API (FFM), connecting your Java code directly to our high-performance Rust core while maintaining the familiar Java development experience. Designed for enterprise workloads, the engine integrates seamlessly with Spring Boot, Quarkus, and other popular Java frameworks. Whether you're building microservices, batch processing systems, or traditional enterprise applications, GoRules handles complex decision logic with consistent sub-millisecond performance. The SDK supports all GoRules features including decision tables, expressions, and complex rule graphs. Decision definitions created in the visual editor work directly with the Java SDK, enabling business users to modify rules without requiring code deployments or developer intervention. [See the public Zen Engine benchmarks](https://gorules.github.io/zen/bench) ## Build with Java. Govern with GoRules. The engine is open source and free forever - add the GoRules BRMS when your team needs versioning, approvals, and an audit trail. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Go Rules Engine - GoRules **URL:** https://gorules.io/open-source/go-rules-engine **Description:** Open source Go rules engine with native bindings. Thread-safe, high-performance business rule evaluation for Golang applications. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch Go SDK # Go rules engine. Open source Go rules engine with native bindings. Thread-safe, high-performance business rule evaluation for Golang applications. [Documentation](https://docs.gorules.io/developers/sdks/go) [GitHub](https://github.com/gorules/zen-go) ## Up and running in three steps. Install the SDK, load a decision graph, evaluate - the same JSON your team edits in the visual editor runs in your process. _Step 1_ ### Install the SDK Add the GoRules engine to your Go module. ``` go get github.com/gorules/zen-go/v2 ``` Copy _Step 2_ ### Load a Decision Create an engine and load your decision graph from a JSON file. ``` package main import ( "os" zen "github.com/gorules/zen-go/v2" ) func main() { engine := zen.NewEngine(zen.EngineConfig{}) graph, _ := os.ReadFile("./decision.json") decision, _ := engine.CreateDecision(graph) } ``` Copy _Step 3_ ### Evaluate Rules Pass your input data and receive the decision result. result in under a millisecond ``` result, _ := decision.Evaluate(map[string]any{ "customer": map[string]any{"tier": "premium", "country": "US"}, "cart": map[string]any{"total": 150, "items": 3}, }) fmt.Println(string(result.Result)) // {"discount":15,"freeShipping":true} ``` Copy ## Why Go? Built for performance and developer experience - native speed with an API that feels at home in your codebase. ### Native Go Implementation Pure Go bindings with CGO for optimal integration. No external processes or HTTP overhead. ### Concurrent Safe Thread-safe engine designed for high-concurrency Go applications. Share one engine across goroutines. ### Minimal Allocations Optimized for low memory overhead and minimal GC pressure in hot paths. ## About the Go SDK GoRules provides a production-ready business rules engine for Go applications. The SDK offers native bindings through CGO, connecting your Go code directly to our high-performance Rust core. Designed for Go's concurrency model, the engine is fully thread-safe and can be shared across goroutines. This makes it perfect for high-throughput web services, microservices, and data processing pipelines where rule evaluation happens on every request. The SDK supports all GoRules features including decision tables, expressions, and complex rule graphs. Decision definitions created in the visual editor work directly with the Go SDK, enabling business users to modify rules without code changes. [See the public Zen Engine benchmarks](https://gorules.github.io/zen/bench) ## Build with Go. Govern with GoRules. The engine is open source and free forever - add the GoRules BRMS when your team needs versioning, approvals, and an audit trail. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## C# Rules Engine - GoRules **URL:** https://gorules.io/open-source/csharp-rules-engine **Description:** Open source C# rules engine with native Rust performance. Decision tables, expressions, and rule graphs for .NET applications via NuGet. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch C# SDK # C# rules engine. Open source C# rules engine with native Rust performance. Decision tables, expressions, and rule graphs for .NET applications via NuGet. [Documentation](https://docs.gorules.io/developers/sdks/csharp) [GitHub](https://github.com/gorules/zen) ## Up and running in three steps. Install the SDK, load a decision graph, evaluate - the same JSON your team edits in the visual editor runs in your process. _Step 1_ ### Install the SDK Add the GoRules engine to your .NET project using the NuGet package. ``` dotnet add package GoRules.ZenEngine ``` Copy _Step 2_ ### Load a Decision Create an engine instance and load your decision graph from a JSON file. ``` using GoRules.ZenEngine; var engine = new ZenEngine(loader: null, customNode: null); var content = new JsonBuffer(File.ReadAllBytes("decision.json")); var decision = engine.CreateDecision(content); ``` Copy _Step 3_ ### Evaluate Rules Pass your input data and get the decision result in milliseconds. result in under a millisecond ``` var context = new JsonBuffer(@"{ ""customer"": { ""tier"": ""premium"", ""country"": ""US"" }, ""cart"": { ""total"": 150, ""items"": 3 } }"); var result = await decision.Evaluate(context, null); Console.WriteLine(result.result); // { "discount": 15, "freeShipping": true } ``` Copy ## Why C#? Built for performance and developer experience - native speed with an API that feels at home in your codebase. ### Rust-Powered Performance Native bindings via UniFFI deliver near-native speed. Process thousands of rules in milliseconds with minimal overhead. ### Cross-Platform Pre-built native libraries for Windows (x64), macOS (x64/ARM), and Linux (x64/ARM). Just add the NuGet package. ### Full .NET Integration Works with .NET 8+, async/await patterns, and IDisposable. Integrates naturally with ASP.NET Core and other frameworks. ## About the C# SDK GoRules provides a high-performance business rules engine for .NET applications. The C# SDK delivers native bindings to our Rust core through UniFFI, giving you exceptional evaluation speed while maintaining a familiar, idiomatic C# developer experience. The engine supports decision tables, expression evaluation, custom node handlers, and full execution tracing. Whether you're building pricing engines, eligibility checkers, or approval workflows in ASP.NET Core, background services, or console applications, GoRules handles the complexity while keeping your code clean and maintainable. The SDK ships with pre-built native libraries for Windows (x64), macOS (x64/ARM), and Linux (x64/ARM), so there's nothing extra to configure. Just add the NuGet package and start evaluating rules. All processing happens in-process with no external service calls, making it ideal for high-throughput APIs and batch processing scenarios. [See the public Zen Engine benchmarks](https://gorules.github.io/zen/bench) ## Build with C#. Govern with GoRules. The engine is open source and free forever - add the GoRules BRMS when your team needs versioning, approvals, and an audit trail. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Terms of service - GoRules **URL:** https://gorules.io/legal/terms-of-service **Description:** This Agreement states the Terms of Service that apply to your use of the services. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch Effective Date: 05.08.2026. These Terms of Service ("Terms" or “TOS”) govern the relationship between **GORULES TECHNOLOGIES DOO**, Trg Narodnog Ustanka 2, Čačak, Serbia, CIN: 21925713, TIN: 113787086 (“GoRules”, "we," "us," or "our"), and the User (as defined herein). These Terms, as amended effective from the Effective Date, apply to all Users who subscribe to the Managed Cloud or the Self-Hosted Product on or after the Effective Date. Existing Users who subscribed prior to the Effective Date under previously applicable terms continue to be governed by those previously applicable terms until the earlier of: (a) the expiry of their then-current billing period, for Users with a billing period; (b) 30 days following the Effective Date, for Users without a billing period (including Demo (Legacy) Cloud Users); or (c) the date on which the User elects to migrate to the Managed Cloud or otherwise agrees in writing to these amended Terms. In this agreement and related documents, the following terms have the following meanings: - "Agreement" means the contract comprising these Terms (as amended from time to time in accordance with Section 3), [Privacy Policy](/legal/privacy-policy), [Cookie Policy](/legal/cookie-policy), [Pricing Plan](/pricing), [Service Level Agreement](/legal/service-level-agreement) (if applicable) (“SLA”), Data Processing Addendum (if applicable), Order Form (if applicable), and, where applicable, any supplemental license terms that accompany the Software, Service and any terms linked in this document or published on Website. - "AI Credits" means the pre-purchased units of consumption that are required to access and use GoRules AI Features. AI Credits are non-refundable and non-transferable. Each eligible Plan includes a baseline allotment of AI Credits as set out on the Website. Additional AI Credits may be purchased separately, subject to the then-current pricing published on the Website. - "AI Features" or "GoRules AI" means the artificial intelligence-powered capabilities made available by GoRules within the Product, including but not limited to AI-assisted rule generation, the AI copilot, automated test case generation, document-to-rule conversion, and any other functionality that relies on a large language model. AI Features are powered by a third-party model provider (please see Section 9 below). - "BRMS" means the Business Rules Management System component of the Product, which provides the visual rule editor, version control, approval workflows, environments, and related governance functionality. For the purposes of service level commitments under the Agreement, BRMS does not include the Zen Engine. - "Content" means all Product’s features and technical resources available to Users, including but not limited to data, text, photographs, videos, audio clips, software, scripts, graphics, and interactive features generated, provided, or otherwise made accessible on or through Product by us, as well as the source code, Website, and other related materials. - “Enterprise” means a User subscribed for the Enterprise Plan, whether under a Self-Hosted deployment or a Managed Cloud deployment, as applicable. - "Zen Engine" means the open source rule evaluation (execution) engine component of the Product responsible for processing inputs and producing decision outputs at runtime. The Zen Engine operates independently of the BRMS and is not subject to the service level commitments applicable to the BRMS under this Agreement. - "Free Plan" means the free version of the Product, available for Self-Hosted deployment, Demo (Legacy) cloud or Managed Cloud. - “Incident” means (i) with respect to the BRMS of the Managed Cloud: a period during which the BRMS is unavailable or materially deviates from its defined functionality, measured in accordance with the Managed Cloud Service Level Agreement; (ii) with respect to the Self-Hosted Product: a period during which the Self-Hosted Product is unavailable, or any deviation from any functionality as defined for the Self-Hosted Product. The following, including but not limited to, shall not be considered as Incident: scheduled maintenance and upgrades, degraded performance, factors outside of GoRules’s control, including any force majeure event, failures of the internet, omissions of User and/or its end users, enforcement of applicable regulations. For the avoidance of doubt, unavailability or degraded performance of the Zen Engine or AI Features shall not constitute an Incident under this Agreement. - “Incident Report” means the User’s notification to GoRules regarding the Incident in accordance with the Order Form. The Incident Report shall include the exact dates, times, and description of the Incident, and, where possible, proof of the Incident. - "Intellectual Property Rights" or “IP“ means all registered and unregistered rights granted, applied for, or otherwise now or hereafter in existence under or related to any patent, copyright, trademark, trade secret, database protection, or another intellectual property right, and all similar or equivalent rights or forms of protection, in any part of the world. - Managed Cloud" means the fully managed, cloud-hosted deployment of the BRMS provided by GoRules as a software-as-a-service offering, in which GoRules is responsible for infrastructure provisioning, hosting, and maintenance. Managed Cloud is distinct from the Self-Hosted Product. The Managed Cloud is hosted on Amazon Web Services (AWS) infrastructure within the applicable region. Managed Cloud plans are set out on the Website. - „Order Form“ means a subscription order form that specifies the commercial details, maintenance and support Services, and other specific terms and conditions for the Self-Hosted Product. If applicable and in case of any discrepancies, the Order Form shall prevail over these Terms. - "Organization" means a User which is a legal entity (including an Enterprise). - "Paid Plan" means any subscription plan that we charge for, as explained [here](/pricing). - "Privacy Policy" means GoRules’ personal data protection policy available [here](/legal/privacy-policy). - “Product” or “Software” means the GoRules software platform, related products and services that we provide, updates, upgrades, modifications, and extensions provided by GoRules, and other linked programs and tools, including: - Demo (Legacy) Cloud, the existing cloud-based service whereby GoRules makes available Software, User Account, and Content (including related mobile and desktop apps, extensions, and other linked programs) on-demand. The Demo (Legacy) Cloud is a legacy offering scheduled for retirement and is available only to existing Users. As of the Effective Date, the Demo (Legacy) Cloud is available only to Users who registered for it prior to the Effective Date and is not offered to new Users. Effective 1 November 2026, the Demo (Legacy) Cloud will become read-only, and GoRules will provide separate notice of the date on which the Demo (Legacy) Cloud will be fully retired and discontinued. - Managed Cloud, whereby GoRules provides the BRMS as a fully managed, cloud-hosted service in accordance with these Terms. - Software installed on a licensed User's device or other device determined by the User and hosted by that User or third party (Self-Hosted), as explained here. The Self-hosted Product is accessed by registering on the license portal [https://portal.gorules.io](https://portal.gorules.io) and obtaining the software license keys for it. This definition does not encompass any open-source software developed by GoRules. - AI Features, which are available as an add-on or included feature across the above deployment modes, subject to these Terms and the User's applicable Paid Plan. - "Service" means making the Product available by GoRules in any version, in full or in part, including any updates, upgrades, modifications, and new features, and all services provided in relation to the Software. - "Terms of Use" or "TOS" means these rules that govern the use of the Service. - "User", “you” and “your'' refers to any person or entity, other than GoRules, that uses, accesses, downloads, saves, installs, possesses, controls, or receives the Service or the Software or any part thereof, including Enterprises, Organizations, and any other category of Users. Users should interpret the term as referring to them unless the context suggests otherwise. - "User Account" means an account provided by Software, whose purpose is to allow User to access and use Service or certain parts of it and create User Content. - "User Content" means any content provided by User in Software, including any entered, recorded, stored, used, controlled, modified, disclosed, transmitted, or erased information and data. - "Website" means the website located at https://gorules.io/. ## 1\. Who can use Products? The Service is solely intended for those who have full legal capacity. Natural persons must be of legal age to be able to use the Service. Legal age depends on the national legislation applicable to the User (typically 18 years old). By using the Service, you represent that you are of legal age, and if you are not, please stop using the Service or Products immediately. The Service is primarily aimed at businesses and companies. If you are using the Service as a natural person for a purpose unrelated to trade, business, or profession and wish to rely on consumer protection legislation, you need to notify GoRules before you start using the Service and before subscribing to any Paid Plan. If the User fails to notify GoRules, it precludes the User from relying on any applicable consumer law. GoRules may, at its sole discretion, reject the provision of Service to certain groups, parties, industries, or companies in certain countries. ## 2\. Acceptance of Terms User shall be bound by this Agreement upon the first occurrence of any of the following: 1. Creating the User Account. 2. Agreeing (explicitly or implicitly) to the Agreement, by using, accessing, or attempting to use or access the Software or the Service (including receiving the provision of Services by GoRules). 3. Downloading, installing, or attempting to install a Self-hosted version. 4. Making the payment for the Paid Plan. 5. Signing the Order Form by both parties (if applicable). By using Product, you acknowledge that you have read, understood, and accepted these TOS in their entirety. These TOS constitute a legally binding agreement between you and us. If you are entering into this agreement on behalf of a legal entity, you represent that you have the authority to bind that entity to these TOS. GoRules may modify the features and functionality of the Service during the Agreement term, providing you with commercially reasonable advance notice of such modification. If you are dissatisfied with the terms of this Agreement or any modifications to this Agreement or the Service, you agree that your sole and exclusive remedy is to terminate your subscription and discontinue use of the Service. ## 3\. Changes to the Agreement We reserve the right, at our sole discretion, to modify or update these Terms or any part of the Agreement at any time. Please review the Terms periodically. We will provide notice of material changes to the Terms via communication through the Website, Product, or other appropriate channels, including email. If you disagree with the new TOS, you must immediately stop using the Product or delete your User Account (if applicable). Your continued use of the Product after such notification constitutes your acceptance of the revised Terms. For the Paid Plans subscribers, regardless of the changes to the TOS, the existing Agreement remains valid until the current billing term expires, unless the parties agree otherwise (including the agreement which entails an implicit consent by the User’s continued use). ## 4\. Use of the Product 1\. Authorization to use: 1. If you are a natural person using the Product, subject to your compliance with the Agreement and your payment of all applicable fees (if any), we grant you a personal, limited, non-exclusive, non-transferable, revocable authorization to access and use the Service for your personal purposes in accordance with the Agreement. 2. If you are an Organization using the Product, subject to your acceptance of this Agreement and your payment of all applicable fees (if any), we grant you a limited, non-exclusive, non-transferable (or restrictedly-transferable), revocable authorization to access and make use of the Service solely for your internal business purposes, in accordance with the Agreement. Nothing in this Agreement obligates GoRules to deliver or make available any copies of computer programs or code to the User, whether in object code or source code form. If you are a User of the Self-hosted Product, please see Section 7 of TOS. If you are a User of AI Features, please see Section 9 of TOS. 2\. Restrictions: 1. Except as expressly permitted by the Agreement, you shall not, and shall not allow any third party to: 1. Copy, publish, modify, create derivative works, or transfer in any way the Product, Website, Service, or any portions of the foregoing; 2. Reverse engineer, decompile, or disassemble the Product, or attempt to derive the source code or architecture of the Product; 3. Work around, or attempt to work around any technical restrictions or limitations in the Software; 4. Use the Product to develop a competing product or service; 5. Use the Product in any way that violates applicable laws, regulations, or third-party rights; 6. Transmit, store, or distribute any content that is unlawful, harmful, threatening, defamatory, obscene, or otherwise objectionable; 7. Interfere with or disrupt the integrity or performance of the Product or its associated infrastructure; 8. Use any automated system, including bots or spiders, to access or interact with the Product in an unreasonably invasive manner, determined at our sole discretion; 9. Use AI Features to develop, train, benchmark, or improve any artificial intelligence or machine learning model, system, or product, whether for your own use or for the benefit of any third party; 10. Submit to AI Features any content that constitutes regulated data (including but not limited to personal health information, financial account data, or government-issued identification numbers) in excess of what is strictly necessary for the intended business rules use case, or without having a valid legal basis for such processing under applicable law; 11. Attempt to reverse-engineer, extract, or replicate the behavior, training data, weights, or architecture of any AI model used to power AI Features, whether by systematic prompting, output harvesting, or any other means. ## 5\. Intellectual Property Rights 1. Ownership: Our Product and Content, including all associated IP, are owned and retained by us or our licensors. Users have only the rights specified under these Terms, and they may not acquire any other IP under this Agreement. Software is made available on a limited-access basis, and no ownership right may be conveyed to any User, irrespective of the use of terms such as "purchase" or "sale" in TOS or anywhere on the Website. Any unauthorized use of any part of the Content shall be deemed an IP infringement. GoRules will take all legal remedies to protect its IP immediately upon knowledge of such unauthorized use. GoRules also reserves all IP not expressly granted in this Agreement. 2. User's IP Rights: You acknowledge and agree that any User Content, including any related IP, i.e., data you input or generate using the Product, belongs exclusively to you. We do not claim any ownership over the data you create or provide through our Software. 3. Restrictions: You shall not, directly or indirectly, reproduce, modify, distribute, sell, rent, lease, sublicense, or create derivative works based on our Product in whole or in part, or circumvent any subscription or payment requirements through database manipulation or other means unless expressly permitted in writing by us. Except for the rights granted under TOS, any copying or downloading of Content in part or whole is permitted only by written consent from GoRules. 4. Protection of IP: You shall take reasonable measures to protect IP associated with our Product. You shall not remove, alter, or obscure any proprietary notices or labels present in the Product. 5. Feedback: If you provide us with any feedback, suggestions, or ideas regarding the Product, you hereby grant us a perpetual, irrevocable, worldwide, royalty-free license to use and incorporate such feedback into the Product without any compensation. 6. Use of User’s Logo a. Permission to User Logo: Unless otherwise agreed between the parties, User grants GoRules a non-exclusive, royalty-free, worldwide license to use, reproduce, and display the User’s logo (the “Logo”) solely to promote and advertise GoRules’ services. This includes but is not limited to, the GoRules’ website, marketing materials, case studies, presentations, and other promotional content. b. Scope and Restrictions: GoRules will use the Logo in a manner consistent with User’s brand guidelines and will not alter or modify the Logo without prior written consent from the User. c. Duration and Termination: The User may revoke this license at any time with 5 days’ written notice to GoRules. Upon such revocation, GoRules shall cease using the Logo and remove it from all promotional materials and publications. d. Ownership: The User retains all rights, title, and interest in and to the Logo. Nothing in this clause shall be construed as granting GoRules any ownership rights in the Logo. ## 6\. Ordering a Product, Subscriptions, and Usage Limitations 1. Ordering process: 1. Product Selection and Payment: To order the Product from us, select the desired option from the options available on our Website. Upon selecting the option, you will provide the necessary payment information and complete the payment through the designated payment gateway. 2. Information Submission and Accuracy: During the ordering process, you may be required to provide certain information relevant to your order, including but not limited to your name, email address, phone number, credit card number, credit card expiration date, billing address, and shipping information. You represent and warrant that you have the legal right to use the chosen payment method(s) provided in connection with your order, as well as that the information you supply to us is true, correct, and complete. User must keep all the billing data complete and accurate and must promptly notify GoRules if the payment method has changed or if User becomes aware of a potential breach of security. If User fails to provide any of the foregoing information, User agrees that GoRules may continue charging for any use of the Service unless User has terminated Agreement as set forth herein. 3. Consent to Information Sharing: By submitting the aforementioned information, you grant GoRules the right to provide this information to payment processing third parties for the completion of your order, including payment processing and verification. GoRules does not have any responsibility nor receives any commission for the processing of the User’s payments and shall not be liable for any matter in connection therewith. More information about this can be found in the third party’s [(Paddle) Terms of Use](https://www.paddle.com/legal/terms). 4. Electronic Delivery: The Product is delivered electronically unless otherwise specified. 2. Subscription and Auto-Renewal: 1. Monthly Subscription: We support monthly subscription plans for the Product, except for the Enterprise Plan. By subscribing to the Paid Plan, you agree to pay the recurring monthly subscription fee as specified during the ordering process or in the corresponding agreement. 2. Auto-Renewal: Unless you cancel your subscription in accordance with this Agreement, your subscription will automatically renew, processed by using the payment information provided during the initial subscription. 3. Upgrading subscription: As a User, you may upgrade your plan at any time by switching to a Paid Plan, or any higher Paid Plan that offers more features. Plans may be upgraded as follows: 3. **Upgrading from the Free Plan to any Paid Plan** You are instantly charged for the next billing period and, after payment, you obtain immediate access to all extra features for the Paid Plan you choose. - **Upgrading to a higher Paid Plan** You are instantly charged for the current subscription term on a pro-rata basis, reflecting the price difference between your current Paid Plan and the higher Paid Plan for the remaining days of the current subscription term, and you obtain immediate access to all extra features of the higher Paid Plan from the date of the upgrade. Your next billing date remains unchanged and corresponds to the original expiry date of your current subscription term, at which point you will be charged the full price of the higher Paid Plan for the following subscription term. 4. Downgrading subscription: As a User, you may downgrade your Paid Plan at any time by switching to a Free Plan or a lower Paid Plan that offers fewer or no extra features. Switching from a Self-Hosted plan to a Managed Cloud plan (or vice versa): A switch between Self-Hosted and Managed Cloud constitutes a change of deployment model and is not treated as a standard upgrade or downgrade. To switch deployment models, please contact GoRules at [support@gorules.io](mailto:support@gorules.io). Any unused AI Credits at the time of a deployment model switch will be forfeited unless otherwise agreed in writing between the parties. Plans may be downgraded as follows: - **Downgrading from any Paid Plan to Free Plan** After your then-current subscription term expires, your access to the extra features will be denied and you can continue to use the Free Plan. - **Downgrading to a lower Paid Plan** After your then-current subscription term expires, your access to the extra features offered in the current Paid Plan will be denied, you will be charged for the lower Paid Plan, based on the subscription term you chose and you can continue to use the lower Paid Plan. Upon any downgrade, cancellation, or expiry of a Paid Plan, any unused AI Credits shall be forfeited and will not be refunded, transferred, or carried over to any successor plan. GoRules strongly recommends that Users consume outstanding AI Credits prior to initiating a downgrade or cancellation. 3. Usage Limitation: 1. Product Usage Limits: Certain parts of the Product offered by GoRules may have usage limitations, such as restrictions on the number of users, API calls, storage capacity, etc. We reserve the right to enforce these limitations and take appropriate actions, including the suspension or termination of your access to the Product in case of non-compliance. 2. AI Credits Usage Limits: AI Features are subject to consumption of AI Credits as described in Section 9.3. GoRules reserves the right to throttle, suspend, or restrict access to AI Features if a User's AI Credit balance is exhausted, if abnormal or abusive consumption patterns are detected, or if usage poses a risk to the performance or availability of AI Features for other Users. GoRules will use commercially reasonable efforts to notify the User before suspending AI Feature access due to credit exhaustion. 4. Support and Maintenance: 1. Support Provision: 1. Paid Product: We provide support and maintenance, but the availability and extent of support may vary depending on the Product and subscription plan. Please find more information [here](/pricing). 2. Free Product: It does not include guaranteed support and maintenance, and the support for the free Product is provided at GoRules' discretion and without any service level agreements. 3. AI Features: AI Features are provided without any support service level commitment. GoRules will use commercially reasonable efforts to address reported issues with AI Features but does not guarantee response or resolution times. Support for AI Features is provided at GoRules' discretion and is subject to the availability of GoRules' third-party AI provider. 2. Maintenance and Updates: 1. Updates: We may release updates, upgrades, or new versions of our Product from time to time at our sole discretion, and such updates are subject to this Agreement, unless other prevailing terms accompany the updates. To ensure optimal performance and security, regularly update the version you use. 2. Maintenance Downtime: Occasionally, we may need to perform scheduled maintenance for Paid Products, during which the Product may be temporarily unavailable. We will make commercially reasonable efforts to notify you in advance of any scheduled maintenance that may affect your access to the Product. The User is not entitled to engage a third party to provide maintenance services on Software. 3. Additional Terms: Additional terms and conditions on support and maintenance may be communicated in a separate agreement, or the Order Form. 5. Managed Cloud Plans: GoRules offers different Managed Cloud subscription plans available here: [https://gorules.io/pricing](/pricing). The Enterprise Plan is available on request; its commercial terms are set out in the applicable Order Form. In the event of any conflict between these Terms and the plan description on the Website, these Terms shall prevail. ## 7\. Self-Hosted Products This section applies to all Users who install and use the Self-hosted Product. Additional terms apply to Enterprise Users subscribing under the Enterprise Plan. In case of any conflict, the specific terms in this section prevail over the general Terms of Service. The Agreement requires a minimum initial commitment term as set forth in the Order Form. License Rights. For the term of the Agreement, GoRules grants User a limited, non-exclusive, non-transferable, revocable, temporary, non-sublicensable, non-refundable license to install a copy of the Software on the User’s device and use the Software solely for User’s business purposes, provided User pays all the agreed fees and complies with the restrictions set forth in the Agreement. This license includes the right for User to grant access to the Software to a specified number of authorized users within its organization, unless otherwise agreed between the parties. Delivery. GoRules shall use commercially reasonable efforts to make the Software available to User in Docker Image format and the ancillary documentation on the commencement date of the Agreement. Delivery shall be considered complete when GoRules provides User with access to download the Software from the hosting platform at [https://hub.docker.com/r/gorules/brms](https://hub.docker.com/r/gorules/brms), access to the ancillary documentation on GoRules’ website, and a valid license key. Installation. User shall install Software by downloading Software on the equipment compliant with Software specification, as set forth in the Order Form (if applicable), in accordance with GoRules’ instructions. The Software can be downloaded by Enterprise without any access code, but it cannot be activated without a valid license key. The license key will be provided to Enterprise upon request via GoRules’ site at [https://portal.gorules.io](https://portal.gorules.io/). The documentation related to the Product is readily available on GoRules’ website and no additional documentation will be sent separately. Fee & Payment. The fees for the use of Software and Services, as well as any payment terms, shall be defined in the [Pricing Plan](/pricing) on the Website, within the Software, or in the Order Form (if applicable). **Restrictions on Software License Rights.** In addition to the restrictions set out in Section 4, and without limiting the generality of the foregoing, User shall not: 1. modify, create derivative works from, distribute, publicly display, publicly perform, or sublicense the Self-hosted Product; 2. rent, lease, or land the Self-hosted Product; 3. use the Self-hosted Product for service bureau or time-sharing purposes, or in any other way allow third parties to exploit the Software; 4. reverse engineer, decompile, disassemble, or otherwise attempt to derive any of the Self-hosted Product’s source code; 5. reproduce or create more copies of the Self-hosted Product than agreed with GoRules; 6. use Self-hosted Product for more users than agreed in the Agreement with GoRules; 7. attempt to exercise any copyright holder’s rights not specifically granted in the Agreement. Breaching any restriction on the User’s software license rights will cause the User to immediately lose the license and shall entitle GoRules to copyright infringement damages. In cases where Enterprise engages third-party subcontractors who have access to the Software, Enterprise warrants that any such third-party subcontractor will comply with these TOS. ## 8\. Managed Cloud Service This Section applies to all Users who access and use the Managed Cloud. Information regarding the infrastructure and data residency practices applicable to the Managed Cloud is set out in the Privacy Policy. ### 8.1 Service Level Commitment - BRMS Service Level Agreement for BRMS is available here: [https://gorules.io/legal/service-level-agreement](/legal/service-level-agreement). ### 8.2 User Responsibilities In using the Managed Cloud, Users are responsible for: (i) maintaining the security of their User Account credentials and access tokens; (ii) configuring integrations with the Managed Cloud in accordance with GoRules's published documentation; (iii) ensuring that any data submitted to the Managed Cloud complies with applicable law, including data protection laws applicable in the User's jurisdiction; (iv) obtaining all necessary consents and authorizations before submitting personal data to the Managed Cloud; and (v) maintaining appropriate back-ups of User Content, notwithstanding GoRules's own redundancy measures. ### 8.3 Relationship to Self-Hosted Terms Section 7 of these Terms (Self-Hosted Products) does not apply to Managed Cloud Users. Users who wish to migrate from Managed Cloud to a Self-Hosted deployment, or vice versa, should contact GoRules at [support@gorules.io](mailto:support@gorules.io). ## 9\. GoRules AI This Section governs your access to and use of AI Features within the Product. AI Features are available to Users on eligible Plans and are subject to the terms set out below in addition to the general Terms of Service. In the event of any conflict, this Section shall prevail with respect to AI Features. ### 9.1 Description of AI Features GoRules AI enables Users to, among other things: generate and modify business rules from natural language input or uploaded documents; use the AI copilot to refine decision logic; automatically generate test cases; and connect external AI tools to the BRMS via the GoRules MCP server. The specific AI Features available to a User depend on the User's applicable Paid Plan, as set out on the Website. GoRules may add, modify, or discontinue individual AI Features at any time. GoRules reserves the right to impose usage limits on AI Features, including rate limits or credit-based consumption restrictions, at any time. ### 9.2 Third-Party AI Provider AI Features are powered by large language models provided by third-party providers. The AI model provider differs depending on the User’s deployment mode: (i) Demo (Legacy) Cloud: AI Features are powered by Claude, developed by Anthropic, Inc. (“Anthropic”). Anthropic’s data handling practices are governed by Anthropic’s applicable terms and privacy documentation. (ii) Managed Cloud: AI Features are powered by Claude, developed by Anthropic, Inc. ("Anthropic"), accessed via Amazon Web Services Bedrock (“AWS Bedrock”). AWS Bedrock processes AI inference requests within the User’s assigned Data Region: for EU Region Users (EU1), inference is processed within the European Union; for US Region Users (US1), inference is processed within the United States. GoRules may change its AI model provider at any time. Users acknowledge and agree that: 1. GoRules does not develop, operate, or control the underlying AI model, and the performance, accuracy, and availability of AI Features are subject to the capabilities and availability of the third-party provider's model; 2. use of AI Features may be subject to the third-party provider's own terms of use and acceptable use policies, and GoRules accepts no responsibility for any failure by a User to comply with such policies; and 3. GoRules is not liable for any interruption, degradation, or failure of AI Features attributable to the third-party AI provider. ### 9.3 AI Credits Access to AI Features requires the consumption of AI Credits. Each eligible Plan includes a baseline allotment of AI Credits, as set out on the Website. AI Credits are consumed each time an AI Feature is used; the rate of consumption per operation is published on the Website and may be updated from time to time. The following terms apply to AI Credits: 1. AI Credits are pre-purchased, non-refundable, and non-transferable. Additionally purchased AI Credits expire twelve (12) months from the date of purchase if unused. 2. unused AI Credits included in an eligible Plan do not roll over to the following billing cycle unless otherwise stated on the Website; 3. additional AI Credits may be purchased at any time at the then-current rates published on the Website; 4. GoRules reserves the right to adjust AI Credit pricing and allotments upon thirty (30) days' prior notice to Users, in accordance with Section 3; and 5. upon termination or downgrade of a Paid Plan, any unused AI Credits (whether included or additionally purchased) are forfeited and will not be refunded or carried over. ### 9.4 No Warranty on AI Outputs AI Features are provided on an "as is" and "as available" basis. GoRules makes no express, implied, or statutory representations or warranties regarding the accuracy, completeness, correctness, reliability, fitness for purpose, or legal compliance of any output generated by AI Features, including but not limited to AI-generated business rules, test cases, or decision logic. Users are solely responsible for reviewing, validating, and approving all AI-generated outputs before deploying or relying on them in any operational, regulated, or business-critical context. The deployment of AI-generated rules without independent human review is undertaken entirely at the User's risk. GoRules specifically disclaims any liability arising from the User's reliance on AI outputs without such review. ### 9.5 User Responsibilities and Acceptable Use of AI Features When using AI Features, Users must not: 1. submit inputs that contain unlawful content, content that infringes third-party intellectual property rights, or content that would otherwise violate these Terms or applicable law; 2. submit personal data of third parties (as defined in applicable data protection law) unless the User has a valid legal basis for such processing and has complied with all applicable notice and consent obligations; 3. deliberately attempt to generate outputs that are misleading, discriminatory, or harmful; 4. use AI Features to develop a competing artificial intelligence product or service, or to extract, reproduce, or compile training data for any third-party machine learning model; 5. attempt to probe, reverse-engineer, or circumvent the behavior, safety mechanisms, or constraints of the underlying AI model. GoRules cannot monitor or control the content of User inputs to AI Features. Users acknowledge that they bear sole responsibility for the inputs they submit and for ensuring that such inputs comply with applicable law and this Agreement. ### 9.6 Data Handling for AI Features GoRules does not store User inputs (prompts) or AI-generated outputs beyond what is strictly necessary to deliver the AI Features in real time. User prompts and AI outputs are not used by GoRules or its third-party AI provider to train, fine-tune, or improve any AI model without the User's explicit prior consent. ### 9.7 No Service Level Commitment for AI Features GoRules makes no uptime, latency, response time, or availability commitments in respect of AI Features. Unavailability or degraded performance of AI Features shall not constitute an Incident under this Agreement and shall not give rise to any service credit entitlement. GoRules will use commercially reasonable efforts to restore AI Feature availability promptly following any disruption, but cannot guarantee continuity of AI Feature availability given its dependence on third-party infrastructure. ### 9.8 AI Features and High-Risk Use Cases AI Features are not designed or validated for use in high-risk decision-making contexts without independent human review and appropriate governance controls. Without limiting Section 11, Users operating in regulated industries, including but not limited to financial services, insurance, healthcare, and aviation, are solely responsible for ensuring that any AI-generated rules meet the regulatory and compliance requirements applicable to their use case before deployment. GoRules does not provide compliance advice and makes no representation that AI-generated outputs satisfy any regulatory standard. ## 10\. Payment Terms 1. Invoicing and Payment: 1. Invoicing and Payment Obligation: Unless otherwise stated in a separate agreement, you are obligated to make payment to GoRules prior to the date of delivery (if applicable). The delivery date refers to the date on which the Product becomes available or accessible to you. Depending on the Plan you have subscribed to, payment shall be processed as follows: (a) _Enterprise Plan:_ Payment is made directly to GoRules, and GoRules will invoice you directly for the applicable fees. (b) _Other Plans:_ Payment is processed by Paddle.com Market Limited ("**Paddle**"), acting as our authorized reseller and merchant of record. In such case, your purchase is subject to Paddle's Buyer Terms and Conditions (available at [https://www.paddle.com/legal/buyer-terms](https://www.paddle.com/legal/buyer-terms)), and Paddle will be the merchant of record and seller responsible for invoicing you, processing your payment, and handling payment-related inquiries, refunds, and chargebacks. These Terms nevertheless continue to govern your use of the Product. 2. Non-Cancelable and Non-Refundable Payments: All payments accrued under these Terms are non-cancellable and non-refundable under any circumstances, unless otherwise expressly agreed between the parties in writing. If the Agreement or a Paid Plan is terminated or varied during a certain billing period, the User shall not be entitled to any refund concerning that billing period. 3. Price: In case of any change of price, GoRules will provide a 30-day notice by any manner chosen by GoRules in its commercially reasonable discretion, including email or posting on the Website (in which case you will be deemed to have received notice on the day following the date it was posted). Any change of price shall enter into force after the expiration of the 30-day notice period or upon expiration of the then-current billing period for each respective User, whichever date is later. For payments processed through Paddle, price changes will be reflected in the amounts invoiced by Paddle from the effective date of the change. 2. Taxes: 1. Tax Liability: It is your responsibility to bear any applicable public duties associated with the purchase of the Service. 2. Tax Calculation and Payment: You will remit payment to us for the Product without any deductions for taxes or other deductibles, including but not limited to bank fees, currency conversion charges, wire transfer fees, or remittance fees that may be applicable. If GoRules is required to collect or remit taxes imposed on you, such taxes will be invoiced to you, such as VAT where applicable, unless you provide GoRules with a valid and timely tax exemption certificate or other required documentation authorized by the appropriate taxing authority. In certain jurisdictions, sales tax is due on the total purchase price at the time of sale, and it must be invoiced and collected at that time. 3. Withholding Delivery for Non-Payment: 1. Non-Payment Consequences: Failure or delay in making payment of any due fee may result in the withholding of delivery or access to the Product until your account balance is paid in full. 2. Suspension or Termination: In the event of non-payment or delayed payment, GoRules may suspend or terminate your access to the Product, and may exercise any other rights or remedies available under applicable law. If your default payment instrument is declined for any reason, we may deny access to the Paid Plan immediately. ## 11\. Data Security, User Content, User Data, Personal Data Protection ### DATA SECURITY 1. Demo (Legacy) Cloud and Managed Cloud Infrastructure (General): GoRules implements commercially reasonable administrative, technical, and organizational security measures consistent with industry standards. Details of GoRules' current security practices are available at the GoRules Trust Center (trust.gorules.io). Details on how data is processed and stored are available at GoRules [Privacy Policy](/legal/privacy-policy). 2. Self-Hosted Product: 1. If you choose to use the self-hosted version of the Product, you acknowledge and agree that you are solely responsible for the security of your own data (User Data) and systems. 2. We are not liable or responsible for any unauthorized access, loss, or disclosure of data, including the User Data that occurs as a result of your hosting and security practices. 3. We also collect personal data during registration on the Website, which is necessary to obtain access to software license keys to the Self-hosted Product. When collecting, processing, and storing such personal data, we will apply an adequate level of data security. 4. Backup and Redundancy: It is recommended that you regularly back up your data to ensure its availability and integrity. 3. Compliance with Regulations: It is your responsibility to understand and comply with any applicable regulations or requirements specific to your industry or jurisdiction. ### SECURITY INCIDENT **External Incident**: In the event of an accidental, unauthorized, or unlawful destruction, loss, alteration, disclosure of, or access to personal data (a “Security Incident”), that impacts the personal data you maintain through Cloud Product, and which is perpetrated by anyone other than your employees, contractors or agents, upon discovery of such Security Incident, GoRules will: (a) initiate remedial actions that comply with applicable law and are consistent with industry standards; and (b) notify you of the Security Incident, its nature and scope, the remedial actions GoRules will undertake, and the timeline within which GoRules expects to remedy the Security Incident. You will be responsible for fulfilling your obligations under applicable law. **Internal Incident**: In the event of a Security Incident which is perpetrated by your affiliate, employee, contractor, or agent, or due to your failure to maintain your systems, network, or User Data securely, you shall have sole responsibility for initiating remedial actions and you shall notify GoRules immediately of the Security Incident and steps you will take to remedy such Incident. In our sole discretion, we may take any action, including suspension of your access to the Service, to prevent harm to you, us, the Service, or other third parties. You waive any right to make a claim against us for losses you incur that may result from our actions. **AI Features Incidents**: In the event of a security incident affecting data processed through AI Features (including User inputs submitted to the AI model), GoRules will notify affected Users in accordance with its obligations as data processor under applicable law. Users acknowledge that GoRules' ability to investigate and remediate such incidents may be limited by the level of access and cooperation provided by its third-party AI model provider. ### USER CONTENT Users are also solely responsible for all text, documents, User Data (as defined below), or other User Content. User warrants, represents, and covenants that the User owns or has a valid and enforceable license to use all User Content. User Content will not infringe, misappropriate, or violate the rights of any person or entity, or any applicable law, rule, or regulation of any government authority of competent jurisdiction. Without limiting the foregoing, any feature(s) of the Service and/or Software that may permit you to temporarily save or otherwise store User Content is offered for your convenience only, and GoRules does not guarantee that the User Content will be retrievable. You are solely responsible for saving, storing, and otherwise maintaining User Content. GoRules reserves the right to refuse, limit or cancel the Service, terminate User Accounts, or remove or edit User Content at its sole discretion. When investigating alleged violations of this Agreement, GoRules reserves the right to review your User Content to resolve the issue. GoRules may also access the User Content when providing technical support or when performing other legal obligations under this Agreement, but has no obligation to monitor or remove any User Content. GoRules cannot be held responsible for any loss, damage, expense, or other harmful consequences to any User resulting from User Content. GoRules will have no responsibility or liability for the accuracy of data uploaded to the Software by User, including without limitation User Data (as defined below) and any other data uploaded by Users. In the event GoRules becomes aware of any User Content that is not compliant with the Agreement or applicable law, GoRules may, in its sole discretion, disable, close, temporarily or permanently limit access to any User Account without any notice. GoRules shall not be liable for any loss, damages, or undesirable consequences resulting from such action. ### USE OF THE USER DATA For the purpose of TOS, “User Data” shall mean data in electronic form input or collected through the Software or Service by or from any User, including without limitation personal data (as defined in [Privacy Policy](/legal/privacy-policy)). The User retains ownership of User Data. Unless it receives the User’s prior written consent, GoRules: (a) shall not access, process, or otherwise use User Data other than as necessary to provide the Service and use of Software (as defined in [Privacy Policy](/legal/privacy-policy)); and (b) shall not intentionally grant any third-party access to User Data, including without limitation GoRules’s other Users, except subcontractors that are subject to a reasonable nondisclosure agreement. Notwithstanding the foregoing, in connection with the provision of AI Features, GoRules will share User inputs with its third-party AI model provider solely to the extent necessary to generate the requested AI output. Such sharing is subject to GoRules's data processing agreement with its AI provider, and User inputs are not retained by the AI provider for model training purposes. GoRules will update this provision if it changes its AI model provider or the applicable data handling terms. Notwithstanding the foregoing, GoRules may disclose User Data as required by applicable law or by proper legal or governmental authority. ### COMPLIANCE WITH DATA PROTECTION LAWS Providing the Service by GoRules involves processing the User’s personal data (as defined in [Privacy Policy](/legal/privacy-policy)). The User determines the purposes and means of processing, making them the data controller. By providing the Service, GoRules acts as a data processor and processes personal data on behalf of and according to instructions given by the User. Despite all other provisions of the Agreement, it is in the User's full responsibility to ensure the legal grounds for processing the personal data (as defined in [Privacy Policy](/legal/privacy-policy)), as well as to properly assess the proportionality of the personal data processing. By entering into Agreement the User warrants and grants to GoRules that the User has secured a valid purpose and legal basis to process personal data via the Service. The User warrants and grants that it has informed the data subjects on all aspects of the processing via the Service or the Software before processing has started and has enforced proper policies and/or has undertaken necessary steps if stipulated by the applicable data protection legislation. The User or Organization shall indemnify, defend, and hold harmless GoRules in full and on-demand from and against any and all liabilities, claims, demands, damages, losses or expenses (including legal and other professional adviser’s fees and disbursements), and penalties incurred by GoRules arising out of or in connection with the User’s breach of the obligations stipulated in this paragraph or applicable data protection laws. For Users on the Managed Cloud in the US Region, GoRules processes User Data as a data processor within the US. For Users on the Managed Cloud in the European Region, GoRules processes User Data as a data processor within the European Union. Users established in the EU or processing personal data of EU data subjects are advised to review the Data Processing Addendum available on request, which sets out the applicable standard contractual clauses and technical and organizational measures relevant to processing within the EU. GoRules does not act as a data controller in respect of personal data submitted by Users to AI Features. Users who submit personal data to AI Features do so as data controllers and are solely responsible for ensuring that such processing has a valid legal basis under applicable data protection law. ## 12\. Warranty Your use of the Products is at your sole risk. The Service is provided on an "as is" and "as available" basis, and GoRules disclaims, to the fullest extent permitted under the applicable law, all statutory warranties and course of performance, course of dealing, and usage related to licensees' and Users' expectations. User is solely responsible for any damage User may suffer resulting from the use of the Service. Without prejudice to the generality of the previous provisions, GoRules does not warrant that: 1. the Service will meet User's specific requirements, nor that the Service will be "fit for purpose" unless GoRules and a User agree otherwise, 2. the Service will be uninterrupted, timely, secure, error-free, or of satisfactory quality, 3. the results that may be obtained from the use of the Service will be accurate or reliable, 4. any errors in the Service will be corrected, 5. AI-generated outputs, including but not limited to AI-generated rules, decision tables, decision graphs, or test cases, will be accurate, complete, legally compliant, fit for the User's intended purpose, or free from errors or bias. GoRules and/or its suppliers make no representations about the suitability, reliability, availability, continuity, timeliness, and accuracy of the Service and Software. 1. Limited warranty for Self-Hosted Paid Products: 1. Our Warranty to You: Subject to the next sentence, GoRules represents and warrants that it is the owner of the Software and every component thereof, or the recipient of a valid license thereto, and that it has and will maintain the full power and authority to grant the IP to the Software set forth in this Agreement without the further consent of any third party. GoRules cannot access User Data on Self-hosted Products (this does not apply to the data necessary for registration on the Website and License portal), unless required by Client for support reasons, in accordance with the Agreement and with your explicit permission. 2. Warranty disclaimer: Except for the express warranties in Section 12.1.a. above, **GORULES MAKES NO WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON INFRINGEMENT OF IP** **OR ANY IMPLIED WARRANTY ARISING FROM STATUTE, COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE.** 2. High-risk activities: 1. The Product, including AI Features, is not designed, licensed or intended for use in high-risk activities or hazardous environments (including, but not limited to aircraft navigation or communication systems, air traffic control, medical devices, life support machines, autonomous vehicles, nuclear facilities, military or defense operations, spacecraft systems, critical infrastructure control systems, or weapons systems), where failure of the Software or reliance on AI-generated outputs could lead to personal injury, death, or environmental damage. 2. We shall not be liable for any damages, losses, or liabilities arising from your use of the Product in such high-risk activities. 3. Users operating in regulated industries, including but not limited to financial services (including credit scoring, AML, and KYC), insurance underwriting and claims, healthcare clinical decision-making, and aviation fare and routing, must ensure that any rules generated or modified using AI Features are independently reviewed and validated by qualified personnel with appropriate domain expertise before deployment. GoRules makes no representation that AI-generated outputs meet any applicable regulatory standard or satisfy any statutory duty of care. Reliance on AI-generated outputs in such contexts without independent validation is undertaken entirely at the User's risk. 3. AI Features - Warranty Disclaimer: WITHOUT LIMITING THE GENERAL WARRANTY DISCLAIMER ABOVE, GORULES EXPRESSLY DISCLAIMS ALL WARRANTIES WITH RESPECT TO AI FEATURES, INCLUDING WITHOUT LIMITATION ANY WARRANTY THAT: (I) AI-GENERATED OUTPUTS WILL BE ACCURATE, COMPLETE, OR SUITABLE FOR ANY PARTICULAR PURPOSE; (II) AI FEATURES WILL OPERATE WITHOUT INTERRUPTION OR ERROR; (III) AI FEATURES WILL SATISFY ANY REGULATORY, COMPLIANCE, OR LEGAL REQUIREMENT APPLICABLE TO THE USER'S BUSINESS OR INDUSTRY; OR (IV) THE UNDERLYING AI MODEL WILL REMAIN AVAILABLE OR UNCHANGED. THE USER ASSUMES FULL RESPONSIBILITY FOR EVALUATING, VALIDATING, AND DEPLOYING ANY OUTPUT PRODUCED BY AI FEATURES. 4. Wrongful use: 1. We shall not be held responsible for any damages, losses, or liabilities arising from the wrongful use of the Product. 2. You shall be solely responsible for any consequences that may arise from your unauthorized, inappropriate, or illegal use of the Product. 3. You must provide complete information for registration purposes and accurate and up-to-date information (including accurate contact information). Using a false identity is strongly prohibited. 4. Subject to item e. below, you will prevent any other person from using your account. 5. You must maintain the security of the account and password, and share it solely with authorized persons. User is responsible and liable for any use of the Website, Service, or Software through User’s account, whether authorized or unauthorized. GoRules cannot be held liable for any loss, damages, or expenses incurred due to User’s failure to comply with this obligation. If you become aware of any unauthorized use of your account, you need to immediately notify us by sending an email to [legal@gorules.io](mailto:legal@gorules.io). 6. You will not engage in activity that violates the privacy of others, or any misuse or unlawful processing of personal data, nor will you publicly display or use Software to share inappropriate content or material. 7. You will not access the Service or the Software to build a competitive product or service, to build a product using similar ideas, features, functions or graphics, or to copy any ideas, features, functions, or graphics. 8. You will not engage in web scraping or data scraping on or related to the Software, including without limitation collection of information through any software that simulates human activity or any bot or web crawler. 9. You will not automate access to the Website or the Service, including, without limitation, through the use of APIs, bots, scrapers, or other similar devices. You acknowledge and agree that your use of the Product is at your own risk. You are solely responsible for evaluating the suitability, use, and results of the Product for your intended purposes. ## 13\. Termination This Agreement shall continue until either party terminates it. Termination by User: You may terminate the Agreement by providing written notice to us or by cessation of use of the Service. If you cancel the subscription during the subscription term, no refunds will be granted and you will be able to access Software until the end of the current term that you paid for, unless your User Account is otherwise suspended. If you use any Paid Plan that involves a recurring payment of a fee, we will continue collecting the fee for the Service using any credit card we have on record for you, until we are notified about cancellation or non-renewal. Termination by Us: We reserve the right to terminate the Agreement at any time by providing written notice to you. Upon termination, any outstanding fees become immediately due, and no refunds shall be issued for any fees paid prior to the termination. Termination takes effect at the end of the current subscription term, provided that you have paid the fees for the entire subscription period. GoRules may immediately terminate this Agreement and suspend your access to the Services and User Account if you do not pay the fees when due in accordance with your Paid Plan. If you fail to pay any part of the subscription fee when due, we may suspend your access to the Services and User Account until all outstanding amounts are fully paid. We reserve the right to terminate this Agreement if the overdue payments remain unpaid. You are obligated to pay the full subscription fee for the agreed subscription period, regardless of any agreed payment schedule. GoRules may deny you access to all or any part of the Service or terminate your account with or without prior notice if you engage in any conduct or activities that GoRules determines, at its sole discretion, violate this Agreement or the rights of GoRules or any third party, or are otherwise inappropriate. Effect of Termination and Survival: 1. All rights and licenses granted under this Agreement shall immediately terminate, and all Orders Forms (if applicable) shall consequently be automatically terminated. 2. User shall cease all use of the Product and delete, destroy, or return all copies of the Self-hosted Product and documentation in its possession or control. Any use of Product after the license has expired shall constitute a breach of GoRules’ IP and will entitle GoRules to copyright infringement damages. Upon termination of the license to use Self-hosted Product, User is obliged to delete Software and the Content from all the devices, prevent all users who have been using Self-hosted Product via the license obtained by User, and present GoRules with the proof of cessation of all activities authorized by the Agreement. Until GoRules receives User’s notice of cessation of use of the Product, it shall be deemed that the User is using Product 3. User may export and save the User Content that is related to the User’s product (release) via an “export” option offered by Software prior to the termination date. 4. Termination of the Agreement shall not relieve either party of any obligations or liabilities accrued prior to the termination. The following provisions will survive termination of this Agreement: - Any obligation of the User to pay for the Service - Section 5 (Intellectual Property) - Section 14 (Indemnity) - Section 12 (Warranty) and Section 15 (Limitation of Liability) - Section 16.6 (Governing Law and Jurisdiction) - Any other provision of this Agreement that must survive to fulfill its essential purpose. ## 14\. Indemnity You agree to defend, indemnify, and hold harmless GoRules and its affiliates from any third-party claims, damages, or expenses (including reasonable attorneys’ fees) arising out of or related to your use of the Products and Services, including but not limited to: 1. Any use or misuse of the Product or Services by you or any authorized user. 2. Claims or damages from your reliance on the accuracy, completeness, or reliability of the Product. 3. Third-party IP infringement claims related to your use of the Product, or invasion of privacy arising from hosting, sharing, or using User Content. 4. Any activity on User Account unless such activity was caused by the act or default of GoRules. 5. Any breach of this Agreement, applicable regulations, industry standards, or its terms and conditions by you. 6. Any violation of third-party terms resulting from your use of the Product. 7. Any other claims, actions, or damages arising from your access to or use of our Product, including but not limited to: 1. Personal injury or property damage 2. Any unauthorized access or use of your account or any breach of security 3. Processing of User’s personal data ## 15\. Limitation of Liability To the maximum extent permitted by the applicable law, GoRules and its affiliates shall not be liable for: 1. Any harm from use or inability to use the Software; 2. Issues from third-party installation, customization, or modifications; 3. Failure to install updates, patches, or upgrades; 4. Unauthorized access to User Content; 5. Unauthorized use of User credentials; 6. Any inaccuracy, error, omission, or failure of any AI-generated output, including but not limited to AI-generated rules, decision logic, test cases, or recommendations produced by AI Features; 7. Any interruption, degradation, or unavailability of AI Features caused by the third-party AI model provider or any change to the underlying AI model; 8. Any decision, action, or omission taken by the User in reliance on AI-generated outputs without independent validation; 9. Any regulatory sanction, fine, or enforcement action arising from the User's deployment of AI-generated rules in a regulated context. GoRules shall not be liable for indirect, incidental, special, or consequential damages (e.g., loss of data, profits, or business) arising from use or performance of the Software or AI Features, delays or failure in using the Software or Services, or any information or services accessed through the Software. If any of the foregoing limitations are deemed unenforceable or in the event any liability of GoRules is established, GoRules’ total liability will not exceed the amount paid by the User in the 12 months prior to the claim, or EUR 100 if no payment was made. For the avoidance of doubt, service credits issued under SLA (Managed Cloud - BRMS Service Credits) are not payments made by the User for the purposes of this paragraph and do not affect the calculation of the liability cap. You agree that this limitation of liability represents a reasonable allocation of risk and is a fundamental element of the basis of the bargain between GoRules and you. You understand that the Website, Service, and Software would not be provided without such limitations. This Section does not exclude mandatory liability for wilful breach by GoRules of any of its obligations, or death or personal injury caused by a defective item produced by GoRules. Neither party is liable for failure to perform due to unforeseeable and uncontrollable events (force majeure), such as natural disasters, war, cyber-attacks, or internet outages. GoRules does not provide its Users with legal advice regarding compliance, data privacy, or other relevant applicable laws in the jurisdictions in which they use the Service, and any statements made by GoRules to you shall not constitute legal advice. **Exclusion of Liability for Data Security for Self-hosted Products**. Given that all the User Content is hosted on the User’s server or server chosen by the User, the security of the User’s data and the User Content and application of the physical, technical, administrative, organizational, and other measures is in the User’s full responsibility. Under no circumstances GoRules may be held accountable for any security data breach, unauthorized access, use, disclosure, or any other illegal activity related to the User’s data (including personal data) in connection with Self-Hosted deployments. **Data Security - Managed Cloud**. For Users on the Managed Cloud, GoRules is responsible for implementing and maintaining commercially reasonable technical and organizational security measures for the infrastructure layer of the Managed Cloud, as described in Section 11 and the GoRules Trust Center. Notwithstanding the foregoing, GoRules' liability for any security breach affecting Managed Cloud User Data is subject to the liability cap set out in this Section and GoRules shall not be liable for any breach or unauthorized access attributable to: (i) the User's own systems, integrations, or credentials; (ii) content or data submitted by the User; or (iii) actions of third parties not within GoRules' reasonable control. **Service Credits - Exclusive Remedy**. To the maximum extent permitted by applicable law, service credits issued under the SLA (Managed Cloud - BRMS uptime) constitute the User's sole and exclusive remedy for any failure by GoRules to meet the Managed Cloud uptime commitment. The User waives any right to claim damages, losses, expenses, or any other form of compensation arising from a failure to meet the uptime commitment, whether in contract, tort, or otherwise, beyond the service credits expressly provided for in the SLA. ## 16\. Miscellaneous 1\. Third Party Websites. The Product may include links to websites or resources operated by third parties, which are provided solely for your convenience. We have no control over such websites or resources, and we are not responsible for any information, materials, or links displayed on such third-party sites. Placing links to third-party websites on the Website does not imply that GoRules recommends or approves services or products offered through such websites. 2. Entire Agreement: This Agreement (as amended from time to time) constitutes the entire agreement between you and GoRules relating to the subject matter herein and supersedes any other agreements, whether oral or written, and this Agreement shall prevail over any such agreements. 3. Severability: If any provision of this Agreement is found to be invalid, illegal, or unenforceable, the remaining provisions shall continue in full force and effect. 4. Confidential Information: “Confidential Information” refers to the following information that one party to this Agreement ( “Discloser”) discloses to the other ( “Recipient”): (a) any information Discloser designates as “Confidential”, either orally or in writing; (b) any object code and source code disclosed by GoRules together with all documentation and any names of actual or potential customers disclosed by User, whether or not marked as confidential; and (c) any other non-public, sensitive information Recipient should reasonably consider a trade secret or otherwise confidential. Information from Order Form shall always be considered confidential. Confidential Information does not include information that: (i) is in Recipient’s possession at the time of disclosure; (ii) is independently developed by Recipient without the use of or reference to Confidential Information; (iii) becomes known publicly, before or after disclosure, other than as a result of Recipient’s improper action or inaction; or (iv) is approved for release in writing by Discloser. Nondisclosure. Recipient agrees to use Confidential Information only for purposes related to this Agreement and to keep it confidential during the term and for 5 years after termination, except that any Confidential Information constituting trade secrets, source code, or object code shall be protected for as long as such information remains a trade secret under applicable law or for 10 years after termination, whichever is longer. Recipient may only share it with employees or contractors who need access, are bound by similar confidentiality obligations, and may not disclose it to other persons without Discloser’s written consent. Recipient is obliged to promptly report any known misuse or unauthorized access. Termination & Return. Upon termination of this Agreement, Recipient shall return all copies of Confidential Information to Discloser or certify, in writing, the destruction thereof. 5. Assignment: You may not assign or transfer any rights or obligations under this Agreement without the prior written consent of GoRules. 6. Governing Law and Jurisdiction: Any dispute, controversy, or claim arising out of or in connection with this Agreement shall be resolved through arbitration administered by the International Court of Arbitration of the International Chamber of Commerce (ICC) in accordance with the ICC Rules of Arbitration. The seat of arbitration shall be Belgrade, Serbia, and the arbitration proceedings shall be conducted in English. The arbitration hearings and conferences shall be held remotely by videoconference, telephone, or other appropriate means of communication, unless otherwise agreed by the parties. The governing law of this agreement shall be the substantive law of the Republic of Serbia, without regard to its conflict of laws principles. If the above agreement, with respect to arbitration, proves to be void or unenforceable, all disputes to which it was intended to apply shall be subject to the exclusive jurisdiction of the competent court in the Republic of Serbia. Notwithstanding the provisions above, GoRules may, at its absolute discretion, assert and seek the protection of its IP and rights concerning Confidential Information or data processing anywhere in the world. ## 17\. Contact Us If you have any questions about these Terms, You can contact us via [support@gorules.io](mailto:support@gorules.io). **On this page** - [1\. Who can use Products?](#1-who-can-use-products) - [2\. Acceptance of Terms](#2-acceptance-of-terms) - [3\. Changes to the Agreement](#3-changes-to-the-agreement) - [4\. Use of the Product](#4-use-of-the-product) - [5\. Intellectual Property Rights](#5-intellectual-property-rights) - [6\. Ordering a Product, Subscriptions, and Usage Limitations](#6-ordering-a-product-subscriptions-and-usage-limitations) - [7\. Self-Hosted Products](#7-self-hosted-products) - [8\. Managed Cloud Service](#8-managed-cloud-service) - [8.1 Service Level Commitment - BRMS](#81-service-level-commitment-brms) - [8.2 User Responsibilities](#82-user-responsibilities) - [8.3 Relationship to Self-Hosted Terms](#83-relationship-to-self-hosted-terms) - [9\. GoRules AI](#9-gorules-ai) - [9.1 Description of AI Features](#91-description-of-ai-features) - [9.2 Third-Party AI Provider](#92-third-party-ai-provider) - [9.3 AI Credits](#93-ai-credits) - [9.4 No Warranty on AI Outputs](#94-no-warranty-on-ai-outputs) - [9.5 User Responsibilities and Acceptable Use of AI Features](#95-user-responsibilities-and-acceptable-use-of-ai-features) - [9.6 Data Handling for AI Features](#96-data-handling-for-ai-features) - [9.7 No Service Level Commitment for AI Features](#97-no-service-level-commitment-for-ai-features) - [9.8 AI Features and High-Risk Use Cases](#98-ai-features-and-high-risk-use-cases) - [10\. Payment Terms](#10-payment-terms) - [11\. Data Security, User Content, User Data, Personal Data Protection](#11-data-security-user-content-user-data-personal-data-protection) - [DATA SECURITY](#data-security) - [SECURITY INCIDENT](#security-incident) - [USER CONTENT](#user-content) - [USE OF THE USER DATA](#use-of-the-user-data) - [COMPLIANCE WITH DATA PROTECTION LAWS](#compliance-with-data-protection-laws) - [12\. Warranty](#12-warranty) - [13\. Termination](#13-termination) - [14\. Indemnity](#14-indemnity) - [15\. Limitation of Liability](#15-limitation-of-liability) - [16\. Miscellaneous](#16-miscellaneous) - [17\. Contact Us](#17-contact-us) --- ## Service level agreement - GoRules **URL:** https://gorules.io/legal/service-level-agreement **Description:** This Agreement states the service level agreement that applies to your use of the services. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch Last updated: 28.08.2026. ## 1\. Introduction This Service Level Agreement (“SLA”) applies to eligible Paid Plan Users using the Self-Hosted Product and/or the Managed Cloud Service, to the extent defined below, unless amended by the Order Form. This SLA does not apply to Free Plan Users. All terms used herein beginning with a capital letter shall have the meaning defined in the Terms of Service. This SLA consists of three service commitments: Uptime (Section 2), Support (Section 3), and the Right to Exit (Section 4). Support is provided in two tiers: Standard Support and Enterprise Support, each with its own set of Response Times, as set out in Section 3. Each part of this SLA applies only to the Users indicated in the table below: Plan Uptime (Section 2) Support (Section 3) Right to Exit (Section 4) Managed Cloud - Business Plan Yes Yes - Standard Support Yes, if on an annual Paid Plan Managed Cloud - Enterprise Plan Yes Yes - Enterprise Support Yes, if on an annual Paid Plan Managed Cloud - Pro Plan No No No Self-Hosted Product - Business Plan No Yes - Standard Support No Self-Hosted Product - Enterprise Plan No Yes - Enterprise Support No Self-Hosted Product - Team Plan No No No For the avoidance of doubt, the Uptime commitment under Section 2 applies solely to the BRMS on the Managed Cloud and does not cover AI Features or Runtime APIs (as defined in Section 2.2). ## 2\. Uptime ### 2.1 Service Level Commitment - BRMS GoRules commits to a monthly uptime of 99.9% for the BRMS for Business Plan and Enterprise Plan Users on Managed Cloud based on the Paid Plan, unless amended by the Order Form. Uptime is calculated on a monthly basis as follows: Uptime % = ((Total minutes in month - Downtime minutes) / Total minutes in month) × 100 For the purposes of this Section, “Downtime” means the total accumulated minutes in a calendar month during which the BRMS is unavailable, excluding Scheduled Maintenance, Excluded Events (as defined in Section 2.2 of this SLA), and any period during which unavailability is attributable to the User. For the avoidance of doubt, the uptime commitment applies only to the BRMS and does not apply to AI Features or Runtime APIs (as defined in Section 2.2). Pro Plan (Managed Cloud) Users are not entitled to a contractual uptime commitment unless otherwise agreed in writing with GoRules. ### 2.2 Excluded Events The following shall be excluded from the calculation of Downtime and shall not constitute an Incident under this Agreement: 1. Scheduled Maintenance, as notified by GoRules in advance in accordance with Section 2.3 of this SLA; 2. factors beyond GoRules’s reasonable control, including but not limited to force majeure events, internet outages, DNS failures, or third-party service failures not caused by GoRules; 3. User’s failure to follow GoRules’s configuration or integration documentation; 4. unavailability caused by User Content, User-initiated actions, or third-party software or services integrated by the User; 5. unavailability of AI Features or Runtime APIs. For the purpose of this SLA “Runtime APIs” means the application programming interface endpoints beginning with the paths /api/rules and /api/mcp, used to evaluate rules, list rules, or interact with the Product via the Model Context Protocol server, as made available by GoRules as part of the Product; 6. unavailability during any period in which User’s account is suspended due to non-payment or breach of the Agreement. ### 2.3 Scheduled Maintenance GoRules will use commercially reasonable efforts to provide Users with at least forty-eight (48) hours’ advance notice of Scheduled Maintenance that is reasonably expected to cause Downtime. Scheduled Maintenance will, where practicable, be conducted outside of peak business hours in the User’s region. Emergency maintenance required to address a critical security vulnerability or system integrity issue may be performed without advance notice, provided that GoRules notifies affected Users as soon as reasonably practicable thereafter. ### 2.4 Service Credits - BRMS Uptime If GoRules fails to meet the 99.9% monthly uptime commitment for the BRMS under Section 2.1 of this SLA, eligible Business Plan and Enterprise Plan Users on Managed Cloud may request service credits as follows: Monthly uptime achieved Service credit (% of monthly Managed Cloud fee) Below 99.9% but at least 99.0% 10% Below 99.0% but at least 95.0% 25% Below 95.0% but at least 90.0% 50% Below 90.0% 100% Service credits: (i) are the User’s sole and exclusive remedy for any failure by GoRules to meet the uptime commitment; (ii) apply only to the BRMS component and not to AI Features or Runtime APIs; (iii) must be claimed by the User in writing within seven (7) calendar days of the end of the affected calendar month; (iv) will be applied to the User’s next billing cycle and may not be exchanged for cash or any other form of compensation; (v) are subject to the aggregate monthly and rolling 12-month caps set out in Section 3.4 of this SLA; and (vi) are forfeited upon termination of the Agreement for any reason, except in the case of termination under Section 4 (Right to Exit), where the refund under Section 4.2 applies. ### 2.5 Downtime Reporting While GoRules monitors the availability of the BRMS on an ongoing basis, Users must submit a formal Downtime Report as a condition to claiming any service credit under this SLA, in accordance with this Section 2.5. To report a period of Downtime relating to the Managed Cloud, Users must submit a Downtime Report to GoRules at [support@gorules.io](mailto:support@gorules.io) within seven (7) calendar days of the date the Downtime occurred or, if later, the date the User discovered or reasonably should have discovered the Downtime. The Downtime Report must include the dates, times, affected functionality, and, where available, supporting evidence of the Downtime. GoRules will acknowledge Downtime Reports within two (2) business days and will use commercially reasonable efforts to investigate and confirm reported Downtime periods in a timely manner. ### 2.6 Service Credit Claims Because service credits are calculated on a monthly basis under Section 2.4, Users submit Downtime Reports throughout the month as Downtime occurs, and then submit a single Service Credit Claim after the calendar month has ended, once the total monthly uptime for that month is known. Only Downtime that has been the subject of a timely Downtime Report under Section 2.5 may be taken into account in calculating the monthly uptime percentage under Section 2.1. GoRules shall have no obligation to issue any service credit for any period of Downtime that was not the subject of a timely Downtime Report. To claim a service credit, the User must submit a written Service Credit Claim to GoRules at [support@gorules.io](mailto:support@gorules.io) within seven (7) calendar days of the end of the affected calendar month, referencing the Downtime Reports submitted during that month. This seven (7) calendar day period runs from the end of the calendar month in all cases and is not extended by the date on which any underlying Downtime Report was submitted. ## 3\. Support (Response Times) ### 3.1 Services and Support Tiers GoRules will provide Services to the User, including any corrections, changes, or workarounds for any defects, errors, or malfunctions in the Product discovered by GoRules or the User. Support under this Section 3 is provided in two tiers, in each case based on the Paid Plan, unless amended by the Order Form: (a) Standard Support - available to Business Plan Users on Managed Cloud and to Business Plan Users using the Self-Hosted Product; and (b) Enterprise Support - available to Enterprise Plan Users on Managed Cloud and to Enterprise Users using the Self-Hosted Product. ### 3.2 Categories of Incidents, Response, and Resolution Time GoRules shall respond to the Incident Report and resolve problems in accordance with the severity levels and the applicable support tier (indicated below). Incident type Response Time - Standard Support Response Time - Enterprise Support Resolution Time **Priority 1**: Incidents that render the Product completely unusable, causing severe disruptions or critical errors that significantly impact functionality or security Within 8 business hours upon Incident Report being submitted As specified in the Order Form Reasonable commercial effort **Priority 2**: Incidents that cause a significant or ongoing interruption of critical functionalities that cause significant inconvenience to the User. While the Product remains functional, this bug significantly impacts the productivity and usability of the system Within 16 business hours upon Incident Report being submitted As specified in the Order Form Reasonable commercial effort **Priority 3**: Incidents that cause limited interruptions of non-critical functionalities of the Product or cause moderate inconvenience to the User Within 24 business hours upon Incident Report being submitted As specified in the Order Form Reasonable commercial effort **Priority 4**: Incidents that have minimal impact on the functionality or usability of the Product, including any general issues or inquiries of the User Within 72 business hours upon Incident Report being submitted As specified in the Order Form Reasonable commercial effort ### 3.3 Support Hours and Cooperation User is obliged to cooperate with GoRules and to provide all the necessary and reasonable assistance to GoRules in resolving the Incident. The Incident Report and GoRules support will be carried out via [support@gorules.io](mailto:support@gorules.io). The GoRules support team will provide assistance and support between 9 AM and 5 PM CET on business days in the Republic of Serbia, and the Response time for any Incident Reports or other inquiries received outside of such business hours shall commence the next business day in the Republic of Serbia. ### 3.4 Service Credit for Delays If GoRules fails to meet the specified Response time set out in Section 3.2 of this SLA (as applicable to the User’s support tier, unless amended by the Order Form), User shall be entitled to request service credits as follows: - If the response is delayed by up to twice the agreed response time, User will be entitled to receive a credit equal to 10% of the monthly fee for the current Paid Plan. - If the response is delayed by more than twice but less than three times the agreed response time, the User will be entitled to receive a credit equal to 20% of the monthly fee for the current Paid Plan. - If the response is delayed three times or more than the agreed response time, User will be entitled to receive a credit equal to 30% of the monthly fee for the current Paid Plan. The maximum aggregate amount of service credits for any given month, whether issued for a failure to meet the uptime commitment under Section 2 or for a failure to meet the Response Times under this Section 3, shall not exceed 100% of the monthly fee for User’s current plan. In addition to the monthly cap on service credits, the total aggregate amount of service credits issued under this SLA shall not exceed 200% of User’s monthly fees for the applicable plan within any rolling 12-month period. Once this super cap is reached, no further service credits shall be issued until the rolling 12-month period resets. Service credits are non-transferable, non-refundable, and cannot be exchanged for cash or any other form of monetary compensation. In the event of termination of the Agreement for any reason, any unused service credits shall be forfeited and will not be available for use, refund, or any other form of compensation. ### 3.5 Incident Reporting and Credit Request Process **(a) Incident Reporting.** To report an Incident, the User must submit an Incident Report to GoRules at [support@gorules.io](mailto:support@gorules.io) within 7 days of the date the Incident occurred or, if later, the date the User discovered or reasonably should have discovered the Incident. The Incident Report must include: (i) the date and time the Incident occurred or was discovered; (ii) a description of the affected functionality; and (iii) where available, supporting evidence of the Incident (such as logs, screenshots, or error messages). GoRules will acknowledge receipt of the Incident Report within two (2) business days and will use commercially reasonable efforts to investigate and resolve the reported Incident within the Response and Resolution times set out in Section 3.2. **(b) Service Credit Request.** If GoRules fails to meet the applicable Response Time set out in Section 3.2, the User may request a service credit in accordance with Section 3.4. The User must submit a written request for the service credit to [support@gorules.io](mailto:support@gorules.io) within 7 days of the date on which the applicable Response Time was exceeded, referencing the original Incident Report. **(c) Review and Application of Credit.** GoRules will review the service credit request and confirm its validity within 7 business days of receipt. If the request is valid, GoRules will apply the credit to the User’s account for the subsequent billing cycle. If the request is denied, GoRules will provide the User with a written explanation of the basis for the denial. **(d) Failure to Meet Deadlines.** Any Incident Report or service credit request submitted outside the timeframes set out in this Section 3.5 shall be deemed waived, and GoRules shall have no obligation to investigate the Incident or issue any service credit in connection therewith. ### 3.6 Exceptions GoRules shall not be obliged to respond to the Incident Report and remedy the Incident in the following cases: 1. if the Incident has occurred as a result of the User’s use of the Product and Service contrary to the Agreement between the parties or any instructions provided by GoRules; 2. if the User had prevented or interfered with the provision of the Response by GoRules; 3. if the Incident has been caused by the unauthorized modifications of the Product or other Software, including the modifications by use of third-party software; 4. if the Incident occurred as a result of a security breach of the User’s device; 5. if the Incident has occurred as a result of a force majeure event; 6. if the User fails to pay due fees until such fees are paid in full. ### 3.7 Self-Hosted Product - Access to User Data GoRules cannot access User Data on Self-hosted Products, unless required by Client for support reasons, in accordance with the Agreement and with Client’s explicit permission. Any such access is only possible if the Client provides all data and information requested by GoRules for that purpose. Accordingly, GoRules’ obligations under this SLA in respect of the Self-Hosted Product, including the Response and Resolution times set out in Section 3.2, do not apply, and GoRules shall not be held liable or obliged to issue any service credit, to the extent that GoRules’ ability to investigate or resolve an Incident is limited by the Client’s failure to provide such data, or information. ## 4\. Right to Exit ### 4.1 Right to Exit for Persistent Uptime Failure If the monthly uptime achieved for the BRMS, measured in accordance with Section 2.1 of this SLA (taking into account the Excluded Events under Section 2.2), falls below 95.0% in each of three (3) consecutive calendar months, each Business Plan or Enterprise Plan User on an annual Paid Plan for the Managed Cloud shall have the right to terminate the Agreement early, by written notice to GoRules at [support@gorules.io](mailto:support@gorules.io) given within thirty (30) days after the end of the third such consecutive calendar month. Termination shall take effect on the date of receipt of such notice, unless a later effective date is specified in the notice. ### 4.2 Refund If the User terminates the Agreement in accordance with Section 4.1, GoRules will refund to the User the prepaid but unused portion of the annual subscription fee, calculated pro rata for the remainder of the then-current annual subscription term following the effective date of termination. The refund shall be reduced by the amount of any service credits already applied in respect of the affected calendar months. The refund will be paid within thirty (30) days of the effective date of termination, using the same payment method used for the original payment, unless otherwise agreed. ### 4.3 Scope The Right to Exit under this Section 4 applies only to Business Plan and Enterprise Plan Users on an annual Paid Plan for the Managed Cloud. For the avoidance of doubt, it does not apply to Pro Plan Users, to Self-Hosted Product Users, or to Users on monthly Paid Plans. Except for the refund under Section 4.2, termination under this Section 4 shall not give rise to any further liability of GoRules towards the User in connection with the uptime failure, without prejudice to any service credits accrued and applied prior to termination. **On this page** - [1\. Introduction](#1-introduction) - [2\. Uptime](#2-uptime) - [2.1 Service Level Commitment - BRMS](#21-service-level-commitment-brms) - [2.2 Excluded Events](#22-excluded-events) - [2.3 Scheduled Maintenance](#23-scheduled-maintenance) - [2.4 Service Credits - BRMS Uptime](#24-service-credits-brms-uptime) - [2.5 Downtime Reporting](#25-downtime-reporting) - [2.6 Service Credit Claims](#26-service-credit-claims) - [3\. Support (Response Times)](#3-support-response-times) - [3.1 Services and Support Tiers](#31-services-and-support-tiers) - [3.2 Categories of Incidents, Response, and Resolution Time](#32-categories-of-incidents-response-and-resolution-time) - [3.3 Support Hours and Cooperation](#33-support-hours-and-cooperation) - [3.4 Service Credit for Delays](#34-service-credit-for-delays) - [3.5 Incident Reporting and Credit Request Process](#35-incident-reporting-and-credit-request-process) - [3.6 Exceptions](#36-exceptions) - [3.7 Self-Hosted Product - Access to User Data](#37-self-hosted-product-access-to-user-data) - [4\. Right to Exit](#4-right-to-exit) - [4.1 Right to Exit for Persistent Uptime Failure](#41-right-to-exit-for-persistent-uptime-failure) - [4.2 Refund](#42-refund) - [4.3 Scope](#43-scope) --- ## Privacy Policy - GoRules **URL:** https://gorules.io/legal/privacy-policy **Description:** How GoRules collects, uses, and protects personal data processed through the GoRules platform. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch _Last updated: 05.08.2026._ Welcome to GoRules’ Privacy Policy! Please note that this Privacy Policy applies to personal data that is collected and processed in the course of providing a Product (as defined in [Terms of Service](/legal/terms-of-service)) by GoRules Technologies d.o.o. Čačak, with registered seat at Trg narodnog ustanka 2, 32000 Čačak, Republic of Serbia, CIN: 21925713, TIN: 113787086, (hereinafter: “GoRules”, or “we”). GoRules, as a Data Controller or Data Processor, (collects and) processes personal data relating to interactions on the Platform (as defined in the Definition Section of this Privacy Policy). This Privacy Policy describes how GoRules uses and protects any information that you share with us in relation to our Platform. We believe in full transparency, which is why we keep our Privacy Policy simple and easy to understand. We strongly urge you to read this Privacy Policy and make sure that you fully understand and agree with it. If you do not agree to this Privacy Policy, please do not access, or otherwise use GoRules Platform. In case there is anything that you would like to ask us regarding this Privacy Policy, please send your inquiry to [legal@gorules.io](mailto:legal@gorules.io). Along with the Terms of Service, this Privacy Policy represents a contract between you and GoRules. Thus, any capitalized but undefined term in this Privacy Policy shall have the meaning given to it in the definitions section of the [Terms of Service.](/legal/terms-of-service) ## Content 1. DEFINITIONS 2. DATA CONTROLLER AND DATA PROCESSOR 3. WHAT DATA DO WE PROCESS ABOUT YOU AND WHEN? 4. WHAT DO WE NOT DO? 5. PERSONAL DATA SECURITY 6. WITH WHOM DO WE SHARE YOUR PERSONAL DATA? 7. INTERNATIONAL TRANSFER OF YOUR PERSONAL DATA 8. HOW LONG DO WE KEEP YOUR DATA? 9. YOUR RIGHTS 10. CHANGES TO PRIVACY POLICY ## 1\. Definitions TERM MEANING Account The account assigned to the Client or User, whose purpose is to enable the Client or User to access and use the Product and manage the User/Client Content. AI Features or GoRules AI The artificial intelligence-powered capabilities made available by GoRules within the Product, including AI-assisted rule generation, the AI copilot, automated test case generation, and document-to-rule conversion. AI Features are powered by a third-party AI model provider that differs by deployment mode: for Demo (Legacy) Cloud, AI Features use Claude (Anthropic, Inc.); for Managed Cloud, AI Features use Claude (Anthropic, Inc.) via AWS Bedrock. For details on how personal data is processed in connection with AI Features, see Section 3.2.2. Client A company (legal entity) or an independent developer (natural person) represented by User(s) registered on its behalf, who enters into the Agreement with GoRules. Consent Your explicit consent on the processing of personal data. Persons who are 16 years of age or older may give free consent to the processing of their personal data. Cookies Cookies and other similar technologies (e.g. web beacons, LocalStorage, etc.) are small pieces of data stored on your device (computer or mobile device). This information is used to track your use of the Platform and to compile statistical reports on Platform activity. Data Controller An entity that alone or jointly with others determines the purposes and means of the processing of personal data. Data Processor Any natural or legal person who processes the data on behalf of the controller. Data Protection Law a) Law on Personal Data Protection (“Official Gazette of the RS” no. 87/2018) and / or b) General Data Protection Regulation 2016/679. Data Subject, or you Any natural person that shares personal data with us via Platform, or in relation to Platform (e.g. via email). Managed Cloud The fully managed, cloud-hosted deployment of the GoRules BRMS provided by GoRules as a software-as-a-service offering, hosted on Amazon Web Services (AWS) infrastructure. For details on data processing in connection with the Managed Cloud, see Sections 3.2, 5, and 7. Platform or Product GoRules software platform made available through any of GoRules’ deployment modes, including the Self-Hosted subscription package, the Demo (Legacy) Cloud (the existing legacy cloud-based subscription), the Managed Cloud, as well as AI Features and related products and services that we provide, individually and collectively. This definition does not encompass any open-source software developed by GoRules. Personal data or data Any information relating to an identified or identifiable natural person; an identifiable natural person is one who can be identified, either directly or indirectly. Therefore, data about a company or any legal entity is not considered to be personal data but registering on behalf of a legal entity may include sharing personal data. For example, information about one-person companies may constitute personal data where it allows the identification of a natural person. The rules also apply to all personal data relating to natural persons in the course of professional activity, such as the employees of a company or organization, and business e-mail addresses like “[firstname.surname@company.com](mailto:firstname.surname@company.com)”. This Privacy Policy does not apply to information from which no individual can reasonably be identified (anonymized information). Processing Any operation or set of operations that is performed on personal data or sets of personal data. This includes activities such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure, or destruction. User An individual engaged by the Client, including but not limited to Client’s employees, developers, consultants and contractors, and registered on the Platform by the Client. ## 2\. DATA CONTROLLER AND DATA PROCESSOR In relation to your personal data processed via the Platform, GoRules may be either a Data Controller or Data Processor. When GoRules acts in the capacity of a Data Controller, GoRules determines the purposes and means of the processing of personal data. The purpose of data processing is the reason why we process your personal data. The table in Section 3.1 of the Privacy Policy presents the purposes and legal basis for data processing. In those cases, GoRules is responsible for your personal data. Apart from Section 3.2, this Privacy Policy primarily contains information on processing your data in the capacity of a Data Controller. Should you have any inquiries, or you wish to exercise any of the rights of a Data Subject stipulated in Section 9, please contact us: - GoRules Technologies d.o.o. Čačak - Trg narodnog ustanka 2, 32000 Čačak, Republic of Serbia - Email: [legal@gorules.io](mailto:legal@gorules.io) Given that GoRules strongly supports fair personal data processing, despite being only a Data Processor in the below-listed cases, we made an additional effort to explain such personal data processing via Platform - in Section 3.2 of this Privacy Policy. The information contained therein outlines how personal data processing via GoRules’ Platform functions in general. But if you wish to send an inquiry, or exercise any of the rights which you may have under the applicable data protection law as the Data Subject, please contact the Client directly, as they hold the position of Data Controller. Since GoRules is a company operating under the laws of the Republic of Serbia and falls under the scope of application of the Data Protection Law, GoRules as a Data Processor is obliged to sign the Data Protection Addendum to the Terms of Service ("DPA"), with the Client as a Data Controller. The DPA reflects the agreement between the Client and GoRules regarding the terms which govern the processing of personal data under GoRules' Terms of Service. Signing the DPA will be considered as an amendment to the Agreement (within the meaning of the Definitions Section of Terms of Service) and will be considered to form a part of the Agreement. Where GoRules processes personal data as a Data Processor on behalf of a Client whose assigned Managed Cloud region is within the European Union (EU1 Region), the DPA includes the applicable standard contractual clauses and technical and organizational measures required under GDPR. ## 3\. WHAT DATA DO WE PROCESS ABOUT YOU AND WHEN? We may collect and receive information about you in various ways: - Information you provide using Platform (for example, by requesting creation of an Account on Platform). - Information you decide to provide through getting in touch with us. - Information we collect using cookies and similar technologies as explained below. ### Personal data we may collect automatically Each time you use Platform we may automatically collect the following information: - At the time of logging in, we store the data in local storage, such as the user id, the hashtag that we generate ourselves and is created at the time of logging in, the date of logging in and the date when you will be logged out automatically. Namely, we have created the functionality that every user is automatically logged out of Platform after exactly 8 hours after being logged in. - when you use the Platform, we will keep a record of the details of that usage, including the date, time, location, frequency and duration of the usage; - technical information about your computer or mobile device for system administration and analysis, including your IP address, URL clickstreams, unique device identifiers, operating system, and network and browser type; - other information about your use of the Platform, including the pages you have viewed, the duration spent on the Platform and User/Client Content you have uploaded to the Platform. Please read our [Cookie Policy](/legal/cookie-policy) in order to find out more about these technologies. ### 3.1 GORULES AS DATA CONTROLLER GoRules will primarily have the role of Data Processor in relation to the collection and processing of your personal data via the Platform. However, for the purpose of complete transparency, we list possible occasions in which GoRules can find itself in the role of Data Controller. **DATA WE COLLECT** **PURPOSE** **LEGAL BASIS** **RETENTION PERIOD** Client’s organization name, first and last name, business email address, Client’s website, size of the Client’s company. Creating and maintaining Client’s Account at the Platform according to the [Terms of Service](/legal/terms-of-service). Processing is necessary for the performance of the Agreement. Until the Account is deleted in accordance with the [Terms of Service](/legal/terms-of-service). Payment information Card holder name, Card number, Expiration date, Security code Billing Information: First name, Last name, Company, VAT ID, Contact Email, Address, Country, State, City, ZIP code When subscribing to any of the Platform’s paid subscription packages or when changing any Platform’s paid subscription packages in accordance with the Terms of Service, this information is being collected by GoRules directly or a third-party processor. Processing is necessary for the performance of the Agreement. We keep only the last four digits of the credit card number under subscription billing info until such Agreement is terminated and for the period necessary to comply with the applicable financial and tax accounting and other statutory obligations in accordance with the applicable law (Section 13 of the Terms of Service). Additional Data i.e., data you decide to share with us by contacting us. If you send us an inquiry or otherwise request support, we will collect the data you decide to share with us. Processing of personal data is either necessary to provide a Product or part thereof or the processing is based on your consent. If the processing is based on your consent, we keep the information until you withdraw your consent or for one year, whichever date comes first. Information necessary for identification, time and date of data subject’s request To allow Data Subjects to exercise their rights in accordance with this Privacy Policy, as defined in Section 9. Processing is necessary for compliance with a legal obligation to which the Data Controller is subject. We keep this information for a period of one year. Other personal data For the prevention and detection of fraud, money laundering or other crimes or to respond to a binding request from a public authority or court. The processing is necessary to comply with legal and regulatory obligations. In accordance with the applicable statutory deadlines. For Managed Cloud subscribers: organization name, first and last name, business email address, country of establishment (for Data Region assignment), and subscription plan details. Creating and maintaining the Client's Managed Cloud account; assigning the appropriate Data Region; administering the Managed Cloud subscription in accordance with the Terms of Service. Processing is necessary for the performance of the Agreement. Until the Account is deleted or the Managed Cloud subscription is terminated, in accordance with the Terms of Service. Billing-related data is retained for the period necessary to comply with applicable financial, tax, and accounting obligations. **Usage and technical data**, i.e., IP address, device and browser information, operating system, pages visited, session duration, click and interaction data, page load times, error logs, and general geolocation derived from IP address, collected through the Platform's website and/or application. This data is limited to technical and usage telemetry only. GoRules does not access, monitor, or process the Content that the Client inputs into, processes through, or generates using the Product, nor does GoRules collect any other identifying information beyond what is strictly necessary for the purposes described herein. Data collection is designed and configured to be limited to what is adequate, relevant, and necessary for these purposes, in accordance with the data minimization principle. To monitor and analyze the performance, availability, and usage of the Platform, to detect and diagnose technical errors, and to improve the functionality and user experience of the Platform. Processing is necessary for our legitimate interest in maintaining, securing, and improving the Platform. We retain this data for a period of 30 days from collection, or as otherwise configured within our analytics tooling, unless a shorter or longer period is required to comply with applicable law. ### 3.2 GORULES AS DATA PROCESSOR As previously stated, concerning some of your personal data processed on the Platform, GoRules is a Data Processor, and the Client is the Data Controller. GoRules processes personal data following instructions from the Data Controller under the Terms of Service, and DPA (if any). The purpose of such personal data processing includes but is not limited to: inviting Clients and Users to the Platform, creating Accounts for Clients and Users, adding mandatory and optional data to the Accounts, adding system user roles, adding permissions to the Accounts, sending relevant notifications in relation to the usage of the Platform. GoRules processes these data when the Platform is being used in the form of any deployment mode, including the Demo (Legacy) Cloud and the Managed Cloud, as well as when Users are registering on the Portal in order to use the Self-Hosted Product. Besides that, GoRules might process data that is required for support reasons, in accordance with the Agreement or with Clients/Users explicit permission. Also, GoRules collects telemetry necessary for the validation of the license for the use of the Self-hosted version of the Platform. In connection with AI Features, GoRules processes User inputs submitted to the AI model solely to the extent necessary to return the requested output; such inputs are not retained after delivery of the output and are not used for AI model training. As a processor, GoRules is permitted to collect, use, disclose and/or otherwise process your personal data only in accordance with its contracts with the Client. #### 3.2.1 Processing when using the Product ##### Cloud-based Products (Demo (Legacy) Cloud and Managed Cloud) You may gain access to the Platform in one of two ways: - Invitation: An existing Client invites you to the Platform by entering your work email address and, optionally, your first and last name. GoRules processes this data as a processor, on the Client's instructions, solely for the purpose of enabling your access to the Platform. You receive an invitation by email, which you accept by clicking the link contained therein. - Sign-up: You may register directly, without being invited by an existing Client, by providing your email address and an organization name, and confirming your registration via a one-time code sent to your email. In this case, you (or the organization on whose behalf you are registering) become the Client, and GoRules processes your data as controller, on the basis of the performance of the Agreement concluded between you and GoRules. Regardless of the access route, to finalize your registration you will confirm your identity using one of the following methods, depending on the authentication method configured for your organization: (i) a one-time code sent to your email address, (ii) Google Sign-In, or (iii) an SSO pop-up. Once registered, you or the Client may optionally add the following data within the Platform: - First name - Last name ##### Self-Hosted Product (License Portal) You may gain access to the Self-Hosted License Portal in one of two ways: - Invitation: An existing Client invites you to the License Portal by entering your work email address. GoRules processes this data as a processor, on the Client's instructions, solely for the purpose of enabling your access to the Portal. - Sign-up: You may register directly, without being invited by an existing Client, by providing your email address, an organization name, your organization's website, and your first and last name, and confirming your registration via a one-time code sent to your email. In this case, GoRules processes your data as controller, on the basis of the performance of the Agreement concluded between you and GoRules. After registration, you will be able to acquire a software license key to access the Self-Hosted Product. With respect to the Self-Hosted Product itself, GoRules only processes the personal data needed to register on the Self-Hosted License Portal, and does not process, access, or monitor personal data or Content that Users upload to or process through the Self-Hosted Product while using it. #### 3.2.2 AI Features Data Processing When a User interacts with AI Features, GoRules acts as a Data Processor in relation to any personal data contained within those inputs. The following applies to personal data processed through AI Features: 1. The AI model provider differs by deployment mode. For Demo (Legacy) Cloud Users: GoRules transmits User inputs to Anthropic (United States) for processing via Claude. This transmission is governed by Anthropic's applicable data processing terms. For Managed Cloud Users: GoRules transmits User inputs to Anthropic, Inc. (United States) via Amazon Web Services Bedrock solely to generate the requested output. For EU Region Users (EU1), this transmission is processed within the European Union and data does not leave the EU. This transmission is governed by adequate data processing agreements. 2. User inputs and AI-generated outputs are not retained by GoRules or by AI model providers beyond what is strictly necessary to deliver the response in real time. They are not used to train, fine-tune, or otherwise improve any AI model. 3. Users should avoid submitting special categories of personal data (as defined under applicable data protection law) through AI Features unless strictly necessary and supported by an appropriate legal basis. 4. The Client, as Data Controller, is responsible for ensuring that any personal data submitted to AI Features is processed on a valid legal basis and that data subjects have been informed accordingly. If you have any questions about how personal data is processed through AI Features, please contact the Client or reach us at [legal@gorules.io](mailto:legal@gorules.io). ## 4\. WHAT DO WE NOT DO? GoRules will never: - Sell any kind of personal information or data. - Disclose this information to marketers or third parties not specified in Section 6 of the Privacy Policy. - Process your data in any way other than stated in this Privacy Policy. - Use personal data contained in User inputs to AI Features to train, fine-tune, benchmark, or otherwise improve any AI model, whether operated by GoRules or a third party, without your explicit prior consent. ## 5\. PERSONAL DATA SECURITY We take administrative, technical, organizational, and other measures to ensure the appropriate level of security of personal data we process. Upon assessing whether a measure is adequate and which level of security is appropriate, we consider the nature of the personal data we are processing and the nature of the processing operations we perform, the risks to which you are exposed by our processing activities, the costs of the implementation of security measures and other relevant matters in the particular circumstances. Some of the measures we apply include access authorization control, protection of integrity and confidentiality, data backup, firewalls, data encryption and other appropriate measures. We equip our staff with the appropriate knowledge and understanding of the importance and confidentiality of your personal data security. Whenever we save your personal information, it’s stored on servers and in facilities that only selected personnel and our contractors have access to. We encrypt all data that you submit through Platform during transmission using SSL in order to prevent unauthorized parties from viewing such information. Remember - all information you submit to us by email is not secure, so please do not send sensitive information in any email to GoRules. We never request that you submit sensitive or personal information over email, so please report any such requests to us by sending an email to [legal@gorules.io](mailto:legal@gorules.io). We protect personal information you provide online in connection with registering an account via GoRules’ Platform. Access to your own personal information is available through an Account created by you. To protect the security of your personal information, never share your credentials with anyone. Please notify us immediately if you believe your Account has been compromised. **Managed Cloud Security**. For Users accessing the Platform through the Managed Cloud, GoRules implements commercially reasonable administrative, technical, and organizational security measures to protect personal data hosted on the Managed Cloud infrastructure (Amazon Web Services). Personal data on the Managed Cloud is stored exclusively within the Data Region assigned to your organization and is not transferred outside that region except as required by law and as explained Section 7 of this Privacy Policy. **AI Features Security**. User inputs submitted to AI Features are transmitted to GoRules' third-party AI model providers over encrypted connections. For Managed Cloud Users assigned to the EU Region (EU1), transmission and inference remain within the European Union and data does not leave the EU. For Demo (Legacy) Cloud Users, inputs are transmitted to Anthropic, Inc. in the United States regardless of the User's location, as there is no Data Region assignment applicable to AI Features under the Demo (Legacy) Cloud. GoRules does not store User inputs or AI-generated outputs after delivery of the response. GoRules has a data processing agreement in place with its AI model providers governing the secure handling of any data transmitted in connection with AI Features. ## 6\. WITH WHOM DO WE SHARE YOUR PERSONAL DATA? GoRules utilizes external processors and sub-processors for certain processing activities. We conduct information audits to identify, categorize and record all personal data that is processed outside our company, so that the information, processing activity, processor and legal basis are all recorded, reviewed and easily accessible. The list of our sub-processors is approved by the Client. We have strict due diligence procedures and measures in place and review, assess and background check all processors prior to forming a business relationship. We obtain company documents, certifications, references and ensure that the processor is adequate, appropriate, and effective for the task we are employing them for. We audit their processes and activities prior to contract and during the contract period to ensure compliance with the data protection regulations and review any codes of conduct that oblige them to confirm compliance. The list of processors and sub-processors with whom we share your personal data is available at [GoRules Trust Center](https://trust.gorules.io/subprocessors). ### Payment processing for the Self-Hosted Plan and Managed Cloud Plan If you purchase the Self-Hosted Plan or the Managed Cloud Plan, your payment is handled by Paddle.com Market Limited ("**Paddle**"), which acts as our authorized reseller and merchant of record. Unlike the processors and sub-processors listed above, Paddle does not process your payment data on our behalf and on our instructions. Instead, Paddle acts as an **independent data controller** for the payment data it collects directly from you (such as your name, email address, billing address, and payment instrument details), and your purchase is subject to Paddle's own Privacy Policy, available at [https://www.paddle.com/legal/privacy](https://www.paddle.com/legal/privacy). Paddle shares with GoRules only a limited set of data necessary to deliver the Product, provide customer support, and prevent fraud. GoRules processes that limited data as controller, in accordance with this Privacy Policy. This does not apply to the Enterprise Plan, where GoRules directly collects and processes your payment data as controller. We may also share your personal data with our outside accountants, legal counsels, and auditors. Moreover, we may disclose your personal information to third parties: - if we are under a duty to disclose or share your personal data in order to comply with any legal obligation; - to prevent and detect fraud or crime; - in response to a subpoena, warrant, court order, or as otherwise required by law. Please note that personal information may be disclosed or transferred as part of, or during negotiations of, a merger, consolidation, sale of our assets, as well as equity financing, acquisition, strategic alliance or in any other situation where personal information may be transferred as one of the business assets of GoRules. We do not have a list of all third parties we share your data with. However, if you would like further information about who we have shared your data with, you can request this by contacting us at [legal@gorules.io](mailto:legal@gorules.io). ## 7\. INTERNATIONAL TRANSFER OF YOUR PERSONAL DATA We may transfer your personal data to countries other than the one you reside in. In that case, we will also apply appropriate technical and organizational measures to ensure an adequate level of security in respect of all personal data we process. If the Data Protection Law applies to you, we make sure that such transfer is made: - to the countries within the EEA; - to the countries which ensure an adequate level of protection; - to the countries which do not belong to those specified under item 1. and 2, but only by applying the appropriate safeguard measures (such as Standard Contractual Clauses adopted by the European Commission) If you would like to obtain more information about these protective measures, please contact us at [legal@gorules.io](mailto:legal@gorules.io). The location where your personal data is stored depends on the deployment mode you use: - Demo (Legacy) Cloud: Personal data is stored on servers located in the European Union (Microsoft Azure). - Managed Cloud: Personal data is stored and processed exclusively within the Data Region assigned to your organization at the time of subscription: - EU Region: AWS within the European Union. - US Region: AWS within United States of America. GoRules does not transfer Managed Cloud personal data outside the assigned Data Region except as required by applicable law, with the exception of telemetry and Real User Monitoring (RUM) data, which is processed and stored in Datadog’s Europe region regardless of the Client’s assigned Data Region. For EU-Region users, data processed within the EU is subject to GDPR and GoRules relies on its data processing agreement with third party vendors as the applicable safeguard. - Self-Hosted Product: Personal data is stored on the Client's own servers or infrastructure. However, certain administrative data related to the Client's license (such as first name, last name, and business email address of the Client's authorized representatives) is collected and stored through GoRules' license portal, which is hosted on servers located in the European Union (Microsoft Azure), for the purpose of license activation and management in accordance with the Terms of Service. **AI Features**: The AI model provider and data transfer arrangements differ by deployment mode: (i) Demo (Legacy) Cloud: User inputs submitted to AI Features are transmitted to Anthropic (United States) for processing via Claude. This transfer is governed by Anthropic's applicable data processing terms. (ii) Managed Cloud: User inputs submitted to AI Features are transmitted to Anthropic, Inc. (United States) via Amazon Web Services Bedrock for processing. For EU Region Users (EU1), AI inference is processed within the European Union and User inputs are not transferred to the United States. This transfer is governed by standard contractual clauses and the data processing agreement between GoRules and Anthropic. User inputs and AI outputs are not retained after delivery of the response. ## 8\. HOW LONG DO WE KEEP YOUR DATA? The period for which we store your personal data depends on a particular purpose for the processing of personal data, as explained in detail in Section 3. We retain personal data for as long as we reasonably require it for legal or business purposes. In determining data retention periods, we take into consideration the applicable law (see [Terms of Service](/legal/terms-of-service)), contractual obligations, and the expectations and requirements of our Clients. When we no longer need personal information, or when you legitimately request us to delete your information, we will securely delete or destroy it. However, as an exception to the retention periods in Section 3 the data may be processed to determine, pursue, or defend claims and counterclaims. ## 9\. YOUR RIGHTS Given that fairness and transparency are our cornerstone principles, we wanted to remind you of the rights that you have as a Data Subject. These rights may be exercised by Data Subject when GoRules operates as a Data Controller. If your inquiry or exercise of any of the Data Subject's rights relates to the data processed by the Client as a Data Controller as explained in Section 3.2 of the Privacy Policy, please contact the Client (that you have linked your Account with). In the event GoRules receives a request for exercising any of these rights directly from a Data Subject, we are obliged to notify the Client before responding to such a request. ### Right of Access You can send us a request for a copy of the personal data we hold about you. We have ensured that appropriate measures have been taken to provide such in a concise, transparent, intelligible, and easily accessible form, using clear and plain language. Such information is provided in writing free of charge. It may be provided by other means when authorized by the Data Subject and with prior verification as to the subject's identity. Information is provided to the Data Subject at the earliest convenience, but at a maximum of 30 days from the date the request was received. Where the provision of information is particularly complex or is subject to a valid delay, the period may be extended by two further months where necessary. ### Right to Object to Processing You have the right to object to the processing of your personal data where that processing is being undertaken based on the Data Controller’s legitimate interest. In such a case the Data Controller is required to cease processing your data unless they can demonstrate adequate grounds that override your objection. ### Right to Correction of Your Personal Data If your personal data processed by the Data Controller is incorrect, you have the right to request that we correct those data. Where notified of inaccurate data by the Data Subject, we will rectify the error within 30 days and inform any third party of the rectification if we have disclosed the personal data in question to them. ### Right to Erasure You have the right to request that your personal data is deleted in certain circumstances, such as: - The personal data are no longer needed for the purpose for which they were collected; - You withdraw your consent (where the processing was based on consent); - You object to the processing and no overriding legitimate grounds are justifying processing the personal data; - The personal data have been unlawfully processed; or - To comply with a legal obligation. However, this right does not apply where, for example, the processing is necessary: - To comply with a legal obligation; or - For the establishment, exercise, or defense of legal claims. Each User can deactivate its User Account. Please note that some data will be kept for our internal business purposes, legal, financial, and accounting purposes. ### Right to Restriction of Processing You can exercise your right to the restriction of processing in the following situations: - if the accuracy of the personal data is contested, - you consider the processing unlawful, but you do not want your personal data to be erased, - we no longer need the personal data, but you require it for the establishment, exercise or defense of legal claims or you have objected to the processing and verification. ### Right to Data Portability Where you have provided personal data to us, you have the right to receive such personal data back in a structured, commonly used and machine-readable format, and to have those data transmitted to a third-party without hindrance, but in each case only where: - The processing is carried out by automated means; and - The processing is based on your consent or the performance of a contract with you. ### Right to Withdraw the Consent If you have provided your consent to the collection, processing, and transfer of your personal data, you have the right to fully or partly withdraw your consent. Once we have received notification that you have withdrawn your consent, we will no longer process your information for the purpose(s) to which you originally consented unless there is another legal ground for the processing. ### Right to Lodge a Complaint If you have any concerns or requests in relation to your personal data, please contact us at [legal@gorules.io](mailto:legal@gorules.io) and we will respond as soon as possible but not later than 30 days. If you are unsatisfied with our response, you may also contact the competent supervisory authority at your country of residency or Commissioner for information of public importance and personal data protection, Bulevar kralja Aleksandra 15, 11120 Belgrade, telephone number: (+381) - 11 - 3408 900, [https://www.poverenik.rs/en/home.html](https://www.poverenik.rs/en/home.html). ## 10\. CHANGES TO OUR PRIVACY POLICY Any changes we may make to our Privacy Policy will be posted on this page and where appropriate may be notified to you by email or advised to you on the next login to the Platform. If you continue with the use of the Platform after the changes were implemented, that will signify that you agree to any such changes. **On this page** - [Content](#content) - [1\. Definitions](#1-definitions) - [2\. DATA CONTROLLER AND DATA PROCESSOR](#2-data-controller-and-data-processor) - [3\. WHAT DATA DO WE PROCESS ABOUT YOU AND WHEN?](#3-what-data-do-we-process-about-you-and-when) - [Personal data we may collect automatically](#personal-data-we-may-collect-automatically) - [3.1 GORULES AS DATA CONTROLLER](#31-gorules-as-data-controller) - [3.2 GORULES AS DATA PROCESSOR](#32-gorules-as-data-processor) - [4\. WHAT DO WE NOT DO?](#4-what-do-we-not-do) - [5\. PERSONAL DATA SECURITY](#5-personal-data-security) - [6\. WITH WHOM DO WE SHARE YOUR PERSONAL DATA?](#6-with-whom-do-we-share-your-personal-data) - [Payment processing for the Self-Hosted Plan and Managed Cloud Plan](#payment-processing-for-the-self-hosted-plan-and-managed-cloud-plan) - [7\. INTERNATIONAL TRANSFER OF YOUR PERSONAL DATA](#7-international-transfer-of-your-personal-data) - [8\. HOW LONG DO WE KEEP YOUR DATA?](#8-how-long-do-we-keep-your-data) - [9\. YOUR RIGHTS](#9-your-rights) - [Right of Access](#right-of-access) - [Right to Object to Processing](#right-to-object-to-processing) - [Right to Correction of Your Personal Data](#right-to-correction-of-your-personal-data) - [Right to Erasure](#right-to-erasure) - [Right to Restriction of Processing](#right-to-restriction-of-processing) - [Right to Data Portability](#right-to-data-portability) - [Right to Withdraw the Consent](#right-to-withdraw-the-consent) - [Right to Lodge a Complaint](#right-to-lodge-a-complaint) - [10\. CHANGES TO OUR PRIVACY POLICY](#10-changes-to-our-privacy-policy) --- ## Cookie Policy - GoRules **URL:** https://gorules.io/legal/cookie-policy **Description:** This Agreement states the cookie policy that applies to your use of the services. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch Welcome to our Cookie Policy! The Cookie Policy is an integral part of our [Privacy Policy](/legal/privacy-policy) and [Terms of Service](/legal/terms-of-service). In the following paragraphs, you can learn more about cookies and their purpose, how we use them on the GoRules Products, and how you can control them. The cookies and similar technologies are not used on GoRules self-hosted products. All terms starting with a capital letter have the same meaning as defined in our [Privacy Policy](/legal/privacy-policy) or [Terms of Service](/legal/terms-of-service). ## 1\. What are the cookies? Cookies are text files (pieces of code) that contain small amounts of information, and they are stored on your computer or mobile device. Cookies are being sent to your browser by a website you visit, and they may be sent back to the originating website during future visits, or to another website that recognizes them. Cookies are useful because they allow a website to remember a user’s device and offer the best possible configuration. On our GoRules Products, we use cookies to make our Service more user-friendly, efficient, and secure. Also, some types of cookies enable us to collect information about the GoRules Products’s use and provide you with the relevant content. ## 2\. Types of cookies Cookies can be classified in three different ways: based on their duration, i.e., how long they last, where they originate from, and what is their purpose. ### (a) Duration of cookies In general, cookies may last a certain period of time (such as 179 days, 1 year, 2 years, etc.), or only while the website visit session lasts. So, session cookies are temporary cookies that expire once you close your browser (or once your session ends). Persistent cookies are cookies that remain on your hard drive until you erase them, or your browser does, depending on the cookie’s expiration date. All persistent cookies have an expiration date written into their code, but their duration can vary. ### (b) Provenance (origin) First-party cookies – cookies that are put on your device directly by us, i.e., the website that you have visited. Third-party cookies - cookies placed on your device, not by us, but by a third party. Third-party cookies are usually related to an advertiser or an analytic system. Whether a certain cookie falls into the category of first-party or third-party ones, you can check in the category ‘provider’ in the table below. ### (c) Purpose Our Products include several types of cookies, which all have different purposes - the necessary ones, statistical, and marketing cookies. In addition, from time-to-time unclassified cookies may appear. #### Necessary cookies Necessary cookies make the GoRules Products usable by enabling basic functions such as page navigation and access to secure areas of the Products. In other words, GoRules Products cannot function properly without these cookies. COOKIE NAME PURPOSE PROVIDER EXPIRY TYPE client Preserves users states across page requests. gorules.io Session cookie First-party cookie dd\_cookie\_test\_\* Temporary cookie used to test for cookie support. editor.gorules.io A few seconds First-party cookie #### Statistic cookies Statistic cookies enable us to understand how visitors interact with GoRules Products, as they collect and report traffic information anonymously. Due to the implementation of these cookies, we can measure and improve the performance of our Products. This way, we know which pages are the most and the least popular with our users, and we can also have an insight into how our visitors move around the Products. All information collected by these cookies is collected anonymously and cannot be reasonably used to identify any particular individual. COOKIE NAME PURPOSE PROVIDER EXPIRY TYPE \_ga Registers a unique ID that is used to generate statistical data on how the visitor uses the website. gorules.io 2 years First-party cookie \_ga\_\* Used by Google Analytics to collect data on the number of times a user has visited the website as well as dates for the first and most recent visit. gorules.io 2 years First-party cookie \_gclxxxx Google conversion tracking cookie gorules.io 3 months First-party cookie \_dd\_s Datadog monitoring cookie gorules.io 15 minutes First-party cookie #### Marketing cookies We have implemented marketing cookies in order to improve our Products and their performance. So, marketing cookies help us provide you with a good user experience and tailored content. These cookies are set up through our Products by our advertising partners, who may use marketing cookies to create a profile of your interests and show you relevant advertisements in other locations. Please note that marketing cookies uniquely identify your browser and device. If you do not allow these cookies, you will not experience our targeted ads on other websites. COOKIE NAME PURPOSE PROVIDER EXPIRY TYPE \_gcl\_au Used by Google AdSense for experimenting with advertisement efficiency across websites using their services. gorules.io 3 months First-party cookie ads/ga-audiences Used by Google AdWords to re-engage visitors that are likely to convert to customers based on the visitor's online behaviour across websites. google.com Session cookie Third-party cookie IDE Used by Google DoubleClick to register and report the website user's actions after viewing or clicking on e of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user. doubleclick.net 1 year Third-party cookie Pagead/1p-conversion/#/ Generated by Google pagead dynamic marketing to track events such as conversions or other meaningful user interactions. google.com Session cookie Third-party cookie \_\_hstc Used by HubSpot to track visitors across the website. Contains domain, user token, initial visit timestamp, last visit timestamp, current visit timestamp, and session number. gorules.io 6 months First-party cookie hubspotutk Used by HubSpot to identify a visitor and associate them with a contact record in the CRM. gorules.io 6 months First-party cookie \_\_hssc Used by HubSpot to track the current session and determine if a new session has started. gorules.io 30 minutes First-party cookie \_\_hssrc Used by HubSpot to determine if the visitor has restarted their browser. gorules.io Session First-party cookie #### Unclassified cookies Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies. COOKIE NAME PURPOSE PROVIDER EXPIRY TYPE Pagead/1p-user-list Unknown google.com Session cookie Third-party cookie ## 3\. Use of external tools on our Products ### Google Analytics On the Products, we have integrated a special analysis service - Google Analytics. Products’ analysis refers to the collection, recording and analysis of data regarding the behaviour of Products’ visitors. In other words, Google Analytics uses cookies to remember a visitor’s behaviour and provide us with reports on the Products’ visits and the visitors’ activity. The operator of the Google Analytics tool is Google Inc., 1600 Amphitheatre Pkwy, Mountain View, CA 94043-1351, USA. Google Analytics uses cookies, as described in the table above. The information about your use of our Products generated by the Google Analytics cookies is usually transmitted to a Google server in the USA and stored there. Google might disclose these personal data collected via the technical procedure to third parties. We have activated IP anonymization, which means that Google shortens the IP addresses of our visitors within the Member States of the European Union or in other countries that are parties to the European Marketing Area Treaty. Only in exceptional cases is the full IP address transmitted to a Google server in the USA and shortened there. Google uses this information to analyze your use of the Products to compile a report about your Products activities and provide us with other services associated with the Products and Service. In addition to the instructions in Section 5. of this Cookie Policy, you may prevent the disclosure of the data generated by the cookie which refers to the use of the Products (including your IP address) to Google, as well as the processing of these data by Google, by downloading and installing the browser plug-in available under the following [link](https://tools.google.com/dlpage/gaoptout?hl=en). This browser add-on notifies Google Analytics via JavaScript that no data or information about website visitors may be transmitted to Google Analytics. Apart from that, a cookie left behind by Google Analytics may be erased at any time via the Internet browser or other software programs. Google Analytics is explained in more detail [here](https://marketingplatform.google.com/about/), while information on how Google processes data you may find on this [link](https://support.google.com/analytics/answer/6004245#zippy=%2Cour-privacy-policy%2Cgoogle-analytics-cookies-and-identifiers). ## 4\. Legal basis for the use of cookies We use cookies only if we have obtained your consent for that (through the cookie settings). In general, the legal basis for the use of cookies on the Products is the consent of the visitor, given in accordance with the [Privacy Policy](/legal/privacy-policy). The only exception is necessary cookies because the legal basis for their implementation is the performance of the agreement concluded with the data subject. Please note that it is assumed that the device you use to access the Products is yours. If you access the Products from a device that you do not own, it will still be assumed that you have the authority to consent to the use of cookies on that device, in accordance with the Cookie Policy. ## 5\. How to block cookies? You can disable any type of cookies, except for the necessary ones. To block the cookies, you can: 1. Refuse cookies via the cookie banner and general cookie settings, or 2. Adjust your browser settings. When disabling the cookies via the cookie banner, please choose the option “Decline”. Also, please have in mind that you can change your cookie preferences at any time by clicking on the “Cookie settings” icon. Then, you can change the available sliders/checkboxes to “On” or “Off” and confirm the choice by clicking on “Save and close”. You may need to refresh your page for your settings to take effect. If you would like to disable cookies via browser, please note that most internet browsers accept cookies by their default setup. However, if you want to refuse or delete cookies, please refer to the help and support area on your browser for further instructions (e.g., [Google Chrome](https://support.google.com/chrome/answer/95647?hl=en-GB), [Microsoft Edge](https://support.microsoft.com/en-us/topic/description-of-cookies-ad01aa7e-66c9-8ab2-7898-6652c100999d), [Mozilla Firefox](https://support.mozilla.org/en-US/kb/cookies-information-websites-store-on-your-computer), [Safari Desktop](https://support.apple.com/en-gb/guide/safari/sfri11471/mac), [Safari Mobile](https://support.apple.com/en-us/HT201265), [Android Browser](https://support.google.com/nexus/answer/54068?visit_id=638337656775564941-1420620462&hl=en&rd=1), [Opera](https://www.opera.com/help), [Opera Mobile](https://help.opera.com/en/mobile/android/#privacy)). Browsers may have different procedures for managing and configuring cookies. But, if you decide to use your browser settings to block all cookies (including necessary cookies), please keep in mind that you may not be able to access all or some parts of our Products. For more information on cookies, i.e., instructions on how to delete or block them, please visit[https://www.aboutcookies.org/](https://www.aboutcookies.org/). ## 6\. Changes to our Cookie Policy Due to legal and technological requirements, we will update this Cookie Policy occasionally. In such a case, you may be notified through a pop-up on the Products interface in a reasonable period prior to and following the change. **On this page** - [1\. What are the cookies?](#1.-what-are-the-cookies) - [2\. Types of cookies](#2.-types-of-cookies) - [(a) Duration of cookies](#a-duration-of-cookies) - [(b) Provenance (origin)](#b-provenance-origin) - [(c) Purpose](#c-purpose) - [Necessary cookies](#necessary-cookies) - [Statistic cookies](#statistic-cookies) - [Marketing cookies](#marketing-cookies) - [Unclassified cookies](#unclassified-cookies) - [3\. Use of external tools on our Products](#3.-use-of-external-tools-on-our-products) - [4\. Legal basis for the use of cookies](#4.-legal-basis-for-the-use-of-cookies) - [5\. How to block cookies?](#5.-how-to-block-cookies) - [6\. Changes to our Cookie Policy](#6.-changes-to-our-cookie-policy) --- ## Telecom Rules Engine - GoRules **URL:** https://gorules.io/industries/telco **Description:** Automate telecom operations with the GoRules business rules engine. Optimize network management, streamline pricing, and simplify product config. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # A rules engine built for Telecom. Transform telecom operations with a flexible decision automation platform that optimizes network resource allocation, enables dynamic pricing models, and streamlines product configuration while improving customer experience. [Get started free](https://us1.gorules.io) [Explore templates](/industries/telco/templates) **Upgrade eligibility**_v2.4.0_ fieldconditionoutcome tenureover 24 monthsoffer upgrade balance.overdueabove $0collect first usage.dataover 80%offer add-on churn.riskhighretention offer ## Streamline Telecom Decision-Making Telecommunications providers face complex challenges in managing network resources, developing competitive pricing strategies, and configuring diverse service offerings. Our business rules engine helps you automate critical telecom decisions with precision, enabling your teams to focus on innovation and customer relationships. ### Optimized Implement sophisticated network management logic that allocates resources based on service priorities, customer tiers, and usage patterns. ### Competitive Deploy dynamic pricing models and tariff structures that adapt to market conditions, customer segments, and service utilization. ### Flexible Quickly update product configurations and service bundles to respond to market opportunities without extensive IT involvement. ## Addressing Telecommunications Decision Challenges Telecom companies face unique challenges that generic automation solutions may not adequately address. Our business rules engine is designed to help with these industry-specific needs. ### Network Resource Optimization Telecommunications networks require complex resource allocation decisions based on multiple factors. Our visual decision graphs make it easier to implement sophisticated traffic management and QoS policies with clear visualization of decision rules. ### Pricing Complexity Telecom pricing involves numerous variables including usage patterns, service tiers, and promotional considerations. Our rules engine helps automate tariff calculations and discount applications across diverse customer segments. ### Product Proliferation Telecoms offer an increasing variety of service combinations and bundles. Our platform supports implementation of complex product configuration rules to ensure appropriate offerings for each customer segment. ### Integration with OSS/BSS Systems Many telecoms rely on established operational and business support systems. Our rules engine offers a flexible REST API that can integrate with your existing infrastructure. ## Potential Benefits for Telecommunications Organizations Implementing our rules engine can help deliver improvements across your telecom operations. ### Enhanced Network Performance Implement rule-based traffic management and resource allocation to help improve service quality during periods of high demand or network constraints. ### Responsive Pricing Strategies Develop and deploy dynamic pricing models that can adapt to changing market conditions, competitive pressures, and customer behaviors. ### Accelerated Product Innovation Reduce time-to-market for new service bundles and offerings by simplifying product configuration rules and reducing dependency on IT implementation cycles. ### Consistent Decision-Making Help ensure that network management, pricing, and product decisions follow established policies, potentially reducing variability across different systems and channels. ### Improved Operational Efficiency Automate routine decisions across network operations and business processes to help reduce manual interventions and accelerate response times. ### Empowered Business Users Enable network operations, product, and marketing teams to manage decision logic with reduced IT dependencies, using our intuitive interface. ## Explore other industries [View all industries](/industries) [**Public Sector** Automate government operations with the GoRules business rules engine. Improve eligibility determination, case management, and citizen services. ](/industries/public-sector)[**Financial** Automate banking and fintech decisions with the GoRules business rules engine. Improve compliance, streamline decisioning, and speed up onboarding. ](/industries/financial)[**Aviation** Automate digital aviation experiences with the GoRules business rules engine. Improve personalization, booking flows, and ancillary offers. ](/industries/aviation) ## Ready to automate telco decisions? Start free on GoRules Cloud, or talk to us about how telco teams run GoRules. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Retail Rules Engine - GoRules **URL:** https://gorules.io/industries/retail **Description:** Automate retail operations with the GoRules business rules engine. Optimize dynamic pricing, manage discounts, and streamline marketplace fees. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # A rules engine built for Retail & Marketplaces. Transform retail operations with a flexible decision automation platform that enables dynamic pricing, streamlines discount management, optimizes marketplace fees, and delivers personalized shopping experiences. [Get started free](https://us1.gorules.io) [Explore templates](/industries/retail/templates) **Promotion rules**_v2.4.0_ fieldconditionoutcome cart.totalover $100free shipping couponWELCOME1010% off member.tiergoldearly access stocklowskip promo ## Streamline Retail Decision-Making Retailers and marketplaces face complex challenges in managing pricing strategies, promotional campaigns, fee structures, and personalization at scale. Our business rules engine helps you automate critical retail decisions with precision, enabling your teams to respond quickly to market changes and customer expectations. ### Competitive Implement dynamic pricing strategies that respond to market conditions, competitor moves, and inventory levels to optimize margins and conversion. ### Optimized Manage complex discount structures and fee calculations that align with business objectives while maintaining profitability. ### Personalized Deliver tailored shopping experiences with customized offerings, preferred payment options, and relevant product recommendations. ## Addressing Retail Decision Challenges Retailers and marketplaces face unique challenges that generic automation solutions may not adequately address. Our business rules engine is designed to help with these industry-specific needs. ### Pricing Complexity Retail pricing involves numerous variables including seasonality, competition, and inventory levels. Our visual decision graphs make it easier to implement sophisticated dynamic pricing strategies with clear visualization of decision rules. ### Promotional Management Managing multiple overlapping promotions and discounts can be challenging. Our rules engine helps automate discount calculations and eligibility determinations while preventing unintended promotional stacking. ### Marketplace Fee Structures Marketplaces need to manage complex seller and shipping fee models that may vary by category, seller performance, and order characteristics. Our platform supports implementation of nuanced fee calculation logic. ### Personalization at Scale Creating relevant experiences for millions of shoppers requires automated decisioning. Our rules engine helps deliver tailored recommendations, offers, and payment options based on shopper data and context. ## Potential Benefits for Retail Organizations Implementing our rules engine can help deliver improvements across your retail operations. ### Enhanced Pricing Agility Quickly implement and adjust pricing strategies that respond to market conditions, competitor actions, and inventory positions without extensive development cycles. ### Improved Promotional Effectiveness Design and deploy sophisticated discount structures that drive desired customer behaviors while maintaining appropriate margin levels. ### Optimized Marketplace Economics Implement intelligent fee structures for sellers and shipping that balance marketplace growth with profitability and service quality. ### Higher Conversion Rates Create more compelling shopping experiences with personalized elements that resonate with individual customer preferences and behaviors. ### Reduced Operational Complexity Automate routine retail decisions to help simplify operations and ensure consistent application of business policies across channels. ### Empowered Business Users Enable merchandising, marketing, and marketplace teams to manage decision logic with reduced IT dependencies, using our intuitive interface. ## Explore other industries [View all industries](/industries) [**Telco** Automate telecom operations with the GoRules business rules engine. Optimize network management, streamline pricing, and simplify product config. ](/industries/telco)[**Public Sector** Automate government operations with the GoRules business rules engine. Improve eligibility determination, case management, and citizen services. ](/industries/public-sector)[**Financial** Automate banking and fintech decisions with the GoRules business rules engine. Improve compliance, streamline decisioning, and speed up onboarding. ](/industries/financial) ## Ready to automate retail decisions? Start free on GoRules Cloud, or talk to us about how retail teams run GoRules. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Government Rules Engine - GoRules **URL:** https://gorules.io/industries/public-sector **Description:** Automate government operations with the GoRules business rules engine. Improve eligibility determination, case management, and citizen services. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # A rules engine built for Public Sector. Transform government operations with a flexible decision automation platform that streamlines eligibility determinations, improves case management, and enhances citizen services while maintaining transparency and compliance. [Get started free](https://us1.gorules.io) [Explore templates](/industries/public-sector/templates) **Benefit eligibility**_v2.4.0_ fieldconditionoutcome household.incomeunder $32,000eligible residencyunder 6 monthsrequest proof dependents3 or morehigher band income.changereportedreassess ## Streamline Government Decision-Making Public sector organizations face unique challenges in delivering citizen services efficiently while ensuring compliance with complex regulations and policy requirements. Our business rules engine helps you automate critical government decisions with precision, enabling your teams to focus on high-value citizen interactions and complex cases. ### Transparent Implement decision logic with clear visualization and comprehensive audit trails that support accountability and help explain outcomes to citizens and stakeholders. ### Consistent Apply policy guidelines and regulatory requirements consistently across all cases and jurisdictions to help ensure equitable service delivery. ### Secure Deploy with offline licensing options in air-gapped, locked-down environments that meet the stringent security requirements of government and defense agencies. ## Addressing Public Sector Decision Challenges Government agencies face unique challenges that generic automation solutions may not adequately address. Our business rules engine is designed to help with these sector-specific needs. ### Complex Eligibility Determinations Government benefits and services often involve multi-faceted eligibility criteria based on numerous factors. Our visual decision graphs make it easier to implement sophisticated eligibility rules with clear visualization of decision logic. ### Case Management Prioritization Government agencies need to efficiently allocate limited resources across varying case priorities. Our platform supports implementation of nuanced case prioritization rules that balance workload, urgency, and service requirements. ### Cross-Agency Coordination Many government services require coordination across multiple agencies and systems. Our rules engine helps standardize decision processes across organizational boundaries while integrating with existing government systems. ### Security Requirements Government agencies often operate in environments with strict security protocols and limited connectivity. Our platform addresses these needs with offline licensing options for secure, air-gapped deployments that maintain operational integrity. ## Potential Benefits for Public Sector Organizations Implementing our rules engine can help deliver improvements across your government operations. ### Enhanced Service Delivery Accelerate eligibility determinations and service approvals to help reduce wait times for citizens while maintaining accuracy and compliance. ### Improved Operational Efficiency Automate routine decisions to help optimize resource allocation and allow staff to focus on complex cases requiring human judgment. ### Greater Consistency Help ensure consistent application of policies and regulations across all cases, jurisdictions, and service channels to support equitable treatment. ### Better Policy Implementation Translate policy directives into operational rules more quickly and accurately, helping to ensure that policy intent is reflected in service delivery. ### Enhanced Transparency Provide clear documentation of decision criteria and logic that can help explain outcomes to citizens, auditors, and oversight bodies. ### Empowered Agency Teams Enable program managers and policy specialists to manage decision logic with reduced IT dependencies, using our intuitive interface. ## Explore other industries [View all industries](/industries) [**Financial** Automate banking and fintech decisions with the GoRules business rules engine. Improve compliance, streamline decisioning, and speed up onboarding. ](/industries/financial)[**Aviation** Automate digital aviation experiences with the GoRules business rules engine. Improve personalization, booking flows, and ancillary offers. ](/industries/aviation)[**Insurance** Automate insurance operations with the GoRules business rules engine. Improve underwriting, streamline claims processing, and optimize pricing. ](/industries/insurance) ## Ready to automate public sector decisions? Start free on GoRules Cloud, or talk to us about how public sector teams run GoRules. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Logistics Rules Engine - GoRules **URL:** https://gorules.io/industries/logistics **Description:** Automate logistics operations with the GoRules business rules engine. Optimize routing, streamline warehouse work, and improve delivery management. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # A rules engine built for Logistics. Transform supply chain operations with a flexible decision automation platform that optimizes routing decisions, streamlines warehouse management, and enhances delivery efficiency while adapting to changing conditions. [Get started free](https://us1.gorules.io) [Explore templates](/industries/logistics/templates) **Carrier selection**_v2.4.0_ fieldconditionoutcome weightover 30 kgfreight destinationdomesticground slanext-dayexpress valueover $2,000insured carrier ## Streamline Logistics Decision-Making Logistics and supply chain organizations face complex challenges in optimizing transportation routes, managing warehouse operations, and ensuring on-time deliveries in a constantly changing environment. Our business rules engine helps you automate critical logistics decisions with precision, enabling your teams to respond quickly to disruptions and customer requirements. ### Optimized Implement intelligent routing and allocation rules that account for multiple constraints including time windows, vehicle capacity, and service requirements. ### Responsive Quickly adapt to disruptions with automated decision workflows that help reroute shipments and reallocate resources based on current conditions. ### Efficient Improve operational performance with rule-based decisions that help balance service levels, cost considerations, and resource utilization. ## Addressing Logistics Decision Challenges Logistics providers face unique challenges that generic automation solutions may not adequately address. Our business rules engine is designed to help with these industry-specific needs. ### Routing Complexity Transportation routing involves numerous variables including delivery windows, vehicle constraints, and traffic conditions. Our visual decision graphs make it easier to implement sophisticated routing logic with clear visualization of decision rules. ### Warehouse Management Optimizing storage allocation, picking routes, and labor assignments requires complex decision-making. Our rules engine helps automate warehouse decisions while adapting to changing inventory and order profiles. ### Last-Mile Delivery Managing final delivery execution with variable service requirements and delivery constraints requires flexible decisioning. Our platform supports implementation of nuanced delivery management rules that balance efficiency and service quality. ### Exception Handling Logistics operations regularly face disruptions requiring rapid decision adjustments. Our rules engine helps implement contingency logic and exception handling processes to maintain service continuity. ## Potential Benefits for Logistics Organizations Implementing our rules engine can help deliver improvements across your logistics operations. ### Enhanced Routing Efficiency Implement intelligent routing algorithms that help optimize vehicle utilization, reduce empty miles, and improve on-time delivery performance. ### Improved Warehouse Operations Automate storage allocation, picking sequence, and resource assignment decisions to help increase throughput and reduce operational costs. ### More Effective Last-Mile Delivery Optimize final delivery execution with rule-based decisions that account for service requirements, delivery constraints, and customer preferences. ### Better Disruption Management Respond more effectively to operational disruptions with automated exception handling and contingency rules that maintain service continuity. ### More Consistent Service Levels Help ensure consistent application of operational policies and service commitments across your logistics network through standardized decision logic. ### Empowered Operations Teams Enable transportation, warehouse, and delivery teams to manage decision logic with reduced IT dependencies, using our intuitive interface. ## Explore other industries [View all industries](/industries) [**Retail** Automate retail operations with the GoRules business rules engine. Optimize dynamic pricing, manage discounts, and streamline marketplace fees. ](/industries/retail)[**Telco** Automate telecom operations with the GoRules business rules engine. Optimize network management, streamline pricing, and simplify product config. ](/industries/telco)[**Public Sector** Automate government operations with the GoRules business rules engine. Improve eligibility determination, case management, and citizen services. ](/industries/public-sector) ## Ready to automate logistics decisions? Start free on GoRules Cloud, or talk to us about how logistics teams run GoRules. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Insurance Rules Engine - GoRules **URL:** https://gorules.io/industries/insurance **Description:** Automate insurance operations with the GoRules business rules engine. Improve underwriting, streamline claims processing, and optimize pricing. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # A rules engine built for Insurance. Transform insurance operations with a flexible decision automation platform that streamlines underwriting, accelerates claims processing, and enables dynamic pricing while maintaining compliance and improving customer experience. [Get started free](https://us1.gorules.io) [Explore templates](/industries/insurance/templates) **Claims triage**_v2.4.0_ fieldconditionoutcome claim.amountunder $1,000auto-approve damage.photosmissingrequest docs injuryreportedadjuster fraud.scoregreater than 0.8investigate ## Streamline Insurance Decision-Making Insurance organizations face complex challenges in balancing risk assessment, operational efficiency, and customer expectations. Our business rules engine helps you automate critical insurance decisions with precision, enabling your teams to focus on complex cases and customer relationships. ### Precise Implement sophisticated underwriting and pricing logic that accounts for multiple risk factors and policy variables through visual decision models. ### Responsive Accelerate claims processing and quote generation with automated decision workflows that handle routine cases efficiently. ### Adaptable Quickly update decision criteria to respond to market changes, emerging risks, or new product configurations without extensive IT involvement. ## Addressing Insurance Decision Challenges Insurance companies face unique challenges that generic automation solutions may not adequately address. Our business rules engine is designed to help with these industry-specific needs. ### Complex Risk Assessment Insurance underwriting involves numerous variables and conditional logic. Our visual decision graphs make it easier to implement sophisticated risk assessment models with clear visualization of decision rules. ### Claims Processing Efficiency Claims handling requires balancing speed, accuracy, and fraud prevention. Our rules engine helps automate routine claims decisions while flagging complex cases for expert review. ### Pricing Precision Insurance pricing must balance competitive positioning with profitability and risk. Our platform supports implementation of complex rating algorithms and dynamic pricing models. ### Product Complexity Insurance products involve numerous coverage options, eligibility rules, and endorsements. Our engine helps manage product configuration rules to ensure appropriate offerings for each customer segment. ## Potential Benefits for Insurance Organizations Implementing our rules engine can help deliver improvements across your insurance operations. ### Faster Underwriting Decisions Automate routine underwriting decisions to help reduce time-to-quote and time-to-bind while maintaining consistent risk assessment. ### Improved Claims Experience Accelerate claims processing with automated decision workflows that can help reduce cycle times and improve customer satisfaction. ### Optimized Pricing Implement sophisticated pricing algorithms with the ability to adjust quickly to market conditions and competitive landscape. ### Consistent Risk Assessment Help ensure that underwriting decisions follow established guidelines and risk appetite, potentially reducing variability across different underwriters. ### Enhanced Product Flexibility Manage complex product configuration rules to support rapid development and deployment of new insurance offerings. ### Empowered Business Users Enable underwriting, claims, and product teams to manage decision logic with reduced IT dependencies, using our intuitive interface. ## Explore other industries [View all industries](/industries) [**Healthcare** Automate clinical decision support with the GoRules business rules engine. Improve compliance, streamline workflows, and support patient care. ](/industries/healthcare)[**Logistics** Automate logistics operations with the GoRules business rules engine. Optimize routing, streamline warehouse work, and improve delivery management. ](/industries/logistics)[**Retail** Automate retail operations with the GoRules business rules engine. Optimize dynamic pricing, manage discounts, and streamline marketplace fees. ](/industries/retail) ## Ready to automate insurance decisions? Start free on GoRules Cloud, or talk to us about how insurance teams run GoRules. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Healthcare Rules Engine - GoRules **URL:** https://gorules.io/industries/healthcare **Description:** Automate clinical decision support with the GoRules business rules engine. Improve compliance, streamline workflows, and support patient care. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # A rules engine built for Healthcare. Transform patient care and operational efficiency with a flexible decision automation platform that supports regulatory compliance, reduces administrative complexity, and helps improve clinical workflows. [Get started free](https://us1.gorules.io) [Explore templates](/industries/healthcare/templates) **Prior authorization**_v2.4.0_ fieldconditionoutcome procedureMRI lumbarauto-approve plan.coverageexcludeddeny costover $5,000clinical review urgencyemergencyapprove ## Streamline Clinical Decision-Making Healthcare organizations face significant pressure to deliver high-quality care while managing costs and navigating complex regulatory requirements. Our business rules engine helps you automate clinical and administrative decisions with precision, allowing your staff to focus more on patient care. ### Efficient Reduce manual processing time and minimize error-prone repetitive tasks through intelligent workflow automation. ### Transparent Comprehensive audit trails and decision logs help support compliance efforts and provide visibility into automated processes. ### Adaptable Optimize revenue cycle management with more consistent processing that can help reduce denials and improve operational efficiency. ## Addressing Healthcare's Decision Challenges Healthcare organizations face unique challenges that generic automation solutions may not adequately address. Our business rules engine is designed to help with these industry-specific needs. ### Regulatory Considerations Healthcare operates in a highly regulated environment with various requirements that differ by region. Our rules engine provides audit trails and decision documentation to support your compliance efforts. ### Complexity of Clinical Decisions Medical decisions often involve numerous variables and conditional logic. Our visual decision graphs make it easier to map complex clinical pathways with clear visualization of decision logic. ### Integration with Existing Systems Many healthcare organizations rely on established IT systems that need to communicate effectively. Our rules engine offers a flexible REST API that can integrate with healthcare standards, helping to connect with your existing infrastructure. ### Evolving Guidelines Clinical best practices and payer requirements change over time. Our platform allows for updates to decision logic without coding, enabling adaptation to changing guidelines. ## Potential Benefits for Healthcare Organizations Implementing our rules engine can help deliver improvements across your organization. ### Streamlined Administrative Processes Automate routine decisions to help clinical and administrative staff reduce time spent on repetitive tasks, allowing them to focus on higher-value activities. ### Improved Decision Consistency Help ensure that decisions follow established protocols and best practices, potentially reducing variability in care delivery and administrative processes. ### Enhanced Decision Documentation Build decision flows with complete audit trails that document automated decisions for review and analysis. ### More Efficient Revenue Cycle Support more consistent application of payer requirements and coding rules to help improve billing processes. ### Support for Clinical Decisions Provide decision support with evidence-based guidelines that can help providers in their care delivery processes. ### Empowered Business Users Enable clinical and operational teams to manage decision logic with reduced IT dependencies, using our intuitive interface. ## Explore other industries [View all industries](/industries) [**Logistics** Automate logistics operations with the GoRules business rules engine. Optimize routing, streamline warehouse work, and improve delivery management. ](/industries/logistics)[**Retail** Automate retail operations with the GoRules business rules engine. Optimize dynamic pricing, manage discounts, and streamline marketplace fees. ](/industries/retail)[**Telco** Automate telecom operations with the GoRules business rules engine. Optimize network management, streamline pricing, and simplify product config. ](/industries/telco) ## Ready to automate healthcare decisions? Start free on GoRules Cloud, or talk to us about how healthcare teams run GoRules. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Financial Rules Engine - GoRules **URL:** https://gorules.io/industries/financial **Description:** Automate banking and fintech decisions with the GoRules business rules engine. Improve compliance, streamline decisioning, and speed up onboarding. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # A rules engine built for Financial Services. Transform banking operations and customer experiences with a flexible decision automation platform that supports regulatory compliance, streamlines approval processes, and helps manage risk effectively. [Get started free](https://us1.gorules.io) [Explore templates](/industries/financial/templates) **Credit policy**_v2.4.0_ fieldconditionoutcome credit.scoregreater than 740approve credit.score640 to 740manual review credit.scoreless than 640decline dtigreater than 0.45refer ## Streamline Financial Decision-Making Financial institutions face increasing pressure to deliver seamless customer experiences while managing risk and navigating complex regulatory requirements. Our business rules engine helps you automate critical banking decisions with precision, enabling your staff to focus more on value-added customer service. ### Efficient Reduce manual review time and minimize errors through automated decision workflows for loan approvals, onboarding, and transaction monitoring. ### Transparent Comprehensive audit trails and decision logs help support compliance efforts and provide visibility into automated processes. ### Adaptable Quickly update decision criteria to respond to market changes, new regulations, or evolving business strategies without extensive IT involvement. ## Addressing Financial Services' Decision Challenges Banks and fintech companies face unique challenges that generic automation solutions may not adequately address. Our business rules engine is designed to help with these industry-specific needs. ### Regulatory Compliance Financial services operate in a highly regulated environment with requirements that vary by jurisdiction. Our rules engine provides audit trails and decision documentation to support your compliance with KYC, AML, and other regulatory frameworks. ### Risk Management Financial decisions involve complex risk assessments with multiple variables. Our visual decision graphs make it easier to implement sophisticated risk models with clear visualization of decision logic. ### Integration with Core Systems Many financial institutions rely on established core banking platforms. Our rules engine offers a flexible REST API that can integrate with your existing infrastructure, including legacy systems. ### Need for Speed and Scale Modern banking requires real-time decisions at scale. Our high-performance engine is designed to handle large transaction volumes while maintaining response times suitable for customer-facing applications. ## Potential Benefits for Financial Institutions Implementing our rules engine can help deliver improvements across your organization. ### Accelerated Customer Journeys Automate routine decisions to reduce wait times for account opening, loan approvals, and other customer-facing processes. ### Improved Decision Consistency Help ensure that decisions follow established policies and risk guidelines, potentially reducing discrepancies across branches, channels, and products. ### Enhanced Fraud Detection Build sophisticated fraud detection rules that can adapt quickly to emerging threats and suspicious patterns. ### Operational Efficiency Reduce manual reviews and exception handling through clear, automated decision paths that handle routine cases while flagging only true exceptions for human review. ### Agile Product Development Launch new financial products faster by quickly implementing the associated decision logic without extensive coding requirements. ### Empowered Business Users Enable risk, compliance, and product teams to manage decision logic with reduced IT dependencies, using our intuitive interface. ## Explore other industries [View all industries](/industries) [**Aviation** Automate digital aviation experiences with the GoRules business rules engine. Improve personalization, booking flows, and ancillary offers. ](/industries/aviation)[**Insurance** Automate insurance operations with the GoRules business rules engine. Improve underwriting, streamline claims processing, and optimize pricing. ](/industries/insurance)[**Healthcare** Automate clinical decision support with the GoRules business rules engine. Improve compliance, streamline workflows, and support patient care. ](/industries/healthcare) ## Ready to automate financial decisions? Start free on GoRules Cloud, or talk to us about how financial teams run GoRules. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Aviation Rules Engine - GoRules **URL:** https://gorules.io/industries/aviation **Description:** Automate digital aviation experiences with the GoRules business rules engine. Improve personalization, booking flows, and ancillary offers. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # A rules engine built for Aviation. Transform passenger journeys and digital interactions with a flexible decision automation platform that supports personalized experiences, streamlines booking processes, and helps optimize revenue opportunities. [Get started free](https://us1.gorules.io) [Explore templates](/industries/aviation/templates) **Crew legality**_v2.4.0_ fieldconditionoutcome duty.hoursover 13swap crew rest.hoursunder 10delay assignment certificationexpiredground weather.divertlikelyadd fuel ## Elevate Digital Aviation Experiences Aviation organizations face unique challenges in balancing digital transformation, customer expectations, and evolving business models. Our business rules engine helps you automate digital decisions with precision, enabling your teams to create more personalized and efficient customer journeys. ### Personalized Tailor digital experiences based on customer segments, loyalty status, and past behavior through data-driven decision rules. ### Revenue-Optimized Customize fee structures, ancillary offerings, and pricing based on multiple factors including route, demand, and customer profile. ### Adaptable Quickly update digital experiences and offerings to respond to market changes, seasonal demands, or competitive pressures without extensive IT involvement. ## Addressing Aviation's Digital Decision Challenges Airlines and aviation organizations face unique digital challenges that generic automation solutions may not adequately address. Our business rules engine is designed to help with these industry-specific needs. ### Complex Pricing and Offers Aviation pricing involves numerous variables including seasonality, fare classes, and passenger characteristics. Our visual decision graphs make it easier to implement sophisticated pricing and offer strategies with clear visualization of decision logic. ### Personalization at Scale Creating relevant experiences for millions of travelers requires automated decisioning. Our rules engine helps deliver tailored messaging, offers, and content based on customer data and context. ### Integration with Digital Platforms Many aviation organizations operate across multiple digital channels and systems. Our rules engine offers a flexible REST API that can integrate with your existing digital infrastructure, including booking engines and mobile apps. ### Rapid Market Changes The digital aviation landscape requires quick adaptation to market conditions. Our engine helps you modify digital experiences, offers, and messaging without lengthy development cycles. ## Potential Benefits for Aviation Digital Experiences Implementing our rules engine can help deliver improvements across your digital touchpoints. ### Enhanced Digital Experiences Automate personalization decisions to help deliver more relevant content, offers, and interactions throughout the customer journey. ### Dynamic Fee Structures Implement flexible fee rules that can adjust based on route, timing, customer value, and other variables to optimize revenue opportunities. ### Improved Conversion Rates Create more compelling booking flows with personalized upsell and cross-sell opportunities based on customer preferences and behavior. ### Digital Channel Consistency Support consistent application of business rules across web, mobile, and third-party channels through centralized decision management. ### Agile Marketing Capabilities Enable quick deployment of promotional offers, targeted campaigns, and seasonal pricing adjustments through rule-based automation. ### Empowered Digital Teams Enable marketing, revenue management, and digital product teams to manage decision logic with reduced IT dependencies, using our intuitive interface. ## Explore other industries [View all industries](/industries) [**Insurance** Automate insurance operations with the GoRules business rules engine. Improve underwriting, streamline claims processing, and optimize pricing. ](/industries/insurance)[**Healthcare** Automate clinical decision support with the GoRules business rules engine. Improve compliance, streamline workflows, and support patient care. ](/industries/healthcare)[**Logistics** Automate logistics operations with the GoRules business rules engine. Optimize routing, streamline warehouse work, and improve delivery management. ](/industries/logistics) ## Ready to automate aviation decisions? Start free on GoRules Cloud, or talk to us about how aviation teams run GoRules. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Dynamic Flow Control with Switch Node - GoRules **URL:** https://gorules.io/components/switch **Description:** Create advanced decision flows with conditional branching. The Switch node routes business logic dynamically using conditions and expressions. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Route every case down the right path. The switch node branches your graph on ZEN expressions - first match or collect, with the full data context carried through every path. **Application****Route****Approve****Manual review****Decline**score > 700score >= 640otherwise ## Branching that stays on the canvas. Routing lives in the graph where everyone can see it - not in nested ifs three files deep. Conditions read like rules, and the simulator shows which branch fired. - First match or collect hit policies - Conditions in ZEN expressions - Context preserved across branches - Active paths highlighted in the simulator [Read the decision graph docs](https://docs.gorules.io/learn/authoring/decision-graphs) ## Intelligent routing, readable rules. Choose how branches evaluate, write conditions the business can verify, and trust that data survives the split. ### First match, or every match. First match takes the highest-priority branch; collect evaluates them all and follows each that applies. **Routing**First matchCollect score > 700_fast track_ amount <= 50000_auto limit_ _otherwise__manual review_ First match takes one branch - collect follows every branch that matches. ### Conditions that read like rules. Branch on scores, countries, product codes - any ZEN expression over your data decides where the flow goes next. [Explore ZEN syntax](https://docs.gorules.io/learn/zen-language/syntax) Branch conditionsscore > 700 and amount <= 50000customer.country in \["DE", "AT", "CH"\]startsWith(product.sku, "INS-")The full ZEN expression language is available on every branch. ### Nothing gets lost on the way. The switch routes the whole payload - every branch receives the same context that came in, so downstream tables and expressions keep working with full data. `{ score: 720, amount: 40000 }`**Route**`{ score: 720, amount: 40000 }` ## One of four building blocks. Switches decide where the flow goes - decision tables, expressions, and functions decide what happens when it gets there. [**Decision table** Spreadsheet-familiar rules with typed inputs and outputs. ](/components/decision-table)[**Expression** Map and transform data with readable expressions. ](/components/expression)[**Function** Drop to JavaScript when a rule needs custom logic. ](/components/function)[**Graph editor** Wire the blocks together on one visual canvas. ](/editor) [See all components](/components) [Manage graphs in the BRMS](/brms) ## One graph, every path covered. Sketch your routing on the canvas and watch the right branch fire - free on GoRules Cloud. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## JavaScript Functions for Advanced Business Logic - GoRules **URL:** https://gorules.io/components/function **Description:** Write custom JavaScript for complex data processing and integrations. A full JavaScript environment with modern features and built-in modules. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # When rules need code, drop into JavaScript. A full JavaScript runtime inside your decision graph - async/await, built-in modules, and console debugging for the logic that expressions can't express. **handler.js**_function_2.1 ms _import_ dayjs _from_ 'dayjs'; _export const_ handler = _async_ (input) => { _const_ age = dayjs().diff(input.birthDate, 'year'); _const_ dti = input.debt / input.income; console.log({ age, dti }); _return_ { ...input, age, dti };}; \> { age: 34, dti: 0.31 } completed · 2.1 ms ## The escape hatch, without the escape. Custom parsing, third-party calls, odd date math - write it in modern JavaScript and it stays versioned, tested, and reviewed like every other block. - Modern ES modules and async/await - dayjs, big.js, zod, and http built in - console.log debugging in the simulator - Execution metrics on every run dayjsbig.jszodhttp [Read the function node docs](https://docs.gorules.io/learn/authoring/function-nodes) ## Developer tools, where the rules live. Call out to services, validate with zod, and debug in real time - inside the graph instead of beside it. ### Call out when you need to. Fetch from internal services with the built-in http module and merge the response into the decision - all with async/await. _const_ res = _await_ http.get( 'internal/credit-bureau', { id: input.customerId },);_return_ { ...input, bureau: res.data }; 200 · 41 ms ### Debug like DevTools. console.log streams into the simulator as the graph executes - inspect values mid-decision, not after it. Console\> { step: 'normalize', ok: true }\> { age: 34, dti: 0.31 }\> { decision: 'refer', reason: 'dti' }Logs stream straight into the simulator while the decision runs. ## One of four building blocks. Functions cover the edge cases - decision tables and expressions carry the readable majority, and switches route between them. [**Decision table** Spreadsheet-familiar rules with typed inputs and outputs. ](/components/decision-table)[**Expression** Map and transform data with readable expressions. ](/components/expression)[**Switch** Route the flow down different paths by condition. ](/components/switch)[**Graph editor** Wire the blocks together on one visual canvas. ](/editor) [See all components](/components) [Manage functions in the BRMS](/brms) ## Keep the custom code, lose the deploys. Move one gnarly function into GoRules and change it without a release train - versioned, tested, and reviewed. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Powerful Expressions for Business Rules - GoRules **URL:** https://gorules.io/components/expression **Description:** Turn complex calculations and data mapping into simple expressions. Powerful syntax for any business scenario, for analysts and developers alike. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Shape data with expressions anyone can read. Map, transform, and calculate with the ZEN expression language - one field per row, readable by analysts, exact enough for the engine. **Pricing**_expression_ZEN language fieldexpression subtotalsum(map(items, #.price \* #.qty)) discountcustomer.tier == "vip" ? 0.1 : 0 shippingweight > 20 ? 15 : 5 total_$.subtotal_ \* (1 - _$.discount_) + _$.shipping_ tax**_$.total_ \* 0.2** ## Write it the way you'd say it. If you know Excel formulas, you already know most of the syntax. Dates, strings, arrays, and math are built in - no code review needed for a price change. - Familiar Excel-like syntax - Built-in date, string, and array functions - Results shown live as you type - Type validation on every field [Read the expression docs](https://docs.gorules.io/learn/authoring/expressions) ## Complex logic, simple steps. Break a calculation into readable rows, build on earlier results with $, and let assistance keep every field correct. ### Chain steps with $. Split a calculation into logical steps and reference any previous result - each row builds on the last, and the whole flow stays readable. base item.price \* item.qty discounted_$.base_ \* (1 - customer.discount) total_$.discounted_ \+ $.shipping Each row can reference the results above it with $. ### Assistance built in. Autocomplete suggests fields and functions from your data model; validation catches errors before they run. total · expression _$.discounted + ro_ round(number, precision) _fn_floor(number) _fn_round.mode _field_ Autocomplete suggests fields and functions from your data - validation runs as you type. ### From input to output, in one node. An expression node maps whatever comes in to exactly what the next block needs - reshape objects, compute totals, format fields. [Explore the ZEN language](https://docs.gorules.io/learn/zen-language/syntax) `{ "items": 3, "weight": 24 }`**Pricing**`{ "total": 118.50 }` ## One of four building blocks. Expressions prepare the data - decision tables judge it, switches route it, and functions cover whatever is left. [**Decision table** Spreadsheet-familiar rules with typed inputs and outputs. ](/components/decision-table)[**Function** Drop to JavaScript when a rule needs custom logic. ](/components/function)[**Switch** Route the flow down different paths by condition. ](/components/switch)[**Graph editor** Wire the blocks together on one visual canvas. ](/editor) [See all components](/components) [Manage expressions in the BRMS](/brms) ## Turn formulas into governed logic. Bring one calculation - pricing, fees, scoring - and see it run as a versioned expression in minutes. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Decision Tables for Business Rules **URL:** https://gorules.io/components/decision-table **Description:** Transform complex business logic into intuitive decision tables. Built for business analysts, backed by enterprise features - manage rules with simplicity. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Decision tables that read like a spreadsheet. Conditions, outcomes, and hit policies in a familiar grid - readable by the business, executed by the engine, with Excel import and export built in. **Credit Policy**_decision-table_First match InputsOutputs credit.score _number_loan.amount _number_decision _string_ _greater than_ 740_up to_ $50,000approve · tier A _between_ 640 _and_ 700_any_manual review _less than_ 640_any_decline **_between_ 700 _and_ 740**_any_approve · tier B ## If you can use Excel, you can use this. Import existing spreadsheets, edit with copy, paste, and drag to fill, and export back whenever you need to. No new tool for the people who own the rules. - Import and export Excel files - Copy, paste, and drag to fill - Typed input and output columns - Loop tables over whole arrays [Read the decision table docs](https://docs.gorules.io/learn/authoring/decision-tables) ## Built for real rulework. Autocomplete, validation, and a built-in simulator keep tables correct while they grow - from three rows to three thousand. ### Every cell checked as you type. Autocomplete suggests fields, operators, and values from your data model, and real-time validation catches errors before they can ship. credit.score · row 4 _between 700 and 74_ 740 _number_745 _number_creditLimit _field_ Suggestions come from your data model - validation flags bad syntax as you type. ### Hit policies decide what wins. First match for prioritized rules, collect to gather every matching row - you choose how the table evaluates. **Cart promotions**First matchCollect customer.tier _is_ vip_10% off_ cart.total _over_ $100_free shipping_ _otherwise__no promotion_ First match stops at the first hit - collect gathers every matching row. ### Test while you build. Run scenarios in the built-in simulator and see exactly which row matched. Debug edge cases before they ever reach production. [Explore testing](https://docs.gorules.io/learn/authoring/testing) _S_ Simulator_Run all_ Score 780 · $30,000 loan_row 1 · approve · tier A_ Score 660 · any amount_row 2 · manual review_ Score 610 · thin file_row 3 · decline_ Boundary case at $50,000_row 1 · approve · tier A_ ## One of four building blocks. Tables rarely work alone - expressions shape data on the way in, switches route the outcome on the way out, all on one canvas. [**Expression** Map and transform data with readable expressions. ](/components/expression)[**Function** Drop to JavaScript when a rule needs custom logic. ](/components/function)[**Switch** Route the flow down different paths by condition. ](/components/switch)[**Graph editor** Wire the blocks together on one visual canvas. ](/editor) [See all components](/components) [Manage tables in the BRMS](/brms) ## Put your first policy in a table. Import a spreadsheet or start from scratch - your first decision table runs in minutes on GoRules Cloud. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## GoRules vs Drools | Best Drools Alternative 2026 **URL:** https://gorules.io/compare/gorules-vs-drools **Description:** Compare GoRules and Drools business rules engines. See differences in performance, ease of use, language support, deployment options, and scalability. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch ![](/emblem.svg) Rules Engine Comparison # GoRules vs Drools A detailed comparison of two business rules engines. See how GoRules' modern, polyglot approach compares to Drools' Java-based BRMS for your decision automation needs. [Try GoRules Free](https://us1.gorules.io)[View Documentation](https://docs.gorules.io) **Quick Summary** **GoRules** is a lightweight, polyglot rules engine built for modern architectures-fast cold starts, horizontal scaling, and native SDKs for Node.js, Python, Go, Rust, Java, and Swift. **Drools** is a mature Java-based BRMS with powerful inference capabilities but heavier JVM overhead and steeper learning curve. GoRules is a strong Drools alternative for teams building cloud-native apps who need rapid iteration; choose Drools for complex Java-centric enterprises needing forward/backward chaining. ## Quick Comparison Here's a side-by-side overview of how GoRules and Drools compare across key dimensions that matter for business rules management. FeatureGoRulesDrools ArchitectureLightweight, embeddableJVM-based, modular Primary LanguageRust core with polyglot SDKsJava Rule FormatJDM (JSON Decision Model)DRL, DMN (XML), Spreadsheets Cold Start TimeMillisecondsSeconds to minutes Rule Hot-ReloadNative, real-timeComplex, often requires restart Visual EditorModern graph-based UIBusiness Central (Guvnor) Inference EngineDeterministic (no chaining)Forward & backward chaining ScalabilityHorizontal (stateless)Vertical (stateful sessions) Serverless ReadyExcellentChallenging (JVM overhead) Learning CurveLowSteep Open SourceMIT LicenseApache 2.0 ## Ease of Use The accessibility of a rules engine determines how quickly your team can adopt it and how effectively business users can participate in rule management. This is often the deciding factor between successful adoption and shelfware. _![](/emblem-white.svg)_ ### GoRules - Visual graph editor - drag and drop decision flows - Spreadsheet-style decision tables for business users - No coding required for most rule authoring - Instant preview and testing in the browser - JSON-based format - easy to read and version control - Built-in simulation and batch testing ### Drools - Business Central web interface for rule management - DMN decision tables with standard notation - DRL syntax requires learning curve - XML-based DMN can be verbose - Full power requires Java knowledge - Complex setup for new projects **GoRules** is designed for collaboration between technical and non-technical users. Business analysts can create and modify decision tables directly, while developers handle integration. The visual graph editor makes complex decision flows easy to understand and maintain. **Drools** is powerful but demands more technical expertise. While Business Central provides a web interface, effective use of Drools typically requires understanding DRL syntax, Java concepts, and the Rete algorithm. This makes it better suited for technical teams. ## Language Support The languages you can use with a rules engine determines how well it fits into your existing tech stack and whether your team can adopt it without major changes. _![](/emblem-white.svg)_ ### GoRules Native SDKs [Node.js](/open-source/javascript-rules-engine)[Python](/open-source/python-rules-engine)[Go](/open-source/go-rules-engine)[Rust](/open-source/rust-rules-engine)[Java](/open-source/java-rules-engine)[Kotlin](/open-source/kotlin-rules-engine)[Swift](/open-source/swift-rules-engine)WebAssemblyPySpark ### Drools Language Support JavaKotlinScalaGroovyREST API **GoRules** provides first-class native SDKs for multiple languages, each optimized for that ecosystem. The Rust core compiles to native binaries and WebAssembly, enabling deployment anywhere from serverless functions to iOS/Android mobile apps to big data pipelines with PySpark and AWS Glue. **Drools** is fundamentally Java-based. While you can use it with other JVM languages like Kotlin or Scala, non-JVM languages must interact via REST APIs, adding latency and complexity. This makes Drools an excellent choice for Java shops but limiting for polyglot environments. ## Performance Characteristics Performance in rules engines isn't just about raw execution speed-it's about startup time, memory usage, scalability, and how well the engine handles dynamic rule changes in production. ### GoRules Performance **Cold Start****<50ms**_Instant serverless deployment_ **Execution Speed****Sub-ms**_Optional compilation for hot paths_ **Rule Hot-Reload****Real-time**_No restart, no downtime_ ### Drools Performance **Cold Start****Seconds-Minutes**_JVM + rule compilation overhead_ **Execution Speed****Sub-ms**_Optimized Rete algorithm_ **Memory Footprint****Hundreds of MB**_JVM + working memory_ ### The Real Difference: Startup Time In execution benchmarks, **GoRules and Drools perform comparably** for most rule sets. GoRules also supports optional ahead-of-time compilation for performance-critical scenarios. The actual execution speed depends heavily on rule complexity and structure. Zen Engine benchmarks are public and continuously updated, so you can verify the numbers yourself. [See the public Zen Engine benchmarks](https://gorules.github.io/zen/bench) Where GoRules dramatically outperforms Drools is **startup time**. GoRules starts in milliseconds while Drools can take seconds to minutes as the JVM initializes and rules compile. This makes GoRules ideal for serverless, auto-scaling, and microservices where instances spin up and down frequently. Drools' Rete algorithm excels at scenarios requiring forward chaining and complex pattern matching across large fact bases-capabilities GoRules intentionally doesn't include in favor of deterministic, explainable decisions. ## Deployment & Scaling How you deploy and scale your rules engine matters as much as its features. Modern architectures demand flexibility in deployment models and the ability to scale with demand. ### Cold Start: First 60 Seconds What happens when a new instance spins up _![](/emblem-white.svg)_GoRules _Ready ~50ms_ Drools _Still initializing..._ 0s15s30s45s60s+ **Time to First Request** ~50ms vs 30-120s **Memory at Startup** ~50MB vs 500MB+ **Serverless Ready** Excellent vs Challenging ### Auto-Scaling: Traffic Spike Response Time to handle 10x traffic increase _![](/emblem-white.svg)_GoRules (Horizontal) _10 instances ~2s_ Drools (Vertical) _Scaling up..._ 0s30s1m2m3m+ **Scale Model** Horizontal vs Vertical **New Instance Ready** <1 second vs Minutes **Cost Model** Pay per use vs Always on ### Deployment Options - **GoRules:** Docker, Kubernetes (Helm charts), AWS ECS/Fargate, Azure Container Apps, serverless functions (Lambda, Cloud Functions), embedded SDK, WebAssembly in browser - **Drools:** Traditional Java deployments, Docker with JVM, Kubernetes via Kogito, Red Hat OpenShift, KIE Server for centralized execution ### Scaling Philosophy **GoRules** is stateless by design, making horizontal scaling trivial. Add more instances behind a load balancer and they immediately start processing requests. This aligns perfectly with Kubernetes auto-scaling and serverless architectures. **Drools** often uses stateful sessions (working memory) which complicates horizontal scaling. While stateless sessions are possible, many Drools patterns rely on state accumulation. This typically leads to vertical scaling (bigger servers) rather than horizontal scaling (more servers). ### Integration Example See how rule execution looks in code for both engines: GoRules (Node.js) ``` import { ZenEngine } from '@gorules/zen-engine'; // Load rules - can be from file, API, or database const engine = new ZenEngine(); const decision = engine.createDecision( await readFile('pricing.json') ); // Execute - hot reload supported const result = await decision.evaluate({ customer: { tier: "gold", years: 5 }, order: { total: 1500 } }); ``` Drools (Java) ``` // Build KIE container (slow startup) KieServices ks = KieServices.Factory.get(); KieContainer kc = ks.getKieClasspathContainer(); KieSession session = kc.newKieSession(); // Insert facts Customer customer = new Customer("gold", 5); Order order = new Order(1500); session.insert(customer); session.insert(order); // Fire rules session.fireAllRules(); session.dispose(); ``` ## When to Use Each Both engines excel in different scenarios. Here's guidance on choosing the right tool for your specific needs. _![](/emblem-white.svg)_ ### Choose GoRules When - You're building microservices or serverless applications - Your stack includes Node.js, Python, Go, or Rust - Business users need to manage rules without IT - You need fast cold starts and horizontal scaling - Rules change frequently and need instant deployment - You want deterministic, explainable decisions - Big data processing with PySpark or AWS Glue ### Choose Drools When - You're in a Java-centric enterprise environment - You need complex event processing (CEP) - Forward/backward chaining inference is required - DMN standard compliance is mandatory - You have existing Red Hat/JBoss infrastructure - Complex pattern matching across many facts - You need the full Rete algorithm capabilities ### The Bottom Line **GoRules** is the better choice for most modern applications. Its lightweight architecture, polyglot support, and focus on developer experience make it ideal for teams building cloud-native applications who want to iterate quickly. The visual editor empowers business users while the native SDKs keep developers happy. **Drools** remains a solid choice for Java enterprises with complex inference requirements. If you need the full power of the Rete algorithm, complex event processing, or have existing investment in Red Hat ecosystem, Drools delivers. Just be prepared for the operational overhead and learning curve. ## Frequently Asked Questions Is GoRules a Drools alternative? Yes, GoRules is a modern alternative to Drools for business rules management. While Drools is a mature Java-based BRMS, GoRules offers a more lightweight, polyglot approach with native SDKs for Node.js, Python, Go, Rust, and Java. GoRules is particularly suited for teams that want faster deployment cycles, horizontal scalability, and a more intuitive visual editor for non-technical users. Can I migrate from Drools to GoRules? Yes, migration from Drools to GoRules is possible. While Drools uses DRL (Drools Rule Language) and DMN XML files, GoRules uses JDM (JSON Decision Model) format. The rule logic can be recreated using GoRules visual decision tables and expression editor. For complex migrations, GoRules offers professional services to assist with the transition. Which is faster: GoRules or Drools? For rule execution, they perform comparably-both achieve sub-millisecond evaluation for most rule sets. GoRules also supports optional compilation for performance-critical paths. The major difference is startup time: GoRules starts in milliseconds while Drools can take seconds to minutes due to JVM initialization and rule compilation. This makes GoRules significantly better for serverless, auto-scaling, and microservices architectures. Does GoRules support DMN like Drools? GoRules uses its own JDM (JSON Decision Model) format instead of DMN. While DMN is a standard, JDM offers advantages like human-readable JSON format, easier version control with Git, and faster parsing. GoRules decision tables provide similar functionality to DMN decision tables with a more intuitive interface. Can non-developers use GoRules vs Drools? GoRules has a significant advantage here. Its visual graph editor and decision tables are designed for business users with no coding experience. Drools, while powerful, typically requires familiarity with DRL syntax or technical knowledge to work with DMN effectively. GoRules enables true collaboration between business and technical teams. What about Drools Kogito vs GoRules? Kogito is Red Hat's cloud-native business automation platform built on Drools and jBPM. While Kogito brings Drools to Kubernetes, it still carries the JVM overhead and complexity. GoRules was built cloud-native from the start with sub-millisecond cold starts, native multi-language support, and simpler deployment without JVM dependencies. ## Ready to try a modern rules engine? Start building with GoRules in minutes. Visual editor, native SDKs for 7+ languages, and cloud-native deployment. [Start for Free](https://us1.gorules.io) [Book a Demo](/contact-us) --- ## Serverless Rules Engine for AWS, Azure & GCP **URL:** https://gorules.io/cloud-native/serverless **Description:** Enterprise serverless deployment with GoRules Lambda layers for AWS Lambda, Azure Functions, and Google Cloud Functions, with native performance. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Run your rules serverless. Enterprise Lambda layers put the native Rust engine inside AWS Lambda, Azure Functions, and Google Cloud Functions - no containers, no cold-start penalty on your logic. [Contact sales](mailto:sales@gorules.io) [Open-source SDKs](/open-source) **Serverless** engine ready **GoRules Layer**_Native Rust engine_ runs on **Lambda / Functions runtime**_Node.js_ _Releases deploy to_ **Development**_Cloud storage → Lambda / SDK_ **Staging**_Cloud storage → Lambda / SDK_ **Production**_Cloud storage → Lambda / SDK_ [About the Agent](/agent) [About the SDKs](/open-source) ## Lambda layers, enterprise-grade. Pre-built layers ship the GoRules engine compiled for each runtime - native Rust speed inside your functions. An enterprise feature: talk to our team to scope your deployment and get access. [Contact us for access](mailto:sales@gorules.io) - Pre-compiled Lambda layers - Native Rust performance - Node.js runtime support - Deployment guidance - Enterprise support included ## Every major serverless platform. The same engine, packaged for the function runtime you already run. ### AWS Lambda Native layers with Rust bindings for the Node.js runtime. - Node.js 18+ runtime - ARM64 (Graviton) and x86\_64 - Cold start optimized ### Azure Functions Custom handlers and extensions with native performance. - Node.js runtime - Custom handlers - Premium and Consumption plans ### Cloud Functions Native SDK integration on Google Cloud Functions. - Node.js runtime - Gen 2 · Cloud Run compatible - Automatic scaling [**Big Data & PySpark** Batch millions of evaluations with distributed processing on Databricks, EMR, or Dataproc. ](/big-data) ## Serverless rules, native speed. Talk to our team about enterprise Lambda layers and your serverless architecture. [Contact sales](mailto:sales@gorules.io) [View open-source SDKs](/open-source) --- ## Kubernetes Rules Engine - Deploy BRMS with Helm **URL:** https://gorules.io/cloud-native/kubernetes **Description:** Deploy GoRules BRMS on Kubernetes with our Helm chart. Cloud-agnostic for EKS, AKS, GKE, or any distribution, with PostgreSQL and horizontal scaling. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Deploy the BRMS on Kubernetes. One production-ready Helm chart for any cluster - EKS, AKS, GKE, or your own. Cloud-agnostic, portable, and built for enterprise scale. [Get started](https://us1.gorules.io) [Helm chart docs](https://docs.gorules.io/developers/platform-guides/kubernetes) **Kubernetes** live $**helm install gorules**✓ release deployed · pods 3/3 Running **GoRules BRMS**_Helm deployment_ **PostgreSQL**_managed service_ _Releases deploy to_ **Development**_Storage → Agent / SDK_ **Staging**_Storage → Agent / SDK_ **Production**_Storage → Agent / SDK_ [About the Agent](/agent) [About the SDKs](/open-source) ## One chart, any cluster. The Helm chart ships deployment, service, ingress, and autoscaling with production defaults - override anything in values.yaml. ### Helm chart A single command installs the complete stack with sensible defaults, and rolling updates keep upgrades at zero downtime. - One-command install - Customizable via values.yaml - Zero-downtime rolling upgrades [Helm chart documentation](https://docs.gorules.io/developers/platform-guides/kubernetes) ### Autoscaling The BRMS is stateless, so replicas scale horizontally without coordination - from one pod at night to hundreds at peak. - HPA on CPU and memory - Custom metrics like request rate - KEDA for event-driven scaling [Scaling guide](https://docs.gorules.io/developers/platform-guides/kubernetes) ### Ingress & TLS Expose the platform through NGINX, Traefik, or cloud load balancers - with cert-manager TLS and service mesh support built in. - Pre-configured ingress templates - Automatic certificates with cert-manager - Istio and Linkerd ready [Networking guide](https://docs.gorules.io/developers/platform-guides/kubernetes) ### Bring your own PostgreSQL. The BRMS keeps users, projects, rule versions, and audit history in PostgreSQL. Point the chart at any managed database and connect with IAM auth, Workload Identity, or managed identities. - Aurora and RDS on AWS - Cloud SQL on Google Cloud - Azure Flexible Server with zone redundancy [Database configuration](https://docs.gorules.io/developers/platform-guides/kubernetes) **GoRules BRMS**_Helm deployment_ **Managed PostgreSQL**_Aurora · Cloud SQL · Azure_ ## Kubernetes-native by default. Built for cloud-native operations and GitOps workflows from the first install. [ ### Prometheus metrics A /metrics endpoint ready for scraping, with pre-built Grafana dashboards. Learn more](https://docs.gorules.io/developers/platform-guides/kubernetes)[ ### Health probes Liveness, readiness, and startup probes for clean pod lifecycles. Learn more](https://docs.gorules.io/developers/platform-guides/kubernetes)[ ### GitOps ready Deploy with ArgoCD or Flux and keep Helm values declarative in Git. Learn more](https://docs.gorules.io/developers/platform-guides/kubernetes) ## One Helm install from production. Run the BRMS on any Kubernetes cluster with the official chart - or start free on GoRules Cloud while you evaluate. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Google Cloud Rules Engine - Self-Hosted BRMS **URL:** https://gorules.io/cloud-native/google-cloud **Description:** Deploy GoRules BRMS on Google Cloud using Cloud Run or GKE with Cloud SQL PostgreSQL. Self-hosted business rules platform with Cloud Monitoring integration. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Deploy the BRMS on Google Cloud. One Docker image on Cloud Run or GKE, Cloud SQL PostgreSQL behind it - the full business rules platform inside your own GCP project. [Get started](https://us1.gorules.io) [Deployment guide](https://docs.gorules.io/developers/deployment/brms/deployment) **Google Cloud** live $docker pull gorules/brms$**gcloud run deploy gorules-brms**✓ service deployed · serving traffic **GoRules BRMS**_Cloud Run / GKE_ **Cloud SQL**_PostgreSQL_ _Releases deploy to_ **Development**_Cloud Storage → Agent / SDK_ **Staging**_Cloud Storage → Agent / SDK_ **Production**_Cloud Storage → Agent / SDK_ [About the Agent](/agent) [About the SDKs](/open-source) ## Two ways in. Both production-ready. The official Docker image runs the same on Cloud Run and GKE - pick managed simplicity or full Kubernetes control. ### Cloud Run The fastest way onto GCP: deploy the container with automatic scaling, built-in HTTPS, and pay-per-request pricing - no infrastructure to manage. - Scale to zero between requests - TLS certificates managed by Google - Traffic splitting for gradual rollouts [Cloud Run guide](https://docs.gorules.io/developers/deployment/brms/deployment) ### Google Kubernetes Engine For enterprise Kubernetes, deploy with the same Helm chart you would use anywhere - with Autopilot nodes, Workload Identity, and global load balancing. - GKE Autopilot - fully managed nodes - Workload Identity for Cloud SQL access - Multi-region Cloud Load Balancing [Kubernetes guide](/cloud-native/kubernetes) ### Backed by Cloud SQL. The BRMS keeps users, projects, rule versions, and audit history in PostgreSQL. Cloud SQL gives it a managed home with automatic failover and point-in-time recovery. - Automated backups, patching, and maintenance - Regional HA with automatic failover - Encryption at rest and in transit by default [Database configuration](https://docs.gorules.io/developers/deployment/brms/deployment) **GoRules BRMS**_Docker container_ **Cloud SQL PostgreSQL**_users · projects · versions · audit_ ## Wired into the rest of GCP. The BRMS plugs into the Google Cloud services you already run - monitoring, secrets, and private networking included. [ ### Cloud Monitoring & Logging Built-in metrics and structured logs with advanced querying. Learn more](https://docs.gorules.io/developers/deployment/brms/deployment)[ ### Secret Manager & IAM Secrets in Secret Manager, fine-grained access with IAM and Workload Identity. Learn more](https://docs.gorules.io/developers/deployment/brms/deployment)[ ### VPC & Private Service Connect Deploy in private VPC networks and reach GCP services privately. Learn more](https://docs.gorules.io/developers/deployment/brms/deployment) ## Run your rules on Google Cloud. Run the BRMS on Cloud Run or GKE with Cloud SQL - or start free on GoRules Cloud while you evaluate. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Azure Rules Engine - Self-Hosted BRMS on Azure **URL:** https://gorules.io/cloud-native/azure **Description:** Deploy GoRules BRMS on Azure using Container Apps or AKS with Azure Database for PostgreSQL. Self-hosted business rules platform with Azure Monitor integration. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Deploy the BRMS on Azure. One Docker image on Container Apps or AKS, Azure Database for PostgreSQL behind it - the full business rules platform inside your own Azure subscription. [Get started](https://us1.gorules.io) [Deployment guide](https://docs.gorules.io/developers/platform-guides/azure-container-apps) **Microsoft Azure** live $docker pull gorules/brms$**az containerapp update --name gorules-brms**✓ revision provisioned · traffic at 100% **GoRules BRMS**_Container Apps / AKS_ **Azure PostgreSQL**_Flexible Server_ _Releases deploy to_ **Development**_Blob Storage → Agent / SDK_ **Staging**_Blob Storage → Agent / SDK_ **Production**_Blob Storage → Agent / SDK_ [About the Agent](/agent) [About the SDKs](/open-source) ## Two ways in. Both production-ready. The official Docker image runs the same on Container Apps and AKS - pick managed simplicity or full Kubernetes control. ### Azure Container Apps The fastest way onto Azure: deploy the container with no clusters or VMs to manage - scaling, load balancing, and certificates handled for you. - Zero infrastructure to manage - Auto scaling on HTTP traffic or CPU - Built-in HTTPS ingress and certificates [Container Apps guide](https://docs.gorules.io/developers/platform-guides/azure-container-apps) ### Azure Kubernetes Service For enterprise Kubernetes, deploy with the same Helm chart you would use anywhere - with Azure AD, Azure Monitor, and Key Vault wired in. - Azure AD single sign-on - Managed identity - no stored credentials - Azure CNI for native VNet networking [Kubernetes guide](/cloud-native/kubernetes) ### Backed by Azure Database for PostgreSQL. The BRMS keeps users, projects, rule versions, and audit history in PostgreSQL. Flexible Server gives it a managed home - zone-redundant, patched, and restorable to any point in time. - Zone-redundant high availability - Point-in-time restore and geo-redundant backups - Encryption at rest and in transit by default [Database configuration](https://docs.gorules.io/developers/platform-guides/azure-container-apps) **GoRules BRMS**_Docker container_ **Azure PostgreSQL**_users · projects · versions · audit_ ## At home in your Azure estate. The BRMS plugs into the Azure services you already run - monitoring, secrets, and private networking included. [ ### Azure Monitor Metrics and logs for dashboards, alerts, and Application Insights. Learn more](https://docs.gorules.io/developers/platform-guides/azure-container-apps)[ ### Key Vault & managed identity Secrets in Key Vault, credential-free authentication with managed identities. Learn more](https://docs.gorules.io/developers/platform-guides/azure-container-apps)[ ### VNet & Private Link Deploy in private VNets and reach Azure services over private endpoints. Learn more](https://docs.gorules.io/developers/platform-guides/azure-container-apps) ## Bring your rules to Azure. Run the BRMS on Container Apps or AKS with Azure PostgreSQL - or start free on GoRules Cloud while you evaluate. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## AWS Rules Engine - Deploy BRMS on ECS or EKS **URL:** https://gorules.io/cloud-native/aws **Description:** Deploy GoRules BRMS on AWS with Docker on ECS or EKS and Aurora PostgreSQL. Self-hosted business rules with CloudWatch monitoring and S3 storage. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Deploy the BRMS on AWS. One Docker image on ECS or EKS, Aurora PostgreSQL behind it - the full business rules platform inside your own AWS account. [Get started](https://us1.gorules.io) [Deployment guide](https://docs.gorules.io/developers/platform-guides/aws-ecs) **Amazon Web Services** live $docker pull gorules/brms$**aws ecs update-service --service gorules-brms**✓ service reached steady state **GoRules BRMS**_ECS / EKS_ **Aurora PostgreSQL**_managed database_ _Releases deploy to_ **Development**_S3 bucket → Agent / SDK_ **Staging**_S3 bucket → Agent / SDK_ **Production**_S3 bucket → Agent / SDK_ [About the Agent](/agent) [About the SDKs](/open-source) ## Two ways in. Both production-ready. The official Docker image runs the same on ECS and EKS - pick managed simplicity or full Kubernetes control. ### Amazon ECS The simplest path to production: run the image on Fargate or EC2 behind an Application Load Balancer, and let ECS handle orchestration and scaling. - Fargate - no servers to manage - Auto scaling on CloudWatch metrics - Service discovery with AWS Cloud Map [ECS deployment guide](https://docs.gorules.io/developers/platform-guides/aws-ecs) ### Amazon EKS Already on Kubernetes? Deploy with the same Helm chart you would use anywhere - plus IAM, ALB Ingress, and managed node groups or Fargate profiles. - One-command Helm install - IAM roles for service accounts (IRSA) - Horizontal Pod Autoscaler support [Kubernetes guide](/cloud-native/kubernetes) ### Backed by Aurora PostgreSQL. The BRMS keeps users, projects, rule versions, and audit history in PostgreSQL. Aurora replicates across Availability Zones with continuous backups - plain RDS PostgreSQL works too. - Automated backups, patching, and maintenance - Multi-AZ failover in seconds - Serverless v2 capacity scaling [Database configuration](https://docs.gorules.io/developers/platform-guides/aws-ecs) **GoRules BRMS**_Docker container_ **Aurora PostgreSQL**_users · projects · versions · audit_ ## Built for the rest of your AWS. The BRMS plugs into the AWS services you already run - monitoring, secrets, and private networking included. [ ### CloudWatch monitoring Metrics for rule evaluations, latency, and errors - ready for dashboards and alerts. Learn more](https://docs.gorules.io/developers/platform-guides/aws-ecs)[ ### IAM & Secrets Manager IAM roles for access, database credentials in AWS Secrets Manager. Learn more](https://docs.gorules.io/developers/platform-guides/aws-ecs)[ ### VPC & private subnets Deploy in private subnets and reach AWS services over VPC endpoints. Learn more](https://docs.gorules.io/developers/platform-guides/aws-ecs) ## Ship rules from your AWS account. Run the BRMS on ECS or EKS with Aurora PostgreSQL - or start free on GoRules Cloud while you evaluate. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## What is Dynamic Pricing and Why It Matters **URL:** https://gorules.io/blog/what-is-dynamic-pricing-and-why-it-matters **Description:** Learn how to implement dynamic pricing strategies that automatically adjust prices based on market demand, competition, and customer behavior. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch [All posts](/blog) What is Dynamic Pricing? Learn how to implement dynamic pricing strategies that automatically adjust prices based on market demand, competition, and customer behavior. How to Dynamic pricing is a strategy where prices automatically adjust based on market demand, competition, and other real-time factors. This pricing approach has become increasingly crucial in modern business, with major retailers and service providers adopting it to optimize revenue and stay competitive in real-time. In today's fast-paced digital economy, static pricing is becoming obsolete. E-commerce giants like Amazon make millions of price changes daily, while airlines adjust ticket prices every few minutes. This constant optimization ensures maximum revenue while maintaining market competitiveness. ## Real-World Use Cases Events and Venues - Sports venues adjusting ticket prices based on team performance and rivalry matches - Concert venues optimizing prices based on artist popularity and seat locations - Museums offering variable admission fees during peak tourist seasons Retail and E-commerce - Grocery stores automating markdowns for perishable goods - Fashion retailers managing seasonal inventory transitions - Electronics stores matching online and in-store pricing Travel Industry - Car rental companies balancing fleet utilization - Tour operators managing seasonal demand - Parking facilities adjusting rates during events ## Challenges in Implementing Dynamic Pricing While dynamic pricing offers significant benefits, implementation challenges exist. Data quality and availability often pose initial hurdles. Systems must process multiple data points quickly while maintaining accuracy. Customer perception also needs careful management - price changes must feel fair and transparent. Technical infrastructure presents another challenge. Traditional pricing systems often struggle with real-time adjustments and multiple variable processing. Integration with existing e-commerce platforms and point-of-sale systems requires careful planning and execution. ## Implementation Success Factors Key factors that determine successful dynamic pricing implementation: 1. **Start Small**: Begin with a single product line or service category 2. **Clear Rules**: Establish transparent pricing boundaries and rules 3. **Monitor Impact**: Track key metrics like revenue, margin, and customer satisfaction 4. **Regular Reviews**: Periodically assess and adjust pricing rules 5. **Customer Communication**: Maintain transparency about pricing practices ## Common Dynamic Pricing Strategies ### Time-based Pricing Time-based pricing adjusts prices according to specific times, seasons, or events. Hotels increase rates during peak tourist seasons, while restaurants offer happy hour discounts during slower periods. This strategy optimizes revenue by matching price sensitivity to customer behavior patterns. ### Demand-based Pricing Demand-based pricing responds to real-time market demand. When demand rises, prices increase to maximize profit margins. Conversely, during low-demand periods, prices decrease to stimulate sales. Ride-sharing services like Uber use this strategy effectively with surge pricing during high-demand periods. ### Competitor-based Pricing Competitor-based pricing automatically adjusts prices in response to competitor movements. This strategy ensures your products remain competitive while maintaining profit margins. Many retailers use automated tools to monitor competitor prices and adjust accordingly. ### Customer Segment Pricing Different customer segments have varying price sensitivities and perceived value. Premium customers might value convenience over cost, while new customers might need introductory offers. This strategy personalizes prices based on customer characteristics and behavior patterns. ## Building a Dynamic Pricing Engine with GoRules GoRules simplifies dynamic pricing implementation through its intuitive decision modeling interface. By combining different pricing factors into a single decision model, businesses can create sophisticated pricing strategies without complex coding. The process involves: 1. Defining pricing variables (demand levels, time periods, competitor positions) 2. Creating adjustment rules using decision tables 3. Setting up real-time price calculations 4. Testing and validating pricing scenarios ![Dynamic pricing decision table in the GoRules editor](/blog/what-is-dynamic-pricing-and-why-it-matters/img-1.jpg) Our dynamic pricing implementation uses GoRules JDM (JSON Decision Model) to create a flexible and maintainable pricing engine. The model consists of three main components that work together to calculate the final price. ### Input Factors Receives the initial request containing: - Base price - Current market demand - Time of day - Competitor price position - Customer segment information ### Adjustment Tables The model uses four decision tables, each responsible for a specific aspect of pricing: - **Market Demand Table**: Evaluates current demand levels (high/medium/low) and determines appropriate price adjustments - **Time-Based Table**: Analyzes time periods (peak/normal/off-peak) to apply time-sensitive pricing - **Competitor Analysis Table**: Compares market position (higher/equal/lower) and adjusts pricing accordingly - **Customer Segment Table**: Applies segment-specific adjustments based on customer type (premium/regular/new) ### Calculation An expression node that: - Combines all adjustment factors - Applies them to the base price - Calculates the final adjusted price - Determines the percentage change from base price ## Interactive Dynamic Pricing Calculator [Experience dynamic pricing](https://gorules.io/use-cases/dynamic-pricing) in action with our interactive calculator. Adjust different variables to see how prices change based on market conditions, time of day, competition, and customer segments. This demo showcases how different factors combine to determine the final price, providing transparency into the decision-making process. By implementing dynamic pricing with GoRules, businesses can quickly adapt to market changes, optimize revenue, and maintain competitive advantage - all while ensuring pricing decisions remain transparent and manageable. S **Stefan**_Co-founder, GoRules_ Co-founder at GoRules, working on the decision engine and the platform teams use to model and release business rules. [](https://github.com/stefan-gorules) **On this page** - [Real-World Use Cases](#real-world-use-cases) - [Challenges in Implementing Dynamic Pricing](#challenges-in-implementing-dynamic-pricing) - [Implementation Success Factors](#implementation-success-factors) - [Common Dynamic Pricing Strategies](#common-dynamic-pricing-strategies) - [Time-based Pricing](#time-based-pricing) - [Demand-based Pricing](#demand-based-pricing) - [Competitor-based Pricing](#competitor-based-pricing) - [Customer Segment Pricing](#customer-segment-pricing) - [Building a Dynamic Pricing Engine with GoRules](#building-a-dynamic-pricing-engine-with-gorules) - [Input Factors](#input-factors) - [Adjustment Tables](#adjustment-tables) - [Calculation](#calculation) - [Interactive Dynamic Pricing Calculator](#interactive-dynamic-pricing-calculator) [ _Credit Policy_ credit.scoredecision _over_ 740approve 700 _to_ 740review _under_ 700decline **Ship rules without deploys** Model, test, and release the logic from this article in GoRules - free to start. Get started](https://us1.gorules.io) ## Read more posts [All posts](/blog) [ Business logic humans can read and machines can run One copy: the owner reads it, every system runs it. Blog Aug 19, 2026 ### Business logic humans can read and machines can run Most companies keep two copies of their business logic: a document people read, and code that actually runs. The two drift apart. We built GoRules so you can keep one copy, something the owner reads and every system runs. ](/blog/business-logic-humans-can-read)[ GoRules Version 2 Policies, static analysis, natural language, a full redesign - and rules that ship like software. Release Aug 4, 2026 ### GoRules Version 2 is here The largest release in our history: policies, static analysis, rules in plain language, a redesigned workspace, and developer tools that turn your rules into a typed API. ](/blog/gorules-version-2)[ SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. Announcement Jan 12, 2026 ### SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. ](/blog/soc-2-type-2) --- ## SOC 2 Type 2 Compliance **URL:** https://gorules.io/blog/soc-2-type-2 **Description:** A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch [All posts](/blog) SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. Announcement We're excited to announce that GoRules has successfully achieved compliance with SOC 2 Type 2, marking a significant milestone in our commitment to data security and regulatory compliance. This achievement represents a pivotal moment for GoRules and reinforces our promise to customers that their data is handled with the highest level of care and protection. As we continue to grow and serve organizations across industries, maintaining robust security standards remains at the core of everything we do. The attainment of SOC 2 Type 2 compliance underscores our dedication to protecting sensitive information and meeting industry standards. Through a rigorous independent audit, we've confirmed our adherence to the stringent requirements of the SOC 2 Type 2 framework. Achieving SOC 2 Type 2 compliance means our customers can trust that GoRules has implemented comprehensive controls around security, availability, and confidentiality. This certification strengthens our data security posture and demonstrates our commitment to operational excellence - giving our partners the confidence they need when integrating our solutions into their workflows. For more details on our security practices and compliance documentation, visit our [Trust Center](https://trust.gorules.io). As we continue to prioritize data security and regulatory compliance, we remain committed to upholding the highest standards of excellence in all aspects of our operations. ![Ivan Miletic](/authors/ivan.jpg) **Ivan Miletic**_Co-founder, GoRules_ Co-founder at GoRules, working on the rules engine core, deployment, and platform security. [](https://github.com/ivanmiletic)[](https://www.linkedin.com/in/ivan-miletic-b395b563) [ _Credit Policy_ credit.scoredecision _over_ 740approve 700 _to_ 740review _under_ 700decline **Ship rules without deploys** Model, test, and release the logic from this article in GoRules - free to start. Get started](https://us1.gorules.io) ## Read more posts [All posts](/blog) [ Business logic humans can read and machines can run One copy: the owner reads it, every system runs it. Blog Aug 19, 2026 ### Business logic humans can read and machines can run Most companies keep two copies of their business logic: a document people read, and code that actually runs. The two drift apart. We built GoRules so you can keep one copy, something the owner reads and every system runs. ](/blog/business-logic-humans-can-read)[ GoRules Version 2 Policies, static analysis, natural language, a full redesign - and rules that ship like software. Release Aug 4, 2026 ### GoRules Version 2 is here The largest release in our history: policies, static analysis, rules in plain language, a redesigned workspace, and developer tools that turn your rules into a typed API. ](/blog/gorules-version-2)[ KYC Automation Architecture Design patterns and implementation strategies for building automated, scalable Know Your Customer (KYC) verification systems. Business Case Nov 29, 2024 ### KYC Automation Architecture: Building Scalable Verification Systems Design patterns and implementation strategies for building automated, scalable Know Your Customer (KYC) verification systems. ](/blog/kyc-automation-architecture) --- ## Reshaping the Insurance Industry with Steadfast Technologies **URL:** https://gorules.io/blog/reshaping-the-insurance-industry **Description:** Steadfast Technologies, a leading InsureTech provider across Australia and New Zealand, partners with GoRules to modernize insurance decisioning. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch [All posts](/blog) Reshaping the Insurance Industry with Steadfast Technologies Announcement![](/logos/steadfast-logo.svg) By leveraging the cutting-edge capabilities of GoRules' Business Rules platform, our partnership is focused on creating a customer-centric approach to InsureTech. This includes the implementation of: - **Intuitive, drag-and-drop forms** - A gateway to digitizing communication, these forms simplify and streamline how brokers engage with their clients. By enabling the creation of customized, user-friendly digital forms, we empower brokers to move client interactions away from traditional email exchanges to a fully digital platform. - **Real-Time Quotation and Pricing Engine** - GoRules' advanced Business Rules platform enables us to provide [real-time quotations](/use-cases/real-time-quotation) and pricing. This means customers can get immediate, accurate [insurance quotes](/industries/insurance) with just a few clicks. It's about making the process of obtaining insurance faster and more transparent, eliminating the traditional waiting times and uncertainties. - **Efficient opportunity management** - Integrating our intuitive digital forms and instant quotation capabilities, we enhance our ability to manage and convert opportunities effectively. This comprehensive approach ensures potential customers are engaged with personalized, timely information, improving our conversion rates. Through streamlined processes and improved customer interactions, we're able to deliver a superior service experience, making every step from initial contact to policy issuance seamless and efficient. Moreover, by integrating with top-tier technology partners like Stripe for seamless payment solutions and Twilio for effective communication, Steadfast Technologies is poised to set new standards in the industry. Steadfast Technologies is a subsidiary of the Steadfast Group, the largest general insurance broker network and group of underwriting agencies in Australasia. Keep an eye out for more updates as we continue to forge the future of InsureTech! S **Stefan**_Co-founder, GoRules_ Co-founder at GoRules, working on the decision engine and the platform teams use to model and release business rules. [](https://github.com/stefan-gorules) [ _Credit Policy_ credit.scoredecision _over_ 740approve 700 _to_ 740review _under_ 700decline **Ship rules without deploys** Model, test, and release the logic from this article in GoRules - free to start. Get started](https://us1.gorules.io) ## Read more posts [All posts](/blog) [ Business logic humans can read and machines can run One copy: the owner reads it, every system runs it. Blog Aug 19, 2026 ### Business logic humans can read and machines can run Most companies keep two copies of their business logic: a document people read, and code that actually runs. The two drift apart. We built GoRules so you can keep one copy, something the owner reads and every system runs. ](/blog/business-logic-humans-can-read)[ GoRules Version 2 Policies, static analysis, natural language, a full redesign - and rules that ship like software. Release Aug 4, 2026 ### GoRules Version 2 is here The largest release in our history: policies, static analysis, rules in plain language, a redesigned workspace, and developer tools that turn your rules into a typed API. ](/blog/gorules-version-2)[ SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. Announcement Jan 12, 2026 ### SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. ](/blog/soc-2-type-2) --- ## Building Python Rules Engine: Lambda and S3 **URL:** https://gorules.io/blog/python-rules-engine-lambda **Description:** Learn how to deploy and utilize a serverless rules engine. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch [All posts](/blog) Serverless Deployment Deploy GoRules with Python on AWS Lambda in just 10 minutes and execute decisions on the cloud. How to In today's world, businesses need to be agile, flexible, and efficient to stay competitive. To achieve this, they need to implement technologies that allow them to process and analyze data quickly and accurately. One technology that has gained popularity in recent years is the serverless computing model. Serverless computing allows developers to write and run code without having to worry about managing servers or infrastructure. This model is cost-effective, and scalable, and reduces the time it takes to deploy code to production. In this article we will learn how to: - Create an Amazon S3 bucket - Create Rules Engine Lambda Function - Create a JDM file - Test Lambda We will start by assuming you already have AWS Account. ## Create an Amazon S3 bucket To create a new bucket login into your AWS Console and go to the link: [https://s3.console.aws.amazon.com/s3/buckets](https://s3.console.aws.amazon.com/s3/buckets) Next, press Create on the right side. ![Amazon S3 Buckets](/blog/python-rules-engine-lambda/img-1.jpg) In the forms enter a unique bucket name and select your region. ![Create Amazon S3 Bucket](/blog/python-rules-engine-lambda/img-2.jpg) Scroll to the bottom, leave other fields as default and press **Create Bucket**. After finishing you should see your new bucket in the list. ![Amazon S3 Buckets - created](/blog/python-rules-engine-lambda/img-3.jpg) We have set up AWS S3 Bucket! ## Create Rules Engine Lambda Function Now, we will create a new Lambda Function and will attach Zen Engine Layer. To use a Zen Engine in a Lambda environment we have two options: 1. Bundle Zen Engine dependency with the Python program, 2. Add Zen Engine Layer that has a built-in dependency. The lambda layer is a smart way to package the dependencies and libraries that simplify serverless deployment. The layer is actually a zip file that contains all the dependencies. It shrinks down the size of the deployment package and makes your deployment more robust. In the next part, we will progress with this option. ### Create Layer To start, open the Lambda service by visiting the Lambda Home page [https://console.aws.amazon.com/lambda/home#/layers](https://console.aws.amazon.com/lambda/home#/layers). You will see a list of your available layers. ![Lambda Layers](/blog/python-rules-engine-lambda/img-4.jpg) Press **Create Layer** and you will see the form as on an image: ![Lambda Create Layer](/blog/python-rules-engine-lambda/img-5.jpg) On the form, we will need to add certain configurations: - enter a name, for example, **zen\_engine\_python\_layer**, - tick Upload a file from Amazon S3 and paste this URL: [https://gorules-public-eu-west-1.s3.eu-west-1.amazonaws.com/lambda/layers/python/python-zen\_engine-v0.4.1-x86\_64-linux-gnu.zip](https://gorules-public-eu-west-1.s3.eu-west-1.amazonaws.com/lambda/layers/python/python-zen_engine-v0.4.1-x86_64-linux-gnu.zip) - select runtime **Python 3.9**, - tick only **x86\_64** architecture _You can also download a zen engine python layer to your machine and manually upload it._ Press **Create** and your Lambda layer will be created. ![Lambda Layer - created](/blog/python-rules-engine-lambda/img-6.jpg) ### Create a Function and attach Layer Next, we will need to create a Function and attach Layer. On the left side of Navigation select **Functions** and a new page will appear with a list of available functions. ![Lambda Functions](/blog/python-rules-engine-lambda/img-7.jpg) To create a new function select **Create function.** Next, on the configuration page: - enter the name of your function, - select Runtime to **Python 3.9**, - select **x86\_64** architecture. ![Lambda Function Create](/blog/python-rules-engine-lambda/img-8.jpg) _Your Runtime and Architecture must match with the previously created Layer._ Next press **Create Function** and your Lambda Function will be created! ![Lambda Function](/blog/python-rules-engine-lambda/img-9.jpg) Now we will need to attach our reusable Layer with built-in dependencies. On the Lambda page scroll to the bottom and in the Layers section press **Add a Layer**. ![Lambda Function - Add a Layer](/blog/python-rules-engine-lambda/img-10.jpg) The new form will appear: ![Lambda Function Layer](/blog/python-rules-engine-lambda/img-11.jpg) On the form select **Custom Layers**, from the dropdown select your previously created layer (e.g. zen\_engine\_python\_layer), and select a version. Press **Add** and your new Layer will be added to your Lambda Function. Your Lambda will now have a Layer with dependencies attached. ### Configure permissions Next, we will need to allow Lambda to access S3. To do this go to a **Configuration** Tab, open the **Permissions** side menu, and press **Edit**. ![Lambda Permissions](/blog/python-rules-engine-lambda/img-12.jpg) On the newly opened form scroll to the bottom and tick **Create a new role from AWS policy templates** in the Execution role section. Enter a new name, for example, **bre\_python\_lambda,** and in the Policy Template search and select **Amazon S3 object read-only permissions**. ![Lambda Permission](/blog/python-rules-engine-lambda/img-13.jpg) Press Save and your new Role will be added to Lambda. ## Python Rules Engine As we have all dependencies and permissions set, we are now left with writing Python code. ![Python Business Rules Engine](/blog/python-rules-engine-lambda/img-14.jpg) _For the source code please visit:_ [_https://github.com/gorules/zen/blob/master/examples/python-lambda-s3/lambda\_function.py_](https://github.com/gorules/zen/blob/master/examples/python-lambda-s3/lambda_function.py) Because we have added a lambda layer we are able to import the zen library without having any dependency directly in the function. The code that you are seeing here is using the loaders logic which is made to read decision files directly from Amazon S3 based on a **key** property of the request. ## Create a JDM file To create and manage decision files we can either create JSON files manually or use GoRules free editor. Open the editor by clicking on the [Editor](https://editor.gorules.io/?template=shipping-fees). The link is loaded with the pre-defined template for the basic evaluation of shipping fees. To learn more about JDM Graphs please visit [JSON Decision Model (JDM)](https://docs.gorules.io/reference/json-decision-model-jdm) documentation. You can also open the decision table by clicking the **Open** link in the Fees node of the graph. ![GoRules JDM](/blog/python-rules-engine-lambda/img-15.jpg) Next, download a JSON file by pressing **File** > **Download JSON** and rename a file to **shipping-fees.json**. Upload a decision file to your S3 bucket. ![Amazon S3 - upload file](/blog/python-rules-engine-lambda/img-16.jpg) ## Test Rules Engine Now, we only need to test the Lambda function! Go back to your Lambda Function and press **Test**. ![Lambda Test](/blog/python-rules-engine-lambda/img-17.jpg) A new dialog will appear prompting the configuration of the test events. Select **Create a new event**, name it to **test**, and for the event JSON paste: ![Lambda Test JSON](/blog/python-rules-engine-lambda/img-18.jpg) The **key** is the file name that we have uploaded to our Amazon S3 bucket and Context is input data that will be validated in the rules engine. After saving a new test event press **Test** again. You can finally see a result. ![Business Rules Engine Performance](/blog/python-rules-engine-lambda/img-19.jpg) Likewise, you are able to upload many different decision files and execute them by naming a Key in the JSON event to a new file. ## Summary In this blog, we explored how to build a serverless rules engine using Python and AWS Lambda. We started by creating an Amazon S3 bucket to store our data. Next, we created a Lambda function and attached a Zen Engine layer, which is a pre-built dependency, to our function. This layer helps streamline the deployment process and makes our Lambda function more robust. We also configured permissions to allow the Lambda function to access S3, ensuring that it has read-only access to the necessary objects. In conclusion, building a [Python rules engine](/open-source/python-rules-engine) with AWS Lambda and S3 can offer numerous benefits for businesses, including increased agility, improved data processing capabilities, and cost savings. By following the steps outlined in this blog, developers can easily set up a serverless rules engine and leverage the power of serverless computing for their business needs. ![Ivan Miletic](/authors/ivan.jpg) **Ivan Miletic**_Co-founder, GoRules_ Co-founder at GoRules, working on the rules engine core, deployment, and platform security. [](https://github.com/ivanmiletic)[](https://www.linkedin.com/in/ivan-miletic-b395b563) **On this page** - [Create an Amazon S3 bucket](#create-an-amazon-s3-bucket) - [Create Rules Engine Lambda Function](#create-rules-engine-lambda-function) - [Create Layer](#create-layer) - [Create a Function and attach Layer](#create-a-function-and-attach-layer) - [Configure permissions](#configure-permissions) - [Python Rules Engine](#python-rules-engine) - [Create a JDM file](#create-a-jdm-file) - [Test Rules Engine](#test-rules-engine) - [Summary](#summary) [ _Credit Policy_ credit.scoredecision _over_ 740approve 700 _to_ 740review _under_ 700decline **Ship rules without deploys** Model, test, and release the logic from this article in GoRules - free to start. Get started](https://us1.gorules.io) ## Read more posts [All posts](/blog) [ Business logic humans can read and machines can run One copy: the owner reads it, every system runs it. Blog Aug 19, 2026 ### Business logic humans can read and machines can run Most companies keep two copies of their business logic: a document people read, and code that actually runs. The two drift apart. We built GoRules so you can keep one copy, something the owner reads and every system runs. ](/blog/business-logic-humans-can-read)[ GoRules Version 2 Policies, static analysis, natural language, a full redesign - and rules that ship like software. Release Aug 4, 2026 ### GoRules Version 2 is here The largest release in our history: policies, static analysis, rules in plain language, a redesigned workspace, and developer tools that turn your rules into a typed API. ](/blog/gorules-version-2)[ SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. Announcement Jan 12, 2026 ### SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. ](/blog/soc-2-type-2) --- ## KYC Automation Architecture: Scalable Verification Systems **URL:** https://gorules.io/blog/kyc-automation-architecture **Description:** Learn how to design and implement a scalable KYC verification system. Discover decision flows and automation techniques to build robust compliance solutions. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch [All posts](/blog) KYC Automation Architecture Design patterns and implementation strategies for building automated, scalable Know Your Customer (KYC) verification systems. Business Case ## Introducton In today's fast-paced financial landscape, **Know Your Customer (KYC)** processes stand as both a critical compliance requirement and a significant operational challenge. [Financial institutions](/industries/financial) worldwide grapple with the complexity of customer verification while trying to maintain efficiency and regulatory compliance. Traditional KYC processes often involve **manual document reviews**, **repetitive data entry**, and **time-consuming verification steps**. These manual approaches not only slow down customer onboarding but also introduce inconsistencies and human errors. For many organizations, what should be a streamlined verification process becomes a bottleneck that frustrates customers and strains internal resources. The impact of these manual processes extends far beyond simple operational inefficiencies. When customer onboarding takes days or weeks instead of minutes or hours, it directly affects customer satisfaction and can lead to abandoned applications. Financial institutions report that up to 40%[\[1\]](https://www.finextra.com/pressarticle/63794/40-of-brits-abandon-bank-onboarding-process) of potential customers abandon the onboarding process due to lengthy KYC procedures. This translates to significant lost revenue opportunities and damaged brand reputation. Moreover, as regulatory requirements continue to evolve and become more complex, maintaining compliance through manual processes becomes increasingly challenging. Organizations must adapt to new regulations across different jurisdictions while ensuring consistent verification standards. This challenge is particularly acute for institutions operating across multiple regions, each with its own regulatory framework. The need for scalable, automated verification systems has never been more pressing. Modern financial institutions require solutions that can handle growing transaction volumes, adapt to regulatory changes, and provide consistent verification outcomes. Automation not only addresses these operational challenges but also creates opportunities for better customer experiences and more efficient compliance processes. ![High-level architecture for KYC Automation](/blog/kyc-automation-architecture/img-1.jpg) Building a scalable KYC verification system requires careful consideration of various architectural components, from **dynamic form generation** to **automated decision-making** and **identity verification integration**. Let's explore how these components work together to create robust, efficient KYC systems that meet both regulatory requirements and business needs. ## Key Components of Modern KYC Architecture ### Dynamic Form Generation ![Example dynamic form for KYC](/blog/kyc-automation-architecture/img-2.jpg) At the heart of modern KYC systems lies the shift from rigid, static forms to dynamic, intelligent interfaces that adapt to both user input and compliance requirements. Traditional forms, with their one-size-fits-all approach, often collect unnecessary information or miss crucial data points depending on the specific case. This inefficiency not only frustrates users but also complicates compliance efforts. Dynamic form generation revolutionizes this approach by creating responsive interfaces that evolve based on context. For instance, when a customer indicates they're a corporate entity rather than an individual, the form automatically adjusts to request relevant company documentation. Similarly, when a user selects their country of operation, the form adapts to collect jurisdiction-specific information required by local regulations. The true power of dynamic forms emerges through **expression languages** like GoRules ZEN. This business-friendly language enables non-technical teams to define complex form behaviors without diving into code. Consider these real-world examples of form logic: - Validate tax ID format: `matches(taxId, "^[0-9]{2}-[0-9]{7}$")` or `error("Invalid tax ID format")` - Show beneficial owner fields: if `company.revenue > 1000000` then show beneficialOwnerFields - Require extra documentation: `customer.riskScore > 80 ? ["proofOfFunds", "sourceOfWealth"] : ["proofOfFunds"]` > One of the key advantages of GoRules ZEN is its versatility - the same expression language powers both **client-side validation** through **WebAssembly (WASM)** and **server-side** logic via native bindings or Rust implementation. This ensures consistent behavior and validation across your entire application stack. **Expression languages** drive sophisticated validation logic that goes far beyond simple required field checks. Forms can implement complex validation rules such as ensuring company registration dates align with regulatory requirements or validating document formats based on jurisdiction. Error messages become contextual and helpful, guiding users to provide correct information rather than simply highlighting errors. The adaptability extends to compliance requirements across different regions. A single form template can dynamically adjust its fields, validation rules, and required documentation based on the jurisdiction. This ensures that whether a customer is onboarding in Singapore, the United Kingdom, or the United States, they're presented with exactly the requirements relevant to their location. Building these adaptive forms requires careful consideration of user experience. The goal is to make complex compliance requirements feel simple and intuitive. Fields appear or hide smoothly as users progress through the form, with clear guidance about why additional information is needed. This progressive disclosure approach prevents overwhelming users while ensuring all necessary data is collected. ### Automated Decision Engine While dynamic forms streamline data collection, automated decision engines form the backbone of intelligent KYC verification. These engines transform complex compliance requirements into structured, automated decision processes that evaluate customer information consistently and efficiently. Business rules play a pivotal role in KYC verification by codifying regulatory requirements and risk assessment policies. Instead of burying these rules deep within application code, modern architectures leverage [rules engines](/brms) to maintain them separately. This separation allows compliance teams to directly manage and update verification logic without requiring software development cycles. Consider some common verification rules in KYC processing: - If customer revenue exceeds $10M and jurisdiction is high-risk, require enhanced due diligence - When beneficial ownership includes politically exposed persons, escalate for manual review - For businesses under 2 years old, require additional financial documentation - If transaction volumes exceed historical patterns by 200%, trigger compliance review When implementing a rules engine like GoRules, decisions become highly maintainable through visual decision modeling. Business analysts can create and modify complex verification logic using intuitive interfaces, while the engine ensures high-performance execution across thousands of verifications. Integration of rules engines into KYC systems typically follows event-driven patterns. As customer information flows through the verification process, the rules engine evaluates data at key decision points, triggering appropriate actions or requests for additional information. This approach enables real-time decision making - crucial for modern digital onboarding experiences where customers expect immediate feedback. The real power of automated decision engines emerges in their ability to handle complex, multi-step verification processes. They can orchestrate various checks, from simple validation rules to sophisticated risk scoring models, while maintaining clear audit trails of each decision. This not only accelerates the verification process but also provides valuable insights for compliance reporting and process optimization. ### Identity Verification (IDV) Integration The final crucial component of modern KYC systems is robust identity verification integration. While forms collect information and rules engines make decisions, identity verification services provide the critical validation of customer identities. These services have evolved from simple document validation to sophisticated multi-factor verification systems that combine document analysis, biometric matching, and data crosschecking. Modern identity verification approaches leverage artificial intelligence and machine learning to analyze identity documents in real-time. When a customer uploads their passport or driver's license, these systems can instantly verify the document's authenticity, check for signs of tampering, and extract relevant information. This automated analysis is complemented by biometric verification, where selfie photos or video recordings are matched against ID documents to confirm the user's identity. Integration with IDV services requires careful architectural consideration. Most organizations opt for a provider-agnostic approach, creating an abstraction layer that can work with multiple IDV providers. Here's how a typical verification flow might work: - Document upload triggers initial automated authenticity checks - Extracted data is cross-referenced with submitted form information - Biometric verification confirms the user matches their documents - Additional checks run against sanctions lists and public databases - Results feed back into the rules engine for final verification decisions The key to successful IDV integration lies in finding the right balance between automation and security. While automated systems can process most verifications quickly and accurately, certain cases may require manual review. The architecture should support seamless escalation to human reviewers when necessary, without disrupting the overall flow. Managing multiple IDV providers has become a common practice, allowing organizations to optimize for different regions, document types, or verification requirements. This approach provides redundancy and helps maintain high verification success rates across diverse customer bases. The verification orchestration layer can intelligently route requests to the most appropriate provider based on factors like document type, jurisdiction, or performance metrics. ## System Integration Considerations Building a robust KYC architecture requires careful consideration of how different components interact and operate as a unified system. Modern implementations typically adopt a microservices approach, breaking down the verification process into discrete, independently deployable services that handle specific aspects of the workflow. A well-designed KYC system orchestrates the flow of data between its components seamlessly. Form submissions trigger validation processes, feeding data into the rules engine for decision-making while simultaneously initiating identity verification checks. This choreography of services must maintain data consistency while handling the asynchronous nature of various verification steps. Error handling becomes particularly crucial in KYC systems where verification failures or service disruptions can significantly impact customer onboarding. Robust architectures implement intelligent fallback strategies. For example, if an automated document verification service is unavailable, the system might gracefully degrade to manual review rather than completely halting the verification process. Each component in the KYC system should implement retry mechanisms, circuit breakers, and fallback options. When primary services fail, secondary paths ensure business continuity while maintaining compliance requirements. Comprehensive monitoring and auditing capabilities are non-negotiable in KYC systems. Organizations need visibility into every verification decision, document check, and rule evaluation. This audit trail serves multiple purposes - from troubleshooting operational issues to demonstrating regulatory compliance. Modern systems implement distributed tracing to track requests across services, combined with detailed logging of all verification steps and decisions. Real-time monitoring also plays a crucial role in maintaining system health and identifying potential issues before they impact customers. Performance metrics, error rates, and verification success rates should be continuously monitored, with alerts configured for any anomalies that might indicate problems with specific verification steps or providers. ## Future-Proofing KYC Systems In the rapidly evolving landscape of financial regulation, future-proofing KYC systems has become a critical consideration. Organizations must build verification architectures that can adapt to new regulatory requirements without requiring complete system overhauls. This adaptability starts with design decisions that anticipate change rather than just meeting current requirements. Regulatory changes are inevitable in the KYC space. Whether it's new documentation requirements, enhanced verification procedures, or changes in risk assessment criteria, your system must be ready to adapt. This is where the separation of concerns in the architecture proves invaluable. When business rules are managed independently through rules engines, and form behaviors are controlled through expression languages, updating verification requirements becomes a configuration change rather than a development project. A well-designed KYC system should treat compliance requirements as dynamic parameters rather than hardcoded constraints. This approach ensures that when regulations change, updates can be implemented quickly without disrupting existing operations. Scalability in KYC systems goes beyond handling increased transaction volumes. Modern architectures must scale across multiple dimensions - supporting new jurisdictions, accommodating different types of customers, and integrating with additional verification services. Cloud-native deployments provide the flexibility to scale components independently based on demand, ensuring cost-effective operations while maintaining performance. The maintenance aspect of KYC systems deserves special attention. Regular updates to verification logic, integration with new identity verification providers, and ongoing performance optimizations should be possible without system downtime. Feature flags and canary deployments allow organizations to roll out changes gradually, monitoring their impact before full deployment. Looking ahead, successful KYC systems will be those that can evolve alongside both technological advancements and regulatory requirements. Organizations should maintain close relationships with regulatory bodies, technology providers, and industry peers to stay ahead of changes and ensure their verification systems remain effective and compliant. ## Conclusion Building robust, automated KYC systems represents a significant shift from traditional manual verification processes. The combination of dynamic forms, intelligent rules engines, and integrated identity verification creates a foundation for efficient, compliant customer onboarding that can adapt to changing requirements. The journey toward automated KYC begins with understanding your current verification bottlenecks and compliance requirements. Start small - perhaps by implementing dynamic forms or automating specific decision points - and gradually expand the system's capabilities. The modular nature of modern KYC architectures allows organizations to evolve their systems incrementally while maintaining operational continuity. Organizations implementing automated KYC systems typically report 60-80% reduction in verification times and up to 50% decrease in operational costs. More importantly, they see significant improvements in customer satisfaction and reduced abandonment rates during onboarding. The long-term benefits of investing in automated KYC systems extend far beyond operational efficiency. A well-designed system provides: - Consistent compliance across all verification processes - Rapid adaptation to regulatory changes - Improved customer experience through faster onboarding - Better risk management through standardized decision-making - Comprehensive audit trails for regulatory reporting - Reduced manual workload for compliance teams As financial services continue to digitize and regulatory requirements evolve, automated KYC systems will become increasingly crucial for maintaining competitive advantage. Organizations that invest in flexible, scalable verification architectures today will be better positioned to handle tomorrow's compliance challenges while delivering superior customer experiences. The key is to approach KYC automation as a strategic initiative rather than just a technical project. By focusing on adaptability, scalability, and user experience while maintaining robust compliance controls, organizations can build verification systems that deliver value well into the future. S **Stefan**_Co-founder, GoRules_ Co-founder at GoRules, working on the decision engine and the platform teams use to model and release business rules. [](https://github.com/stefan-gorules) **On this page** - [Introducton](#introducton) - [Key Components of Modern KYC Architecture](#key-components-of-modern-kyc-architecture) - [Dynamic Form Generation](#dynamic-form-generation) - [Automated Decision Engine](#automated-decision-engine) - [Identity Verification (IDV) Integration](#identity-verification-idv-integration) - [System Integration Considerations](#system-integration-considerations) - [Future-Proofing KYC Systems](#future-proofing-kyc-systems) - [Conclusion](#conclusion) [ _Credit Policy_ credit.scoredecision _over_ 740approve 700 _to_ 740review _under_ 700decline **Ship rules without deploys** Model, test, and release the logic from this article in GoRules - free to start. Get started](https://us1.gorules.io) ## Read more posts [All posts](/blog) [ Business logic humans can read and machines can run One copy: the owner reads it, every system runs it. Blog Aug 19, 2026 ### Business logic humans can read and machines can run Most companies keep two copies of their business logic: a document people read, and code that actually runs. The two drift apart. We built GoRules so you can keep one copy, something the owner reads and every system runs. ](/blog/business-logic-humans-can-read)[ GoRules Version 2 Policies, static analysis, natural language, a full redesign - and rules that ship like software. Release Aug 4, 2026 ### GoRules Version 2 is here The largest release in our history: policies, static analysis, rules in plain language, a redesigned workspace, and developer tools that turn your rules into a typed API. ](/blog/gorules-version-2)[ SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. Announcement Jan 12, 2026 ### SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. ](/blog/soc-2-type-2) --- ## GoRules Version 2 is here **URL:** https://gorules.io/blog/gorules-version-2 **Description:** GoRules v2: policy documents with automatic execution order, static analysis with pre-flight checks, natural-language rules, a redesigned workspace with dark mode, and OpenAPI-powered developer tools. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch [All posts](/blog) GoRules Version 2 Policies, static analysis, natural language, a full redesign - and rules that ship like software. Release Version 2 is the largest release in the history of GoRules. It has been almost a year in the making, and it touches everything: how rules are written, how they are checked, how they read, how the workspace feels, and how your systems consume them. This post walks through the six changes that matter most. If you would rather see it than read it, the [launch video](https://player.mux.com/2xnLNPO5n52bVYbJCba7fg2QiL3Bf7HuzBuWnwGZT5k) covers the highlights in a minute. ## Policies: rules as documents Most business logic does not start life as a diagram. It starts as a document - an underwriting manual, a pricing policy, a compliance procedure. Then someone translates that document into an implementation, and from that moment on there are two versions of the truth: the one people read, and the one that actually runs. Keeping them aligned is the job nobody owns. Version 2 introduces **policies**: a new way to write rules as a governed document. A policy reads top to bottom like the manual it replaces - prose where you need context, and typed rule blocks where you need logic: data models, dictionaries, decision tables, expressions, matches, and assertions. The part that makes this more than formatting: **you never wire the execution order**. The engine reads what every block consumes and produces, derives the order automatically, and keeps it correct as the document evolves. Reorganize the document for the reader - the engine still runs it right. Shared definitions live in their own policies and are pulled in with imports, so a rate table maintained by one team is reused everywhere it applies. underwriting-policy · policyexecution order: derived Underwriting Policy Premiums are derived from the applicant’s risk profile, then bounded by the guardrails below. **baseRate**\=the rate table entry for the coverage class **premium**\=baseRate plus riskPoints times 12.4 **Credit score**applicant.creditScore **Employment**applicant.years **Risk tier**riskTier 1 greater than 740 at least 2 preferred 2 between 640 and 739 at least 1 standard 3 less than 640 manual Policies are first-class citizens: they run through the same engine as decision graphs, they are versioned, tested, reviewed and released the same way, and they are callable over the same API. Graphs remain the right tool for orchestrating flows; policies are the right tool when the logic _is_ the document. ## Explain: every value has a story The question that follows every automated decision is the same: _why?_ Why this premium, why this rejection, why did this transaction get flagged? In most systems, answering it means an engineer, a debugger, and an afternoon. In Version 2, every computed value carries its own explanation. Run a simulation, click any result, and you get the full story: which rules fired, what each step contributed, and what the value was at every point along the way. Ask the opposite question too - _why was this value not computed?_ - and Explain shows you exactly which condition stopped it. valid invoice · trace5.0 ms⚲ Explain invoice-validation Trace of policy execution. validationStatus - Rule 4 Assigned status = "valid". missingCount is 0 and lineItemIssueCount is 0 and totalMismatch is false fieldChecks - Expression 4 Assigned missingCount = 0. missingCount = len($.missingFields) This works across both formats - policies and decision graphs alike - and the same lineage view answers the structural version of the question before anything runs: for any output, see the full chain of blocks and fields that feed it. When an auditor, a regulator, or a customer asks how a decision was made, the answer is a click, not a code review. ## Static analysis and Quality Control Here is an uncomfortable truth about most rule systems: the first time you find out a rule is broken is when it runs. A typo in a field name, two rules writing the same value, a condition that can never be reached - all invisible until production traffic finds them. Version 2 compiles every policy and every graph continuously, as you type, and checks it against more than twenty named diagnostics: conflicting writers, circular dependencies, type mismatches, undefined variables, unreachable rules, and more. Findings appear in a Problems panel that jumps you to the exact block, table cell, or node - the same experience developers expect from a modern IDE, applied to business rules. pricing-policy · problems3 findings 111 Premium riskPoints is a number, but the discount rule compares it to a stringTYPE\_MISMATCH Two blocks write applicant.riskTier - the second silently winsDUPLICATE\_WRITER Row 14 in Risk rating can never match - row 9 already covers this rangeUNREACHABLE\_RULE Pre-flight: static analysis · tests · reviews These checks are not advisory. Pre-flight gates run before anything merges or deploys: static analysis clean, tests green, reviews complete. And for the people who answer to auditors, the new **Quality Control** page runs every test and every check across the entire workspace and exports the result as a single, print-ready report. Compliance sign-off stops being a screenshot-collection exercise. ## Rules in plain language The oldest problem in this category: the person who owns a rule cannot read the rule. Every review, every audit, every change request passes through a translator - and translation is where mistakes live. Version 2 renders every rule in plain language. The same rule, two views: developers see the expression, business owners read a sentence. Toggle between them at any time - and edit in either. The natural view is not a summary or an approximation; it is a faithful rendering of exactly what will execute, down to picking dates from a calendar instead of typing date syntax. eligibility · expressionCodeNatural customer.tier \== "gold" and order.total \> 500 If the customer’s tier is Gold and the order total is greater than 500 Plain language ships in English, Spanish, and Brazilian Portuguese - the whole product does, in fact. A pricing analyst in São Paulo reads the same executable rule as the engineer who embeds it, each in the form they think in. ## Redesigned, end to end Version 2 is also a visual and structural redesign of the entire workspace. The graph editor was rebuilt from the ground up: a cleaner canvas, full keyboard navigation, copy and paste across graphs, and visual node-level diffs - so reviewing a change to a decision graph looks like reviewing the graph, not a wall of JSON. Function nodes gained a live console and bundled, autocompleted libraries. invoice-validation · graphdark mode **Invoice**_input_ **validationStatus**_table_ **Result**_output_ −  100%  + Keyboard-firstVisual diffENESPT-BR Dark mode covers everything - the editors, the panels, the assistant. Spotlight search now looks _inside_ your rules: table cells, expressions, data models, and policy prose, jumping straight to the matching row. And the whole experience adapts to its audience: a developer mode reveals the technical surfaces, while business users get a focused workspace without them. ## Developer tools: rules as a typed API Rules only matter once systems call them. Version 2 treats that as a first-class product surface rather than a documentation problem. Switch on developer mode and every graph and policy in your workspace appears in the **API Explorer** as a live HTTP endpoint - with request and response schemas derived from the rules themselves, and example payloads pulled from your actual test cases. Evaluation is addressable at any scope: a branch while you develop, a specific commit, a release, or a deployed environment. developer tools · api18 endpoints · openapi spec ↓ _▾_POSTdq/field-check-engineGraph https://api.gorules.io/rules/lpl/env/production/evaluate/dq/field-check-engine⧉ RequestResponseExamplescURLNode.jsPython const result = await evaluate('dq/field-check-engine', batch) Because the workspace publishes a generated **OpenAPI specification**, something quietly powerful becomes possible: you can generate typed clients and contracts for any language with standard OpenAPI tooling. Your decision service stops being a stringly-typed HTTP call and becomes a typed dependency in your codebase - request and response models included, regenerated whenever the rules change. And when you would rather not make a network call at all, the engine now ships with built-in loaders: download a release as a ZIP and evaluate it entirely inside your own process - in Node.js, Python, Go, Rust, C#, Java, or Kotlin. The same rules, the same results, zero runtime dependency on us. ## Also in Version 2 A release this size does not fit in six sections. Among the rest: - **GoRules AI, sharper** - it understands your workspace far better, manages long conversations without losing the thread, reads execution traces to pinpoint failures, and you can bring your own LLM across six providers. [More on the AI page](/ai). - **MCP server** - connect Claude Desktop, Cursor, or the CLI to your live workspace with one command, over a local-only bridge with rotating tokens. - **Tests, faster and doing double duty** - the test runner is dramatically quicker on large suites, and your real test payloads now become the example requests in the API docs. - **Managed cloud** - GoRules Cloud is now generally available in two regions, US East and Europe, with data residency, self-serve plans, and SOC 2 Type II. A dedicated post is coming; [pricing is live today](/pricing). - **Faster, everywhere it runs** - the workspace, editors, and test runner are simply faster, and Zen Engine 1.0 now runs natively in nine languages, in the browser, and on mobile. ## Upgrading If you already work in a Version 2 workspace, there is nothing to do - everything in this post is live in your project today. Projects still on the legacy v1 experience keep working, and you can migrate them from the app whenever you are ready. If you are on the legacy Demo cloud: it becomes read-only on November 1, 2026, and rules you have published keep evaluating until retirement. Moving to US1 or EU1 takes a few clicks from sign-in, and we are happy to help if you would rather not do it alone. Version 2 is live today - in the [cloud](https://us1.gorules.io) and self-hosted. Open your workspace, or [talk to an engineer](/contact-us) about what it changes for your team. S **Stefan**_Co-founder, GoRules_ Co-founder at GoRules, working on the decision engine and the platform teams use to model and release business rules. [](https://github.com/stefan-gorules) **On this page** - [Policies: rules as documents](#policies) - [Explain: every value has a story](#explain) - [Static analysis and Quality Control](#static-analysis) - [Rules in plain language](#natural-language) - [Redesigned, end to end](#redesign) - [Developer tools: rules as a typed API](#developer-tools) - [Also in Version 2](#also) - [Upgrading](#upgrading) [ _Credit Policy_ credit.scoredecision _over_ 740approve 700 _to_ 740review _under_ 700decline **Ship rules without deploys** Model, test, and release the logic from this article in GoRules - free to start. Get started](https://us1.gorules.io) ## Read more posts [All posts](/blog) [ Business logic humans can read and machines can run One copy: the owner reads it, every system runs it. Blog Aug 19, 2026 ### Business logic humans can read and machines can run Most companies keep two copies of their business logic: a document people read, and code that actually runs. The two drift apart. We built GoRules so you can keep one copy, something the owner reads and every system runs. ](/blog/business-logic-humans-can-read)[ SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. Announcement Jan 12, 2026 ### SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. ](/blog/soc-2-type-2)[ KYC Automation Architecture Design patterns and implementation strategies for building automated, scalable Know Your Customer (KYC) verification systems. Business Case Nov 29, 2024 ### KYC Automation Architecture: Building Scalable Verification Systems Design patterns and implementation strategies for building automated, scalable Know Your Customer (KYC) verification systems. ](/blog/kyc-automation-architecture) --- ## Embedded Decision Engine: Flexible Business Logic **URL:** https://gorules.io/blog/embedded-decision-engine-adding-flexibility-to-your-platform **Description:** Explore a powerful approach to adding configurable business logic to your product. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch [All posts](/blog) Adding Flexibility to Your Product Explore a powerful approach to adding configurable business logic to your product. How to As a product owner, you know that every customer wants to make your product their own. But custom code for each client isn't scalable, and hard-coded business rules become a maintenance nightmare. What if your customers could customize crucial business logic themselves, without compromising your product's stability? ## The Secret to Scalable Customization Every SaaS product starts with a promise: to solve business problems efficiently. But as you grow, you discover that each customer's business is unique. Their pricing models differ. Their approval workflows vary. Their compliance requirements are specific to their industry and region. You're now faced with an age-old product dilemma: How do you scale while maintaining the flexibility your enterprise customers demand? ### The Customization Trap If you're like most product teams, you've probably encountered these scenarios: - A major customer loves your product but needs their specific discount rules implemented - A financial institution wants to use your platform but requires custom risk assessment logic - A healthcare provider needs to add their unique patient eligibility criteria - A retail client needs specialized inventory management rules Traditionally, you had three options. **(1) Custom Development**: Build specific versions for each client - Expensive to maintain - Slow to implement - Creates technical debt - Delays product innovation **(2) Rigid Configuration**: Force customers into pre-defined options - Limits customer growth - Reduces competitive advantage - Leads to customer churn - Misses market opportunities **(3) Complex Settings**: Create elaborate configuration systems - Confusing for users - Difficult to maintain - Hard to troubleshoot - Prone to errors But there's a better way. ### Enter Embedded Business Rules Imagine giving your customers a "control room" for your product's behavior. A place where they can modify how your software works for their specific needs, without touching the core product. This is what embedded business rules with GoRules offers, and it comes in two flexible flavors. #### Light Integration: Expression Language In today's competitive SaaS landscape, your customers demand flexibility in how your product works for their specific needs. Yet, building custom features for each client quickly becomes unsustainable. This is where GoRules' Expression Language integration shines, offering a sophisticated yet lightweight solution to embed customizable business logic into your product. The ZEN Expression Language is designed for products that need to give customers control over calculations, validations, and conditional logic without the complexity of a full decision engine. Think of it as embedding a powerful calculator that understands business context - one that can handle everything from simple arithmetic to complex business rules. Use Cases: - **Insurance Form Builder** - Create dynamic forms with real-time calculations and validations using expressions - **Pricing Engine** - Let customers define complex pricing rules combining multiple factors like volume, customer type, and market conditions - **Risk Calculator** - Enable custom risk scoring algorithms that adapt to different business models and market segments - **Eligibility Checker** - Define precise qualification criteria for products, services, or benefits - **Commission Calculator** - Create flexible commission structures with multiple tiers and conditions - **Document Validator** - Build custom validation rules for document processing and approval - **Rating System** - Implement scoring models that combine multiple weighted factors #### Full Decision Engine Integration ![Decision model embedded in a host application](/blog/embedded-decision-engine-adding-flexibility-to-your-platform/img-2.jpg) What sets full decision engine integration apart is its ability to handle complex, interrelated rules while remaining manageable for business users. A manufacturing company might use it to orchestrate quality control processes that span multiple production lines, each with its own specifications and requirements. The visual rule builder makes it possible for quality managers to update these processes without requiring IT intervention, while the version control system ensures changes can be tracked and rolled back if needed. This integration is ideal for products that need to support sophisticated decision trees, complex rule sets, and interconnected business logic. It gives your customers a complete environment for managing their decision criteria, with visual tools for building decision graphs and testing capabilities. Use Cases: - **Loan Decisioning** - Define comprehensive credit assessment rules combining multiple criteria and thresholds - **Insurance Rating** - Create complex rating rules that evaluate multiple risk factors and policy conditions - **Product Configuration** - Build sophisticated product rules determining features and pricing based on multiple inputs - **Eligibility Assessment** - Implement detailed eligibility rules for complex products or services - **Risk Evaluation** - Design comprehensive risk assessment models with multiple decision points - **Automated Underwriting** - Create detailed underwriting rules evaluating multiple criteria and conditions - **Compliance Checks** - Build rule sets that evaluate compliance against multiple regulatory requirements #### Why GoRules? **Start Small, Scale Big** - Begin with simple expressions - Grow into full decision automation - Adapt as your needs evolve **Seamless Integration** - Open-source flexibility - Direct engineering support - Professional services when needed - Comprehensive documentation **Developer Friendly** - Modern React components - Clean, documented code - Easy to customize and extend - Intuitive API design **Built for Customization** - White-label ready - Themeable interface - Extensible architecture - Flexible component structure ### The Real Value Proposition For Your Customers: - Self-service customization - Faster implementation - Business logic control - Independence from IT For Your Team: - Single codebase - Reduced custom development - Lower technical debt - Faster customer onboarding ### Taking the Next Step The future of SaaS isn't about building every feature your customers might need. It's about giving them the tools to adapt your product to their needs. GoRules makes this possible through embedded business rules, whether you need simple expression evaluation or full decision automation. Your customers get the flexibility they need, while you maintain the scalability your business demands. Ready to transform your product from a rigid solution to a flexible platform? Let's talk about how embedded business rules can work for you. [Contact us](https://gorules.io/contact-us) today to explore how GoRules can help you achieve the perfect balance between customization and scalability. S **Stefan**_Co-founder, GoRules_ Co-founder at GoRules, working on the decision engine and the platform teams use to model and release business rules. [](https://github.com/stefan-gorules) **On this page** - [The Secret to Scalable Customization](#the-secret-to-scalable-customization) - [The Customization Trap](#the-customization-trap) - [Enter Embedded Business Rules](#enter-embedded-business-rules) - [Light Integration: Expression Language](#light-integration:-expression-language) - [Full Decision Engine Integration](#full-decision-engine-integration) - [Why GoRules?](#why-gorules) - [The Real Value Proposition](#the-real-value-proposition) - [Taking the Next Step](#taking-the-next-step) [ _Credit Policy_ credit.scoredecision _over_ 740approve 700 _to_ 740review _under_ 700decline **Ship rules without deploys** Model, test, and release the logic from this article in GoRules - free to start. Get started](https://us1.gorules.io) ## Read more posts [All posts](/blog) [ Business logic humans can read and machines can run One copy: the owner reads it, every system runs it. Blog Aug 19, 2026 ### Business logic humans can read and machines can run Most companies keep two copies of their business logic: a document people read, and code that actually runs. The two drift apart. We built GoRules so you can keep one copy, something the owner reads and every system runs. ](/blog/business-logic-humans-can-read)[ GoRules Version 2 Policies, static analysis, natural language, a full redesign - and rules that ship like software. Release Aug 4, 2026 ### GoRules Version 2 is here The largest release in our history: policies, static analysis, rules in plain language, a redesigned workspace, and developer tools that turn your rules into a typed API. ](/blog/gorules-version-2)[ SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. Announcement Jan 12, 2026 ### SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. ](/blog/soc-2-type-2) --- ## Business logic humans can read and machines can run **URL:** https://gorules.io/blog/business-logic-humans-can-read **Description:** Business logic drifts when a document describes it and separate code runs it. GoRules keeps one copy: policy documents the owner can read, rendered from the same compiled rules that answer your API and your Spark jobs. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch [All posts](/blog) Business logic humans can read and machines can run One copy: the owner reads it, every system runs it. Blog Every company past a certain size keeps two copies of its business logic. One copy is a document, something like the credit policy or the pricing sheet, and it sits in Confluence or a PDF. The person who owns that document understands the business. The other copy is code, and engineers wrote it by reading the document. Companies come to us with what happens next, and we hear the same story in every industry. Take a lending team. The policy says that anyone with an active bankruptcy gets declined. Automatically, no exceptions. The code mostly agrees, except that a contractor added a bypass for one partner years ago. That partner is gone. The bypass still runs. It catches so few applications that nobody notices, until an auditor asks which copy is the real policy. Nobody can answer that without an engineer, who has to read the service and compare it against the document from memory. Every change to the policy goes through that same engineer. So the analyst stops trusting the document, then stops updating it, and now it deserves the distrust. Trust only moves down from here. We think a company should keep one copy. The person who owns the logic can read it, and every system that needs an answer can run it. Everything we built comes from refusing to give up either half. ## Why not just write the if-statements? Because the analyst who owns the credit policy can't read a pull request. Code runs everywhere, and that's the easy half. The hard half is review, and when the reviewer can't read the thing under review, review turns into translation. Translation drifts. Usually it's worse than one translation. The same logic gets built twice, once in the service for online requests and once in SQL or Spark for the nightly batch. Count the document and one policy now exists in three places. Anyone who has run scoring logic online and offline knows how that ends. The two engines disagree on some Tuesday, and nobody can say which one was right. ## Didn't Drools already solve this? It tried, honestly, and it deserves credit. The Rete algorithm made large rule sets fast, and DMN gave the industry a standard way to model decisions. The ambition was right too: business users should own the logic. Two problems never got solved. The first is portability. Drools lives on the JVM, so if your services run Python or Node, or your nightly batch runs PySpark, the engine becomes another server you call over the network. You're back to keeping copies. The second is language. Authoring happens in a console that still feels like 2010, and nothing in it speaks the owner's tongue: DMN gives you tables and a diagram that wires them together, but never a sentence a policy owner would recognize as their policy. We keep a feature-by-feature [comparison](/compare/gorules-vs-drools) if you want the long version. ## Why not let an LLM decide? A decision system owes you three things. The same input gets the same answer. You can see why before you trust it. And someone else can check it later. An LLM fails all three by construction, not by immaturity: the answer can change between runs, the reasoning is a story the model tells afterward, and there's no trace anyone can replay. No future model version fixes that, because the failure isn't a capability gap. It's what probabilistic means. The model does have a right seat, though. An agent can read the messy email, ask the follow-up question, and then call the policy for the decision itself. The model proposes, the policy decides, and all three guarantees come back. ## So what's the solution? We built GoRules. The engine underneath is called ZEN, we wrote it in Rust, and it's been MIT licensed and open source since 2023. Teams have run decision graphs and tables on it for years. Policies, the document format this blog is about, shipped this summer. So this is recent work. A policy is a flat list of typed blocks inside a document: data models, dictionaries, decision tables, single expressions, match blocks, assertions, and ordinary prose between them. You never wire block A to block B. ### So if nothing's wired up, what runs first? The engine works that out for you. It reads what every block consumes and what every block produces, builds the dependency graph, and derives the execution order from that. A spreadsheet recalculates the same way. A build system schedules targets the same way. For a policy document it means you can arrange the pages for whoever reads them, with the summary up front and the rate tables in an appendix, and the engine still runs the thing correctly. The compiler holds you to two rules while it does this. Only one block may write a given property. And no block may depend on itself, directly or through a chain of other blocks. Break either one and your document doesn't compile. You get a named diagnostic on your screen instead of a surprise in production. credit-knockout · policyexecution order: derived Credit knockout policy Any failed knockout declines the application before pricing runs. Knockouts noActiveBankruptcy when the applicant’s bankruptcy status is not Active validEmailDomain when the applicant’s email domain is not one of the disposable domains Risk tier **Credit score**_applicant.creditScore_**Risk tier**_riskTier_ 1greater than 740preferred 2between 640 and 739standard 3less than 640manual review + execution order 1noActiveBankruptcy 2validEmailDomain 3riskTier Document order changes. Execution order stays put, derived from what each block reads and writes. ### Who writes the English, a model? Nobody writes it. The compiler emits it. An engineer types `customer.tier == "gold" and order.total > 500`, and the analyst reads "If the customer's tier is Gold and the order total is greater than 500." The obvious guess in 2026 is that a language model produced that sentence. It didn't, and none of this depends on one. The engine compiles the expression and describes the result piece by piece: this part is a field and here is its type, this part is a comparison, this part is a value with a display label. A locale table turns each piece into a phrase, and English, Spanish, and Brazilian Portuguese ship today. The projection is deterministic, and it only runs one way, from the compiled expression to the sentence. Editing runs the other way, and that's the one place we do use a language model. You change the sentence, the model proposes an expression, and the compiler accepts it or rejects it. What renders afterward is the deterministic projection of whatever the compiler accepted. The sentence is never the source of truth. So the analyst's view and the engineer's view can't drift apart, because both of them are renderings of one compiled document. eligibility · rulenaturalcode If the customer’s tier is Gold and the order total is greater than 500 customer.tier \== "gold" and order.total \> 500 Two renderings of one compiled artifact. Editing either view lands in the same underlying expression. ### Isn't this COBOL again? No, because the arrow points the other way. COBOL and the natural-language programming that followed it failed for one reason: somebody wrote English and a machine tried to execute it. Ambiguity went in, ambiguity came out. Here an engineer writes a small typed expression, and the English falls out of the compiled form, readable and editable. If the sentence renders on your screen, that sentence is exactly what runs. (If you're an engineer: it's a disassembler whose listings read as English.) ### How fast is it? About 10 microseconds for the median of the 89 real-world decision models in our benchmark suite. A simple decision table lands around 2.4. Money math runs on decimals, never floats. A full execution trace, which tells you which rules fired and what every property that got read contained, costs roughly an extra tenth on top. Those numbers matter for what they let you do. The engine is a library rather than a service, so the same document that answers a REST call also runs inside a PySpark worker. You send the rules to every worker once, each worker loads its own engine, and rows get evaluated right where the data sits. There's no per-row API call and no second copy of the policy written in Spark SQL, so your nightly batch can't disagree with your API. Both of them run the identical document. Native bindings ship for Node, Python, Go, Rust, Java, Kotlin, C#, and Swift, and we [documented the Spark pattern](https://docs.gorules.io/developers/integrations/pyspark) using the plain Python binding. nightly scoring · batchsame policy, two placements rules behind an API, called per row network hop engine embedded in the job ## Can I see a whole one? Here's the policy from the opening, small enough to read in one sitting. Two knockout assertions and a risk tier table, plus one application evaluated with the trace open. credit-knockout · simulationinput: Jane Cooper · score 655 Credit knockout policy Any failed knockout declines the application before pricing runs. noActiveBankruptcy \= **false** when the applicant’s bankruptcy status is not Active Failed (0 of 1 conditions passed) validEmailDomain \= **true** when the applicant’s email domain is not one of the disposable domains Passed (1 of 1 conditions) **Credit score**_applicant.creditScore_**Risk tier**_riskTier_ 1greater than 740preferred 2between 640 and 739standard 3less than 640manual review + Row 2 matched and assigned riskTier \= **"standard"** Declinedstopped by: active bankruptcy check The trace is our favorite part of the product. An engineer used to answer "why was this application declined" by attaching a debugger to production. Now anyone answers it by reading. ## What stops an analyst from changing a threshold at 4pm? The same thing that stops an engineer from doing it, which is review. We version policies and put them through review and release like everything else in the product. So the 4pm change lands as a commit somebody approved, not as an incident you find on Monday. ## When is this a bad idea? When your rules change twice a year and engineers are the only people who touch them. Write the if-statements. A dependency you don't need costs you more than repetition you can read. This starts paying when the logic changes weekly, or when the person who owns it doesn't ship code. It pays double when the same decision has to run in more than one place. Two sharper edges, so you hear them from us first. We type the rules statically, so type mismatches and undefined variables fail compilation, and the compiler tracks nullability through the types. Exhaustiveness is the soft spot. Write a rule that lists cases but no catch-all, and it still compiles. Feed it an input none of the cases cover and you get null back, an empty answer instead of an error. We have mixed feelings about whether we should make that stricter. The other edge is contributions. The engine is MIT and it will stay MIT, but we currently accept documentation and tests only, not code. With a compiler-shaped core, a drive-by feature PR costs us more to review than it cost anyone to write, and we'd rather say that out loud than let pull requests rot. We know how that reads to an open source audience. It's still the honest tradeoff. ## Where do I get it? ZEN, the engine, is [on GitHub](https://github.com/gorules/zen) under MIT. Everything else lives at [docs.gorules.io](https://docs.gorules.io): the policy format, the projection layer, the editor, and the integration guides. The benchmark suite publishes with every release, regression alerts included. S **Stefan**_Co-founder, GoRules_ Co-founder at GoRules, working on the decision engine and the platform teams use to model and release business rules. [](https://github.com/stefan-gorules) **On this page** - [Why not just write the if-statements?](#why-not-just-write-the-if-statements) - [Didn't Drools already solve this?](#didnt-drools-already-solve-this) - [Why not let an LLM decide?](#why-not-let-an-llm-decide) - [So what's the solution?](#so-whats-the-solution) - [Can I see a whole one?](#can-i-see-a-whole-one) - [What stops an analyst from changing a threshold at 4pm?](#what-stops-an-analyst-from-changing-a-threshold-at-4pm) - [When is this a bad idea?](#when-is-this-a-bad-idea) - [Where do I get it?](#where-do-i-get-it) [ _Credit Policy_ credit.scoredecision _over_ 740approve 700 _to_ 740review _under_ 700decline **Ship rules without deploys** Model, test, and release the logic from this article in GoRules - free to start. Get started](https://us1.gorules.io) ## Read more posts [All posts](/blog) [ GoRules Version 2 Policies, static analysis, natural language, a full redesign - and rules that ship like software. Release Aug 4, 2026 ### GoRules Version 2 is here The largest release in our history: policies, static analysis, rules in plain language, a redesigned workspace, and developer tools that turn your rules into a typed API. ](/blog/gorules-version-2)[ SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. Announcement Jan 12, 2026 ### SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. ](/blog/soc-2-type-2)[ KYC Automation Architecture Design patterns and implementation strategies for building automated, scalable Know Your Customer (KYC) verification systems. Business Case Nov 29, 2024 ### KYC Automation Architecture: Building Scalable Verification Systems Design patterns and implementation strategies for building automated, scalable Know Your Customer (KYC) verification systems. ](/blog/kyc-automation-architecture) --- ## Automated Approvals: From SharePoint to Modern Workflows **URL:** https://gorules.io/blog/automated-approval-system **Description:** Discover how automated approval workflows can revolutionize your operations. Compare SharePoint, Power Automate and business rules engines for optimal results v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch [All posts](/blog) Automated Approval Systems Discover how automated approval workflows can revolutionize your operations. Business Case ## **The Hidden Cost of Manual Approvals** In the modern business landscape, [approval workflows](/approval-flows) are often the hidden bottlenecks that slow down critical business operations. From purchase orders and expense reports to document reviews and customer onboarding, manual approval processes create friction that impacts both operational efficiency and user experience. Industry reports suggest that employees spend an average of 4 hours per week just managing approvals, while managers dedicate up to 20% of their time reviewing and authorizing requests. The rise of **automated approval systems** marks a significant shift in how organizations handle these critical workflows. As businesses seek greater efficiency and consistency in their decision-making processes, automation has evolved from a luxury to a necessity. In this article, we'll explore how modern rule-based approval engines are transforming business operations, enabling organizations to streamline processes, reduce errors, and accelerate business outcomes while maintaining proper controls and compliance. ![Automated Approval System Benefits - Faster processing, cost reduction and improved accuracy](/blog/automated-approval-system/img-1.jpg) ## The Evolution of Approval Processes ![Evolution of approval processes through years](/blog/automated-approval-system/img-2.jpg) Traditional approval processes have long been a cornerstone of business operations, historically relying on paper forms, manual signatures, and in-person meetings. While these methods served their purpose, they came with significant drawbacks: lengthy processing times, documents lost in transit, and the inability to track approval status effectively. The digital revolution brought the first wave of transformation, moving approvals into email systems and basic workflow tools. Organizations began adopting electronic signatures and digital forms, marking a significant step forward in efficiency. SharePoint and similar platforms introduced structured workflows, helping businesses standardize their approval processes across departments. Today, we're witnessing the next evolution in approval automation. Modern systems leverage advanced business rules engines, artificial intelligence, and sophisticated workflow automation tools to create dynamic, intelligent approval processes. These solutions don't just digitize existing workflows - they fundamentally transform how organizations approach approvals, offering real-time processing, adaptive routing based on business rules, and seamless integration with existing enterprise systems. ## Modern Approaches to Approval Automation ### Traditional Workflow Tools Basic workflow automation tools provide straightforward routing capabilities and simple approval chains. These solutions excel at handling linear processes with fixed steps and clear decision points. While they offer easy implementation and user-friendly interfaces, they often struggle with complex scenarios requiring dynamic routing or sophisticated business logic. Their rigid nature can make it difficult to adapt to changing business requirements. ## SharePoint for Approval Workflows SharePoint, Microsoft's collaborative platform, serves as a foundation for document management and workflow automation in many organizations. Its native approval capabilities are deeply integrated with document libraries and lists, making it particularly effective for: - Document approvals and reviews - Content publishing workflows - Team-based collaboration - Basic vendor and contract approvals While SharePoint approval workflows offer robust document-centric features and familiar interfaces, they can be limited in handling complex business logic or cross-platform processes. Organizations often find themselves constrained by: - Limited customization options - Fixed routing patterns - Challenges with multi-stage approvals - Performance issues with high-volume processes ## Power Automate Approval Solutions Power Automate elevates Microsoft's automation capabilities by providing a modern, flexible platform for creating sophisticated approval workflows. As a cloud-based service, it offers: - Visual workflow designers for no-code automation - Pre-built approval templates - Integration with 300+ business applications - Mobile approval capabilities - Real-time notifications and tracking - OAuth and modern authentication support Key strengths for approval processes include: - Quick implementation of standard approval flows - Easy integration with Microsoft 365 suite - Built-in mobile experience - Modern user interface However, organizations should consider limitations such as: - Complexity in handling dynamic routing rules - Challenges with high-volume processing - Limited options for complex business logic - Potential costs for premium connectors ## Business Rules Engines Business rules engines represent the most sophisticated approach to approval automation. Unlike traditional tools, they separate business logic from process flow, enabling organizations to modify approval rules without changing the underlying workflow. They excel at handling: - Complex conditional approvals - Dynamic routing based on multiple variables - Real-time decision making - Integration with multiple systems - Compliance and audit requirements This flexibility makes them particularly valuable for organizations with evolving approval requirements or complex regulatory environments. ## Transforming Workflows with GoRules While traditional approval tools focus on routing and task management, GoRules takes a fundamentally different approach by putting business logic at the center of approval automation. This business rules engine approach allows organizations to create sophisticated, adaptive approval workflows that can evolve with changing business needs. ### The Power of Business Rules At its core, GoRules transforms complex approval decisions into clear, manageable business rules. Instead of rigid if-then statements or fixed routing paths, approvals can be based on multiple factors such as: - Transaction amounts and thresholds - Risk levels and compliance requirements - Customer or vendor relationships - Historical data and past performance - Department-specific criteria ### Versatile Integration Capabilities GoRules is designed to enhance both traditional and modern workflow systems: #### Traditional Systems - SharePoint workflows for document approvals - Power Automate for Microsoft ecosystem integration - ServiceNow for IT service management - Jira for project workflows #### Modern Workflow Platforms - Temporal for durable execution of approval flows - Apache Airflow for data pipeline approvals - n8n for workflow automation - Camunda for business process orchestration - Kubernetes-native workflow engines like Argo Workflows This flexibility allows organizations to leverage GoRules' powerful decision engine regardless of their chosen workflow platform, combining robust business rules with modern orchestration capabilities. ![GoRules integration capabilities with Power Automate, SharePoint, Temporal and Airflow](/blog/automated-approval-system/img-3.jpg) ### Addressing Common Pain Points GoRules directly tackles the most challenging aspects of approval automation: - Dynamic Routing: Automatically determines approval paths based on multiple criteria - Consistency: Ensures uniform application of approval policies across the organization - Adaptability: Allows quick updates to approval rules without IT intervention - Scalability: Handles high-volume approvals with consistent performance - Compliance: Maintains detailed audit trails and decision logs ### Real-World Applications Organizations are using GoRules to transform various approval processes: - Financial institutions automating loan approvals based on complex risk assessments - Manufacturing companies streamlining purchase order approvals across global operations - Healthcare providers managing treatment authorizations while ensuring compliance - Insurance companies automating claims approvals with dynamic rule sets This rules-first approach enables organizations to move beyond simple workflow automation to true intelligent approval processing, whether standalone or integrated with modern workflow orchestration platforms. ## The Path Forward ### The Future of Automated Approvals The landscape of approval automation continues to evolve, with business rules engines like GoRules leading the transformation. As organizations face increasing pressure to improve efficiency while maintaining control, the ability to combine sophisticated decision logic with modern workflow platforms has become crucial. Whether enhancing existing SharePoint workflows, building on Power Automate, or integrating with cutting-edge platforms like Temporal, the flexibility to adapt and scale approval processes is now within reach. ### Taking the Next Step For organizations looking to modernize their approval processes, the journey begins with evaluating current workflows and identifying opportunities for automation. Consider these steps: 1. Assess your current approval processes and pain points 2. Evaluate whether your existing tools can scale with your needs 3. Explore how a business rules engine could enhance your workflow platform 4. Start small with a pilot project to demonstrate value 5. Plan for broader implementation across your organization Ready to transform your approval workflows? [Contact us](https://gorules.io/contact-us) to learn more about building intelligent, scalable approval processes that grow with your business. S **Stefan**_Co-founder, GoRules_ Co-founder at GoRules, working on the decision engine and the platform teams use to model and release business rules. [](https://github.com/stefan-gorules) **On this page** - [The Hidden Cost of Manual Approvals](#the-hidden-cost-of-manual-approvals) - [The Evolution of Approval Processes](#the-evolution-of-approval-processes) - [Modern Approaches to Approval Automation](#modern-approaches-to-approval-automation) - [Traditional Workflow Tools](#traditional-workflow-tools) - [SharePoint for Approval Workflows](#sharepoint-for-approval-workflows) - [Power Automate Approval Solutions](#power-automate-approval-solutions) - [Business Rules Engines](#business-rules-engines) - [Transforming Workflows with GoRules](#transforming-workflows-with-gorules) - [The Power of Business Rules](#the-power-of-business-rules) - [Versatile Integration Capabilities](#versatile-integration-capabilities) - [Traditional Systems](#traditional-systems) - [Modern Workflow Platforms](#modern-workflow-platforms) - [Addressing Common Pain Points](#addressing-common-pain-points) - [Real-World Applications](#real-world-applications) - [The Path Forward](#the-path-forward) - [The Future of Automated Approvals](#the-future-of-automated-approvals) - [Taking the Next Step](#taking-the-next-step) [ _Credit Policy_ credit.scoredecision _over_ 740approve 700 _to_ 740review _under_ 700decline **Ship rules without deploys** Model, test, and release the logic from this article in GoRules - free to start. Get started](https://us1.gorules.io) ## Read more posts [All posts](/blog) [ Business logic humans can read and machines can run One copy: the owner reads it, every system runs it. Blog Aug 19, 2026 ### Business logic humans can read and machines can run Most companies keep two copies of their business logic: a document people read, and code that actually runs. The two drift apart. We built GoRules so you can keep one copy, something the owner reads and every system runs. ](/blog/business-logic-humans-can-read)[ GoRules Version 2 Policies, static analysis, natural language, a full redesign - and rules that ship like software. Release Aug 4, 2026 ### GoRules Version 2 is here The largest release in our history: policies, static analysis, rules in plain language, a redesigned workspace, and developer tools that turn your rules into a typed API. ](/blog/gorules-version-2)[ SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. Announcement Jan 12, 2026 ### SOC 2 Type 2 Compliance A significant milestone in our commitment to data security, regulatory compliance, and building trust with our customers. ](/blog/soc-2-type-2) --- ## Rules Engine Telco Templates - GoRules **URL:** https://gorules.io/industries/telco/templates **Description:** Discover a collection of customizable telco templates designed to simplify and accelerate your decision automation projects. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Telco templates. Customizable telco templates - download one, load it into GoRules, and start your decision automation from a working model instead of a blank canvas. 10 templates found [_Telco_ ### Dynamic Tariff Engine Rule-based pricing system for telecommunication services that automatically applies discounts based on user profiles, time periods, and location types. ](/industries/telco/templates/dynamic-tarrif-engine)[_Telco_ ### Regional Compliance Manager Automated system that applies region-specific data privacy rules for telecommunications services across EU, US, UK, Canada, and Australia. ](/industries/telco/templates/regional-compliance-manager)[_Telco_ ### Customer Eligibility Engine Intelligent system that analyzes customer data to determine service upgrades, loyalty rewards, and premium features based on usage patterns and account history. ](/industries/telco/templates/customer-eligibility-engine)[_Telco_ ### Service Level Agreement Enforcement Automated system that monitors telecommunication service levels, detects SLA violations, and triggers appropriate compensation and escalation responses. ](/industries/telco/templates/service-level-agreement-enforcement)[_Telco_ ### Device Compatibility Checker Intelligent system that evaluates device models and firmware versions to determine service availability and feature compatibility. ](/industries/telco/templates/device-compatibility-checker)[_Telco_ ### Partner Revenue Sharing Automated calculation system that determines commission rates, bonuses, and payouts for content, service, and technology partnership agreements. ](/industries/telco/templates/partner-revenue-sharing)[_Telco_ ### International Roaming Policy Manager Automated telecom solution that applies custom roaming rates and service levels based on customer destination, plan type and usage patterns. ](/industries/telco/templates/international-roaming-policy-manager)[_Telco_ ### Cellular Data Rollover System Intelligent system that automatically calculates and applies unused data transfers to next billing cycles based on customer plan tiers and usage patterns. ](/industries/telco/templates/cellular-data-rollover-system)[_Telco_ ### MVNO Partner Enablement Automated rules engine that determines service access, network resources, and pricing tiers for mobile virtual network operators based on partnership metrics. ](/industries/telco/templates/mvno-partner-enablement)[_Telco_ ### Legacy Plan Management Rules-based telecom system that preserves benefits for long-term customers while streamlining catalog offerings and guiding migration paths. ](/industries/telco/templates/legacy-plan-management) ## Start from a template, ship your own rules. Download any telco template, load it into GoRules, and make it yours - free on GoRules Cloud. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Rules Engine Retail Templates - GoRules **URL:** https://gorules.io/industries/retail/templates **Description:** Discover a collection of customizable retail templates designed to simplify and accelerate your decision automation projects. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Retail templates. Customizable retail templates - download one, load it into GoRules, and start your decision automation from a working model instead of a blank canvas. 10 templates found [_Retail_ ### Seller Approval Workflow Rules-based marketplace solution that evaluates business credentials, expertise, inventory quality, and background checks to maintain seller standards. ](/industries/retail/templates/seller-approval-workflow)[_Retail_ ### Dynamic Marketplace Commission Calculator Automated system for calculating seller commission rates based on product category, sales data, seller performance, and promotional periods. ](/industries/retail/templates/dynamic-marketplace-comission-calculator)[_Retail_ ### Product Listing Scoring Automated scoring system that evaluates and ranks product listings based on image quality, description completeness, and other key marketplace success factors. ](/industries/retail/templates/product-listing-scoring)[_Retail_ ### Marketplace Seller Grading System Objective performance evaluation system that scores sellers on delivery, satisfaction, inventory, and compliance metrics to determine marketplace status. ](/industries/retail/templates/marketplace-seller-grading-system)[_Retail_ ### Marketplace Listing Verification System Automated risk assessment system that flags suspicious marketplace listings based on brand authenticity, pricing anomalies, and seller credibility factors. ](/industries/retail/templates/marketplace-listing-verification-system)[_Retail_ ### Returns and Refund Policy Automated system that determines return eligibility, responsibility, and refund calculations based on purchase conditions and seller policies. ](/industries/retail/templates/returns-and-refund-policy)[_Retail_ ### Seller Fee Calculator Adaptive fee structure that automatically calculates transaction rates, subscription costs, and service charges based on seller metrics and program eligibility. ](/industries/retail/templates/seller-fee-calculator)[_Retail_ ### Affiliate Commission Calculator Dynamic system that calculates precise affiliate payouts based on product category, performance metrics, and promotional factors. ](/industries/retail/templates/affiliate-commission-calculator)[_Retail_ ### Flash Sale Eligibility Smart retail solution that automatically selects products for flash sales based on inventory, profitability, seasonality, and seller performance. ](/industries/retail/templates/flash-sale-eligibility)[_Retail_ ### Dynamic FX Rate Pricing System Tiered foreign exchange rate system that offers preferential rates for premium products, enhancing margins on luxury items while maintaining competitiveness. ](/industries/retail/templates/dynamic-fx-rate-pricing-system) ## Start from a template, ship your own rules. Download any retail template, load it into GoRules, and make it yours - free on GoRules Cloud. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Rules Engine Public Sector Templates - GoRules **URL:** https://gorules.io/industries/public-sector/templates **Description:** Discover a collection of customizable public sector templates designed to simplify and accelerate your decision automation projects. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Public Sector templates. Customizable public sector templates - download one, load it into GoRules, and start your decision automation from a working model instead of a blank canvas. 10 templates found [_Public Sector_ ### Government Assistance Streamlined decision system that determines program eligibility based on income thresholds, household size, age factors, and special circumstances. ](/industries/public-sector/templates/government-assistance)[_Public Sector_ ### Tax Exemption Automated system that assesses organizations for 501(c)(3) tax-exempt status based on structure, activities, and financial metrics. ](/industries/public-sector/templates/tax-exemption)[_Public Sector_ ### Municipal Permit Evaluation System Automated system that evaluates building and event permits based on zoning regulations, safety requirements, and environmental impact factors. ](/industries/public-sector/templates/municipal-permit-evaluation-system)[_Public Sector_ ### Immigration Eligibility Evaluator Rules-based system automating visa application processing by evaluating documentation completeness, background checks and qualification scoring. ](/industries/public-sector/templates/immigration-eligibility-evaluator)[_Public Sector_ ### Environmental Compliance Assessment Rules-based system that evaluates organizational compliance with environmental regulations based on industry type, emissions data, and geographical location. ](/industries/public-sector/templates/environment-compliance-assessment)[_Public Sector_ ### School District Resource Allocation Data-driven funding distribution tool that allocates educational resources based on student population, performance metrics, and specialized program needs. ](/industries/public-sector/templates/school-district-resource-allocation)[_Public Sector_ ### Traffic Violation Penalty Calculator Automated system that determines appropriate fines, points, and penalties for traffic violations based on severity, driver history, and circumstances. ](/industries/public-sector/templates/traffic-violation-penalty-calculator)[_Public Sector_ ### Disaster Relief Fund Allocation Automated system that calculates disaster relief payments based on damage severity, household factors, income level, and insurance coverage status. ](/industries/public-sector/templates/disaster-relief-fund-allocation)[_Public Sector_ ### Import Duties Calculator Automated system that calculates precise import duties and taxes based on product details, country relationships, and trade agreements. ](/industries/public-sector/templates/import-duties-calculator)[_Public Sector_ ### Grant Funding Distribution Automated system that calculates grant awards based on project merit, applicant quality, budget availability, and potential community impact. ](/industries/public-sector/templates/grant-funding-distribution) ## Start from a template, ship your own rules. Download any public sector template, load it into GoRules, and make it yours - free on GoRules Cloud. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Rules Engine Logistics Templates - GoRules **URL:** https://gorules.io/industries/logistics/templates **Description:** Discover a collection of customizable logistics templates designed to simplify and accelerate your decision automation projects. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Logistics templates. Customizable logistics templates - download one, load it into GoRules, and start your decision automation from a working model instead of a blank canvas. 10 templates found [_Logistics_ ### Shipping Carrier Selector Rule-based system that selects optimal carriers by analyzing package details, service level needs, and cost factors to streamline shipping decisions. ](/industries/logistics/templates/shipping-carrier-selector)[_Logistics_ ### Delivery Route Optimizer Smart logistics system that evaluates capacity, traffic, time windows, and distance to determine the most efficient delivery routes for maximum efficiency. ](/industries/logistics/templates/delivery-route-optimizer)[_Logistics_ ### Warehouse Storage Location Maximizes warehouse efficiency by strategically placing products based on turnover rates, picking frequency, and product characteristics. ](/industries/logistics/templates/warehouse-storage-location)[_Logistics_ ### Order Consolidation System Smart logistics system that optimizes shipping by combining orders based on location proximity, delivery timeframes, and available carrier capacity. ](/industries/logistics/templates/order-consolidation-system)[_Logistics_ ### Dynamic Shipping Cost Calculator Advanced shipping rate system that automatically calculates costs based on shipment attributes, seasonal variables, and customer loyalty tiers. ](/industries/logistics/templates/dynamic-shipping-cost-calculator)[_Logistics_ ### Last-Mile Delivery Assignment Automated system that matches packages with delivery personnel by priority, weight, skills, location, and time to optimize efficiency. ](/industries/logistics/templates/last-mile-delivery-assignment)[_Logistics_ ### Warehouse Cross-Docking Automated system that determines optimal handling of incoming shipments based on outbound orders, time constraints, and current warehouse capacity. ](/industries/logistics/templates/warehouse-cross-docking)[_Logistics_ ### Hazardous Materials Management System Automated rules engine that classifies hazardous materials and provides handling, storage, and transportation guidelines based on regulatory requirements. ](/industries/logistics/templates/hazardous-materials-management-system)[_Logistics_ ### Returns Processing System Streamlines product return processing by applying business rules based on customer status, product details, and return circumstances for optimal efficiency. ](/industries/logistics/templates/returns-processing-system)[_Logistics_ ### Supply Chain Risk Evaluator Assessment system that analyzes supplier data, geopolitical factors, and market conditions to prioritize supply chain vulnerabilities. ](/industries/logistics/templates/supply-chain-risk) ## Start from a template, ship your own rules. Download any logistics template, load it into GoRules, and make it yours - free on GoRules Cloud. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Rules Engine Insurance Templates - GoRules **URL:** https://gorules.io/industries/insurance/templates **Description:** Discover a collection of customizable insurance templates designed to simplify and accelerate your decision automation projects. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Insurance templates. Customizable insurance templates - download one, load it into GoRules, and start your decision automation from a working model instead of a blank canvas. 10 templates found [_Insurance_ ### Policy Eligibility Analyzer Automated rule-based system that evaluates customer eligibility for insurance policies based on age, location, and specific risk factors. ](/industries/insurance/templates/policy-eligibility-analyzer)[_Insurance_ ### Auto Insurance Premium Calculator Dynamic pricing system that determines accurate premiums based on driver profile, vehicle specifications, and coverage options for personalized insurance rates. ](/industries/insurance/templates/auto-insurance-premium-calculator)[_Insurance_ ### Insurance Claim Validation System Automated verification that validates insurance claims against policy status, timeframe requirements, and claim details before investigation. ](/industries/insurance/templates/claim-validation-system)[_Insurance_ ### Policy Discount Calculator Automated system that calculates personalized insurance discounts based on customer loyalty, policy bundling, and vehicle safety features. ](/industries/insurance/templates/policy-discount-calculator)[_Insurance_ ### Applicant Risk Assessment Scoring system that evaluates credit history, income stability, and debt ratios to categorize insurance applicants into risk tiers. ](/industries/insurance/templates/application-risk-assessment)[_Insurance_ ### Insurance Coverage Calculator Personalized insurance coverage recommendations based on property value, location risk factors, and claim history to optimize protection and cost. ](/industries/insurance/templates/insurance-coverage-calculator)[_Insurance_ ### Insurance Agent Commission Dynamic commission calculation system that determines agent payouts based on policy type, premium value, and agent performance metrics. ](/industries/insurance/templates/insurance-agent-commission)[_Insurance_ ### Insurance Underwriting Risk Automated system that evaluates insurance applications against risk factors to determine whether manual underwriting review is necessary. ](/industries/insurance/templates/insurance-underwriting-risk)[_Insurance_ ### Vehicle Claims Resolution Automated decision system for determining optimal insurance claim resolution based on damage severity, vehicle age, and parts availability. ](/industries/insurance/templates/vehicle-claims-resolution)[_Insurance_ ### Customer Lifetime Value Insurance calculation system that determines customer value metrics to optimize retention strategies and set appropriate service tiers for policyholders. ](/industries/insurance/templates/customer-lifetime-value) ## Start from a template, ship your own rules. Download any insurance template, load it into GoRules, and make it yours - free on GoRules Cloud. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Rules Engine Healthcare Templates - GoRules **URL:** https://gorules.io/industries/healthcare/templates **Description:** Discover a collection of customizable healthcare templates designed to simplify and accelerate your decision automation projects. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Healthcare templates. Customizable healthcare templates - download one, load it into GoRules, and start your decision automation from a working model instead of a blank canvas. 10 templates found [_Healthcare_ ### Patient Triage System Rules-based medical triage system that prioritizes patients in emergency departments based on vital signs, symptoms, and chief complaints. ](/industries/healthcare/templates/patient-triage-system)[_Healthcare_ ### Clinical Pathway Selection Decision system that determines optimal treatment pathways based on diagnosis severity, comorbidities, and patient characteristics for personalized care plans. ](/industries/healthcare/templates/clinical-pathway-selection)[_Healthcare_ ### Medication Dosage Calculator Clinical decision system that calculates precise medication dosages based on patient weight, age, and organ function to maximize safety and efficacy. ](/industries/healthcare/templates/medication-dosage-calculator)[_Healthcare_ ### Insurance Prior Authorization Automated system that evaluates insurance requirements for medical services based on carrier rules, diagnosis codes, and service details. ](/industries/healthcare/templates/insurance-prior-authorization)[_Healthcare_ ### Clinical Treatment Protocol Decision system that selects personalized medical treatments based on diagnosis, patient characteristics, and risk factors for optimal healthcare outcomes. ](/industries/healthcare/templates/clinical-treatment-protocol)[_Healthcare_ ### Preventive Care Recommendation Data-driven system that generates personalized preventive healthcare recommendations based on patient demographics and risk factors. ](/industries/healthcare/templates/preventive-care-recommendation)[_Healthcare_ ### Clinical Lab Results Interpreter Automated system that evaluates laboratory test results against patient context to determine abnormalities and urgent follow-up actions. ](/industries/healthcare/templates/clinical-lab-result-interpreter)[_Healthcare_ ### Medical Appointment Priority System Scheduling system that prioritizes patients by clinical severity, risk factors, and wait times to optimize care and resource allocation. ](/industries/healthcare/templates/medical-appointment-priority-system)[_Healthcare_ ### Care Team Assignment System Automated system for assigning optimal healthcare providers to patients based on medical conditions, age, care complexity, and personal needs. ](/industries/healthcare/templates/care-team-assignment-system)[_Healthcare_ ### Clinical Trial Eligibility Screener Automated patient screening system that evaluates medical criteria to determine clinical trial eligibility based on multiple health factors. ](/industries/healthcare/templates/clinical-trial-eligibility-screener) ## Start from a template, ship your own rules. Download any healthcare template, load it into GoRules, and make it yours - free on GoRules Cloud. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Rules Engine Financial Templates - GoRules **URL:** https://gorules.io/industries/financial/templates **Description:** Discover a collection of customizable financial templates designed to simplify and accelerate your decision automation projects. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Financial templates. Customizable financial templates - download one, load it into GoRules, and start your decision automation from a working model instead of a blank canvas. 10 templates found [_Financial_ ### Loan Approval Automated system that evaluates credit scores, income, debt ratios, and employment history to determine mortgage eligibility and personalized interest rates. ](/industries/financial/templates/loan-approval)[_Financial_ ### Real-Time Fraud Detection Advanced transaction monitoring system that identifies suspicious financial activities using location analysis, spending patterns, and behavioral anomalies. ](/industries/financial/templates/realtime-fraud-detection)[_Financial_ ### Customer Onboarding KYC Verification Automated compliance checks that validate identity documents, screen against watchlists, and apply risk-based due diligence during onboarding. ](/industries/financial/templates/customer-onboarding-kyc-verification)[_Financial_ ### Portfolio Risk Monitor Dynamic portfolio management system that continuously evaluates investment holdings against market conditions to implement appropriate risk mitigation actions. ](/industries/financial/templates/portfolio-risk-monitor)[_Financial_ ### Payment Routing & Fee Calculator Intelligent payment processing that determines optimal routing paths, calculates precise fees, and applies security measures per transaction. ](/industries/financial/templates/payment-routing-and-fee-calculator)[_Financial_ ### Financial Transaction Compliance Classifier Automated system that classifies financial transactions, assigns risk scores, identifies compliance issues, and determines regulatory reporting requirements. ](/industries/financial/templates/transaction-compliance-classifier)[_Financial_ ### Smart Financial Product Matcher Personalized banking product recommendations based on credit score and income, matching customers with the right financial products for their unique situation. ](/industries/financial/templates/smart-financial-product-matcher)[_Financial_ ### Credit Limit Adjustment Data-driven solution that evaluates payment history, utilization, and financial behavior to automatically recommend credit limit changes. ](/industries/financial/templates/credit-limit-adjustment)[_Financial_ ### Customer Service Escalation Intelligent routing system that prioritizes customer inquiries based on customer value, issue complexity, and financial impact for optimal support allocation. ](/industries/financial/templates/customer-service-escalation)[_Financial_ ### Account Dormancy Management Proactive banking solution that identifies inactive accounts, determines appropriate interventions, and ensures compliance with regulatory requirements. ](/industries/financial/templates/account-dormancy-management) ## Start from a template, ship your own rules. Download any financial template, load it into GoRules, and make it yours - free on GoRules Cloud. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Rules Engine Aviation Templates - GoRules **URL:** https://gorules.io/industries/aviation/templates **Description:** Discover a collection of customizable aviation templates designed to simplify and accelerate your decision automation projects. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Aviation templates. Customizable aviation templates - download one, load it into GoRules, and start your decision automation from a working model instead of a blank canvas. 10 templates found [_Aviation_ ### Flight Dispatch Decision System Rules-based aviation system that evaluates weather, aircraft, crew, and weight factors to ensure regulatory compliance and safe flight operations. ](/industries/aviation/templates/flight-dispatch-decision-system)[_Aviation_ ### Dynamic Airline Ticket Pricing Engine Automated fare optimization system that sets ticket prices based on time to departure, seat availability, market demand, and competitor pricing. ](/industries/aviation/templates/dynamic-ticket-pricing)[_Aviation_ ### Booking Personalization System Dynamic flight booking platform that tailors UI, discounts, and features based on customer loyalty status, device type, booking history, and traffic source. ](/industries/aviation/templates/booking-personalization-system)[_Aviation_ ### Flight Ancillary Recommendations Data-driven system that personalizes travel add-on recommendations based on customer profile, route details, and previous purchasing behavior. ](/industries/aviation/templates/flight-ancillary-recommendations)[_Aviation_ ### Booking Fraud Detection Advanced risk assessment that evaluates payment methods, booking patterns, and account behavior to prevent travel reservation fraud. ](/industries/aviation/templates/booking-fraud-detection)[_Aviation_ ### Airline Seat Map Display Rules Dynamic seat map system that personalizes seat availability based on loyalty tier, fare class, group size and cabin occupancy levels. ](/industries/aviation/templates/seat-map-optimization)[_Aviation_ ### Online Check-in Eligibility System Automated passenger validation system that determines online check-in eligibility based on travel documents, flight timing, and special assistance requirements. ](/industries/aviation/templates/online-checkin-eligibility)[_Aviation_ ### Flight Rebooking Fee Calculator Dynamic fee system for airline booking modifications that adjusts charges based on fare class, time to departure, loyalty status, and change history. ](/industries/aviation/templates/flight-rebooking-fee-calculator)[_Aviation_ ### Airline Upgrade Eligibility Advanced passenger upgrade decision engine that evaluates loyalty status, fare class, corporate agreements, and cabin availability to prioritize upgrades. ](/industries/aviation/templates/airline-upgrade-eligibility)[_Aviation_ ### Airline Loyalty Points Calculator Advanced system for calculating airline loyalty program points based on fare class, route type, distance, member status, and seasonal promotions. ](/industries/aviation/templates/airline-loyalty-points-calculations) ## Start from a template, ship your own rules. Download any aviation template, load it into GoRules, and make it yours - free on GoRules Cloud. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Service Level Agreement Enforcement - GoRules **URL:** https://gorules.io/industries/telco/templates/service-level-agreement-enforcement **Description:** Automated system that monitors telecommunication service levels, detects SLA violations, and triggers appropriate compensation and escalation responses. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Service Level Agreement Enforcement Automated system that monitors telecommunication service levels, detects SLA violations, and triggers appropriate compensation and escalation responses. Download template Share ### Solution This service monitoring system ensures telecom providers meet their contractual obligations by continuously tracking critical service parameters like downtime, response time, and packet loss. When performance drops below agreed thresholds, the system automatically identifies SLA breaches based on the customer's service tier and the severity of the issue. For premium customers, the system enforces stricter SLA requirements with faster response times and lower tolerance for service disruptions. The system calculates appropriate compensation amounts based on the breach duration and customer tier, offering service credits for premium customers and account credits for standard customers. Escalation workflows are triggered based on severity levels, with critical issues receiving immediate attention from senior management while medium-severity issues are routed to support teams with appropriate response timeframes. ### How it works The service monitoring system follows a structured decision process: 1. **Parameter Validation**: Captures real-time data about service status, downtime duration, response time, and packet loss. 2. **Parameter Classification**: Identifies which specific parameter is triggering the evaluation (downtime, response time, or packet loss). 3. **SLA Breach Detection**: Compares current parameter values against contractual thresholds based on the customer's service tier. 4. **Severity Assessment**: Determines issue severity based on parameter type, breach status, and customer tier. 5. **Compensation Calculation**: Computes appropriate compensation amounts and types (service credits vs. account credits). 6. **Escalation Management**: Determines if escalation is required and specifies timeframe and appropriate management level. ### Where teams use it - Telecommunications service management - Internet service provider operations - Managed service level agreements - Enterprise network monitoring - Business continuity assurance - Customer satisfaction management ## Inside the decision model Service Level Agreement Enforcement ships as a JDM decision graph with 7 nodes, 5 decision tables and 25 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_expression_ validateServiceParameters_table_ determineParameterType_table_ assessSLABreach_table_ determineSeverity_table_ calculateCompensation_table_ determineEscalation _01_ ### Request _input_ Incident evaluation begins with three request objects: service carries the measurements (status, downtimeDuration, responseTime, packetLoss), customer supplies the serviceTier that sets the contractual thresholds, and incident holds the report metadata. **Sample request**_JSON_ { "service": { "id": "internet\_service\_123", "name": "Business Fiber Internet", "status": "down", "downtimeDuration": 45, "responseTime": 320, "packetLoss": 0.8, "startTime": "2025-03-19T15:30:00Z" }, "customer": { "id": "cust\_789", "name": "Acme Corporation", "serviceTier": "premium", "contractId": "contract\_456", "contactEmail": "support@acmecorp.com" }, "incident": { "id": "inc\_123456", "reportedTime": "2025-03-19T15:45:00Z", "reportedBy": "automated\_monitoring" } } _02_ ### Validate Service Parameters _expression_ Raw telemetry is normalized before any rule fires: isDowntime becomes the boolean service.status == 'down', while downtimeDuration, responseTime, and packetLoss are defaulted to 0 with the ?? operator so missing probes cannot break threshold comparisons. customerTier falls back to 'standard', which means an unknown customer is judged against the looser SLA rather than the premium one. _isDowntime_`service.status == 'down'` _downtimeDuration_`service.downtimeDuration ?? 0` _responseTime_`service.responseTime ?? 0` _packetLoss_`service.packetLoss ?? 0` _customerTier_`customer.serviceTier ?? 'standard'` _03_ ### Determine Parameter Type _table_ One violating parameter is selected per evaluation, in priority order under a first hit policy: isDowntime == true wins first and outputs 'downtime' with the duration as parameterValue, then responseTime > 0, then packetLoss > 0, with an 'unknown' fallback carrying 0. Only the first matching row fires, so a full outage is always assessed as downtime even if latency and loss are also degraded. Ranking downtime above the other signals reflects how NOC triage works in practice: when a service is down, response time and packet loss readings are symptoms of the same event, and double-counting them would inflate both severity and compensation. The 'unknown' row keeps the graph deterministic when monitoring sends an event with no measurable breach. Input Parameter TypeparameterType Parameter ValueparameterValue isDowntime == true 'downtime' downtimeDuration responseTime > 0 'responseTime' responseTime packetLoss > 0 'packetLoss' packetLoss \- 'unknown' 0 _04_ ### Assess Sla Breach _table_ Breach detection compares parameterValue against tier-specific limits, with the premium row for each parameterType listed before the standard one. Premium contracts tolerate downtime > 10 minutes, responseTime > 200, and packetLoss > 0.5 before slaBreached flips to true; standard contracts allow > 30, > 500, and > 2 respectively, and the final row returns 'No SLA breach detected'. Each hit also writes a breachDescription such as 'Excessive downtime for premium customer' for the incident record. Running one threshold table per tier pair is how SLA schedules are actually written into enterprise contracts: the customer buys a numeric commitment, and the 2x-4x headroom between premium and standard limits is what differentiates the products. Half a percent packet loss is a defensible premium ceiling because real-time services like VoIP degrade noticeably beyond it, while 2 percent is livable for ordinary browsing traffic. Parameter TypeparameterType Service LevelcustomerTier Parameter ValueparameterValue SLA BreachedslaBreached Breach DescriptionbreachDescription 'downtime' 'premium' \> 10 true 'Excessive downtime for premium customer' 'downtime' 'standard' \> 30 true 'Excessive downtime for standard customer' 'responseTime' 'premium' \> 200 true 'Response time exceeds premium SLA' 'responseTime' 'standard' \> 500 true 'Response time exceeds standard SLA' 'packetLoss' 'premium' \> 0.5 true 'Packet loss exceeds premium SLA' 'packetLoss' 'standard' \> 2 true 'Packet loss exceeds standard SLA' +1 more row in the downloadable template _05_ ### Determine Severity _table_ Severity is graded by crossing slaBreached with parameterType and customerTier under a first hit policy. A breached 'downtime' event is 'critical' (severityScore 3) for 'premium' customers and 'high' (2) for 'standard'; 'responseTime' and 'packetLoss' breaches score 'high' for premium and 'medium' (1) for standard, and anything without a breach resolves to 'none' with score 0. Shifting every category up one notch for premium accounts encodes the commercial reality that enterprise contracts, like the fiber customer in the sample, often carry penalty clauses and reference risk, so the same outage costs the carrier more. The numeric severityScore alongside the label makes it easy for downstream systems to sort or aggregate incidents without parsing strings. SLA BreachedslaBreached Parameter TypeparameterType Customer tiercustomerTier Severity LevelseverityLevel Severity ScoreseverityScore true 'downtime' 'premium' 'critical' 3 true 'downtime' 'standard' 'high' 2 true 'responseTime' 'premium' 'high' 2 true 'responseTime' 'standard' 'medium' 1 true 'packetLoss' 'premium' 'high' 2 true 'packetLoss' 'standard' 'medium' 1 +1 more row in the downloadable template _06_ ### Calculate Compensation _table_ Payouts scale with the measured breach: when slaBreached is true, a 'premium' customer receives parameterValue \* 5 as a 'service\_credit', any other breached tier receives parameterValue \* 2 as an 'account\_credit', and non-breaches get compensationType 'none' with amount 0. Crediting proportionally to the breach magnitude, minutes of downtime in the sample case, follows the standard SLA remedy model where compensation is a service credit rather than cash, which caps the carrier's exposure while still making the guarantee enforceable. The 5x versus 2x multiplier is a pricing decision that keeps premium credits meaningful relative to the higher fees those customers pay. SLA BreachedslaBreached Customer tiercustomerTier Compensation amountcompensationAmount Compensation typecompensationType true 'premium' parameterValue \* 5 'service\_credit' true \- parameterValue \* 2 'account\_credit' \- \- 0 'none' _07_ ### Determine Escalation _table_ Routing follows severityLevel directly: 'critical' escalates to 'senior\_management' with an 'immediate' timeframe, 'high' goes to a 'service\_manager' within '4\_hours', 'medium' to the 'support\_team' within '24\_hours', and anything else sets requiresEscalation to false. The three output fields together form a complete dispatch instruction for the ticketing system. Tiered response clocks like immediate/4/24 hours mirror the restoration targets telecom operators publish in support plans, where the escalation level rises with severity so management attention is reserved for incidents that threaten contract penalties. Mapping the no-breach case to 'none' keeps informational events out of the on-call queue. Severity levelseverityLevel Requires EscalationrequiresEscalation Escalation TimeframeescalationTimeframe Escalation LevelescalationLevel 'critical' true 'immediate' 'senior\_management' 'high' true '4\_hours' 'service\_manager' 'medium' true '24\_hours' 'support\_team' \- false 'none' 'none' ## Other Telco templates [View all templates](/templates) [_Telco_ ### Dynamic Tariff Engine Rule-based pricing system for telecommunication services that automatically applies discounts based on user profiles, time periods, and location types. ](/industries/telco/templates/dynamic-tarrif-engine)[_Telco_ ### Regional Compliance Manager Automated system that applies region-specific data privacy rules for telecommunications services across EU, US, UK, Canada, and Australia. ](/industries/telco/templates/regional-compliance-manager)[_Telco_ ### Customer Eligibility Engine Intelligent system that analyzes customer data to determine service upgrades, loyalty rewards, and premium features based on usage patterns and account history. ](/industries/telco/templates/customer-eligibility-engine) ## Make this template your own. Load Service Level Agreement Enforcement into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Regional Compliance Manager - GoRules **URL:** https://gorules.io/industries/telco/templates/regional-compliance-manager **Description:** Automated system that applies region-specific data privacy rules for telecommunications services across EU, US, UK, Canada, and Australia. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Regional Compliance Manager Automated system that applies region-specific data privacy rules for telecommunications services across EU, US, UK, Canada, and Australia. Download template Share ### Solution This compliance system automatically applies the correct regional data privacy frameworks to customer accounts based on their location. It enforces region-specific regulations like GDPR for EU customers, CCPA for US customers, and Privacy Act requirements for Australian users. The system manages data retention periods, ranging from 12 months in Australia to 36 months in the US and default regions. For telecommunications providers, the solution handles service restrictions such as roaming caps in the EU and UK, and international call verification requirements in the US. It verifies customer consent status, evaluates age restrictions for premium services, and determines if data export is permitted based on regional laws. The system also differentiates between business and individual customers, applying the appropriate compliance rules to each customer type. ### How it works The compliance management process follows these key steps: 1. **Customer Data Input**: Captures customer location, type, age, and consent status along with requested services. 2. **Regional Rule Application**: Determines applicable privacy framework (GDPR, CCPA, UK GDPR, PIPEDA, Privacy Act) based on customer region. 3. **Compliance Verification**: Checks if explicit consent requirements are satisfied and calculates data retention dates. 4. **Service Eligibility Assessment**: Evaluates eligibility for premium services based on customer type, region, and age requirements. 5. **Restriction Identification**: Flags service-specific restrictions like roaming caps or third-party data sharing limitations. 6. **Compliance Summary Generation**: Creates a concise compliance status overview with retention periods and applicable framework. ### Where teams use it - Telecom service providers operating across multiple jurisdictions - Mobile carriers managing international roaming services - Customer data management for global telecommunications companies - Subscription-based communications services with tiered offerings - Data privacy compliance for mobile service providers - New customer onboarding for international phone and internet services ## Inside the decision model Regional Compliance Manager ships as a JDM decision graph with 4 nodes, 2 decision tables and 11 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ customerData_table_ regionalComplianceRules_expression_ complianceEvaluation_table_ serviceEligibility _01_ ### Customer Data _input_ Everything hinges on the customer object, whose region, type, age, and consentProvided fields select the privacy framework, while the serviceRequest flags (upgradeToPremium, internationalRoaming, dataSharing) describe what the customer is asking for. **Sample request**_JSON_ { "customer": { "id": "CUST-83921", "region": "EU", "type": "individual", "consentProvided": true, "age": 32, "serviceLevel": "standard", "dateJoined": "2023-05-15" }, "serviceRequest": { "upgradeToPremium": true, "internationalRoaming": true, "dataSharing": false } } _02_ ### Regional Compliance Rules _table_ Jurisdiction mapping is a single first-hit lookup on customer.region that emits five compliance fields at once. 'EU' resolves to the 'GDPR' framework with 24 months retention, exportAllowed false, and restrictions \['roaming\_cap', 'third\_party\_data\_sharing'\]; 'US' maps to 'CCPA' with 36 months and 'international\_calls\_verification'; 'UK' mirrors the EU under 'UK\_GDPR'; 'CA' and 'AU' map to 'PIPEDA' and 'Privacy\_Act' with 18 and 12 months. An unmatched region falls into the 'default' row with consentRequired false. The frameworks named here are the real regimes a carrier faces in each market, and keeping EU and UK data exports blocked by default reflects how operators treat cross-border transfers conservatively until an adequacy or contractual basis is confirmed. The retention months themselves are policy choices rather than statutory numbers: privacy laws generally demand a justified limit, not a fixed figure, so shorter windows in AU and CA simply encode a stricter internal stance where the market allows it. Regioncustomer.region Data Retention Period (months)compliance.dataRetentionMonths Privacy Frameworkcompliance.privacyFramework Explicit Consent Requiredcompliance.explicitConsentRequired Service Restrictionscompliance.serviceRestrictions Data Export Allowedcompliance.dataExportAllowed 'EU' 24 'GDPR' true \['roaming\_cap', 'third\_party\_data\_sharing'\] false 'US' 36 'CCPA' true \['international\_calls\_verification'\] true 'UK' 24 'UK\_GDPR' true \['roaming\_cap'\] false 'CA' 18 'PIPEDA' true \[\] true 'AU' 12 'Privacy\_Act' true \[\] true \- 36 'default' false \[\] true _03_ ### Compliance Evaluation _expression_ Consent is reconciled here: complianceStatus is 'compliant' when compliance.explicitConsentRequired is true and customer.consentProvided is true, or when no explicit consent is required at all, and 'non\_compliant' otherwise. dataRetentionDate projects the purge deadline by adding dataRetentionMonths of 30-day blocks to date('now'), and complianceSummary condenses region, framework, and retention into one line for account records. _complianceStatus_`compliance.explicitConsentRequired == true and customer.consentProvided == true ? 'compliant' : (compliance.explicitConsentRequired == false ? 'compliant' : 'non_compliant')` _dataRetentionDate_`date('now') + (number(compliance.dataRetentionMonths) * 30 * 24 * 60 * 60 * 1000)` _complianceSummary_`` `Region: ${customer.region}, Framework: ${compliance.privacyFramework}, Retention: ${compliance.dataRetentionMonths} months` `` _04_ ### Service Eligibility _table_ Premium eligibility is decided by crossing customer.type with customer.region under a first hit policy. 'business' customers are eligible everywhere, with the 'EU' row flagged for an additional data processing agreement; 'individual' customers in 'US', 'CA', or 'AU' pass with no extra requirements, while in 'EU' or 'UK' eligibility is the live expression customer.age >= 18. The final blank row defaults eligibleForPremium to false until the customer is properly categorized. Ordering business rows above individual ones matters because B2B accounts are governed by controller-processor contracts rather than per-person consent, which is why the EU business note points at a processing agreement instead of an age check. Gating minors out of premium tiers in EU and UK matches the heightened protection both regimes give to children's data, and defaulting unknown customers to ineligible is the safe posture for a compliance system. Customer Typecustomer.type Regioncustomer.region Eligible for Premium Serviceseligibility.premiumServices Additional Noteseligibility.notes 'business' 'EU' true 'Business customers in EU require additional data processing agreement' 'business' \- true 'Standard business customer requirements apply' 'individual' 'US', 'CA', 'AU' true 'No additional requirements' 'individual' 'EU', 'UK' customer.age >= 18 'Age verification required for premium services' \- \- false 'Default ineligible until properly categorized' ## Other Telco templates [View all templates](/templates) [_Telco_ ### Dynamic Tariff Engine Rule-based pricing system for telecommunication services that automatically applies discounts based on user profiles, time periods, and location types. ](/industries/telco/templates/dynamic-tarrif-engine)[_Telco_ ### Customer Eligibility Engine Intelligent system that analyzes customer data to determine service upgrades, loyalty rewards, and premium features based on usage patterns and account history. ](/industries/telco/templates/customer-eligibility-engine)[_Telco_ ### Service Level Agreement Enforcement Automated system that monitors telecommunication service levels, detects SLA violations, and triggers appropriate compensation and escalation responses. ](/industries/telco/templates/service-level-agreement-enforcement) ## Make this template your own. Load Regional Compliance Manager into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Partner Revenue Sharing - GoRules **URL:** https://gorules.io/industries/telco/templates/partner-revenue-sharing **Description:** Automated calculation system that determines commission rates, bonuses, and payouts for content, service, and technology partnership agreements. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Partner Revenue Sharing Automated calculation system that determines commission rates, bonuses, and payouts for content, service, and technology partnership agreements. Download template Share ### Solution The Partner Commission Calculator automates revenue sharing calculations based on partnership agreements. It determines appropriate commission structures by analyzing key partnership factors including partner type, revenue generated, service category, and exclusivity status. For content partners, the system applies tiered rates with higher commissions for premium streaming services generating over $1M in revenue. The calculator factors in contract duration and customer segment to apply appropriate multipliers, rewarding longer commitments and enterprise-level partnerships. It calculates base commissions on revenue generated, then adds performance bonuses adjusted by the appropriate multipliers. This ensures fair compensation while maximizing company revenue, with all calculations transparently documented for both partners and internal stakeholders. ### How it works The decision graph processes partnership data through three main components: 1. **Input Processing**: Collects critical partnership data including partner type, revenue generated, service category, customer segment, contract duration, and exclusivity status. 2. **Commission Rate Determination**: Evaluates partner characteristics against a decision table to assign appropriate base commission rates, performance bonus rates, and partner tier classification. 3. **Final Calculation**: Applies business logic to determine duration and segment multipliers, calculates base commission amount, adjusts bonus commission with appropriate multipliers, and computes total commission and company revenue. The system supports various partner types (content, service, technology) with specialized rate structures for each category and adjusts calculations based on revenue thresholds and partnership terms. ### Where teams use it - Media streaming partnership agreements - Telecommunications service provider contracts - Technology integration partnerships - IoT service provider agreements - Voice service reseller programs - Content licensing agreements ## Inside the decision model Partner Revenue Sharing ships as a JDM decision graph with 3 nodes, 1 decision table and 9 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ partnerCommissionRates_expression_ calculateCommission _01_ ### Request _input_ Six request fields describe the agreement: partnerType, serviceCategory, revenueGenerated, and exclusivity pick the rate card, while contractDuration and customerSegment feed the multipliers applied at the end. **Sample request**_JSON_ { "partnerType": "content", "revenueGenerated": 1500000, "serviceCategory": "streaming", "customerSegment": "enterprise", "contractDuration": 24, "exclusivity": true } _02_ ### Partner Commission Rates _table_ Rate cards are resolved by matching partnerType, serviceCategory, revenueGenerated, and exclusivity under a first hit policy, so each family's most demanding row sits on top. A 'content' partner in 'streaming' with revenue > 1000000 and exclusivity true earns the 'premium' tier at a 0.35 baseCommissionRate and 0.02 bonusRate, stepping down to 0.30 above 500000 and 0.25 for the 'basic' row. 'service' partners split by category, 'voice' at 0.28 or 0.22 versus 'IoT' at 0.32, while 'technology' partners top the card at 0.40 for revenue > 1000000 and any unmatched combination falls back to 0.20 with the 'default' tier. Paying more for exclusivity and for revenue above a threshold reflects how content and wholesale deals are actually negotiated: an exclusive catalog is a differentiator worth extra margin, and volume tiers give partners a reason to concentrate traffic with one carrier. The specific percentages are commercial choices rather than industry standards, with technology integrations rated highest because they tend to displace the most internal build cost. Partner TypepartnerType Service CategoryserviceCategory RevenuerevenueGenerated Exclusivityexclusivity Base Commission RatebaseCommissionRate Performance Bonus RatebonusRate Partner TierpartnerTier 'content' 'streaming' \> 1000000 true 0.35 0.02 'premium' 'content' 'streaming' \> 500000 \- 0.30 0.015 'standard' 'content' 'streaming' \- \- 0.25 0.01 'basic' 'service' 'voice' \> 750000 \- 0.28 0.02 'premium' 'service' 'voice' \- \- 0.22 0.01 'standard' 'service' 'IoT' \- \- 0.32 0.025 'technological' +3 more rows in the downloadable template _03_ ### Calculate Commission _expression_ Settlement math happens in one pass: durationMultiplier is 1 for contracts of 12 months or less, 1.1 up to 36, and 1.2 beyond, while segmentMultiplier pays 1.15 for 'enterprise' and 1.1 for 'business' customers. baseCommission is revenueGenerated \* baseCommissionRate, the bonus applies both multipliers on top of bonusRate, and totalCommission plus telcoRevenue split the generated revenue into the partner payout and what the carrier keeps, giving both sides a fully traceable statement. _durationMultiplier_`contractDuration <= 12 ? 1 : (contractDuration <= 36 ? 1.1 : 1.2)` _segmentMultiplier_`customerSegment == 'enterprise' ? 1.15 : (customerSegment == 'business' ? 1.1 : 1)` _baseCommission_`revenueGenerated * baseCommissionRate` _bonusCommission_`revenueGenerated * bonusRate * $.durationMultiplier * $.segmentMultiplier` _totalCommission_`$.baseCommission + $.bonusCommission` _telcoRevenue_`revenueGenerated - $.totalCommission` ## Other Telco templates [View all templates](/templates) [_Telco_ ### Dynamic Tariff Engine Rule-based pricing system for telecommunication services that automatically applies discounts based on user profiles, time periods, and location types. ](/industries/telco/templates/dynamic-tarrif-engine)[_Telco_ ### Regional Compliance Manager Automated system that applies region-specific data privacy rules for telecommunications services across EU, US, UK, Canada, and Australia. ](/industries/telco/templates/regional-compliance-manager)[_Telco_ ### Customer Eligibility Engine Intelligent system that analyzes customer data to determine service upgrades, loyalty rewards, and premium features based on usage patterns and account history. ](/industries/telco/templates/customer-eligibility-engine) ## Make this template your own. Load Partner Revenue Sharing into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## MVNO Partner Enablement - GoRules **URL:** https://gorules.io/industries/telco/templates/mvno-partner-enablement **Description:** Automated rules engine that determines service access, network resources, and pricing tiers for mobile virtual network operators based on partnership metrics. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # MVNO Partner Enablement Automated rules engine that determines service access, network resources, and pricing tiers for mobile virtual network operators based on partnership metrics. Download template Share ### Solution This MVNO partner management solution streamlines telecom wholesale relationships by dynamically applying business rules to virtual operators. The system evaluates each partner's profile - including type, tenure, and subscriber base - to automatically determine appropriate service access levels, from basic to full service tiers. Network resource allocation is precisely tailored to each MVNO's service level, with specific provisions for data capacity, voice minutes, SMS volumes, and API capabilities. The solution also implements a tiered pricing structure that accounts for both service level and market scale, determining revenue sharing percentages and granular usage rates for data and voice services. This creates a scalable framework that grows with MVNOs while ensuring profitable, sustainable partnerships for the host carrier. ### How it works The decision system evaluates MVNO partners through three interconnected rule components: 1. **Partner Service Access**: Evaluates the MVNO's type (premium, standard, startup), age, and subscriber count to determine appropriate service access level and bandwidth priority. 2. **Network Resource Allocation**: Based on the assigned service level, allocates specific network resources including data capacity (GB), voice minutes, SMS count, and appropriate API access level. 3. **Partner Pricing**: Combines service level and subscriber count to establish pricing tier, revenue sharing percentage, and unit costs for data and voice services. The system maintains full data transparency throughout the decision process, ensuring both host carriers and MVNOs understand service provisioning and cost structures. ### Where teams use it - Telecom wholesale partnership management - MVNO onboarding and service provisioning - Dynamic resource allocation for virtual operators - Revenue share and pricing tier automation - Scalable service level management - Telecom partner lifecycle management ## Inside the decision model MVNO Partner Enablement ships as a JDM decision graph with 4 nodes, 3 decision tables and 13 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ partnerServiceAccess_table_ networkResourceAllocation_table_ partnerPricing _01_ ### Request _input_ A single partner object carries everything the rules need: type, ageInMonths, and subscriberCount determine service access and pricing, while id, name, region, and businessModel travel through as account metadata. **Sample request**_JSON_ { "partner": { "id": "mvno-123", "name": "TechMobile", "type": "premium", "ageInMonths": 36, "subscriberCount": 120000, "region": "Northeast", "businessModel": "business-focused" } } _02_ ### Partner Service Access _table_ Access levels come from crossing partner.type with tenure and scale under a first hit policy. A 'premium' MVNO older than 24 months with more than 100000 subscribers earns 'full' serviceAccessLevel and 'high' bandwidthPriority; a premium partner with only > 50000 subscribers drops to 'enhanced'. 'standard' partners need > 12 months and > 25000 subscribers for the 'standard' level, otherwise they share the 'basic'/'low' row with every 'startup'. Graduating wholesale access on tenure and subscriber count is normal host-carrier practice: a virtual operator only earns priority on shared radio capacity once its traffic is predictable and its business proven, and startups begin at basic access because overcommitting bandwidth to an unproven brand risks the host's own retail quality. The thresholds themselves are commercial checkpoints, not industry constants. Partner Typepartner.type Partner Age (months)partner.ageInMonths Subscriber Countpartner.subscriberCount Service Access Levelconfig.serviceAccessLevel Bandwidth Priorityconfig.bandwidthPriority 'premium' \> 24 \> 100000 'full' 'high' 'premium' \- \> 50000 'enhanced' 'medium' 'standard' \> 12 \> 25000 'standard' 'medium' 'standard' \- \- 'basic' 'low' 'startup' \- \- 'basic' 'low' _03_ ### Network Resource Allocation _table_ Quota packages follow mechanically from config.serviceAccessLevel: 'full' unlocks 5000 GB of data, 1000000 voice minutes, 2000000 SMS, and 'advanced' API access; 'enhanced' halves that to 2500 GB and 500000 minutes; 'standard' gets 1000 GB with 'intermediate' APIs, and 'basic' bottoms out at 500 GB, 100000 minutes, and 'basic' API access. Keeping the resource grid keyed on the access level alone, rather than re-testing partner attributes, means the earlier table is the single place where eligibility is decided and this one stays a pure capacity catalog. The roughly 2x steps between rows give the host carrier a clean upgrade path to sell, and tiered API access mirrors how wholesale platforms gate provisioning and reporting endpoints by contract level. Service Access Levelconfig.serviceAccessLevel Data Allocation (GB)resources.dataAllocationGB Voice Minutesresources.voiceMinutes SMS Countresources.smsCount API Access Levelresources.apiAccessLevel 'full' 5000 1000000 2000000 'advanced' 'enhanced' 2500 500000 1000000 'intermediate' 'standard' 1000 250000 500000 'intermediate' 'basic' 500 100000 200000 'basic' _04_ ### Partner Pricing _table_ Wholesale rates improve with scale: 'full' access with > 100000 subscribers lands in 'tier1' with a 0.85 revenueShareFactor and the lowest unit costs, 0.004 per MB and 0.002 per minute. 'enhanced' with > 50000 gets 'tier2' at 0.88, 'standard' with > 10000 gets 'tier3' at 0.9, and everything else defaults to 'tier4', where the MVNO keeps 0.95 of revenue but pays the highest rates, 0.008 and 0.004. The inverse relationship in this card, bigger partners keep less of their revenue but buy capacity cheaper per unit, is a deliberate structure: at tier1 volume the host monetizes through share of a large base, while tier4 pricing lets small entrants keep margin on thin revenue at the cost of steeper unit rates. Volume-banded data and voice pricing is the standard shape of MVNO wholesale agreements, though these particular rates are business choices. Service Levelconfig.serviceAccessLevel Subscriber Countpartner.subscriberCount Pricing Tierpricing.tier Revenue Sharepricing.revenueShareFactor Data Cost Per MBpricing.dataRatePerMB Voice Cost Per Minpricing.voiceRatePerMinute 'full' \> 100000 'tier1' 0.85 0.004 0.002 'enhanced' \> 50000 'tier2' 0.88 0.005 0.003 'standard' \> 10000 'tier3' 0.9 0.006 0.003 \- \- 'tier4' 0.95 0.008 0.004 ## Other Telco templates [View all templates](/templates) [_Telco_ ### Dynamic Tariff Engine Rule-based pricing system for telecommunication services that automatically applies discounts based on user profiles, time periods, and location types. ](/industries/telco/templates/dynamic-tarrif-engine)[_Telco_ ### Regional Compliance Manager Automated system that applies region-specific data privacy rules for telecommunications services across EU, US, UK, Canada, and Australia. ](/industries/telco/templates/regional-compliance-manager)[_Telco_ ### Customer Eligibility Engine Intelligent system that analyzes customer data to determine service upgrades, loyalty rewards, and premium features based on usage patterns and account history. ](/industries/telco/templates/customer-eligibility-engine) ## Make this template your own. Load MVNO Partner Enablement into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Legacy Plan Management - GoRules **URL:** https://gorules.io/industries/telco/templates/legacy-plan-management **Description:** Rules-based telecom system that preserves benefits for long-term customers while streamlining catalog offerings and guiding migration paths. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Legacy Plan Management Rules-based telecom system that preserves benefits for long-term customers while streamlining catalog offerings and guiding migration paths. Download template Share ### Solution This telecom plan management system intelligently handles legacy service plans through a structured decision framework. The system first identifies plan types based on name patterns and age, determining whether customers qualify for grandfathered status based on their tenure. For qualified legacy customers, it preserves their original data allowances, international calling minutes, and special features like free evening calls. For non-grandfathered legacy plans, the system recommends appropriate modern alternatives from the current catalog, mapping legacy offerings to standardized equivalents while maintaining similar benefit levels. This reduces catalog complexity without disrupting customer experience. The migration eligibility component identifies which customers should remain on protected plans and which can be migrated with promotional offers, enabling targeted retention strategies while preventing catalog sprawl. ### How it works The decision graph processes customer and plan data through a sequential evaluation flow: 1. **Plan Identification**: Analyzes the plan name, age, and customer tenure to categorize plans as legacy, premium, value, or standard, and determines grandfathered status. 2. **Benefit Determination**: Evaluates each plan category and grandfathered status to assign appropriate data allowances, international minutes, and feature retention policies. 3. **Catalog Mapping**: Maps legacy plans to their current catalog equivalents, providing simplified plan names and recommended plan IDs. 4. **Migration Assessment**: Determines migration eligibility based on plan category and grandfathered status, generating appropriate offer details. 5. **Field Cleanup**: Filters the response to include only relevant information for downstream systems. ### Where teams use it - Telecommunications plan rationalization - Legacy product management - Customer retention strategies - Catalog simplification initiatives - Service migration planning - Customer value preservation ## Inside the decision model Legacy Plan Management ships as a JDM decision graph with 6 nodes, 4 decision tables and 18 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ identifyPlanType_table_ determineBenefits_table_ mapToCurrentCatalog_table_ determineMigrationEligibility_expression_ omitFields _01_ ### Request _input_ Classification starts from two objects: plan carries the name, ageInMonths, dataAllowance, internationalMinutes, and feature list under review, and customer contributes tenureInMonths, the field that decides whether legacy status becomes protected. **Sample request**_JSON_ { "plan": { "id": "LEGACY-PLAN-2019", "name": "Legacy Unlimited Family Plan", "ageInMonths": 48, "dataAllowance": 25, "internationalMinutes": 120, "features": \[ "Unlimited SMS", "Free Evening Calls", "Family Sharing" \] }, "customer": { "id": "CUST-12345", "tenureInMonths": 36, "segment": "Family", "location": "Urban" } } _02_ ### Identify Plan Type _table_ Categorization runs on name patterns plus age under a first hit policy: a plan.name matching contains($, "Legacy") with plan.ageInMonths > 36 and customer.tenureInMonths > 24 is classed 'legacy' with isGrandfathered true, while a Legacy name older than 24 months without the tenure requirement stays 'legacy' but ungrandfathered. Names containing "Value" or "Essential" map to 'value', "Premium" or "Unlimited" to 'premium', and everything else defaults to 'standard'. Requiring both plan age and customer tenure before grandfathering is deliberate: protection is meant for people who have actually held the old terms, not for anyone who recently landed on an aging SKU. Pattern-matching the plan name is a pragmatic classifier for real catalogs, where years of marketing-named plans rarely share a clean taxonomy field, and the ordering matters because 'Legacy Unlimited Family Plan' should hit the legacy rows before the 'Unlimited' pattern can claim it as premium. Plan Nameplan.name Plan Age (months)plan.ageInMonths Customer Tenure (months)customer.tenureInMonths Plan CategoryplanDetails.category GrandfatheredplanDetails.isGrandfathered contains($, "Legacy") \> 36 \> 24 'legacy' true contains($, "Legacy") \> 24 \- 'legacy' false contains($, "Value") or contains($, "Essential") \- \- 'value' false contains($, "Premium") or contains($, "Unlimited") \- \- 'premium' false \- \- \- 'standard' false _03_ ### Determine Benefits _table_ Entitlements follow from the category and grandfathered pair, checked top-down. A grandfathered 'legacy' plan keeps its own plan.dataAllowance and plan.internationalMinutes with retainSpecialFeatures true; an ungrandfathered legacy plan keeps its data but drops to 10 international minutes and loses special features. 'premium' plans get fixed grants of 50 GB and 100 minutes, 'value' plans 15 GB and 0, and the fallback row issues the 'standard' package of 25 GB and 50 minutes, each with a customer-facing description string. Echoing the original allowances for protected customers is the whole point of grandfathering: the carrier honors sold terms rather than substituting a catalog value. Trimming perks like international minutes for non-protected legacy plans, while the next node offers a modern equivalent, gently narrows the gap between old and current products so migration becomes attractive instead of forced. Plan CategoryplanDetails.category Is GrandfatheredplanDetails.isGrandfathered Data Allowance (GB)planDetails.dataAllowanceGB Retain Special FeaturesplanDetails.retainSpecialFeatures International MinutesplanDetails.internationalMinutes Plan DescriptionplanDetails.description 'legacy' true plan.dataAllowance true plan.internationalMinutes 'This is a grandfathered legacy plan with protected benefits.' 'legacy' false plan.dataAllowance false 10 'This is a legacy plan eligible for migration to our current offerings.' 'premium' \- 50 true 100 'Premium plan with our highest tier of benefits.' 'value' \- 15 false 0 'Value plan with essential features.' \- \- 25 false 50 'Standard plan with balanced features.' _04_ ### Map To Current Catalog _table_ Catalog targets are assigned from the same category and grandfathered inputs: protected legacy customers keep their own plan.name and plan.id as the recommendation, while ungrandfathered legacy plans map to 'Telco Essentials Plus' ('PLAN-ESS-001'). 'premium' resolves to 'Telco Premium Unlimited', 'value' to 'Telco Essentials', and the default row to 'Telco Standard' ('PLAN-STD-001'). Collapsing an arbitrary set of legacy names onto five current SKUs is how catalog rationalization actually gets done: billing, care, and CPQ systems all get a single recommendedPlanId to act on instead of parsing historical product names. Passing the untouched plan identity through for grandfathered accounts keeps the mapping table safe to run on every customer, protected or not. Plan CategoryplanDetails.category Is GrandfatheredplanDetails.isGrandfathered Simplified Plan NamesimplifiedPlanName Recommended Plan IDrecommendedPlanId 'legacy' true plan.name plan.id 'legacy' false 'Telco Essentials Plus' 'PLAN-ESS-001' 'premium' \- 'Telco Premium Unlimited' 'PLAN-PREM-001' 'value' \- 'Telco Essentials' 'PLAN-VAL-001' \- \- 'Telco Standard' 'PLAN-STD-001' _05_ ### Determine Migration Eligibility _table_ Migration is the final gate, driven by planDetails.category and planDetails.isGrandfathered. Grandfathered legacy customers get migrationEligible false with the note 'Protected legacy plan - migration not recommended', ungrandfathered legacy plans become eligible with 3 months promotional pricing on Telco Essentials Plus, and the catch-all marks current catalog plans as needing no migration. Pairing the eligibility flag with ready-made offer text lets retention campaigns act on the output directly, and sweetening the move with a time-boxed promotion instead of forcing it reflects how carriers retire plans without triggering churn or complaints. Excluding protected customers keeps the tool aligned with the tenure commitment made in the identification step. Plan CategoryplanDetails.category Is GrandfatheredplanDetails.isGrandfathered Migration EligiblemigrationEligible Migration Offer DetailsmigrationOfferDetails 'legacy' true false 'Protected legacy plan - migration not recommended' 'legacy' false true 'Eligible for migration to Telco Essentials Plus with 3 months promotional pricing' \- \- false 'Current catalog plan - no migration needed' _06_ ### Omit Fields _expression_ Response shaping happens last: the plan, planDetails, and customer keys are set to null so intermediate working data is stripped and downstream systems receive only the decision outputs, such as simplifiedPlanName, recommendedPlanId, migrationEligible, and migrationOfferDetails. Trimming the payload here keeps internal classification detail from leaking into consuming channels. _plan_`null` _planDetails_`null` _customer_`null` ## Other Telco templates [View all templates](/templates) [_Telco_ ### Dynamic Tariff Engine Rule-based pricing system for telecommunication services that automatically applies discounts based on user profiles, time periods, and location types. ](/industries/telco/templates/dynamic-tarrif-engine)[_Telco_ ### Regional Compliance Manager Automated system that applies region-specific data privacy rules for telecommunications services across EU, US, UK, Canada, and Australia. ](/industries/telco/templates/regional-compliance-manager)[_Telco_ ### Customer Eligibility Engine Intelligent system that analyzes customer data to determine service upgrades, loyalty rewards, and premium features based on usage patterns and account history. ](/industries/telco/templates/customer-eligibility-engine) ## Make this template your own. Load Legacy Plan Management into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## International Roaming Policy Manager - GoRules **URL:** https://gorules.io/industries/telco/templates/international-roaming-policy-manager **Description:** Automated telecom solution that applies custom roaming rates and service levels based on customer destination, plan type and usage patterns. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # International Roaming Policy Manager Automated telecom solution that applies custom roaming rates and service levels based on customer destination, plan type and usage patterns. Download template Share ### Solution This international roaming manager automatically determines appropriate service levels and pricing when customers travel abroad. The system evaluates the destination country and region against established roaming agreements to apply the correct service tier, from premium to minimal coverage. Each tier defines specific data access levels (full, limited, restricted, or emergency-only) with corresponding rate structures for data, voice, and SMS usage. The solution calculates estimated daily costs based on the customer's typical usage patterns and determines if data and voice roaming should be enabled based on the customer's plan permissions and destination policies. It tracks remaining data allowances by comparing quota limits against current usage, ensuring customers stay within their plan boundaries. This prevents bill shock while maintaining appropriate service levels that align with both carrier agreements and customer expectations. ### How it works The decision graph evaluates roaming eligibility and rates through these key processes: 1. **Regional Policy Lookup**: Identifies the destination region from the customer travel data and determines the appropriate service tier, access level, and base rates for data, voice, and SMS. 2. **Service Tier Assignment**: Applies predetermined service levels with EU regions receiving premium access, while areas with fewer agreements receive basic or minimal coverage. 3. **Rate Application**: Sets specific pricing for each region, with rates increasing based on the carrier's roaming agreements (ranging from €1.0/MB in EU regions to €5.0/MB in regions with minimal agreements). 4. **Cost Projection**: Calculates the customer's estimated daily costs based on their historical usage patterns and the destination's rate structure. 5. **Service Activation**: Determines which services to enable based on customer permissions and remaining allowances, preventing unexpected charges. ### Where teams use it - Mobile network operators managing international roaming - MVNOs implementing partner carrier agreements - Corporate telecom expense management - Travel plan optimization for frequent international travelers - Prepaid service providers with international offerings - IoT device deployments requiring cross-border connectivity ## Inside the decision model International Roaming Policy Manager ships as a JDM decision graph with 3 nodes, 1 decision table and 5 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ roamingRequest_table_ roamingPolicyLookup_expression_ calculateRoamingParameters _01_ ### Roaming Request _input_ Two request objects drive the decision: destination supplies the region that selects the roaming policy, and customer carries the profile permissions, quotas, and average usage plus the usage counters already consumed on this trip. **Sample request**_JSON_ { "destination": { "country": "France", "region": "EU", "arrivalDate": "2025-03-20", "departureDate": "2025-03-27" }, "customer": { "id": "C123456789", "profile": { "planType": "International Plus", "isDataRoamingAllowed": true, "isVoiceRoamingAllowed": true, "dataRoamingQuota": 5000, "avgDailyDataUsage": 250, "avgDailyVoiceUsage": 15, "avgDailySmsUsage": 10 }, "usage": { "dataRoamingUsed": 1250, "voiceRoamingUsed": 45, "smsRoamingUsed": 22 } } } _02_ ### Roaming Policy Lookup _table_ Zone pricing is a single first-hit lookup on destination.region that emits the whole rate card at once. 'EU' gets the 'premium' tier with 'full' data access at 1.0 per MB, 0.15 per voice minute, and 0.05 per SMS; 'USA', 'Canada' and the 'Australia', 'New Zealand', 'Japan', 'South Korea' group are 'standard'/'limited' at 2.0 and 2.5 per MB; 'China', 'India', 'Brazil', 'Russia', 'Mexico' fall to 'basic'/'restricted' at 3.5, and any unlisted region hits the catch-all: 'minimal' tier, 'emergency' access only, 5.0 per MB. Grouping countries into rate zones is exactly how roaming is wholesaled between carriers, since retail prices track the inter-operator tariffs negotiated per agreement, and EU destinations are cheapest here because intra-EU roaming is the most mature and regulated market. The emergency-only fallback for unknown regions is the standard defensive posture: where no agreement exists, wholesale costs are unpredictable, so everything except emergency service stays off. Regiondestination.region ServiceTierpolicy.serviceTier DataAccesspolicy.dataAccess DataRatePerMBpolicy.dataRate VoiceRatePerMinpolicy.voiceRate SMSRatePerMessagepolicy.smsRate 'EU' 'premium' 'full' 1.0 0.15 0.05 'USA', 'Canada' 'standard' 'limited' 2.0 0.25 0.10 'Australia', 'New Zealand', 'Japan', 'South Korea' 'standard' 'limited' 2.5 0.30 0.15 'China', 'India', 'Brazil', 'Russia', 'Mexico' 'basic' 'restricted' 3.5 0.40 0.25 \- 'minimal' 'emergency' 5.0 0.50 0.30 _03_ ### Calculate Roaming Parameters _expression_ Trip economics and switches are computed from the selected policy: totalEstimatedDailyCost multiplies avgDailyDataUsage, avgDailyVoiceUsage, and avgDailySmsUsage by the matching policy rates to give a bill-shock preview before travel. isDataRoamingEnabled requires both policy.serviceTier != 'minimal' and the customer's own isDataRoamingAllowed opt-in, voice only needs the customer permission, and remainingDataAllowance subtracts dataRoamingUsed from dataRoamingQuota so provisioning knows how much headroom is left. _totalEstimatedDailyCost_`customer.profile.avgDailyDataUsage * policy.dataRate + customer.profile.avgDailyVoiceUsage * policy.voiceRate + customer.profile.avgDailySmsUsage * policy.smsRate` _isDataRoamingEnabled_`policy.serviceTier != 'minimal' and customer.profile.isDataRoamingAllowed == true` _isVoiceRoamingEnabled_`customer.profile.isVoiceRoamingAllowed == true` _remainingDataAllowance_`customer.profile.dataRoamingQuota - customer.usage.dataRoamingUsed` ## Other Telco templates [View all templates](/templates) [_Telco_ ### Dynamic Tariff Engine Rule-based pricing system for telecommunication services that automatically applies discounts based on user profiles, time periods, and location types. ](/industries/telco/templates/dynamic-tarrif-engine)[_Telco_ ### Regional Compliance Manager Automated system that applies region-specific data privacy rules for telecommunications services across EU, US, UK, Canada, and Australia. ](/industries/telco/templates/regional-compliance-manager)[_Telco_ ### Customer Eligibility Engine Intelligent system that analyzes customer data to determine service upgrades, loyalty rewards, and premium features based on usage patterns and account history. ](/industries/telco/templates/customer-eligibility-engine) ## Make this template your own. Load International Roaming Policy Manager into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Dynamic Tariff Engine - GoRules **URL:** https://gorules.io/industries/telco/templates/dynamic-tarrif-engine **Description:** Rule-based pricing system for telecommunication services that automatically applies discounts based on user profiles, time periods, and location types. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Dynamic Tariff Engine Rule-based pricing system for telecommunication services that automatically applies discounts based on user profiles, time periods, and location types. Download template Share ### Solution This dynamic pricing engine for telecommunication services automatically applies appropriate tariffs based on multiple factors. The system differentiates between premium, business, and standard user accounts, applying specific discount rates for each service type (calls, data, and messaging). It factors in time sensitivity by adjusting rates for peak hours, off-peak periods, and weekends. Location awareness is built into the pricing logic, with different rates for domestic usage versus international roaming. The system combines all applicable factors to calculate the final per-unit price and provides clear documentation of which specific pricing rules were applied to each transaction. This ensures transparent billing while maintaining flexible pricing that reflects both user loyalty status and usage patterns. ### How it works The decision graph processes telecommunications pricing through three key stages: 1. **User Profile Analysis**: Evaluates whether the user has premium, business, or standard status and applies appropriate service-specific multipliers (greater discounts for premium users). 2. **Time and Location Assessment**: Analyzes when and where the service is being used, applying different multipliers for domestic vs. roaming usage, and adjusting rates based on peak hours, off-peak periods, or weekends. 3. **Tariff Calculation**: Determines the base rate for the specific service (calls, data, or messaging), then combines all applicable multipliers to calculate the final per-unit price. The system documents which specific rules were applied, creating a transparent audit trail for each pricing decision. ### Where teams use it - Mobile network operator billing systems - MVNO (Mobile Virtual Network Operator) pricing - Corporate telecommunications management - International roaming charge calculation - Prepaid service bundling - Real-time billing for telecommunications services ## Inside the decision model Dynamic Tariff Engine ships as a JDM decision graph with 4 nodes, 2 decision tables and 15 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ userProfileRules_table_ timeLocationRules_expression_ calculateFinalTariff _01_ ### Request _input_ Pricing starts from the raw request: userProfile, serviceType, timePeriod, and locationType drive every multiplier downstream, while usage, currency, userId, and timestamp pass through as billing context. **Sample request**_JSON_ { "userProfile": "premium", "serviceType": "calls", "timePeriod": "peak", "locationType": "domestic", "currency": "EUR", "usage": { "amount": 15, "unit": "minutes" }, "userId": "USR123456", "timestamp": "2025-03-20T14:30:00Z" } _02_ ### User Profile Rules _table_ Loyalty pricing is resolved by matching userProfile against serviceType with a first hit policy, so the eight rows are ordered from most to least specific. A 'premium' user gets a profileMultiplier of 0.8 on 'calls', 0.9 on 'data', and 0.7 on 'messaging'; 'business' accounts get 0.85, 0.8, and 0.6 respectively. The 'standard' row and the blank catch-all both return 1.0, and each row also emits profileRuleApplied, a human-readable label like 'Premium user call discount' for the audit trail. Discounting per service rather than per account is standard carrier practice: messaging has near-zero marginal cost, so it carries the deepest cuts (0.7 and 0.6), while data discounts stay shallower because network capacity is the scarce resource. The 1.0 fallback rows guarantee the engine never fails to price a request, it just charges the undiscounted rate. User ProfileuserProfile Service TypeserviceType Profile MultiplierprofileMultiplier Rule AppliedprofileRuleApplied 'premium' 'calls' 0.8 'Premium user call discount' 'premium' 'data' 0.9 'Premium user data discount' 'premium' 'messaging' 0.7 'Premium user messaging discount' 'business' 'calls' 0.85 'Business user call discount' 'business' 'data' 0.8 'Business user data discount' 'business' 'messaging' 0.6 'Business user messaging discount' +2 more rows in the downloadable template _03_ ### Time Location Rules _table_ Congestion and roaming premiums come from a second first-hit table that crosses timePeriod with locationType. Every 'roaming' row is a surcharge, from 1.5 at 'peak' down to 1.2 on 'weekend', while domestic usage swings both ways: 1.2 at peak, 0.9 'off-peak', and 0.8 on weekends. A blank final row returns a neutral 1.0 timeLocationMultiplier, and timeLocationRuleApplied records which band fired. Time-of-day pricing is how operators shift discretionary usage away from busy-hour cells, so charging 1.2 at peak while rebating 0.8 on weekends is a classic load-shaping spread. Roaming never dips below 1.2 here because wholesale inter-operator charges apply regardless of when the visited network is used, so the carrier keeps a floor over its own cost. Time PeriodtimePeriod Location TypelocationType Time Location MultipliertimeLocationMultiplier Rule AppliedtimeLocationRuleApplied 'peak' 'roaming' 1.5 'Peak hour roaming surcharge' 'peak' 'domestic' 1.2 'Peak hour domestic rate' 'off-peak' 'roaming' 1.3 'Off-peak roaming rate' 'off-peak' 'domestic' 0.9 'Off-peak domestic discount' 'weekend' 'roaming' 1.2 'Weekend roaming rate' 'weekend' 'domestic' 0.8 'Weekend domestic discount' +1 more row in the downloadable template _04_ ### Calculate Final Tariff _expression_ The last step turns multipliers into money. baseTariff is picked per service, 0.05 per unit for 'calls', 0.02 for 'data', and 0.01 otherwise, then finalTariff multiplies it by profileMultiplier and timeLocationMultiplier from the two tables. currency falls back to 'USD' when the request omits it, and rulesSummary collects the base rate plus both applied-rule labels so every price can be explained line by line. _baseTariff_`serviceType == 'calls' ? 0.05 : (serviceType == 'data' ? 0.02 : 0.01)` _finalTariff_`$.baseTariff * profileMultiplier * timeLocationMultiplier` _currency_`currency ?? 'USD'` _rulesSummary_``[`Base rate: ${$.baseTariff} per unit`, profileRuleApplied, timeLocationRuleApplied]`` ## Other Telco templates [View all templates](/templates) [_Telco_ ### Regional Compliance Manager Automated system that applies region-specific data privacy rules for telecommunications services across EU, US, UK, Canada, and Australia. ](/industries/telco/templates/regional-compliance-manager)[_Telco_ ### Customer Eligibility Engine Intelligent system that analyzes customer data to determine service upgrades, loyalty rewards, and premium features based on usage patterns and account history. ](/industries/telco/templates/customer-eligibility-engine)[_Telco_ ### Service Level Agreement Enforcement Automated system that monitors telecommunication service levels, detects SLA violations, and triggers appropriate compensation and escalation responses. ](/industries/telco/templates/service-level-agreement-enforcement) ## Make this template your own. Load Dynamic Tariff Engine into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Device Compatibility Checker - GoRules **URL:** https://gorules.io/industries/telco/templates/device-compatibility-checker **Description:** Intelligent system that evaluates device models and firmware versions to determine service availability and feature compatibility. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Device Compatibility Checker Intelligent system that evaluates device models and firmware versions to determine service availability and feature compatibility. Download template Share ### Solution This device compatibility system instantly determines which services and features are available on specific device models and firmware versions. The solution evaluates customer devices against predefined compatibility rules for multiple smartphone brands including iPhones, Samsung Galaxy, and Pixel phones. When a device query is received, the system extracts the model information and firmware version, then applies specific compatibility rules based on major and minor firmware versions. The system supports multiple service tiers including basic service access, HD streaming capabilities, advanced features, and next-generation functionality. For certain device/firmware combinations, special exceptions are applied to ensure accurate compatibility results. This allows service providers to deliver tailored experiences while preventing feature activation on unsupported devices. ### How it works The compatibility checker processes device information through these key steps: 1. **Input Processing**: Captures device model, firmware version, device ID, and subscriber details. 2. **Data Normalization**: Converts device model names to lowercase and extracts the major firmware version number. 3. **Primary Compatibility Check**: Evaluates the normalized device model and major firmware version against a rules table to determine initial service eligibility. 4. **Exception Handling**: Applies special compatibility rules for specific device-firmware combinations, particularly for HD streaming eligibility. 5. **Results Generation**: Produces a final compatibility assessment showing which services and features are available for the specific device. ### Where teams use it - Telecommunications service provisioning - Streaming media platform compatibility - Mobile app feature availability - Device upgrade recommendations - Technical support troubleshooting - Customer self-service portals ## Inside the decision model Device Compatibility Checker ships as a JDM decision graph with 4 nodes, 2 decision tables and 15 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_expression_ normalize\_data_table_ determine\_compatibility_table_ check\_minor\_version _01_ ### Request _input_ Compatibility is resolved from just two request fields, deviceModel and deviceFirmware, while deviceId, subscriberId, and requestTimestamp ride along for provisioning and audit purposes. **Sample request**_JSON_ { "deviceModel": "iPhone 13 Pro", "deviceFirmware": "14.2.1", "deviceId": "A1B2C3D4E5F6", "subscriberId": "2022050789", "requestTimestamp": "2023-04-15T10:30:45Z" } _02_ ### Normalize Data _expression_ Free-text device names are made matchable before any lookup: normalizedModel applies lower(deviceModel) so 'iPhone 13 Pro' matches a contains check for 'iphone', and majorVersion takes number(split(deviceFirmware, '.')\[0\]) to reduce a string like '14.2.1' to the integer 14. Every rule downstream keys on these two normalized values instead of raw input. _normalizedModel_`lower(deviceModel)` _majorVersion_`number(split(deviceFirmware, '.')[0])` _03_ ### Determine Compatibility _table_ Capability flags are assigned per brand family with a first hit policy, each family's rows ordered from newest firmware down. Rows match normalizedModel with contains($, 'iphone'), 'samsung galaxy', or 'pixel', then band on majorVersion: iPhones need >= 15 for nextGenFeatures, >= 13 for advancedFeatures, and >= 10 for hdStreaming; Samsung Galaxy unlocks advanced features at >= 10 and HD at >= 8; Pixel at >= 6 and >= 4. Any recognized device keeps basicService true even below those bands, and an unrecognized model fails all four flags. Gating features on the firmware major version rather than the model name matches how carriers actually provision services: codecs, eSIM behavior, and streaming DRM ship with OS releases, not hardware. Reserving nextGenFeatures for iPhone firmware 15 and up while no Samsung or Pixel band grants it is simply how this catalog is staged, and defaulting unknown devices to no service is the safe posture for provisioning. Device ModelnormalizedModel Major VersionmajorVersion Basic Servicecompatibility.basicService HD Streamingcompatibility.hdStreaming Advanced Featurescompatibility.advancedFeatures Next Gen Featurescompatibility.nextGenFeatures contains($, 'iphone') \>= 15 true true true true contains($, 'iphone') \>= 13 and < 15 true true true false contains($, 'iphone') \>= 10 and < 13 true true false false contains($, 'iphone') < 10 true false false false contains($, 'samsung galaxy') \>= 10 true true true false contains($, 'samsung galaxy') \>= 8 and < 10 true true false false +5 more rows in the downloadable template _04_ ### Check Minor Version _table_ A second pass overrides the HD verdict for known problem combinations: contains($, 'iphone') with majorVersion <= 14 forces compatibility.hdStreaming to false, and the 'samsung galaxy' and 'pixel' rows force it false outright, while the blank fallback row re-emits the existing compatibility.hdStreaming value untouched. Exception tables like this exist because lab-tested firmware bands do not always survive contact with the field; when a specific build ships a broken player or DRM stack, support teams need a place to switch a capability off without rebuilding the main matrix. Keeping the override in its own small table means the temporary block can be removed later without touching the eleven-row compatibility grid. Device ModelnormalizedModel Major versionmajorVersion HD Streaming Finalcompatibility.hdStreaming contains($, 'iphone') <= 14 false contains($, 'samsung galaxy') \- false contains($, 'pixel') \- false \- \- compatibility.hdStreaming ## Other Telco templates [View all templates](/templates) [_Telco_ ### Dynamic Tariff Engine Rule-based pricing system for telecommunication services that automatically applies discounts based on user profiles, time periods, and location types. ](/industries/telco/templates/dynamic-tarrif-engine)[_Telco_ ### Regional Compliance Manager Automated system that applies region-specific data privacy rules for telecommunications services across EU, US, UK, Canada, and Australia. ](/industries/telco/templates/regional-compliance-manager)[_Telco_ ### Customer Eligibility Engine Intelligent system that analyzes customer data to determine service upgrades, loyalty rewards, and premium features based on usage patterns and account history. ](/industries/telco/templates/customer-eligibility-engine) ## Make this template your own. Load Device Compatibility Checker into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Customer Eligibility Engine - GoRules **URL:** https://gorules.io/industries/telco/templates/customer-eligibility-engine **Description:** Intelligent system that analyzes customer data to determine service upgrades, loyalty rewards, and premium features based on usage patterns and account history. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Customer Eligibility Engine Intelligent system that analyzes customer data to determine service upgrades, loyalty rewards, and premium features based on usage patterns and account history. Download template Share ### Solution This telecom decision engine evaluates customer profiles to create personalized upgrade paths and special offers. The system assigns loyalty tiers based on account longevity and spending patterns, with corresponding discount percentages ranging from 5% to 20%. It automatically identifies eligibility for service upgrades by analyzing account standing, contract status, and tier level. The engine calculates special offer eligibility in real-time based on actual usage metrics, identifying customers who would benefit from international calling bundles, data boosters, or family plans. For high-value customers, the system activates premium features like priority support, content streaming, international roaming, and concierge services. The solution delivers clear upgrade messaging that customer service representatives can use during interactions, creating a consistent experience across all touchpoints. ### How it works The decision graph processes customer data through five key evaluation stages: 1. **Account Status Evaluation**: Analyzes account age, payment history, and contract status to determine if the customer is in good standing. 2. **Loyalty Tier Assignment**: Categorizes customers into platinum, gold, silver, bronze, or standard tiers based on tenure, spending habits, and account status. 3. **Upgrade Eligibility Analysis**: Determines upgrade options by examining loyalty tier, contract status, and account standing, with special rules for contract renewal periods. 4. **Special Offers Generation**: Identifies relevant offers based on usage patterns, including international calling bundles for high-minute users and data boosters for customers approaching usage limits. 5. **Premium Features Allocation**: Activates premium service features based on loyalty tier and eligibility criteria, with a tiered approach to feature availability. ### Where teams use it - Customer retention campaigns targeting contract renewal periods - Upsell initiatives for underutilized service features - Automated service upgrade recommendations during customer interactions - Loyalty program management and tiered rewards distribution - Personalized offer generation based on usage patterns - Premium service feature allocation and management ## Inside the decision model Customer Eligibility Engine ships as a JDM decision graph with 6 nodes, 4 decision tables and 24 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ evaluateAccountStatus_table_ determineLoyaltyTier_table_ determineUpgradeEligibility_expression_ determineSpecialOffers_table_ determinePremiumFeatures _01_ ### Request _input_ Three request blocks feed the evaluation: accountInfo (accountAge, paymentHistory, monthlySpend, contractStatus) drives standing and tier, usageStats (callMinutes, dataUtilizationPercent) drives offers, and customerProfile supplies the devices list used for family-plan targeting. **Sample request**_JSON_ { "customerId": "CUST12345", "accountInfo": { "accountAge": 28, "paymentHistory": "excellent", "currentPlan": "Family Premium 50GB", "monthlySpend": 95, "contractStatus": "pending\_renewal" }, "usageStats": { "dataUsageGB": 42.5, "dataUtilizationPercent": 85, "callMinutes": 350, "textMessages": 1250 }, "customerProfile": { "segment": "consumer", "location": "Seattle, WA", "devices": \[ "iPhone 14", "iPad Air", "Apple Watch" \], "previousComplaints": 0 } } _02_ ### Evaluate Account Status _table_ Standing is graded first, using a first hit policy over accountInfo.accountAge, paymentHistory, and contractStatus. Accounts of 24 months or more with 'excellent' payments earn "excellent" status regardless of contract; 12 and 6 month tenures qualify as "good" or "fair" when payments are at least 'good' or 'fair' and the contract is 'active' or 'pending\_renewal'. Younger accounts under 6 months can still reach "fair" if payments are clean and the contract is 'active', while an 'expired' contract forces "poor" with goodStanding false, and anything unmatched lands in "review". Tenure-plus-payment scoring is how carriers separate credit risk from loyalty: a long, cleanly paid account is safe to upsell, while an expired contract means there is no active billing relationship to build on. Sending unclassifiable accounts to "review" rather than approving them keeps edge cases in front of a human instead of silently granting eligibility. Account Age (Months)accountInfo.accountAge Payment HistoryaccountInfo.paymentHistory Contract StatusaccountInfo.contractStatus Account Statuseligibility.accountStatus In Good Standingeligibility.goodStanding \>= 24 'excellent' \- "excellent" true \>= 12 'excellent', 'good' 'active', 'pending\_renewal' "good" true \>= 6 'excellent', 'good', 'fair' 'active', 'pending\_renewal' "fair" true < 6 'excellent', 'good' 'active' "fair" true \- 'poort' \- "poor" false \- \- 'expired' "poor" false +1 more row in the downloadable template _03_ ### Determine Loyalty Tier _table_ Tiering runs top-down with a first hit policy so the richest match wins: "platinum" needs 36 or more months of tenure, monthlySpend of at least 120, and 'excellent' status, earning a 20 percent loyaltyDiscountPercent. "gold" (24 months, spend 80) pays 15, "silver" (12 months, spend 50) pays 10, "bronze" (6 months, spend 30, any status) pays 5, and the catch-all row assigns "standard" with 0. Pairing tenure with monthly spend is standard loyalty design: either signal alone is gameable, but together they identify accounts whose lifetime value justifies a margin giveback. The 5-to-20 percent ladder is a business calibration rather than an industry constant, sized so the top discount stays well below the revenue gap between a 120-dollar and a 30-dollar account. Account Age (Months)accountInfo.accountAge Monthly Spend ($)accountInfo.monthlySpend Account Statuseligibility.accountStatus Loyalty Tiereligibility.loyaltyTier Loyalty Discounteligibility.loyaltyDiscountPercent \>= 36 \>= 120 'excellent' "platinum" 20 \>= 24 \>= 80 'excellent', 'good' "gold" 15 \>= 12 \>= 50 'excellent', 'good', 'fair' "silver" 10 \>= 6 \>= 30 \- "bronze" 5 \- \- \- "standard" 0 _04_ ### Determine Upgrade Eligibility _table_ Upgrade paths depend on three signals: eligibility.goodStanding, eligibility.loyaltyTier, and a contract condition expression testing accountInfo.contractStatus == 'pending\_renewal' or 'ending\_soon'. Platinum and gold customers in good standing get canUpgrade and premiumPlanEligible, and if their contract is in the renewal window they also unlock earlyUpgradeEligible with the message "High-priority upgrade eligible. Offers for all plan categories." Silver needs the renewal window for a standard upgrade, bronze and standard tiers only qualify when the contract is 'ending\_soon', and goodStanding false blocks upgrades entirely. Concentrating the best offers in the 'pending\_renewal' and 'ending\_soon' windows mirrors how retention actually works: churn risk spikes when a commitment lapses, so that is when an early device upgrade is worth its subsidy cost. Restricting proactive premium offers to the top two tiers keeps acquisition-style spend pointed at the accounts most likely to repay it. Good Standingeligibility.goodStanding Loyalty Tiereligibility.loyaltyTier Contract Condition Eligible For Upgradeeligibility.canUpgrade Premium Plan Eligibleeligibility.premiumPlanEligible Early Upgrade Eligibleeligibility.earlyUpgradeEligible Upgrade Messageeligibility.upgradeMessage true \['platinum', 'gold'\] accountInfo.contractStatus == 'pending\_renewal' or accountInfo.contractStatus == 'ending\_soon' true true true "High-priority upgrade eligible. Offers for all plan categories." true \['platinum', 'gold'\] \- true true false "Premium plan upgrade eligible based on customer tier." true \['silver'\] accountInfo.contractStatus == 'pending\_renewal' or accountInfo.contractStatus == 'ending\_soon' true false false "Standard upgrade eligible based on contract status." true \['bronze', 'standard'\] accountInfo.contractStatus == 'ending\_soon' true false false "Basic upgrade eligible as contract is ending." false \- \- false false false "Not eligible for upgrades due to account standing." \- \- \- false false false "Standard eligibility rules apply." _05_ ### Determine Special Offers _expression_ Offer flags are computed directly from behavior: internationalBundle fires when usageStats.callMinutes > 300, dataBooster when dataUtilizationPercent > 80, familyPlan when len(customerProfile.devices) >= 3, and deviceUpgrade and loyaltyReward reuse the eligibility results from earlier nodes. offerCount then counts the true flags, and that count feeds the premium features table as a proxy for how engaged the customer is. _eligibility.specialOffers_`{ "internationalBundle": usageStats.callMinutes > 300, "dataBooster": usageStats.dataUtilizationPercent > 80, "familyPlan": len(customerProfile.devices) >= 3, "deviceUpgrade": eligibility.canUpgrade, "loyaltyReward": eligibility.loyaltyTier in ["platinum", "gold", "silver"] }` _eligibility.offerCount_`len(filter(values($.eligibility.specialOffers), # == true))` _06_ ### Determine Premium Features _table_ Feature entitlements are unlocked tier by tier under a first hit policy, with eligibility.offerCount acting as an engagement gate. "platinum" customers in good standing with 3 or more active offers get all four flags, prioritySupport through conciergeService; "gold" with at least 2 offers loses only the concierge, "silver" with 1 keeps prioritySupport and contentStreaming, and "bronze" gets prioritySupport alone. Any account where goodStanding is false, or that matches nothing, receives no features and an explanatory features.message. Granting perks like internationalRoaming and concierge service only where tier and engagement overlap is a sensible cost control: these features carry real servicing cost, so tying them to customers who already qualify for multiple offers keeps them aimed at accounts the carrier most wants to retain. The message column gives support reps a ready-made explanation for why a feature is or is not available. Loyalty Tiereligibility.loyaltyTier Good Standingeligibility.goodStanding Special Offer Counteligibility.offerCount Priority Supportfeatures.prioritySupport Content Streamingfeatures.contentStreaming International Roamingfeatures.internationalRoaming Concierge Servicefeatures.conciergeService Features Messagefeatures.message \['platinum'\] true \>= 3 true true true true "All premium features available based on platinum status." \['gold'\] true \>= 2 true true true false "Most premium features available based on gold status." \['silver'\] true \>= 1 true true false false "Selected premium features available based on silver status." \['bronze'\] true \- true false false false "Basic premium features available based on bronze status." \- false \- false false false false "No premium features available due to account standing." \- \- \- false false false false "No premium features available." ## Other Telco templates [View all templates](/templates) [_Telco_ ### Dynamic Tariff Engine Rule-based pricing system for telecommunication services that automatically applies discounts based on user profiles, time periods, and location types. ](/industries/telco/templates/dynamic-tarrif-engine)[_Telco_ ### Regional Compliance Manager Automated system that applies region-specific data privacy rules for telecommunications services across EU, US, UK, Canada, and Australia. ](/industries/telco/templates/regional-compliance-manager)[_Telco_ ### Service Level Agreement Enforcement Automated system that monitors telecommunication service levels, detects SLA violations, and triggers appropriate compensation and escalation responses. ](/industries/telco/templates/service-level-agreement-enforcement) ## Make this template your own. Load Customer Eligibility Engine into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Cellular Data Rollover System - GoRules **URL:** https://gorules.io/industries/telco/templates/cellular-data-rollover-system **Description:** Intelligent system that automatically calculates and applies unused data transfers to next billing cycles based on customer plan tiers and usage patterns. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Cellular Data Rollover System Intelligent system that automatically calculates and applies unused data transfers to next billing cycles based on customer plan tiers and usage patterns. Download template Share ### Solution This data rollover system automatically manages the transfer of unused mobile data to subsequent billing cycles for telecom subscribers. The solution analyzes each customer's current plan type, monthly data allowance, and consumption patterns to determine rollover eligibility and calculate precise amounts of data to carry forward. Premium subscribers benefit from unlimited rollover capabilities, while standard and basic plan subscribers receive proportional rollover allowances based on their service tier. The system enforces plan-specific restrictions, including maximum rollover amounts (50% of monthly allowance for standard plans, 25% for basic plans) and caps consecutive rollovers at three billing cycles to prevent excessive accumulation. When processing each billing cycle transition, the system generates clear customer notifications explaining rollover status and available data amounts for the upcoming period. ### How it works The data rollover process functions through a sequence of logical evaluations: 1. **Usage Analysis**: Calculates unused data by subtracting actual consumption from monthly allowance 2. **Eligibility Check**: Verifies if the customer has positive unused data and plan-level rollover permissions 3. **Plan Assessment**: Applies different rollover calculations based on customer's service tier: - Premium plans: Full rollover of all unused data - Standard plans: Rollover up to 50% of monthly allowance - Basic plans: Rollover up to 25% of monthly allowance 4. **Consecutive Rollover Limitation**: Prevents excessive data accumulation by resetting rollover after three consecutive cycles 5. **Customer Notification**: Generates personalized messages explaining rollover status and available data for next billing cycle ### Where teams use it - Mobile service providers - MVNO (Mobile Virtual Network Operators) - Corporate telecommunications management - Family plan data allocation - Data sharing across multiple devices - Prepaid mobile service offerings ## Inside the decision model Cellular Data Rollover System ships as a JDM decision graph with 6 nodes, 1 decision table and 5 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ dataRolloverRequest_expression_ calculateUnusedData_table_ determineRolloverAmount_switch_ verifyRollover_expression_ processSuccessfulRollover_expression_ processNoRollover _01_ ### Data Rollover Request _input_ Two request objects are enough for a cycle transition: plan brings type, monthlyDataAllowance, and rolloverEligible, while currentBillingCycle reports dataUsed, the running consecutiveRollovers counter, and any rolloverData already banked. **Sample request**_JSON_ { "plan": { "type": "premium", "monthlyDataAllowance": 50, "rolloverEligible": true }, "currentBillingCycle": { "dataUsed": 35, "consecutiveRollovers": 1, "rolloverData": 5 } } _02_ ### Calculate Unused Data _expression_ Before any tier rule runs, the leftover balance is established: unusedData is plan.monthlyDataAllowance minus currentBillingCycle.dataUsed, isPositiveUnusedData flags whether there is anything to carry at all, and previousRolloverAmount defaults currentBillingCycle.rolloverData to 0 with ?? so first-cycle customers are handled cleanly. These three values are what the rollover table actually reads. _unusedData_`plan.monthlyDataAllowance - currentBillingCycle.dataUsed` _isPositiveUnusedData_`$.unusedData > 0` _previousRolloverAmount_`currentBillingCycle.rolloverData ?? 0` _03_ ### Determine Rollover Amount _table_ Carry-forward amounts are tiered by plan.type under a first hit policy, with the guard rows for exhausted eligibility at the bottom. 'premium' plans with isPositiveUnusedData true and consecutiveRollovers < 3 bank the full unusedData + previousRolloverAmount; 'standard' plans take min(\[unusedData + previousRolloverAmount, plan.monthlyDataAllowance \* 0.5\]) and 'basic' plans min(\[unusedData, plan.monthlyDataAllowance \* 0.25\]). Once the counter reaches >= 3 the amount is forced to 0 with the reason 'Maximum consecutive rollovers (3) reached', and no unused data likewise rolls nothing. Capping cheaper tiers at 50% and 25% of the monthly allowance is how carriers bound the liability that banked data represents: every rolled gigabyte is capacity sold once but deliverable twice. The three-cycle ceiling serves the same purpose for premium accounts, where the unlimited carry would otherwise compound each month, and the reason strings double as customer-facing copy so billing does not need to re-derive the explanation. Plan Typeplan.type Has Unused DataisPositiveUnusedData Consecutive RolloverscurrentBillingCycle.consecutiveRollovers Rollover AmountnextBillingCycle.rolloverData ReasonnextBillingCycle.rolloverReason 'premium' true < 3 unusedData + previousRolloverAmount 'Unlimited rollover for Premium plan' 'standard' true < 3 min(\[unusedData + previousRolloverAmount, plan.monthlyDataAllowance \* 0.5\]) 'Standard plan can rollover up to 50% of monthly allowance' 'basic' true < 3 min(\[unusedData, plan.monthlyDataAllowance \* 0.25\]) 'Basic plan can rollover up to 25% of monthly allowance' \- true \>= 3 0 'Maximum consecutive rollovers (3) reached' \- false \- 0 'No unused data to rollover' _04_ ### Verify Rollover _switch_ Branching is a single test: when nextBillingCycle.rolloverData > 0 the flow takes the success path, and the default statement routes everything else to the no-rollover handler. Splitting here lets the two outcomes set different messages, counters, and statuses without conditional logic inside the expression nodes. _nextBillingCycle.rolloverData > 0_ `Process Successful Rollover` _otherwise_ `Process No Rollover` _05_ ### Process Successful Rollover _expression_ On the success branch the response is assembled: responseMessage interpolates nextBillingCycle.rolloverData into a customer notification, consecutiveRollovers is incremented from the current cycle's count, and nextBillingCycle.status is set to 'approved' so billing applies the banked data next period. _responseMessage_`` `Rollover successful. You have ${nextBillingCycle.rolloverData} GB of rollover data available for your next billing cycle.` `` _nextBillingCycle.consecutiveRollovers_`currentBillingCycle.consecutiveRollovers + 1` _nextBillingCycle.status_`'approved'` _06_ ### Process No Rollover _expression_ The empty branch closes the loop the other way: responseMessage explains the outcome using nextBillingCycle.rolloverReason with a fallback of 'No unused data available', consecutiveRollovers resets to 0 so the customer earns a fresh three-cycle window, and status becomes 'no\_rollover'. Resetting the counter here is what makes the cap a limit on consecutive carries rather than a lifetime one. _responseMessage_`` `No data rolled over. Reason: ${nextBillingCycle.rolloverReason ?? 'No unused data available'}` `` _nextBillingCycle.consecutiveRollovers_`0` _nextBillingCycle.status_`'no_rollover'` ## Other Telco templates [View all templates](/templates) [_Telco_ ### Dynamic Tariff Engine Rule-based pricing system for telecommunication services that automatically applies discounts based on user profiles, time periods, and location types. ](/industries/telco/templates/dynamic-tarrif-engine)[_Telco_ ### Regional Compliance Manager Automated system that applies region-specific data privacy rules for telecommunications services across EU, US, UK, Canada, and Australia. ](/industries/telco/templates/regional-compliance-manager)[_Telco_ ### Customer Eligibility Engine Intelligent system that analyzes customer data to determine service upgrades, loyalty rewards, and premium features based on usage patterns and account history. ](/industries/telco/templates/customer-eligibility-engine) ## Make this template your own. Load Cellular Data Rollover System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Seller Fee Calculator - GoRules **URL:** https://gorules.io/industries/retail/templates/seller-fee-calculator **Description:** Adaptive fee structure that automatically calculates transaction rates, subscription costs, and service charges based on seller metrics and program eligibility. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Seller Fee Calculator Adaptive fee structure that automatically calculates transaction rates, subscription costs, and service charges based on seller metrics and program eligibility. Download template Share ### Solution This fee calculation system provides marketplace sellers with transparent, personalized pricing based on their business profile. The system evaluates seller category (premium, standard, or basic), applying tiered fee structures that reward higher sales volume with lower transaction rates. Premium sellers receive the lowest rates starting at 8%, while standard and basic sellers have higher base rates adjusted by monthly sales performance. Beyond base rates, the system analyzes seller performance ratings to offer additional discounts for high-quality merchants. Exceptional sellers with ratings above 4.8 can receive up to 3% rate reductions, while those with poor ratings face penalty charges. Special program participation unlocks exclusive promotional benefits. The calculator provides sellers with a clear breakdown of transaction fees, subscription costs, and any additional charges, helping them understand their total marketplace costs and incentivizing performance improvements. ### How it works The seller fee calculator applies business rules through several evaluation stages: 1. **Input Processing**: The system receives seller data including category, monthly sales volume, performance rating, and special program status. 2. **Base Fee Determination**: A decision table evaluates seller category and sales volume to assign the appropriate base fee rate and subscription tier cost. 3. **Performance Adjustment**: A second decision table analyzes performance metrics and program participation to apply rate adjustments and determine eligibility for promotional benefits. 4. **Low Performance Penalties**: Sellers with ratings below benchmarks receive rate increases and additional service charges. 5. **Fee Calculation**: The final expression node calculates the effective fee rate, transaction fees based on monthly volume, and combines all charges for a total monthly fee. ### Where teams use it - Online marketplaces and retail platforms - SaaS platforms with tiered pricing models - Affiliate marketing programs - Digital content distribution networks - Franchise business models - Service provider marketplaces ## Inside the decision model Seller Fee Calculator ships as a JDM decision graph with 4 nodes, 2 decision tables and 16 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ determineCategoryFees_table_ calculateAdditionalFees_expression_ calculateTotalFees _01_ ### Request _input_ One block carries everything: sellerData, whose category, monthlySalesVolume, performanceRating, and inSpecialProgram fields drive both fee tables and the final total. **Sample request**_JSON_ { "sellerData": { "category": "premium", "monthlySalesVolume": 72000, "performanceRating": 4.9, "inSpecialProgram": true } } _02_ ### Determine Category Fees _table_ Base pricing pairs sellerData.category with sellerData.monthlySalesVolume under a first hit policy. 'premium' sellers pay a 0.08 rate above 100000 in monthly sales, 0.10 above 50000, and 0.12 otherwise, always with a 99.99 subscriptionFee; 'standard' steps through 0.15, 0.18, and 0.20 with a 29.99 subscription; 'basic' pays 0.25 above 25000 or 0.30 with no subscription at all, and the blank fallback row prices unknown categories at 0.35 on the 'basic' tier. The structure is the classic subscription-versus-take-rate trade seen in professional seller plans: a fixed 99.99 per month buys the lowest transaction rates, while free 'basic' accounts pay for the platform entirely through the 0.30 cut. Volume breaks inside each tier reward growth without a plan change, and defaulting unclassified sellers to the most expensive 0.35 rate is a deliberate nudge to get every account properly categorized. Seller CategorysellerData.category Monthly Sales VolumesellerData.monthlySalesVolume Base Fee Ratefees.baseFeeRate Subscription Tierfees.subscriptionTier Subscription Feefees.subscriptionFee 'premium' \> 100000 0.08 'premium' 99.99 'premium' \> 50000 0.10 'premium' 99.99 'premium' \- 0.12 'premium' 99.99 'standard' \> 75000 0.15 'standard' 29.99 'standard' \> 25000 0.18 'standard' 29.99 'standard' \- 0.20 'standard' 29.99 +3 more rows in the downloadable template _03_ ### Calculate Additional Fees _table_ Adjustments layer on top of the base rate from sellerData.performanceRating and inSpecialProgram, again first hit. Ratings above 4.8 earn a rateAdjustment of -0.03 inside the special program or -0.02 outside it, ratings above 4.5 get -0.01 only with program membership, and hasPromotionalBenefits turns true only on the in-program rows. On the penalty side, a rating below 3.0 adds 0.05 to the rate plus a 25 additionalServiceCharge, below 4.0 adds 0.02 plus 10, and the fallback row leaves everything at zero. Row order does real work here: the harsher below-3.0 penalty sits above the below-4.0 row so the worst sellers cannot match the milder rule first. Tying the deepest discount to both a 4.8+ rating and program membership follows how platforms reserve their best economics for enrolled top performers, and the flat service charges on weak ratings are a sensible way to price the extra support and dispute handling those accounts generate. Performance RatingsellerData.performanceRating Special ProgramsellerData.inSpecialProgram Rate Adjustmentfees.rateAdjustment Additional Service Chargefees.additionalServiceCharge Promotional Benefitsfees.hasPromotionalBenefits \> 4.8 true \-0.03 0 true \> 4.8 false \-0.02 0 false \> 4.5 true \-0.01 0 true \> 4.5 false 0 0 false < 3.0 \- 0.05 25 false < 4.0 \- 0.02 10 false +1 more row in the downloadable template _04_ ### Calculate Total Fees _expression_ Three expressions turn the assembled fees into a bill: effectiveFeeRate adds fees.rateAdjustment to fees.baseFeeRate, transactionFee multiplies that rate by sellerData.monthlySalesVolume, and totalMonthlyFee adds the subscriptionFee and additionalServiceCharge on top. With passThrough off, the seller sees just these three numbers as the breakdown of what they owe. _effectiveFeeRate_`fees.baseFeeRate + fees.rateAdjustment` _transactionFee_`sellerData.monthlySalesVolume * $.effectiveFeeRate` _totalMonthlyFee_`$.transactionFee + fees.subscriptionFee + fees.additionalServiceCharge` ## Other Retail templates [View all templates](/templates) [_Retail_ ### Seller Approval Workflow Rules-based marketplace solution that evaluates business credentials, expertise, inventory quality, and background checks to maintain seller standards. ](/industries/retail/templates/seller-approval-workflow)[_Retail_ ### Dynamic Marketplace Commission Calculator Automated system for calculating seller commission rates based on product category, sales data, seller performance, and promotional periods. ](/industries/retail/templates/dynamic-marketplace-comission-calculator)[_Retail_ ### Product Listing Scoring Automated scoring system that evaluates and ranks product listings based on image quality, description completeness, and other key marketplace success factors. ](/industries/retail/templates/product-listing-scoring) ## Make this template your own. Load Seller Fee Calculator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Seller Approval Workflow - GoRules **URL:** https://gorules.io/industries/retail/templates/seller-approval-workflow **Description:** Rules-based marketplace solution that evaluates business credentials, expertise, inventory quality, and background checks to maintain seller standards. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Seller Approval Workflow Rules-based marketplace solution that evaluates business credentials, expertise, inventory quality, and background checks to maintain seller standards. Download template Share ### Solution This automated seller approval system streamlines the onboarding process by evaluating multiple qualification factors before accepting new merchants. It analyzes business credentials by verifying documentation authenticity and assessing company maturity based on years in operation. The expertise validation ensures merchants have adequate knowledge in their primary category, while inventory quality assessment examines product authenticity, compliance with regulations, and image quality standards. The system incorporates comprehensive background screening including criminal record verification, credit assessment, and identity confirmation. When evaluating applications, each factor receives a weighted score that contributes to the final approval decision. Rejected applications include specific reasoning, allowing potential sellers to address deficiencies. Approved sellers receive immediate confirmation with their qualification score, enabling marketplace operators to maintain consistent quality standards while efficiently processing applications. ### How it works The decision graph processes seller applications through a series of evaluation stages: 1. **Input Processing**: Collects business credentials, category expertise information, inventory quality data, and background check results. 2. **Business Credential Validation**: Assigns scores based on documentation validity and business longevity, categorizing businesses as new, established, or mature. 3. **Qualification Assessment**: Evaluates the combined factors of business status, category expertise rating, inventory quality, and background check results. 4. **Scoring Algorithm**: Calculates a final qualification score by weighing each factor appropriately and applying business rules. 5. **Approval Decision**: Routes applications through approval or rejection paths based on qualification thresholds. 6. **Result Generation**: Creates final response with approval status, qualification score, and timestamp. ### Where teams use it - Online marketplaces and retail platforms - B2B wholesale supplier networks - Specialty product marketplaces - Artisan and handcrafted goods platforms - Service provider networks - Digital product marketplaces ## Inside the decision model Seller Approval Workflow ships as a JDM decision graph with 6 nodes, 2 decision tables and 11 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ sellerApplicationRequest_table_ evaluateBusinessCredentials_table_ evaluateSellerQualifications_switch_ routeApplication_expression_ generateApprovalResult_expression_ generateRejectionResult _01_ ### Seller Application Request _input_ Every application carries four top-level blocks: businessCredentials, categoryExpertise, inventoryQuality, and backgroundCheck. Fields like businessCredentials.yearsInBusiness, categoryExpertise.rating, and backgroundCheck.passed feed the two scoring tables directly. **Sample request**_JSON_ { "businessCredentials": { "hasValidDocumentation": true, "yearsInBusiness": 2.5, "businessName": "TechGadgets LLC", "businessType": "Limited Liability Company", "taxId": "12-3456789" }, "categoryExpertise": { "primaryCategory": "Electronics", "yearsOfExperience": 3, "certifications": \[ "Consumer Electronics Specialist" \], "rating": 4 }, "inventoryQuality": { "sampleProducts": 15, "brandAuthenticity": true, "productCompliance": true, "productImageQuality": "high", "rating": 4.2 }, "backgroundCheck": { "passed": true, "criminalRecord": false, "creditScore": 720, "identityVerified": true } } _02_ ### Evaluate Business Credentials _table_ Documentation validity is checked before anything else: with a first hit policy, the row where businessCredentials.hasValidDocumentation is false returns a credentialScore of 0 and a businessStatus of 'invalid'. Valid businesses are then banded by businessCredentials.yearsInBusiness, with under 1 year scoring 15 as 'new', the \[1..3) range scoring 25 as 'established', and 3 or more years scoring 35 as 'mature'. Gating on documentation first mirrors how marketplaces actually onboard merchants, since a missing registration or tax record stops review regardless of other strengths. The one and three year cutoffs are sensible proxies for survival risk, as most small-business failures happen in the first years of trading, so longevity earns a progressively larger share of the credential score. Has Valid DocumentationbusinessCredentials.hasValidDocumentation Years In BusinessbusinessCredentials.yearsInBusiness Credential Scoreevaluation.credentialScore Business Statusevaluation.businessStatus Credential Notesevaluation.credentialNotes false \- 0 'invalid' 'Business documentation is missing or invalid' true < 1 15 'new' 'New business with limited history' true \[1..3) 25 'established' 'Established business with moderate history' true \>= 3 35 'mature' 'Mature business with solid history' _03_ ### Evaluate Seller Qualifications _table_ Four signals converge here under a first hit policy: evaluation.businessStatus, categoryExpertise.rating, inventoryQuality.rating, and backgroundCheck.passed. An 'invalid' status short-circuits to a finalScore of 0, a failed background check caps the score at 15 or 30 depending on whether expertise sits below or at least 3, and a passed check with inventoryQuality.rating below 3 still rejects at 40 with 'Low inventory quality score'. Sellers rating at least 3 on both expertise and inventory are approved at 85 as a 'Strong seller profile', and the fallback row approves remaining passed applicants at evaluation.credentialScore + 30 as a 'Standard seller approval'. Treating the background check as a hard gate is standard marketplace practice, because fraud and counterfeit exposure lands on the platform no matter how skilled the seller is. The inventory quality floor protects the catalog itself, while the additive fallback keeps borderline but clean applicants in play, so rejections come with a specific stated reason rather than a single opaque score. Business Statusevaluation.businessStatus Category ExpertisecategoryExpertise.rating Inventory QualityinventoryQuality.rating Background Check PassedbackgroundCheck.passed Final Scoreevaluation.finalScore Is Approvedevaluation.isApproved Evaluation Notesevaluation.notes \== 'invalid' \- \- \- 0 false 'Business credentials are invalid' \- < 3 \- false 15 false 'Failed background check and low category expertise' \- \>= 3 \- false 30 false 'Failed background check despite good category expertise' \- \- < 3 true 40 false 'Low inventory quality score' \- \>= 3 \>= 3 true 85 true 'Strong seller profile with good expertise and inventory' \- \>= 4 \>= 4 true 95 true 'Exceptional seller profile with excellent expertise and inventory' +1 more row in the downloadable template _04_ ### Route Application _switch_ Routing splits on a single boolean: the condition evaluation.isApproved == true sends the application down the approval branch, and the default statement catches everything else as a rejection. Keeping the branch logic out of the scoring tables lets each outcome build its own response payload. _evaluation.isApproved == true_ `Generate Approval Result` _otherwise_ `Generate Rejection Result` _05_ ### Generate Approval Result _expression_ Approved applications are reduced to a clean response: status is set to 'APPROVED', score carries evaluation.finalScore forward, and approvalDate is stamped with date('now'). With passThrough disabled, intermediate evaluation fields stay out of the payload returned to the onboarding system. _status_`'APPROVED'` _score_`evaluation.finalScore` _approvalDate_`date('now')` _06_ ### Generate Rejection Result _expression_ On the rejection branch the shape mirrors the approval payload, with status set to 'REJECTED' and a rejectionDate from date('now'). Returning evaluation.finalScore even on rejection lets applicants see how far they fell short of the approval bar before reapplying. _status_`'REJECTED'` _score_`evaluation.finalScore` _rejectionDate_`date('now')` ## Other Retail templates [View all templates](/templates) [_Retail_ ### Dynamic Marketplace Commission Calculator Automated system for calculating seller commission rates based on product category, sales data, seller performance, and promotional periods. ](/industries/retail/templates/dynamic-marketplace-comission-calculator)[_Retail_ ### Product Listing Scoring Automated scoring system that evaluates and ranks product listings based on image quality, description completeness, and other key marketplace success factors. ](/industries/retail/templates/product-listing-scoring)[_Retail_ ### Marketplace Seller Grading System Objective performance evaluation system that scores sellers on delivery, satisfaction, inventory, and compliance metrics to determine marketplace status. ](/industries/retail/templates/marketplace-seller-grading-system) ## Make this template your own. Load Seller Approval Workflow into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Returns and Refund Policy - GoRules **URL:** https://gorules.io/industries/retail/templates/returns-and-refund-policy **Description:** Automated system that determines return eligibility, responsibility, and refund calculations based on purchase conditions and seller policies. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Returns and Refund Policy Automated system that determines return eligibility, responsibility, and refund calculations based on purchase conditions and seller policies. Download template Share ### Solution This policy enforcement system streamlines the returns process by evaluating multiple factors to determine eligibility and responsibility. The system first checks if a return request falls within the seller's specified time window and meets their return policy requirements. For eligible returns, it identifies whether the responsibility lies with the buyer, seller, or platform based on the reported issue and product condition. Once responsibility is established, the system calculates the appropriate refund amount, factoring in potential restocking fees when applicable. It also determines whether return shipping costs should be covered and by which party. The system provides clear explanations at each decision point and estimates processing times based on the responsible party. This creates transparency for all stakeholders while ensuring consistent application of marketplace policies across all transactions. ### How it works The decision graph processes return requests through three interconnected nodes: 1. **Return Eligibility Assessment**: Evaluates if the return falls within the allowed timeframe (standard or extended), checks if returns are permitted by the seller's policy, and considers the reason for the return. 2. **Responsibility Determination**: Assigns responsibility to the appropriate party (buyer, seller, platform, or shared) based on the return reason, item condition, and eligibility determination. For example, damaged new items are the seller's responsibility, while "changed mind" returns are the buyer's responsibility. 3. **Refund Calculation**: Computes the refund amount based on eligibility and responsibility, applying restocking fees when appropriate. It also determines whether return shipping costs are covered and estimates processing time based on the responsible party. ### Where teams use it - E-commerce marketplaces - Retail return centers - Online shopping platforms - Drop-shipping businesses - Third-party seller management - Multi-vendor retail solutions - Customer service automation ## Inside the decision model Returns and Refund Policy ships as a JDM decision graph with 4 nodes, 2 decision tables and 13 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ returnEligibility_table_ responsibilityDetermination_expression_ refundCalculation _01_ ### Request _input_ A return request carries the flat fields returnReason, daysSincePurchase, originalPrice, and itemCondition alongside sellerPolicy with returnsAllowed, returnWindow, restockingFeePercent, and freeReturnShipping. The orderInfo, buyerInfo, and productDetails blocks travel with the request for context. **Sample request**_JSON_ { "orderInfo": { "orderId": "ORD-12345", "purchaseDate": "2023-10-15" }, "returnReason": "damaged", "daysSincePurchase": 25, "originalPrice": 89.99, "itemCondition": "new", "sellerPolicy": { "returnsAllowed": true, "returnWindow": 30, "restockingFeePercent": 15, "freeReturnShipping": false }, "buyerInfo": { "id": "USR-789", "returnHistory": { "totalReturns": 3, "recentDisputes": 0 } }, "productDetails": { "category": "electronics", "isWarrantyActive": true } } _02_ ### Return Eligibility _table_ Eligibility is decided first, with a first hit policy over daysSincePurchase, sellerPolicy.returnsAllowed, and returnReason. Within 30 days and with returns allowed, the reasons 'damaged', 'defective', and 'wrong\_item' produce the code 'eligible', while 'changed\_mind' maps to 'eligible\_restocking\_fee'; between 30 and 60 days only 'damaged' and 'defective' qualify as 'eligible\_extended', anything past 60 days fails as 'ineligible\_timeframe', returnsAllowed set to false fails as 'ineligible\_non\_returnable', and the blank row catches the rest as 'ineligible\_other'. The 30-day window is the standard return period across most of retail, and extending it to 60 days only for product faults mirrors how sellers separate goodwill remorse returns from defect claims that would surface later anyway. Cutting off entirely past 60 days bounds the seller's open liability, and letting sellerPolicy.returnsAllowed veto everything keeps final-sale merchandise enforceable in the same table. Days Since PurchasedaysSincePurchase Item ReturnablesellerPolicy.returnsAllowed Return ReasonreturnReason Is EligiblereturnStatus.isEligible Eligibility CodereturnStatus.code Eligibility MessagereturnStatus.message < 30 true 'damaged', 'defective', 'wrong\_item' true 'eligible' 'The return is within policy timeframe and eligible for processing.' < 30 true 'changed\_mind' true 'eligible\_restocking\_fee' 'Return is eligible but subject to restocking fee per seller policy.' \> 30, <= 60 true 'damaged', 'defective' true 'eligible\_extended' 'Extended return period applies for product issues.' \> 60 \- \- false 'ineligible\_timeframe' 'Return period has expired.' \- false \- false 'ineligible\_non\_returnable' 'Item is marked as non-returnable in seller policy.' \- \- \- false 'ineligible\_other' 'Return does not meet eligibility criteria.' _03_ ### Responsibility Determination _table_ Fault assignment reads returnReason, itemCondition, and the upstream returnStatus.isEligible under a first hit policy. Eligible 'damaged' or 'defective' returns on 'new' or 'like\_new' items assign resolution.responsibleParty to 'seller', 'wrong\_item' is also the seller's fault, 'damaged\_in\_transit' goes to 'platform' under shipping protection, 'changed\_mind' lands on the 'buyer', and 'damaged' or 'defective' claims on 'used' or 'refurbished' items resolve as 'shared'. Ineligible returns get 'none' with refundApproved false, and the fallback row escalates unmatched cases to 'platform' review without approving a refund. This split follows how marketplaces genuinely allocate return costs: sellers own defects on goods sold as new, transit damage sits with whoever runs the shipping program, and remorse returns are the buyer's expense. The 'shared' outcome for used and refurbished items is a pragmatic choice because pre-existing wear makes fault hard to attribute, and defaulting unknown combinations to platform review rather than an automatic refund keeps edge cases with a human. Return ReasonreturnReason Item ConditionitemCondition Is EligiblereturnStatus.isEligible Responsible Partyresolution.responsibleParty Refund Approvedresolution.refundApproved Responsibility Noteresolution.note 'damaged', 'defective' 'new', 'like\_new' true 'seller' true 'Seller is responsible for product issues on new items.' 'wrong\_item' \- true 'seller' true 'Seller is responsible for shipping incorrect item.' 'damaged\_in\_transit' \- true 'platform' true 'Platform shipping protection covers transit damage.' 'changed\_mind' \- true 'buyer' true 'Buyer is responsible for return costs when changing mind.' 'damaged', 'defective' 'used', 'refurbished' true 'shared' true 'Responsibility is shared for used/refurbished items with issues.' \- \- false 'none' false 'No refund applicable for ineligible returns.' +1 more row in the downloadable template _04_ ### Refund Calculation _expression_ Money and logistics resolve in one expression step. refundAmount pays the full originalPrice when resolution.refundApproved is true, discounts it by sellerPolicy.restockingFeePercent when the code is 'eligible\_restocking\_fee', and drops to 0 otherwise; returnShippingCovered and refundShipping are true whenever the responsibleParty is 'seller' or 'platform', so buyers only pay return postage on their own remorse returns. processingTimeEstimate maps to 7, 5, or 3 days by responsible party, with 14 days for unapproved cases that need review. _refundAmount_`resolution.refundApproved == true ? (returnStatus.code == 'eligible_restocking_fee' ? originalPrice * (1 - sellerPolicy.restockingFeePercent / 100) : originalPrice) : 0` _refundShipping_`resolution.responsibleParty == 'seller' or resolution.responsibleParty == 'platform'` _returnShippingCovered_`resolution.responsibleParty == 'seller' or resolution.responsibleParty == 'platform'` _processingTimeEstimate_`resolution.refundApproved == true ? (resolution.responsibleParty == 'platform' ? 7 : resolution.responsibleParty == 'seller' ? 5 : 3) : 14` ## Other Retail templates [View all templates](/templates) [_Retail_ ### Seller Approval Workflow Rules-based marketplace solution that evaluates business credentials, expertise, inventory quality, and background checks to maintain seller standards. ](/industries/retail/templates/seller-approval-workflow)[_Retail_ ### Dynamic Marketplace Commission Calculator Automated system for calculating seller commission rates based on product category, sales data, seller performance, and promotional periods. ](/industries/retail/templates/dynamic-marketplace-comission-calculator)[_Retail_ ### Product Listing Scoring Automated scoring system that evaluates and ranks product listings based on image quality, description completeness, and other key marketplace success factors. ](/industries/retail/templates/product-listing-scoring) ## Make this template your own. Load Returns and Refund Policy into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Product Listing Scoring - GoRules **URL:** https://gorules.io/industries/retail/templates/product-listing-scoring **Description:** Automated scoring system that evaluates and ranks product listings based on image quality, description completeness, and other key marketplace success factors. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Product Listing Scoring Automated scoring system that evaluates and ranks product listings based on image quality, description completeness, and other key marketplace success factors. Download template Share ### Solution This scoring system improves marketplace performance by evaluating five critical aspects of product listings. The system analyzes image quality by counting total images, checking for high-resolution photos, and verifying variant images exist. For descriptions, it examines word count, bullet point usage, specification details, and optimal keyword density to ensure listings attract search traffic. The solution also evaluates pricing competitiveness through market rank analysis and discount availability. Inventory management scores are calculated based on stock levels and shipping timeframes. Each category receives individual ratings plus an overall score with performance classification. This helps sellers quickly identify specific improvement areas, prioritize optimization efforts, and implement targeted changes to boost visibility and conversion rates. ### How it works The decision graph evaluates product listings through a systematic process: 1. **Data Input**: Receives listing information including image details, description characteristics, pricing position, and inventory status. 2. **Image Quality Assessment**: Evaluates the number of images, resolution quality, and presence of variant images. 3. **Content Evaluation**: Analyzes description word count, bullet point usage, specification details, and keyword optimization. 4. **Competitive Analysis**: Scores pricing position against marketplace competitors and discount availability. 5. **Inventory Rating**: Evaluates stock levels and shipping timeframes for availability scoring. 6. **Score Calculation**: Combines individual category scores into a total rating with classification (excellent, good, average, poor, unacceptable). 7. **Feedback Generation**: Creates detailed breakdown of scores by category with specific improvement recommendations. ### Where teams use it - E-commerce marketplace sellers - Retail product catalog management - Marketplace compliance departments - Product information management systems - Digital marketing agencies - Brand content optimization ## Inside the decision model Product Listing Scoring ships as a JDM decision graph with 4 nodes, 2 decision tables and 10 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ imageQuality_table_ descriptionAndOtherFactors_expression_ overallScore _01_ ### Request _input_ Listing data arrives nested under a single listing object with four groups: images (count, highResolution, hasVariantImages), description (wordCount, hasBulletPoints, hasSpecifications, keywordDensity), pricing (competitiveRank, hasDiscount), and inventory (stockLevel, daysToShip). The two scoring tables read straight from these nested fields. **Sample request**_JSON_ { "listing": { "images": { "count": 4, "highResolution": true, "hasVariantImages": true }, "description": { "wordCount": 250, "hasBulletPoints": true, "hasSpecifications": true, "keywordDensity": 3.2 }, "pricing": { "competitiveRank": 2, "hasDiscount": true }, "inventory": { "stockLevel": 15, "daysToShip": 2 } } } _02_ ### Image Quality _table_ Photos are graded on a first hit ladder over listing.images.count, highResolution, and hasVariantImages: five or more high-resolution images with variant shots score 30 as 'excellent', three or more high-resolution images score 25 as 'good', two score 20 as 'average', a single image of any quality scores 10 as 'poor', and the blank row scores 0 as 'missing'. Both the score and the category label land under scores.imageQuality. The five-image bar matches common marketplace style guides, which ask sellers to show a product from multiple angles before it converts well in search. Reserving the top band for listings with variant images is a sensible choice, since color and size shots are the last merchandising step most sellers skip, while the steep drop for low-resolution photos reflects how directly image quality shows up in click-through and return rates. Image Countlisting.images.count High Resolutionlisting.images.highResolution Has Variant Imageslisting.images.hasVariantImages Image Scorescores.imageQuality.score Image Categoryscores.imageQuality.category \>= 5 true true 30 'excellent' \>= 3 true \- 25 'good' \>= 2 true \- 20 'average' \>= 1 \- \- 10 'poor' \- \- \- 0 'missing' _03_ ### Description And Other Factors _table_ Four score columns are filled from one first hit table: descScore, keywordScore, inventoryScore, and pricingScore, driven by wordCount, hasBulletPoints, hasSpecifications, keywordDensity, stockLevel, and competitiveRank together. The 'excellent' row wants more than 300 words with bullets and specifications, keywordDensity between 2 and 5, stockLevel above 20, and competitiveRank under 3, paying 30/20/10/10; the bands then step down through 'good' (25/15/8/8), 'average' (15/10/5/5), and 'poor' (10/5/3/3) to a blank 'missing' row that zeroes everything. The 2 to 5 keyword density window follows real search-optimization practice, where thin keyword coverage loses traffic and stuffing reads as spam, and the widening band to '> 1 and < 6' for 'good' tolerates less tuned copy. Requiring every dimension to clear a band together means a listing is graded on its weakest link, which is deliberate: a rich description cannot mask an out-of-stock item, and competitiveRank under 3 rewards offers priced among the top few in their market, where buy-box style placement is actually won. Word Countlisting.description.wordCount Has Bullet Pointslisting.description.hasBulletPoints Has Specificationslisting.description.hasSpecifications Keyword Densitylisting.description.keywordDensity Stock Levellisting.inventory.stockLevel Competitive Ranklisting.pricing.competitiveRank Description Scorescores.descriptionCompleteness.score Keyword Scorescores.keywordOptimization.score Inventory Scorescores.inventoryAvailability.score Pricing Scorescores.pricingCompetitiveness.score Categoryscores.descriptionCompleteness.category \> 300 true true \> 2 and < 5 \> 20 < 3 30 20 10 10 'excellent' \> 200 true \- \> 1 and < 6 \> 10 < 5 25 15 8 8 'good' \> 100 \- \- \> 0 \> 5 < 10 15 10 5 5 'average' \> 50 \- \- \- \> 0 \- 10 5 3 3 'poor' \- \- \- \- \- \- 0 0 0 0 'missing' _04_ ### Overall Score _expression_ A final expression sums the five scores.\* values into totalScore, then classifies it with stepped thresholds: 80 and above is 'excellent', 60 'good', 40 'average', 20 'poor', and anything lower 'unacceptable'. It also reports a maximumPossibleScore of 100 and assembles a breakdown object with each category's score and label, so sellers see exactly which of imageQuality, descriptionCompleteness, keywordOptimization, inventoryAvailability, or pricingCompetitiveness to fix first. _totalScore_`scores.imageQuality.score + scores.descriptionCompleteness.score + scores.keywordOptimization.score + scores.inventoryAvailability.score + scores.pricingCompetitiveness.score` _overallScoreCategory_`$.totalScore >= 80 ? 'excellent' : $.totalScore >= 60 ? 'good' : $.totalScore >= 40 ? 'average' : $.totalScore >= 20 ? 'poor' : 'unacceptable'` _maximumPossibleScore_`100` _breakdown_`{ 'imageQuality': scores.imageQuality, 'descriptionCompleteness': scores.descriptionCompleteness, 'keywordOptimization': scores.keywordOptimization, 'inventoryAvailability': scores.inventoryAvailability, 'pricingCompetitiveness': scores.pricingCompetitiveness }` ## Other Retail templates [View all templates](/templates) [_Retail_ ### Seller Approval Workflow Rules-based marketplace solution that evaluates business credentials, expertise, inventory quality, and background checks to maintain seller standards. ](/industries/retail/templates/seller-approval-workflow)[_Retail_ ### Dynamic Marketplace Commission Calculator Automated system for calculating seller commission rates based on product category, sales data, seller performance, and promotional periods. ](/industries/retail/templates/dynamic-marketplace-comission-calculator)[_Retail_ ### Marketplace Seller Grading System Objective performance evaluation system that scores sellers on delivery, satisfaction, inventory, and compliance metrics to determine marketplace status. ](/industries/retail/templates/marketplace-seller-grading-system) ## Make this template your own. Load Product Listing Scoring into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Marketplace Seller Grading System - GoRules **URL:** https://gorules.io/industries/retail/templates/marketplace-seller-grading-system **Description:** Objective performance evaluation system that scores sellers on delivery, satisfaction, inventory, and compliance metrics to determine marketplace status. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Marketplace Seller Grading System Objective performance evaluation system that scores sellers on delivery, satisfaction, inventory, and compliance metrics to determine marketplace status. Download template Share ### Solution This automated grading system objectively evaluates marketplace seller performance using key operational metrics. It scores sellers on four critical dimensions: on-time delivery rate, customer satisfaction ratings, inventory accuracy, and policy compliance. Each metric is assessed against industry-standard thresholds and assigned a 1-5 point score. The system automatically identifies seller strengths and improvement areas by analyzing performance patterns. Based on the aggregate score calculation, sellers receive a letter grade (A-F), performance status, and specific recommended actions. Top performers gain premium status with enhanced visibility, while underperforming sellers receive targeted improvement plans. This creates a fair, transparent framework that motivates sellers to maintain high standards while giving marketplace administrators clear insights for partner management. ### How it works The decision system follows a structured evaluation process: 1. **Data Collection**: Processes seller performance metrics and account information from the marketplace platform. 2. **Individual Metric Scoring**: Evaluates each performance indicator against defined thresholds: - On-time delivery (≥98% = 5 points, scaling down to <85% = 1 point) - Customer satisfaction (≥4.8 = 5 points, scaling down to <3.5 = 1 point) - Inventory accuracy (≥99% = 5 points, scaling down to <85% = 1 point) - Policy compliance (≥98% = 5 points, scaling down to <85% = 1 point) 3. **Score Aggregation**: Calculates the average score across all metrics and identifies specific strengths (scores ≥4) and improvement areas (scores ≤2). 4. **Grade Assignment**: Assigns letter grades based on the average score: - A grade (≥4.5) = "Outstanding" with premium seller status - B grade (≥3.5) = "Good" with featured seller status - C grade (≥2.5) = "Satisfactory" with standard privileges - D grade (≥1.5) = "Needs Improvement" requiring a performance plan - F grade (<1.5) = "Poor" triggering account review ### Where teams use it - E-commerce marketplaces managing third-party sellers - Multi-vendor platforms evaluating vendor performance - Retail supplier relationship management - Dropshipping network quality control - Franchise performance tracking in retail chains - Reseller program tier qualification ## Inside the decision model Marketplace Seller Grading System ships as a JDM decision graph with 7 nodes, 5 decision tables and 25 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ evaluate\_delivery_table_ evaluate\_satisfaction_table_ evaluate\_inventory_table_ evaluate\_compliance_expression_ aggregate\_scores_table_ calculate\_final\_grade _01_ ### Request _input_ Two blocks drive the grade: metrics, carrying onTimeDeliveryRate, customerSatisfaction, inventoryAccuracy, and policyCompliance, and sellerInfo with the account's id, name, and monthsActive. The four percentages and the star rating each feed their own scoring table in parallel. **Sample request**_JSON_ { "metrics": { "onTimeDeliveryRate": 96.5, "customerSatisfaction": 4.7, "inventoryAccuracy": 97.2, "policyCompliance": 94.8 }, "sellerInfo": { "id": "S12345", "name": "Global Gadgets Store", "monthsActive": 18 } } _02_ ### Evaluate Delivery _table_ Delivery performance is banded with a first hit policy on metrics.onTimeDeliveryRate: 98 or above earns 5 points, 95 earns 4, 90 earns 3, 85 earns 2, and the blank fallback row assigns 1 to everything below, writing the result to scores.delivery. A high-90s on-time bar is realistic because large marketplaces hold third-party sellers to late-shipment thresholds in that range before restricting accounts. The single-point steps between 85 and 98 give sellers a visible ladder to climb, while anything under 85 is treated as operationally failing rather than merely weak. On-Time Delivery Ratemetrics.onTimeDeliveryRate Scorescores.delivery \>= 98 5 \>= 95 4 \>= 90 3 \>= 85 2 \- 1 _03_ ### Evaluate Satisfaction _table_ Star ratings compress into five points through a first hit ladder on metrics.customerSatisfaction: 4.8 and above scores 5, 4.5 scores 4, 4.0 scores 3, 3.5 scores 2, and the fallback row gives 1, stored as scores.customerSatisfaction. All the cutoffs sit between 3.5 and 4.8 because ratings on a five-star scale cluster high, so the meaningful differences between sellers live in the top of the range. A seller below 4.0 already reads as risky to shoppers browsing a marketplace, which is why the ladder punishes mid-range ratings harder than the raw numbers suggest. Customer Satisfactionmetrics.customerSatisfaction Scorescores.customerSatisfaction \>= 4.8 5 \>= 4.5 4 \>= 4.0 3 \>= 3.5 2 \- 1 _04_ ### Evaluate Inventory _table_ Stock records are held to the strictest top band of the four tables: metrics.inventoryAccuracy needs 99 or above for 5 points, then 95 for 4, 90 for 3, 85 for 2, with the blank row assigning 1, saved to scores.inventory. The tighter 99 threshold is deliberate, since inaccurate inventory turns directly into oversells and cancelled orders, the defect marketplaces penalize most heavily. The lower rungs mirror the delivery table so the two operational metrics read on the same scale when averaged. Inventory Accuracymetrics.inventoryAccuracy Scorescores.inventory \>= 99 5 \>= 95 4 \>= 90 3 \>= 85 2 \- 1 _05_ ### Evaluate Compliance _table_ Policy adherence uses the same five-point ladder as delivery: metrics.policyCompliance at 98 or above scores 5, then 95, 90, and 85 step down to 2, with everything else caught at 1 and written to scores.compliance. Holding compliance to a 98 top band is a sensible business choice because violations, unlike a late parcel, expose the platform itself to listing takedowns and legal risk. Scoring it on the shared 1-to-5 scale keeps it weighted equally with the operational metrics in the average rather than acting as a separate veto. Policy Compliancemetrics.policyCompliance Scorescores.compliance \>= 98 5 \>= 95 4 \>= 90 3 \>= 85 2 \- 1 _06_ ### Aggregate Scores _expression_ Aggregation happens in one expression step scoped to the scores object via its outputPath: averageScore is avg(values(scores)), strengths collects metric names with filter(keys(scores), scores\[#\] >= 4), and improvements collects those at 2 or below. Producing named strength and improvement lists alongside the average is what lets the response tell a seller what to fix, not just how they rank. _averageScore_`avg(values(scores))` _strengths_`filter(keys(scores), scores[#] >= 4)` _improvements_`filter(keys(scores), scores[#] <= 2)` _07_ ### Calculate Final Grade _table_ Letter grades come off a first hit ladder over scores.averageScore: 4.5 and above is 'A' / 'Outstanding' and 'Eligible for premium seller status', 3.5 is 'B' with featured status, 2.5 is 'C' with 'Standard seller privileges', 1.5 is 'D' requiring a performance improvement plan, and the fallback row issues 'F' with 'Account review required'. With passThrough off, the response reduces to grade, status, and recommendedAction. Half-point cutoffs around each whole grade mean a seller must average well on all four metrics to move up, since one weak score drags the mean below the next boundary. Tying grades to concrete privileges like premium and featured placement follows how marketplaces actually run seller tiering, and the D and F rows attach mandatory actions so poor grades trigger a process instead of just a label. Average Scorescores.averageScore Gradegrade Statusstatus ActionrecommendedAction \>= 4.5 'A' 'Outstanding' 'Eligible for premium seller status' \>= 3.5 'B' 'Good' 'Eligible for featured seller status' \>= 2.5 'C' 'Satisfactory' 'Standard seller privileges' \>= 1.5 'D' 'Needs Improvement' 'Performance improvement plan required' \- 'F' 'Poor' 'Account review required' ## Other Retail templates [View all templates](/templates) [_Retail_ ### Seller Approval Workflow Rules-based marketplace solution that evaluates business credentials, expertise, inventory quality, and background checks to maintain seller standards. ](/industries/retail/templates/seller-approval-workflow)[_Retail_ ### Dynamic Marketplace Commission Calculator Automated system for calculating seller commission rates based on product category, sales data, seller performance, and promotional periods. ](/industries/retail/templates/dynamic-marketplace-comission-calculator)[_Retail_ ### Product Listing Scoring Automated scoring system that evaluates and ranks product listings based on image quality, description completeness, and other key marketplace success factors. ](/industries/retail/templates/product-listing-scoring) ## Make this template your own. Load Marketplace Seller Grading System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Marketplace Listing Verification System - GoRules **URL:** https://gorules.io/industries/retail/templates/marketplace-listing-verification-system **Description:** Automated risk assessment system that flags suspicious marketplace listings based on brand authenticity, pricing anomalies, and seller credibility factors. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Marketplace Listing Verification System Automated risk assessment system that flags suspicious marketplace listings based on brand authenticity, pricing anomalies, and seller credibility factors. Download template Share ### Solution This marketplace verification system protects buyers and platform integrity by automatically identifying high-risk listings that require manual review. The system evaluates multiple risk signals including price deviation from market averages, seller reputation metrics, account history, and category sensitivity. For luxury and high-value items, it verifies brand authenticity against known premium labels and flags suspicious underpricing that could indicate counterfeit merchandise. Listings are assessed against seller credibility factors including feedback rating, account age, and previous policy violations. The system assigns risk levels based on combinations of these factors, with more severe flags triggered when multiple risk indicators appear together. Each flagged listing receives specific verification requirements - either immediate manual review for high-risk cases or batch verification for medium-risk items - ensuring marketplace quality while maintaining operational efficiency. ### How it works The decision graph evaluates listings through a sequential risk assessment process: 1. **Risk Factor Calculation**: Computes key metrics including price deviation percentage, seller credibility scores, and category sensitivity indicators. 2. **Brand Authentication**: Verifies if the brand belongs to a high-value category and compares pricing against market averages. 3. **Seller Evaluation**: Analyzes seller history including account age, previous violations, and feedback rating. 4. **Risk Level Assignment**: Applies decision rules to determine if the listing presents high, medium, or low risk based on combined factors. 5. **Verification Routing**: Routes high-risk listings for immediate manual review, medium-risk listings to batch verification queues, and approves low-risk listings automatically. ### Where teams use it - Luxury goods marketplaces - Electronics and technology resale platforms - Collectibles and rare item exchanges - Designer fashion marketplaces - Multi-vendor retail platforms - Auction and bidding sites - Peer-to-peer selling applications - Global commerce platforms with third-party sellers ## Inside the decision model Marketplace Listing Verification System ships as a JDM decision graph with 4 nodes, 2 decision tables and 11 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_expression_ calculateRiskFactors_table_ evaluateRiskLevel_table_ determineAction _01_ ### Request _input_ Three request blocks feed the assessment: listing with its brand, price, and condition, category with type, averagePrice, and the highValueBrands list, and seller with rating, accountAgeDays, and previousViolations. Every downstream risk factor derives from these fields. **Sample request**_JSON_ { "listing": { "id": "LIST12345", "title": "Designer Handbag - Limited Edition", "brand": "LuxuryBrand", "price": 950, "condition": "New", "description": "Authentic designer handbag, limited edition, comes with certificate" }, "category": { "id": "CAT789", "type": "luxury", "name": "Designer Handbags", "averagePrice": 1500, "highValueBrands": \[ "LuxuryBrand", "PremiumDesigner", "ExclusiveFashion" \] }, "seller": { "id": "SELL456", "name": "FashionReseller", "rating": 3.8, "accountAgeDays": 45, "previousViolations": 1, "listingsCount": 27 } } _02_ ### Calculate Risk Factors _expression_ Raw signals become named booleans and one number before any rules run: priceDeviationScore is the absolute percentage gap between listing.price and category.averagePrice, isSensitiveCategory checks category.type against \['luxury', 'electronics', 'collectibles', 'designer'\], and isHighValueBrand looks the brand up in category.highValueBrands. Three seller flags complete the set: hasLowRating for ratings under 4.0, isNewSeller for accounts under 90 days, and hasPreviousViolations for any violation on record, so the risk table can combine plain flags instead of repeating arithmetic. _priceDeviationScore_`abs((listing.price - category.averagePrice) / category.averagePrice * 100)` _isSensitiveCategory_`contains(['luxury', 'electronics', 'collectibles', 'designer'], category.type)` _isHighValueBrand_`contains(category.highValueBrands ?? [], listing.brand)` _hasLowRating_`seller.rating < 4.0` _isNewSeller_`seller.accountAgeDays < 90` _hasPreviousViolations_`seller.previousViolations > 0` _03_ ### Evaluate Risk Level _table_ Risk levels come from combining those flags under a first hit policy. The two 'high' rows both require isHighValueBrand with priceDeviationScore > 30, with and without hasPreviousViolations; the 'medium' rows then cover a high-value brand with a violation history, a priceDeviationScore > 40 on its own, sellers with 'Multiple previous seller violations', and isNewSeller or hasLowRating paired with isSensitiveCategory. The blank fallback row assigns 'low' with 'Standard risk level', and each hit writes both riskAssessment.level and a human-readable reason. A recognized luxury label priced 30 percent or more away from category.averagePrice is the classic counterfeit signal in brand-name resale, which is why that combination alone reaches 'high' while a 40 percent deviation on an unbranded item only reaches 'medium'. Pairing account age and rating with category sensitivity also reflects where fraud actually concentrates, since new or poorly rated sellers in luxury and electronics are the usual entry point, and single weak signals stay below the review threshold to keep false positives down. Brand Risk Price Risk Seller Risk Risk LevelriskAssessment.level Risk ReasonriskAssessment.reason isHighValueBrand == true priceDeviationScore > 30 hasPreviousViolations == true 'high' 'Suspicious pricing for high-value brand with history of violations' isHighValueBrand == true priceDeviationScore > 30 \- 'high' 'Suspicious pricing for high-value brand' isHighValueBrand == true \- hasPreviousViolations == true 'medium' 'High-value brand with seller violation history' \- priceDeviationScore > 40 \- 'medium' 'Significant price deviation from market average' \- \- hasPreviousViolations > 2 'medium' 'Multiple previous seller violations' isNewSeller == true isSensitiveCategory == true \- 'medium' 'New seller listing sensitive category items' +2 more rows in the downloadable template _04_ ### Determine Action _table_ Verification workload is routed by a three-row first hit table on riskAssessment.level: 'high' sets verification.required to true with type 'manual', 'medium' also requires verification but through the 'batch' queue, and 'low' sets required to false with type 'none'. Each row carries a verification.message explaining the outcome. Reserving immediate manual review for 'high' risk while batching 'medium' cases is standard trust-and-safety operations, since reviewer time is the scarce resource and batch queues keep coverage on mid-risk listings without blocking their publication. Auto-approving 'low' risk keeps the vast majority of listings flowing with no added friction. Risk LevelriskAssessment.level Requires Verificationverification.required Verification Typeverification.type Verification Messageverification.message 'high' true 'manual' 'High risk listing requires immediate manual verification' 'medium' true 'batch' 'Medium risk listing added to batch verification queue' 'low' false 'none' 'No verification required' ## Other Retail templates [View all templates](/templates) [_Retail_ ### Seller Approval Workflow Rules-based marketplace solution that evaluates business credentials, expertise, inventory quality, and background checks to maintain seller standards. ](/industries/retail/templates/seller-approval-workflow)[_Retail_ ### Dynamic Marketplace Commission Calculator Automated system for calculating seller commission rates based on product category, sales data, seller performance, and promotional periods. ](/industries/retail/templates/dynamic-marketplace-comission-calculator)[_Retail_ ### Product Listing Scoring Automated scoring system that evaluates and ranks product listings based on image quality, description completeness, and other key marketplace success factors. ](/industries/retail/templates/product-listing-scoring) ## Make this template your own. Load Marketplace Listing Verification System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Flash Sale Eligibility - GoRules **URL:** https://gorules.io/industries/retail/templates/flash-sale-eligibility **Description:** Smart retail solution that automatically selects products for flash sales based on inventory, profitability, seasonality, and seller performance. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Flash Sale Eligibility Smart retail solution that automatically selects products for flash sales based on inventory, profitability, seasonality, and seller performance. Download template Share ### Solution This dynamic product selection system streamlines flash sale management by evaluating multiple product attributes simultaneously. It first analyzes inventory levels to ensure sufficient stock exists for promotional volume, while verifying profit margins meet minimum thresholds to maintain profitability during discounted pricing periods. The seasonality analyzer matches product types with appropriate calendar periods, prioritizing seasonal items during their peak relevance while also identifying year-round products. For seller evaluation, the system examines both historical sales performance and customer satisfaction ratings to ensure quality standards. The final eligibility determination applies business rules that weigh these factors together, generating appropriate discount percentages based on how strongly a product meets the criteria. This automation significantly reduces manual review time while maximizing promotional effectiveness. ### How it works The decision graph processes product eligibility through four sequential evaluation nodes: 1. **Inventory & Margin Check**: Validates that products have sufficient stock (minimum 50 units) and acceptable profit margins (minimum 25%) to sustain discounting. 2. **Seasonality Analysis**: Aligns product seasonality with current calendar month, prioritizing items in their peak selling period while identifying year-round merchandise. 3. **Seller Quality Assessment**: Calculates seller performance factors based on rating (minimum 4.0) and historical sales volume (minimum 1000 units), with adjustment factors applied. 4. **Final Eligibility Determination**: Combines all evaluation factors to determine qualification status and appropriate discount percentage (ranging from 5-15% based on qualification strength). ### Where teams use it - E-commerce marketplace flash sales - Retail inventory reduction programs - Seasonal merchandise promotions - Seller performance incentive programs - End-of-season product clearance - New seller growth acceleration ## Inside the decision model Flash Sale Eligibility ships as a JDM decision graph with 5 nodes, 3 decision tables and 16 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ checkInventoryAndMargin_table_ checkSeasonality_expression_ checkSellerQuality_table_ determineEligibility _01_ ### Request _input_ A flat request describes one candidate product: productId and category identify it, currentInventory and profitMargin cover the economics, season and currentMonth handle timing, and sellerRating with sellerHistoricalSales profiles the merchant. The schema marks all eight fields as required. **Sample request**_JSON_ { "productId": "PROD-12345", "category": "Electronics", "currentInventory": 75, "profitMargin": 0.28, "season": "summer", "currentMonth": 7, "sellerRating": 4.5, "sellerHistoricalSales": 2500 } _02_ ### Check Inventory And Margin _table_ Stock and margin are screened together with a first hit policy: 50 or more units with a profitMargin of at least 0.25 passes as 'Sufficient inventory and margin', and 100 or more units passes with a thinner 0.15 margin. Below that, fewer than 20 units fails as 'Insufficient inventory for flash sale', a margin under 0.1 fails as 'Margin too low for promotion', and the blank row rejects everything else, writing passesInitialCheck and initialCheckReason either way. Flash sales spike demand, so the stock floor exists to avoid instant sellouts and the cancellations that follow, a standard concern when planning promotional volume. Accepting a lower 0.15 margin once inventory clears 100 units reflects clearance economics, where moving overstock justifies a thinner cut, while the 0.1 hard floor keeps any discounted sale from going out below cost. Current InventorycurrentInventory Profit MarginprofitMargin Passes Initial CheckpassesInitialCheck Initial Check ReasoninitialCheckReason \>= 50 \>= 0.25 true 'Sufficient inventory and margin' \>= 100 \>= 0.15 true 'High inventory with acceptable margin' < 20 \- false 'Insufficient inventory for flash sale' \- < 0.1 false 'Margin too low for promotion' \- \- false 'Default: Does not meet primary criteria' _03_ ### Check Seasonality _table_ Calendar fit is a lookup of season against currentMonth lists: 'summer' matches months 6, 7, 8, 'winter' matches 1, 2, 12, 'fall' matches 9, 10, 11, 'spring' matches 3, 4, 5, and 'all-year' products pass in any month. The blank fallback row sets isInSeason to false with the reason 'Product out of season'. Tying promotion slots to the demand calendar is how retailers actually plan markdown and event cadences, since discounting a summer item in month 7 amplifies existing demand while the same discount in winter just erodes margin. The 'all-year' row keeps staple merchandise eligible without forcing a fake season onto it. Seasonseason Current MonthcurrentMonth Is In SeasonisInSeason Season ReasonseasonReason 'summer' 6, 7, 8 true 'Summer product in summer months' 'winter' 1, 2, 12 true 'Winter product in winter months' 'fall' 9, 10, 11 true 'Fall product in fall months' 'spring' 3, 4, 5 true 'Spring product in spring months' 'all-year' \- true 'Product available year-round' \- \- false 'Product out of season' _04_ ### Check Seller Quality _expression_ Seller signals compress into three values: isQualifiedSeller requires sellerRating >= 4.0 and sellerHistoricalSales >= 1000 together, seasonalityFactor becomes 1.2 in season versus 0.8 out, and sellerFactor grades 1.5 for qualified sellers, 1.0 for ratings of at least 3.5, and 0.5 below that. The isQualifiedSeller flag is what the eligibility table branches on next, including its top-seller exemption row. _isQualifiedSeller_`sellerRating >= 4.0 and sellerHistoricalSales >= 1000` _seasonalityFactor_`isInSeason ? 1.2 : 0.8` _sellerFactor_`$.isQualifiedSeller ? 1.5 : (sellerRating >= 3.5 ? 1.0 : 0.5)` _05_ ### Determine Eligibility _table_ Everything converges in a first hit table over passesInitialCheck, isInSeason, and isQualifiedSeller. All three true earns the full 15 discountPercentage as 'Product fully qualifies for flash sale', an in-season product without a qualified seller gets 10, a qualified seller off season gets 8, and a failed initial check can still salvage 5 through the 'Top seller exemption applied' row when isQualifiedSeller == true and currentInventory >= 30. The fallback row marks the product ineligible with a discount of 0. Scaling discount depth with qualification strength is sound promotion economics: the deepest cut is only funded when inventory, margin, season, and seller quality all line up, and each missing factor shaves the offer rather than killing it. The exemption row is a sensible business choice to keep proven sellers in the program, with its own 30-unit floor so the override never books a sale the stock cannot cover. Initial CheckpassesInitialCheck SeasonalityisInSeason Seller QualityisQualifiedSeller Is Eligible For Flash SaleisEligibleForFlashSale Eligibility ReasoneligibilityReason Discount PercentagediscountPercentage passesInitialCheck == true isInSeason == true isQualifiedSeller == true true 'Product fully qualifies for flash sale' 15 passesInitialCheck == true isInSeason == true isQualifiedSeller == false true 'Seasonal product with sufficient inventory/margin' 10 passesInitialCheck == true isInSeason == false isQualifiedSeller == true true 'Off-season product from top seller' 8 passesInitialCheck == false \- isQualifiedSeller == true and currentInventory >= 30 true 'Top seller exemption applied' 5 \- \- \- false 'Product does not qualify for flash sale' 0 ## Other Retail templates [View all templates](/templates) [_Retail_ ### Seller Approval Workflow Rules-based marketplace solution that evaluates business credentials, expertise, inventory quality, and background checks to maintain seller standards. ](/industries/retail/templates/seller-approval-workflow)[_Retail_ ### Dynamic Marketplace Commission Calculator Automated system for calculating seller commission rates based on product category, sales data, seller performance, and promotional periods. ](/industries/retail/templates/dynamic-marketplace-comission-calculator)[_Retail_ ### Product Listing Scoring Automated scoring system that evaluates and ranks product listings based on image quality, description completeness, and other key marketplace success factors. ](/industries/retail/templates/product-listing-scoring) ## Make this template your own. Load Flash Sale Eligibility into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Dynamic Marketplace Commission Calculator - GoRules **URL:** https://gorules.io/industries/retail/templates/dynamic-marketplace-comission-calculator **Description:** Automated system for calculating seller commission rates based on product category, sales data, seller performance, and promotional periods. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Dynamic Marketplace Commission Calculator Automated system for calculating seller commission rates based on product category, sales data, seller performance, and promotional periods. Download template Share ### Solution This marketplace commission system calculates fair rates by analyzing multiple factors that impact commission structures. It evaluates product categories with different base rates and sales thresholds, automatically applying lower rates for categories like home goods and higher rates for fashion items. Seller performance metrics directly influence commission adjustments, rewarding high ratings and fulfillment rates with reduced commissions. The system factors in sales volume through multipliers that benefit high-volume sellers, promoting growth and marketplace expansion. During promotional periods, the calculator automatically applies temporary rate modifications to align with marketing initiatives. All calculations seamlessly combine to generate a single, transparent final commission rate that balances marketplace revenue needs with seller incentives. ### How it works The decision graph processes commission calculations through several connected components: 1. **Base Rate Assignment**: Determines initial commission percentage based on product category and sales amount thresholds. 2. **Performance Evaluation**: Analyzes seller metrics including rating and fulfillment rate to apply adjustments. 3. **Promotion Detection**: Checks if current date falls within promotion period dates. 4. **Volume Analysis**: Applies multipliers for high-volume sellers who exceed set thresholds. 5. **Final Calculation**: Combines base rate, performance adjustments, and promotional factors to produce the final commission rate. ### Where teams use it - Online marketplaces with multiple seller categories - E-commerce platforms with performance-based incentives - Multi-vendor retail systems - Seasonal retail promotions management - Seller loyalty and incentive programs - Cross-category commission standardization ## Inside the decision model Dynamic Marketplace Commission Calculator ships as a JDM decision graph with 4 nodes, 2 decision tables and 11 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ productCategoryRates_table_ sellerPerformanceAdjustment_expression_ promotionalAdjustment _01_ ### Request _input_ A single request combines product.category, sales.amount and sales.volume, seller.rating and seller.fulfillmentRate, plus the promotion.startDate and endDate window. Category and amount pick the base rate while the remaining fields adjust it. **Sample request**_JSON_ { "product": { "category": "electronics", "id": "prod-123" }, "sales": { "amount": 750, "volume": 120 }, "seller": { "id": "sell-456", "rating": 4.7, "fulfillmentRate": 97 }, "promotion": { "startDate": "2025-02-01", "endDate": "2025-04-01" } } _02_ ### Product Category Rates _table_ Base rates come from pairing product.category with a sales.amount threshold under a first hit policy: 'electronics' pays 0.12 above 500 and 0.08 otherwise, 'fashion' pays 0.15 above 300 and 0.10 otherwise, 'home' pays 0.11 above 400 and 0.07 otherwise, and the empty catch-all row sets 0.05 for any other category. The result lands in commission.baseRate for the later adjustment steps. Category-differentiated take rates are how real marketplaces price their referral fees, and fashion sitting highest at 0.15 matches the industry pattern of apparel commanding the largest commissions while electronics and home goods run leaner. Charging more above each amount threshold is a straightforward business choice to take a larger share of high-ticket orders, and the 0.05 floor keeps unlisted categories from slipping through uncommissioned. Categoryproduct.category Sales Amountsales.amount Base Commission Ratecommission.baseRate 'electronics' \> 500 0.12 'electronics' \- 0.08 'fashion' \> 300 0.15 'fashion' \- 0.10 'home' \> 400 0.11 'home' \- 0.07 +1 more row in the downloadable template _03_ ### Seller Performance Adjustment _table_ Two service metrics move the rate together: a first hit table reads seller.rating alongside seller.fulfillmentRate and writes commission.performanceAdjustment. Ratings above 4.5 with fulfillment above 95 map to 0.02, above 4.0 with 90 to 0.01, ratings below 3.0 with fulfillment below 80 to -0.02, and the blank fallback row leaves the adjustment at 0. Requiring both metrics to clear a band before an adjustment applies is deliberate, since a high star rating with poor fulfillment usually signals operational trouble rather than seller quality. The mid-90s fulfillment bar reflects where marketplaces commonly set seller performance standards, and the two-point spread in either direction keeps the adjustment meaningful without swamping the category base rate. Ratingseller.rating Fulfillment Rateseller.fulfillmentRate Performance Adjustmentcommission.performanceAdjustment \> 4.5 \> 95 0.02 \> 4.0 \> 90 0.01 < 3.0 < 80 \-0.02 \- \- 0 _04_ ### Promotional Adjustment _expression_ Everything joins in one expression step: isPromotionActive checks that date('now') falls between promotion.startDate and promotion.endDate, promotionAdjustment adds 0.03 while a promotion runs, and volumeMultiplier becomes 1.2 once sales.volume > 100. The final line multiplies commission.baseRate plus both adjustments by that multiplier to produce finalCommissionRate, the single number the marketplace bills against. _isPromotionActive_`date(promotion.startDate) <= date('now') and date('now') <= date(promotion.endDate)` _volumeMultiplier_`sales.volume > 100 ? 1.2 : 1.0` _promotionAdjustment_`$.isPromotionActive ? 0.03 : 0` _finalCommissionRate_`(commission.baseRate + commission.performanceAdjustment + $.promotionAdjustment) * $.volumeMultiplier` ## Other Retail templates [View all templates](/templates) [_Retail_ ### Seller Approval Workflow Rules-based marketplace solution that evaluates business credentials, expertise, inventory quality, and background checks to maintain seller standards. ](/industries/retail/templates/seller-approval-workflow)[_Retail_ ### Product Listing Scoring Automated scoring system that evaluates and ranks product listings based on image quality, description completeness, and other key marketplace success factors. ](/industries/retail/templates/product-listing-scoring)[_Retail_ ### Marketplace Seller Grading System Objective performance evaluation system that scores sellers on delivery, satisfaction, inventory, and compliance metrics to determine marketplace status. ](/industries/retail/templates/marketplace-seller-grading-system) ## Make this template your own. Load Dynamic Marketplace Commission Calculator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Dynamic FX Rate Pricing System - GoRules **URL:** https://gorules.io/industries/retail/templates/dynamic-fx-rate-pricing-system **Description:** Tiered foreign exchange rate system that offers preferential rates for premium products, enhancing margins on luxury items while maintaining competitiveness. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Dynamic FX Rate Pricing System Tiered foreign exchange rate system that offers preferential rates for premium products, enhancing margins on luxury items while maintaining competitiveness. Download template Share ### Solution This dynamic foreign exchange rate system optimizes pricing for cross-border sales by assigning different FX rates based on product value tiers. Premium and luxury items benefit from more favorable conversion rates, protecting margins on high-value merchandise while maintaining competitive pricing in target markets. The system first categorizes products into four distinct tiers based on base price thresholds, then applies the appropriate currency conversion rate. For each product category, the system assigns specific FX rates and optional discounts customized by currency pair, with premium products receiving the most advantageous rates. Lower-priced standard items use baseline exchange rates. This approach rewards customers purchasing high-value items while ensuring profitability across diverse product catalogs and international markets. The system includes transparent messaging to explain the benefit being applied to each transaction. ### How it works The decision graph implements a two-stage evaluation process: 1. **Product Categorization**: The first decision table analyzes the product's base price and assigns it to one of four categories: premium (≥$10,000), luxury (≥$5,000), mid-range (≥$1,000), or standard (all others). 2. **FX Rate Determination**: The second decision table uses three key inputs - product category, base currency, and target currency - to determine the appropriate exchange rate parameters. 3. **Rate Application**: For each category-currency combination, the system applies: - A specific FX rate tailored to the product's value tier - An optional discount percentage for preferred categories - A descriptive message explaining the rate benefit 4. **Result Generation**: The system combines all this information into a structured response containing the applicable FX rate details for the transaction. ### Where teams use it - Global e-commerce platforms with varied product catalogs - Luxury retail with international shipping - Marketplace platforms supporting cross-border transactions - Travel booking systems with dynamic currency conversion - International wholesale procurement systems - Subscription services with tiered international pricing ## Inside the decision model Dynamic FX Rate Pricing System ships as a JDM decision graph with 3 nodes, 2 decision tables and 13 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ determineProductCategory_table_ determineFXRateAdjustment _01_ ### Request _input_ One product plus a currency pair make up the request: product.basePrice drives the tiering, baseCurrency and targetCurrency select the rate row, and quantity with customerTier travel along for context. **Sample request**_JSON_ { "product": { "id": "PRD-12345", "name": "Luxury Watch", "basePrice": 8500 }, "baseCurrency": "USD", "targetCurrency": "EUR", "quantity": 1, "customerTier": "gold" } _02_ ### Determine Product Category _table_ Price bands assign the tier with a first hit policy on product.basePrice: 10000 and above is 'premium', 5000 and above is 'luxury', 1000 and above is 'mid-range', and the blank fallback row labels everything else 'standard', writing the result to product.category. Descending thresholds under first hit mean the highest band a price clears always wins, which keeps the four rows unambiguous without upper bounds. The round 1000/5000/10000 cutoffs are a sensible business segmentation rather than any external standard, and doing the tiering once here keeps the FX table from repeating price logic across every currency pair. Product Priceproduct.basePrice Product Categoryproduct.category \>= 10000 'premium' \>= 5000 'luxury' \>= 1000 'mid-range' \- 'standard' _03_ ### Determine Fx Rate Adjustment _table_ Rates come from matching product.category with baseCurrency 'USD' and targetCurrency 'EUR' or 'GBP' under a first hit policy: 'premium' converts at 0.90 to EUR and 0.78 to GBP with a 0.02 discount, 'luxury' at 0.91 and 0.79 with 0.015, 'mid-range' at 0.92 and 0.80 with 0.01, and 'standard' at 0.93 and 0.81 with no discount. The blank fallback row applies a 1.0 rate with the message 'Default base rate applied', and since passThrough is off the response is just fxDetails.rate, discount, and message. The gap between 0.90 and 0.93 per dollar is where the FX spread lives, and giving high-value tiers the lower conversion figure plus an explicit discount means premium buyers pay the smallest currency markup, echoing how FX providers tier their spreads by transaction size. Funding that concession from premium and luxury margins is a deliberate trade to stay price-competitive on big-ticket cross-border orders, while the 1.0 fallback keeps unsupported pairs safe and the per-row messages make the applied benefit explainable at checkout. Categoryproduct.category Base CurrencybaseCurrency Target CurrencytargetCurrency FX RatefxDetails.rate DiscountfxDetails.discount MessagefxDetails.message 'premium' 'USD' 'EUR' 0.90 0.02 'Premium products receive our most favorable rate' 'premium' 'USD' 'GBP' 0.78 0.02 'Premium products receive our most favorable rate' 'luxury' 'USD' 'EUR' 0.91 0.015 'Luxury products receive favorable rates' 'luxury' 'USD' 'GBP' 0.79 0.015 'Luxury products receive favorable rates' 'mid-range' 'USD' 'EUR' 0.92 0.01 'Mid-range products receive standard rates' 'mid-range' 'USD' 'GBP' 0.80 0.01 'Mid-range products receive standard rates' +3 more rows in the downloadable template ## Other Retail templates [View all templates](/templates) [_Retail_ ### Seller Approval Workflow Rules-based marketplace solution that evaluates business credentials, expertise, inventory quality, and background checks to maintain seller standards. ](/industries/retail/templates/seller-approval-workflow)[_Retail_ ### Dynamic Marketplace Commission Calculator Automated system for calculating seller commission rates based on product category, sales data, seller performance, and promotional periods. ](/industries/retail/templates/dynamic-marketplace-comission-calculator)[_Retail_ ### Product Listing Scoring Automated scoring system that evaluates and ranks product listings based on image quality, description completeness, and other key marketplace success factors. ](/industries/retail/templates/product-listing-scoring) ## Make this template your own. Load Dynamic FX Rate Pricing System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Affiliate Commission Calculator - GoRules **URL:** https://gorules.io/industries/retail/templates/affiliate-commission-calculator **Description:** Dynamic system that calculates precise affiliate payouts based on product category, performance metrics, and promotional factors. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Affiliate Commission Calculator Dynamic system that calculates precise affiliate payouts based on product category, performance metrics, and promotional factors. Download template Share ### Solution This affiliate commission system calculates payouts by analyzing multiple performance factors to reward top-performing partners. The calculator first establishes base commission rates specific to each product category (electronics, fashion, beauty, and home goods), with fashion and beauty offerings earning higher rates to incentivize promotion in these categories. Performance bonuses are determined by examining both referral volume and conversion quality. Affiliates generating higher traffic (100+ monthly referrals) with exceptional conversion rates (15%+) earn maximum volume bonuses. The system incorporates special promotion multipliers that increase commission rates by 25% during promotional periods, encouraging timely marketing efforts. Final calculations combine all factors to determine precise commission amounts on each sale, creating a transparent and motivating payment structure. ### How it works The decision graph processes affiliate performance data through three key stages: 1. **Category Rate Determination**: Assigns appropriate base commission rates and potential volume bonus caps according to product category, with rates ranging from 5-15%. 2. **Performance Evaluation**: Analyzes two key metrics - monthly referral quantity and conversion rate quality - to calculate volume bonuses and performance multipliers. Higher-performing affiliates receive bonuses up to 5% and multipliers up to 1.2x. 3. **Commission Calculation**: Applies the promotion multiplier (1.25x for special promotions) and combines all factors to calculate the final commission rate and exact payout amount for each sale. This tiered approach ensures affiliates are rewarded proportionally to their contribution, with top performers potentially earning over triple the base commission rate. ### Where teams use it - E-commerce affiliate programs - Fashion and beauty brand partnerships - Electronics retailer referral systems - Subscription service referral programs - Influencer marketing campaigns - Digital marketplace commission structures ## Inside the decision model Affiliate Commission Calculator ships as a JDM decision graph with 4 nodes, 2 decision tables and 10 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ categoryRates_table_ performanceRates_expression_ calculateCommission _01_ ### Request _input_ Five flat fields drive the payout: productCategory, monthlyReferrals, conversionRate, isSpecialPromotion, and saleAmount. The category picks the base economics and the rest scale them. **Sample request**_JSON_ { "productCategory": "fashion", "monthlyReferrals": 75, "conversionRate": 0.12, "isSpecialPromotion": true, "saleAmount": 350 } _02_ ### Category Rates _table_ Category economics are set in one first hit lookup on productCategory: 'electronics' maps to a baseCommissionRate of 0.08 with a volumeBonusMax of 0.03, 'fashion' to 0.12 and 0.04, 'beauty' to 0.15 and 0.05, 'home\_goods' to 0.10 and 0.03, and the blank fallback row pays 0.05 with a 0.02 cap for anything else. These spreads track category margins the way real affiliate programs do: beauty and fashion carry the richest payouts because their gross margins support them, while electronics run thin and pay accordingly. Emitting each category's own bonus ceiling alongside the base rate keeps later performance bonuses proportional, so a top affiliate in electronics cannot out-earn the category's economics. Product CategoryproductCategory Base RatebaseCommissionRate Volume Bonus MaxvolumeBonusMax 'electronics' 0.08 0.03 'fashion' 0.12 0.04 'beauty' 0.15 0.05 'home\_goods' 0.10 0.03 \- 0.05 0.02 _03_ ### Performance Rates _table_ Bonuses require traffic and quality together: a first hit table over monthlyReferrals and conversionRate pays the full volumeBonusMax with a 1.2 performanceMultiplier at 100+ referrals converting at 0.15 or better, then steps down through volumeBonusMax \* 0.8 at 1.15, \* 0.6 at 1.1 for the 50-referral band, and \* 0.3 at 1.05 for 25 referrals converting at just 0.05. The blank fallback row pays no volumeBonus and a neutral multiplier of 1. Gating every bonus row on conversionRate as well as referral count is standard affiliate-program defense, since raw referral volume is cheap to inflate with low-intent traffic while conversions are not. Expressing bonuses as fractions of the category's cap rather than fixed numbers keeps the incentive curve identical across categories, and a 15 percent conversion bar for the top band is a genuinely demanding threshold in e-commerce. Monthly ReferralsmonthlyReferrals Conversion RateconversionRate Volume BonusvolumeBonus Performance MultiplierperformanceMultiplier \>= 100 \>= 0.15 volumeBonusMax 1.2 \>= 100 \>= 0.10 volumeBonusMax \* 0.8 1.15 \>= 50 \>= 0.10 volumeBonusMax \* 0.6 1.1 \>= 25 \>= 0.05 volumeBonusMax \* 0.3 1.05 \- \- 0 1 _04_ ### Calculate Commission _expression_ Final math happens in three expressions: promotionMultiplier is 1.25 when isSpecialPromotion is true and 1 otherwise, finalCommissionRate computes (baseCommissionRate + volumeBonus) \* performanceMultiplier \* promotionMultiplier, and commissionAmount applies that rate to saleAmount. Stacking the multipliers after the additive bonus is what lets a top performer during a promotion earn well above the category base rate on the same sale. _promotionMultiplier_`isSpecialPromotion ? 1.25 : 1` _finalCommissionRate_`(baseCommissionRate + volumeBonus) * performanceMultiplier * $.promotionMultiplier` _commissionAmount_`saleAmount * $.finalCommissionRate` ## Other Retail templates [View all templates](/templates) [_Retail_ ### Seller Approval Workflow Rules-based marketplace solution that evaluates business credentials, expertise, inventory quality, and background checks to maintain seller standards. ](/industries/retail/templates/seller-approval-workflow)[_Retail_ ### Dynamic Marketplace Commission Calculator Automated system for calculating seller commission rates based on product category, sales data, seller performance, and promotional periods. ](/industries/retail/templates/dynamic-marketplace-comission-calculator)[_Retail_ ### Product Listing Scoring Automated scoring system that evaluates and ranks product listings based on image quality, description completeness, and other key marketplace success factors. ](/industries/retail/templates/product-listing-scoring) ## Make this template your own. Load Affiliate Commission Calculator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Traffic Violation Penalty Calculator - GoRules **URL:** https://gorules.io/industries/public-sector/templates/traffic-violation-penalty-calculator **Description:** Automated system that determines appropriate fines, points, and penalties for traffic violations based on severity, driver history, and circumstances. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Traffic Violation Penalty Calculator Automated system that determines appropriate fines, points, and penalties for traffic violations based on severity, driver history, and circumstances. Download template Share ### Solution This traffic violation assessment system calculates fair and consistent penalties by analyzing multiple factors in each case. The system first classifies violations by type and severity, assigning base fines and points according to established guidelines. For speeding violations, the system factors in the exact speed over the limit, with higher excesses resulting in steeper penalties. The system then applies circumstantial modifiers based on location (with special attention to school zones), the driver's violation history, and the overall severity classification. When violations occur in school zones or are committed by repeat offenders, penalties are appropriately increased. For severe violations with multiple previous offenses, the system can recommend license suspension. The final assessment includes a calculated risk level and payment deadline, with higher-risk violations receiving shorter payment windows and closer monitoring. ### How it works The decision graph processes violations through four interconnected stages: 1. **Violation Classification**: Categorizes the offense based on type (speeding, DUI, etc.) and assigns initial severity level, points, and base fine amount. 2. **Penalty Calculation**: Applies multipliers to the base penalty based on contextual factors like previous violations and school zone location. Determines if license suspension is warranted for severe cases. 3. **Assessment Finalization**: Rounds calculated values to ensure clean, whole-number fines and point assessments. 4. **Risk Analysis**: Evaluates the driver's risk level based on final point count and violation severity, then assigns appropriate payment deadlines-shorter for high-risk cases and longer for minor infractions. ### Where teams use it - Municipal traffic courts - Police departments - Highway patrol agencies - DMV violation processing - Traffic enforcement agencies - Automated citation systems - Driver education programs - Insurance penalty assessments ## Inside the decision model Traffic Violation Penalty Calculator ships as a JDM decision graph with 5 nodes, 3 decision tables and 23 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ classify\_violation_table_ calculate\_penalty_expression_ finalize\_assessment_table_ assess\_risk\_and\_deadlines _01_ ### Request _input_ Two objects arrive with each citation: violation carries the type, speed\_over\_limit, and in\_school\_zone flag that determine the base penalty and modifiers, while driver contributes previous\_violations for the repeat-offender rules. The date, location, and license\_number fields are recorded but not used in any rule. **Sample request**_JSON_ { "violation": { "type": "speeding", "speed\_over\_limit": 25, "in\_school\_zone": true, "date": "2025-03-15T14:30:00Z", "location": "Main St & 5th Ave" }, "driver": { "license\_number": "DL123456789", "previous\_violations": 1, "license\_issue\_date": "2020-06-15" } } _02_ ### Classify Violation _table_ Offense type sets the baseline in a first-hit table over violation.type and violation.speed\_over\_limit. Speeding is graduated: > 30 over the limit is 'severe' with 4 points and a 300 base fine, > 15 is 'moderate' with 3 points and 150, and any lesser excess is 'minor' at 2 points and 75. Named offenses get fixed rows, 'dui' at the top with 6 points and 500, 'reckless\_driving' at 5 points and 350, 'running\_red\_light' and 'driving\_without\_license' as 'moderate', and the empty catch-all prices unknown violation types as 'minor' with 1 point and 50. Graduating speeding penalties by the margin over the limit is exactly how real fine schedules work, and placing DUI and reckless driving at the top of the point scale matches demerit systems everywhere, since points are meant to track crash risk rather than revenue. A nonzero default row is a deliberate safety net so an unrecognized offense still produces an enforceable minimum penalty instead of an error. Violation Typeviolation.type Speed Over Limitviolation.speed\_over\_limit Severityassessment.severity Pointsassessment.base\_points Base Fineassessment.base\_fine 'speeding' \> 30 'severe' 4 300 'speeding' \> 15 'moderate' 3 150 'speeding' \- 'minor' 2 75 'running\_red\_light' \- 'moderate' 3 200 'illegal\_turn' \- 'minor' 2 100 'dui' \- 'severe' 6 500 +3 more rows in the downloadable template _03_ ### Calculate Penalty _table_ Context scales the baseline here: the table crosses assessment.severity with driver.previous\_violations and violation.in\_school\_zone under a first hit policy. The harshest row, 'severe' with > 2 priors in a school zone, doubles the fine via assessment.base\_fine \* 2, multiplies points by 1.5, and is the only row that sets license\_suspension\_recommended to true. Below it, plain 'severe' cases take a 1.5x fine, 'moderate' repeat offenders 1.25x on both fine and points, a 'moderate' school-zone offense 1.2x, 'minor' with > 3 priors 1.1x, and the default row passes base\_fine and base\_points through untouched. Each multiplier has a real-world counterpart: many jurisdictions double fines in school zones, repeat offenders face enhanced penalties under habitual-offender provisions, and license suspension is normally reserved for the combination of a serious offense and a bad record rather than any single factor. The strictly decreasing multiplier ladder keeps the table's first-hit ordering honest, the worst applicable enhancement always wins. Severityassessment.severity Previous Violationsdriver.previous\_violations In School Zoneviolation.in\_school\_zone Final Fineassessment.final\_fine Final Pointsassessment.final\_points License Suspension Recommendedassessment.license\_suspension\_recommended 'severe' \> 2 true assessment.base\_fine \* 2 assessment.base\_points \* 1.5 true 'severe' \- \- assessment.base\_fine \* 1.5 assessment.base\_points false 'moderate' \> 2 \- assessment.base\_fine \* 1.25 assessment.base\_points \* 1.25 false 'moderate' \- true assessment.base\_fine \* 1.2 assessment.base\_points false 'minor' \> 3 \- assessment.base\_fine \* 1.1 assessment.base\_points false \- \- \- assessment.base\_fine assessment.base\_points false _04_ ### Finalize Assessment _expression_ A small cleanup step applies round(assessment.final\_fine) and round(assessment.final\_points) before the risk stage. The 1.5x and 1.25x multipliers upstream can produce fractional values like 4.5 points, and citations must state whole-dollar fines and integer point assessments, so rounding here keeps the downstream >= 3 and >= 5 point comparisons and the printed penalty consistent. _assessment.final\_fine_`round(assessment.final_fine)` _assessment.final\_points_`round(assessment.final_points)` _05_ ### Assess Risk And Deadlines _table_ Driver risk and the payment window come from crossing assessment.final\_points with severity, first hit wins. A 'severe' violation carrying >= 5 points is the only 'high' risk outcome; >= 3 points yields 'medium' at any severity; and the point-agnostic rows at the bottom default to 'low', including a final empty catch-all. Deadlines run opposite to risk: every 'severe' row gets 15 days to pay, 'moderate' rows 30, and 'minor' or unmatched rows 45. Using the points actually assessed, after enhancement, rather than the base offense makes the risk label reflect the full circumstances of the case. Shorter deadlines for serious violations are a sensible collections policy, keeping high-risk drivers from sitting on unpaid penalties, while the 45-day window for minor infractions mirrors the more lenient response periods typical for ordinary citations. Final Pointsassessment.final\_points Severityassessment.severity Risk Levelassessment.risk\_level Payment Deadline Daysassessment.payment\_deadline\_days \>= 5 'severe' 'high' 15 \>= 3 'severe' 'medium' 15 \>= 3 'moderate' 'medium' 30 \>= 3 'minor' 'medium' 45 \- 'severe' 'low' 15 \- 'moderate' 'low' 30 +2 more rows in the downloadable template ## Other Public Sector templates [View all templates](/templates) [_Public Sector_ ### Government Assistance Streamlined decision system that determines program eligibility based on income thresholds, household size, age factors, and special circumstances. ](/industries/public-sector/templates/government-assistance)[_Public Sector_ ### Tax Exemption Automated system that assesses organizations for 501(c)(3) tax-exempt status based on structure, activities, and financial metrics. ](/industries/public-sector/templates/tax-exemption)[_Public Sector_ ### Municipal Permit Evaluation System Automated system that evaluates building and event permits based on zoning regulations, safety requirements, and environmental impact factors. ](/industries/public-sector/templates/municipal-permit-evaluation-system) ## Make this template your own. Load Traffic Violation Penalty Calculator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Tax Exemption - GoRules **URL:** https://gorules.io/industries/public-sector/templates/tax-exemption **Description:** Automated system that assesses organizations for 501(c)(3) tax-exempt status based on structure, activities, and financial metrics. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Tax Exemption Automated system that assesses organizations for 501(c)(3) tax-exempt status based on structure, activities, and financial metrics. Download template Share ### Solution This tax exemption evaluation system automates the process of determining whether organizations qualify for tax-exempt status under section 501(c)(3) of the tax code. The system analyzes key organizational attributes including type (nonprofit, religious, or educational), annual revenue figures, percentage of public support funding, involvement in political activities, and the proportion of charitable work performed. For qualifying organizations, the system assigns appropriate classifications such as public charity or private foundation based on their public support percentages. It additionally provides specific filing requirements based on revenue thresholds, indicating whether Form 990-N, 990-EZ, or the full Form 990 must be submitted. Organizations that don't qualify receive clear explanations about disqualification reasons - typically political activity involvement or insufficient charitable focus - along with guidance on restructuring options and potential alternative classifications. ### How it works The decision graph evaluates tax-exempt eligibility through these key steps: 1. **Data Collection**: Gathers essential organization information including type, annual revenue, public support percentage, political activity status, and charitable activities percentage. 2. **Primary Eligibility Assessment**: Evaluates if the organization meets fundamental 501(c)(3) requirements - no political activity and at least 85% charitable work. 3. **Classification Determination**: For eligible organizations, determines specific status (public charity, private foundation) based on public support percentages. 4. **Requirement Assignment**: For exempt organizations, calculates the appropriate annual filing form (990-N, 990-EZ, or 990) based on revenue thresholds. 5. **Non-exempt Guidance**: For organizations that don't qualify, provides clear reasons for disqualification, appeal deadlines, and alternative classification options. ### Where teams use it - Nonprofit organizations seeking tax exemption - Religious institutions applying for 501(c)(3) status - Educational institutions evaluating tax status - Private foundations determining filing requirements - Organizations needing to restructure to qualify for exemption - Tax professionals advising nonprofit clients ## Inside the decision model Tax Exemption ships as a JDM decision graph with 5 nodes, 1 decision table and 8 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ organizationRequest_table_ taxExemptionEvaluation_switch_ requiresAdditionalClassification_expression_ exemptRequirements_expression_ nonExemptGuidance _01_ ### Organization Request _input_ Five flat fields describe the organization: organizationType, annualRevenue, publicSupportPercentage, politicalActivity, and charitableActivitiesPercentage. The schema documents each one, and every downstream node reads from this set directly. **Sample request**_JSON_ { "organizationType": "nonprofit", "annualRevenue": 175000, "publicSupportPercentage": 45.7, "politicalActivity": false, "charitableActivitiesPercentage": 92.3 } _02_ ### Tax Exemption Evaluation _table_ One table settles both eligibility and classification under a first hit policy. The top five rows all require politicalActivity to be false and charitableActivitiesPercentage >= 85: 'religious' and 'educational' organizations qualify outright, while 'nonprofit' rows split on publicSupportPercentage into a public charity at >= 33.3, a moderate-support charity at >= 10 and < 33.3, and an 'Exempt - Private Foundation' below 10. Because later rows only run when earlier ones miss, the two disqualification rows (politicalActivity true, charitable share < 85) catch failures, and the empty default row routes anything else to 'Requires Further Review'. The cut points follow real 501(c)(3) practice. Political campaign activity is an absolute bar for 501(c)(3) organizations, and the 33.3 threshold tracks the IRS one-third public support test that separates public charities from private foundations, with the 10-33.3 band echoing the facts-and-circumstances fallback. The 85 percent charitable-activities floor is a policy simplification of the requirement that an exempt organization be operated primarily for exempt purposes. Organization TypeorganizationType Political ActivitypoliticalActivity Charitable Activities PercentagecharitableActivitiesPercentage Public Support PercentagepublicSupportPercentage Classificationresult.classification Statusresult.status Explanationresult.explanation 'religious' false \>= 85 \- '501(c)(3)' 'Exempt' 'Religious organization with no political activity and high charitable focus' 'educational' false \>= 85 \- '501(c)(3)' 'Exempt' 'Educational institution with no political activity and high charitable focus' 'nonprofit' false \>= 85 \>= 33.3 '501(c)(3)' 'Exempt' 'Public charity with substantial public support' 'nonprofit' false \>= 85 \>= 10 and < 33.3 '501(c)(3)' 'Exempt' 'Public charity with moderate public support' 'nonprofit' false \>= 85 < 10 '501(c)(3)' 'Exempt - Private Foundation' 'Private foundation with limited public support' \- true \- \- 'Non-exempt' 'Not Eligible' 'Disqualified due to political activity' +2 more rows in the downloadable template _03_ ### Requires Additional Classification _switch_ Routing splits on a single test: result.classification == '501(c)(3)' sends exempt organizations to the filing-requirements branch, while the empty default statement carries everyone else, non-exempt and pending alike, to the guidance branch. Keeping the fork on classification rather than status means the private foundation variant still gets filing requirements, since its classification is also '501(c)(3)'. _result.classification == '501(c)(3)'_ `Exempt Requirements` _otherwise_ `Non Exempt Guidance` _04_ ### Exempt Requirements _expression_ For exempt organizations, this step derives the annual filing obligation with the chained expression annualRevenue < 50000 ? '990-N' : annualRevenue < 200000 ? '990-EZ' : '990', which matches the actual IRS gross-receipts thresholds for the e-Postcard and the short form. It also sets result.publicDisclosureRequired to true, reflecting that exempt organizations must make their annual returns publicly available, and stamps result.effectiveDate. _result.annualFilingRequirement_`annualRevenue < 50000 ? '990-N' : annualRevenue < 200000 ? '990-EZ' : '990'` _result.publicDisclosureRequired_`true` _result.effectiveDate_`'2025-03-20'` _05_ ### Non Exempt Guidance _expression_ Organizations on the non-exempt path get actionable output instead of a bare denial. result.nextSteps distinguishes 'Not Eligible' organizations, which must restructure, from pending ones that should submit documentation for manual review, and result.alternativeOptions suggests 'Consider 501(c)(4) or 501(c)(6) classification' for nonprofits, the real alternatives for organizations with political or business-league activity. A fixed result.appealDeadline gives the response a concrete follow-up date. _result.nextSteps_`result.status == 'Not Eligible' ? 'Organization must restructure to meet eligibility requirements' : 'Submit additional documentation for manual review'` _result.appealDeadline_`'2025-05-19'` _result.alternativeOptions_`organizationType == 'nonprofit' ? 'Consider 501(c)(4) or 501(c)(6) classification' : ''` ## Other Public Sector templates [View all templates](/templates) [_Public Sector_ ### Government Assistance Streamlined decision system that determines program eligibility based on income thresholds, household size, age factors, and special circumstances. ](/industries/public-sector/templates/government-assistance)[_Public Sector_ ### Municipal Permit Evaluation System Automated system that evaluates building and event permits based on zoning regulations, safety requirements, and environmental impact factors. ](/industries/public-sector/templates/municipal-permit-evaluation-system)[_Public Sector_ ### Immigration Eligibility Evaluator Rules-based system automating visa application processing by evaluating documentation completeness, background checks and qualification scoring. ](/industries/public-sector/templates/immigration-eligibility-evaluator) ## Make this template your own. Load Tax Exemption into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## School District Resource Allocation - GoRules **URL:** https://gorules.io/industries/public-sector/templates/school-district-resource-allocation **Description:** Data-driven funding distribution tool that allocates educational resources based on student population, performance metrics, and specialized program needs. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # School District Resource Allocation Data-driven funding distribution tool that allocates educational resources based on student population, performance metrics, and specialized program needs. Download template Share ### Solution This education funding allocation system automates the distribution of resources to schools using multiple factors to ensure equitable and targeted support. The system first determines base funding using student population size and school type, applying higher per-student rates to smaller schools to account for fixed operational costs. It then adjusts allocations based on academic performance, providing additional support to underperforming schools to help close achievement gaps. The system also recognizes specialized educational needs by allocating supplemental funding for special programs. Schools receive dedicated resources for special education students, English language learners, gifted education, STEM initiatives, and arts programs. Each supplemental allocation is calculated based on specific program enrollment numbers or fixed amounts for infrastructure-based programs. This multi-factor approach ensures resources are distributed according to actual student needs while supporting strategic educational initiatives. ### How it works The decision graph evaluates school data through three sequential steps: 1. **Base Allocation**: Analyzes student population and school type to determine the foundational funding amount, applying higher per-student rates to smaller schools to offset fixed costs. 2. **Performance Adjustment**: Calculates the average of math and reading test scores to determine a performance multiplier. Schools scoring below 70% receive a 20% funding increase, while schools between 70-85% receive a 10% increase. 3. **Special Programs Calculation**: Identifies all special programs offered by the school and allocates additional funding based on: - Special education: $3,000 per enrolled student - ESL programs: $2,500 per enrolled student - Gifted programs: $1,800 per enrolled student - STEM initiatives: $20,000 flat allocation - Arts programs: $15,000 flat allocation All components work together to create a total funding package that addresses each school's unique profile and needs. ### Where teams use it - Public school district budget allocation - State-level education funding distribution - Charter school network resource management - Education grant program administration - School improvement initiative funding - Rural and small school support programs ## Inside the decision model School District Resource Allocation ships as a JDM decision graph with 4 nodes, 2 decision tables and 10 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ baseAllocation_expression_ performanceAdjustment_table_ specialProgramsAdjustment _01_ ### Request _input_ A single school object drives the whole allocation: student\_population and type size the base grant, test\_scores.math and test\_scores.reading feed the performance adjustment, and the special\_programs list plus the special\_education\_students, esl\_students, and gifted\_students counts determine supplemental funding. **Sample request**_JSON_ { "school": { "id": "sch\_12345", "name": "Washington High School", "type": "secondary", "student\_population": 750, "special\_education\_students": 45, "esl\_students": 80, "gifted\_students": 35, "test\_scores": { "math": 82, "reading": 78 }, "special\_programs": \[ "special\_education", "esl", "stem" \] } } _02_ ### Base Allocation _table_ Per-student rates fall as enrollment grows: with a first hit policy on school.student\_population, schools > 1000 get school.student\_population \* 5000 as 'large', > 500 gets a 5500 rate as 'medium', > 200 gets 6000 as 'small', and the remaining rows tag 'very\_small' schools, with 'elementary' type getting the top 6500 rate and everything else 6000. The output expressions compute allocation.base\_funding directly in the table, so the size category and the dollar amount always stay in sync. The inverse relationship between size and rate reflects a real feature of state education funding formulas, often called a small-school or sparsity adjustment: fixed costs like administration and facilities do not shrink with enrollment, so small schools need more dollars per student to offer the same program. The specific rates are illustrative, but the monotonic 5000-6500 ladder is the right shape. Student Populationschool.student\_population School Typeschool.type Base Fundingallocation.base\_funding School Size Categoryallocation.school\_size \> 1000 \- school.student\_population \* 5000 'large' \> 500 \- school.student\_population \* 5500 'medium' \> 200 \- school.student\_population \* 6000 'small' \- 'elementary' school.student\_population \* 6500 'very\_small' \- \- school.student\_population \* 6000 'very\_small' _03_ ### Performance Adjustment _expression_ Three chained expressions turn test results into money. performance\_score averages school.test\_scores.math and reading, the nested conditional maps it to a performance\_multiplier of 1.2 below 70, 1.1 below 85, and 1.0 otherwise, and adjusted\_funding multiplies allocation.base\_funding by that factor. Boosting rather than penalizing low scores encodes a compensatory funding stance, extra resources flow to schools with achievement gaps instead of being withdrawn from them. _performance\_score_`(school.test_scores.math + school.test_scores.reading) / 2` _performance\_multiplier_`$.performance_score < 70 ? 1.2 : ($.performance_score < 85 ? 1.1 : 1.0)` _adjusted\_funding_`allocation.base_funding * $.performance_multiplier` _04_ ### Special Programs Adjustment _table_ Unlike the earlier stages, this table runs under a collect hit policy, so every matching row fires and the results accumulate under the funding output path. Each row tests membership with contains(school.special\_programs, ...) and prices the program its own way: enrollment-driven amounts of school.special\_education\_students \* 3000, esl\_students \* 2500, and gifted\_students \* 1800, versus flat grants of 20000 for 'stem' and 15000 for 'arts'. The sample school matches three rows at once, which is exactly what collect is for. Per-pupil supplements for special education and English learners mirror weighted student funding, the mainstream approach in US school finance where student categories carry extra weights on top of base funding, and putting the highest weight on special education matches its real cost profile. Flat amounts for STEM and arts are the natural fit for infrastructure-style initiatives whose costs do not scale with headcount. Special Programs Additional Fundingallocation.program\_funding Funding Descriptionallocation.funding\_descriptions contains(school.special\_programs, 'special\_education') school.special\_education\_students \* 3000 'Special Education Support' contains(school.special\_programs, 'esl') school.esl\_students \* 2500 'ESL Program Support' contains(school.special\_programs, 'gifted') school.gifted\_students \* 1800 'Gifted Program Support' contains(school.special\_programs, 'stem') 20000 'STEM Program Support' contains(school.special\_programs, 'arts') 15000 'Arts Program Support' ## Other Public Sector templates [View all templates](/templates) [_Public Sector_ ### Government Assistance Streamlined decision system that determines program eligibility based on income thresholds, household size, age factors, and special circumstances. ](/industries/public-sector/templates/government-assistance)[_Public Sector_ ### Tax Exemption Automated system that assesses organizations for 501(c)(3) tax-exempt status based on structure, activities, and financial metrics. ](/industries/public-sector/templates/tax-exemption)[_Public Sector_ ### Municipal Permit Evaluation System Automated system that evaluates building and event permits based on zoning regulations, safety requirements, and environmental impact factors. ](/industries/public-sector/templates/municipal-permit-evaluation-system) ## Make this template your own. Load School District Resource Allocation into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Municipal Permit Evaluation System - GoRules **URL:** https://gorules.io/industries/public-sector/templates/municipal-permit-evaluation-system **Description:** Automated system that evaluates building and event permits based on zoning regulations, safety requirements, and environmental impact factors. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Municipal Permit Evaluation System Automated system that evaluates building and event permits based on zoning regulations, safety requirements, and environmental impact factors. Download template Share ### Solution This permit evaluation system streamlines the application process for building construction and event permits by applying clear regulatory criteria. The system assesses applications across different zone types (residential, commercial, industrial) and event categories (indoor, outdoor), checking each against specific thresholds for approval. For building permits, the system evaluates height restrictions, square footage limits, and safety scores based on zoning type. Residential applications must meet height limits of 35 feet, while commercial buildings face different standards up to 100 feet. For events, the system considers attendee counts and venue safety scores, with larger gatherings requiring additional management plans. Every application undergoes environmental impact assessment, with minimal impact applications fast-tracked while those with moderate or significant impact face additional requirements or potential denial. The system provides clear reasoning for all decisions, helping applicants understand next steps. ### How it works The decision graph processes permit applications through several connected evaluation stages: 1. **Application Classification**: Identifies the application type (building or event) and categorizes by zone type (residential, commercial, industrial) or event location (indoor, outdoor). 2. **Initial Approval Check**: Evaluates the application against zone-specific criteria including building height, square footage, and safety scores, assigning an initial status. 3. **Environmental Impact Assessment**: Reviews the environmental impact level (minimal, moderate, significant) against the initial approval status. 4. **Final Determination**: Combines all evaluations to produce a final status (Approved, Conditional, Denied, Pending) with detailed reasoning. 5. **Next Steps Assignment**: Assigns appropriate follow-up processes based on the final determination, from standard approval to comprehensive review requirements. ### Where teams use it - Municipal building permit processing - Commercial construction approval - Residential building code enforcement - Public event permitting - Industrial development assessment - Environmental compliance verification - Automated variance identification - Streamlined application screening ## Inside the decision model Municipal Permit Evaluation System ships as a JDM decision graph with 4 nodes, 2 decision tables and 17 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ permitRequest_expression_ applicationClassification_table_ initialApprovalCheck_table_ environmentalCheck _01_ ### Permit Request _input_ A permit application arrives with applicationType and zoneType plus the measurable facts the rules test: buildingHeight, squareFootage, safetyScore, and environmentalImpact. The applicantInfo, propertyAddress, and projectDescription objects ride along for record-keeping but are not evaluated by any rule. **Sample request**_JSON_ { "applicationType": "building", "zoneType": "residential", "buildingHeight": 28, "squareFootage": 3200, "safetyScore": 85, "environmentalImpact": "minimal", "applicantInfo": { "name": "John Smith", "contactEmail": "john.smith@example.com", "phoneNumber": "555-123-4567" }, "propertyAddress": { "street": "123 Main Street", "city": "Anytown", "state": "CA", "zipCode": "90210" }, "projectDescription": "Single-family home construction with attached garage" } _02_ ### Application Classification _expression_ Before any rules run, five booleans classify the application: isResidentialZone, isCommercialZone, and isIndustrialZone each combine applicationType == 'building' with a zoneType check, while isOutdoorEvent and isIndoorEvent pair applicationType == 'event' with a location value. Precomputing these flags keeps the approval table readable, since each row can reference one named flag instead of repeating the two-part condition. _isResidentialZone_`applicationType == 'building' and zoneType == 'residential'` _isCommercialZone_`applicationType == 'building' and zoneType == 'commercial'` _isIndustrialZone_`applicationType == 'building' and zoneType == 'industrial'` _isOutdoorEvent_`applicationType == 'event' and location == 'outdoor'` _isIndoorEvent_`applicationType == 'event' and location == 'indoor'` _03_ ### Initial Approval Check _table_ Zone-specific approval criteria live in one first-hit table whose first column holds inline expressions over the classification flags. Residential rows pass at buildingHeight <= 35 with squareFootage < 5000 and safetyScore >= 80, and flip to 'Conditional' with a variance requirement above 35 feet. Commercial rows allow up to 100 feet under 20000 square feet with a safety floor of 85, isIndustrialZone rows are always 'Conditional' pending environmental assessment, and events split at 500 expectedAttendees for outdoor or a 90 safety score for indoor. Near the bottom, any application with safetyScore < 75 is 'Denied' outright, and the empty final row leaves everything else 'Pending' for manual review. The 35-foot cap reflects a genuinely common residential height limit in municipal zoning codes, roughly two and a half stories, while the higher commercial allowance and the escalating safety floors (80, 85, 90 as risk grows from residential to industrial) are sensible tiering rather than any specific statute. Routing over-height buildings to a variance process instead of denying them mirrors how zoning boards actually handle nonconforming proposals. Application Type Square FootagesquareFootage Safety ScoresafetyScore StatusinitialApprovalStatus ReasonstatusReason isResidentialZone and buildingHeight <= 35 < 5000 \>= 80 'Approved' 'Residential building meets height and safety requirements' isResidentialZone and buildingHeight > 35 < 5000 \>= 80 'Conditional' 'Residential building exceeds height limits, requires variance approval' isCommercialZone and buildingHeight <= 100 < 20000 \>= 85 'Approved' 'Commercial building meets standard requirements' isCommercialZone and buildingHeight > 100 \- \>= 85 'Conditional' 'Commercial building exceeds height limits, requires additional review' isIndustrialZone \- \>= 90 'Conditional' 'Industrial buildings require environmental impact assessment' isOutdoorEvent and expectedAttendees <= 500 \- \>= 75 'Approved' 'Small outdoor event meets safety requirements' +4 more rows in the downloadable template _04_ ### Environmental Check _table_ Final disposition comes from crossing initialApprovalStatus with environmentalImpact under a first hit policy. An 'Approved' application stays approved only when impact is 'minimal'; 'moderate' impact downgrades it to 'Conditional' with an 'environmental\_review' next step, and conditional applications with moderate impact escalate to 'comprehensive\_review', appending ' and requires environmental assessment' to the carried-over statusReason. The 'significant' row denies either status outright, and the 'Denied' and 'Pending' rows pass their statusReason through unchanged so earlier reasoning survives to the response. Making environmental impact a gate that can only hold or worsen the outcome, never improve it, matches how discretionary permitting works in practice: environmental review is a required clearance layered on top of zoning compliance, not a factor traded off against it. The graded next steps, from 'standard' through 'comprehensive\_review', give the intake team a workload signal in the same pass. Initial StatusinitialApprovalStatus Environmental ImpactenvironmentalImpact Final StatusapprovalStatus Final ReasonapprovalReason Next StepsnextSteps 'Approved' 'minimal' 'Approved' 'Application approved - Minimal environmental impact' 'standard' 'Approved' 'moderate' 'Conditional' 'Application requires environmental mitigation plan' 'environmental\_review' 'Conditional' 'minimal' 'Conditional' statusReason 'standard\_review' 'Conditional' 'moderate' 'Conditional' statusReason + ' and requires environmental assessment' 'comprehensive\_review' 'Conditional' or 'Approved' 'significant' 'Denied' 'Application denied due to significant environmental impact' 'rejected' 'Denied' \- 'Denied' statusReason 'rejected' +1 more row in the downloadable template ## Other Public Sector templates [View all templates](/templates) [_Public Sector_ ### Government Assistance Streamlined decision system that determines program eligibility based on income thresholds, household size, age factors, and special circumstances. ](/industries/public-sector/templates/government-assistance)[_Public Sector_ ### Tax Exemption Automated system that assesses organizations for 501(c)(3) tax-exempt status based on structure, activities, and financial metrics. ](/industries/public-sector/templates/tax-exemption)[_Public Sector_ ### Immigration Eligibility Evaluator Rules-based system automating visa application processing by evaluating documentation completeness, background checks and qualification scoring. ](/industries/public-sector/templates/immigration-eligibility-evaluator) ## Make this template your own. Load Municipal Permit Evaluation System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Import Duties Calculator - GoRules **URL:** https://gorules.io/industries/public-sector/templates/import-duties-calculator **Description:** Automated system that calculates precise import duties and taxes based on product details, country relationships, and trade agreements. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Import Duties Calculator Automated system that calculates precise import duties and taxes based on product details, country relationships, and trade agreements. Download template Share ### Solution This import duty calculator determines exact customs fees by analyzing multiple factors that affect international shipping costs. The system classifies products using both category information and Harmonized System codes to establish base duty rates specific to product types. It then applies country-specific rules that consider origin-destination relationships, existing free trade agreements, and current sanctions status. The calculator handles preferential treatment eligibility, applying appropriate discounts when permitted by international trade agreements. Special handling for sanctioned countries automatically triggers additional fees and higher multipliers. The system ensures minimum duty thresholds are met while calculating the final duty amount and percentage rate relative to product value. This streamlines customs clearance processes while providing accurate, rules-compliant duty calculations for both businesses and customs brokers. ### How it works The calculator processes import information through several specialized components: 1. **Product Classification**: Analyzes product category and HS code to determine the appropriate base duty rate and product classification. 2. **Country Rules Assessment**: Evaluates the relationship between origin and destination countries, applying multipliers based on trade agreements and identifying sanctioned nations. 3. **Duty Calculation**: Processes all collected data through a multi-step formula that: - Calculates initial base duty from product value and classification rate - Applies country-specific adjustments based on trade relationships - Adds sanctions-related fees when applicable - Applies preferential treatment discounts if eligible - Ensures a minimum duty threshold is met - Calculates the effective duty rate as a percentage of product value ### Where teams use it - E-commerce platforms calculating cross-border shipping fees - Import/export businesses planning international shipments - Customs brokers preparing documentation for clients - Logistics companies providing shipping cost estimates - Trade compliance departments verifying duty calculations - Government agencies monitoring trade flows and revenue ## Inside the decision model Import Duties Calculator ships as a JDM decision graph with 4 nodes, 2 decision tables and 15 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ product\_classification_table_ country\_rules_expression_ duty\_calculation _01_ ### Request _input_ A shipment is described by three objects: product with its category, value, weight, and hsCode; origin with the country plus the hasFTA and preferentialTreatment flags; and destination with the receiving country. Everything except weight is consumed by a downstream rule. **Sample request**_JSON_ { "product": { "category": "electronics", "value": 1200, "weight": 0.8, "hsCode": "851712" }, "origin": { "country": "CN", "hasFTA": false, "preferentialTreatment": false }, "destination": { "country": "US" } } _02_ ### Product Classification _table_ Classification pairs product.category with a Harmonized System prefix test under a first hit policy. 'electronics' splits on startsWith($, '85') for 'High-Tech Electronics' at a 0.15 baseRate versus '90' for 'Precision Electronics' at 0.12; 'textiles' distinguishes 'Clothing' (chapters 61, 62 at 0.20) from 'Home Textiles' (63 at 0.18); 'food' separates 'Perishable Food' (02, 03, 04 at 0.22) from 'Processed Food' (19, 20, 21 at 0.16); 'automotive' with prefix '87' takes the highest rate at 0.25; and the empty row defaults everything else to 'General Merchandise' at 0.18. The chapter prefixes are the real HS nomenclature, 85 for electrical machinery, 61 and 62 for knitted and woven apparel, 87 for vehicles, so matching on the first two digits mirrors how customs schedules actually key rates to headings. The rate spread is also directionally faithful: real tariff schedules tax clothing and food more heavily than most electronics. The exact percentages are simplified single rates standing in for line-by-line tariff schedules. Product Categoryproduct.category HS Codeproduct.hsCode Base Duty Rateclassification.baseRate Product Classificationclassification.category 'electronics' startsWith($, '85') 0.15 'High-Tech Electronics' 'electronics' startsWith($, '90') 0.12 'Precision Electronics' 'textiles' startsWith($, '61'), startsWith($, '62') 0.20 'Clothing' 'textiles' startsWith($, '63') 0.18 'Home Textiles' 'food' startsWith($, '02'), startsWith($, '03'), startsWith($, '04') 0.22 'Perishable Food' 'food' startsWith($, '19'), startsWith($, '20'), startsWith($, '21') 0.16 'Processed Food' +2 more rows in the downloadable template _03_ ### Country Rules _table_ Trade relationships turn into a multiplier on the classified rate, matched first-hit on origin.country, destination.country, and origin.hasFTA. 'MX' and 'CA' with hasFTA true get a countryMultiplier of 0.0, duty-free, while 'CN' to 'US' without an FTA is surcharged at 1.25, the European group 'GB', 'DE', 'FR', 'IT', 'ES' gets a mild 0.8 preference, 'VN' 0.9, and 'KP', 'IR' are the only rows setting hasSanctions true with a punitive 3.0 multiplier. The catch-all row applies a neutral 1.0 with no sanctions so unlisted origins still price normally. Each row tracks a recognizable feature of US trade policy: duty-free Mexican and Canadian goods under a free trade agreement, elevated duties on Chinese imports, and North Korea and Iran as comprehensively sanctioned origins. Modeling all of that as one multiplier per lane is a simplification, but it keeps the geopolitical layer separate from product classification, which is how customs systems are typically structured. Origin Countryorigin.country Destination Countrydestination.country Has FTAorigin.hasFTA Country MultipliercountryRules.multiplier Has SanctionscountryRules.hasSanctions 'CN' 'US' false 1.25 false 'MX' 'US' true 0.0 false 'CA' 'US' true 0.0 false 'GB', 'DE', 'FR', 'IT', 'ES' 'US' false 0.8 false 'KP', 'IR' 'US' \- 3.0 true 'VN' 'US' false 0.9 false +1 more row in the downloadable template _04_ ### Duty Calculation _expression_ Seven expressions assemble the final figure in order: baseDuty multiplies product.value by number(classification.baseRate), countryAdjustment applies the country multiplier, and additionalFees adds product.value \* 0.1 only when countryRules.hasSanctions is true. preferentialDiscount then cuts the adjusted duty to 80 percent when origin.preferentialTreatment is set, and minDuty enforces a max(\[10, ...\]) floor, but only when countryAdjustment > 0, so FTA lanes with a 0.0 multiplier stay genuinely duty-free instead of being bumped to the 10-dollar minimum. totalDuty and dutyRate finish the job, and with passThrough disabled the node returns just these computed keys as the response. _baseDuty_`product.value * number(classification.baseRate)` _countryAdjustment_`$.baseDuty * number(countryRules.multiplier)` _additionalFees_`countryRules.hasSanctions == true ? product.value * 0.1 : 0` _preferentialDiscount_`origin.preferentialTreatment == true ? $.countryAdjustment * 0.8 : $.countryAdjustment` _minDuty_`$.countryAdjustment > 0 ? max([10, $.preferentialDiscount]) : 0` _totalDuty_`$.minDuty + $.additionalFees` _dutyRate_`$.totalDuty / product.value` ## Other Public Sector templates [View all templates](/templates) [_Public Sector_ ### Government Assistance Streamlined decision system that determines program eligibility based on income thresholds, household size, age factors, and special circumstances. ](/industries/public-sector/templates/government-assistance)[_Public Sector_ ### Tax Exemption Automated system that assesses organizations for 501(c)(3) tax-exempt status based on structure, activities, and financial metrics. ](/industries/public-sector/templates/tax-exemption)[_Public Sector_ ### Municipal Permit Evaluation System Automated system that evaluates building and event permits based on zoning regulations, safety requirements, and environmental impact factors. ](/industries/public-sector/templates/municipal-permit-evaluation-system) ## Make this template your own. Load Import Duties Calculator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Immigration Eligibility Evaluator - GoRules **URL:** https://gorules.io/industries/public-sector/templates/immigration-eligibility-evaluator **Description:** Rules-based system automating visa application processing by evaluating documentation completeness, background checks and qualification scoring. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Immigration Eligibility Evaluator Rules-based system automating visa application processing by evaluating documentation completeness, background checks and qualification scoring. Download template Share ### Solution This automated immigration evaluation system streamlines visa application processing by methodically assessing applicant eligibility through multiple criteria. The system first verifies all required documentation including passport validity, completed application forms, proof of funds, and medical examination results. For security purposes, it performs thorough background checks examining criminal history, previous immigration violations, security flags, and visa rejection history. The qualification assessment component evaluates education levels from primary to doctorate, work experience duration, language proficiency, in-demand skills, and family connections. Each criterion receives a numerical score with appropriate weighting. Applications automatically route to approval, rejection, or manual review based on combined scores and rule-based conditions. This system dramatically reduces processing times while ensuring consistent application of immigration criteria and providing clear justification for all decisions. ### How it works The decision graph processes applications through sequential evaluation stages: 1. **Documentation Verification**: Checks passport validity, application completeness, proof of funds, and medical examination status. 2. **Background Screening**: Evaluates criminal history, immigration violations, security concerns, and previous visa rejections. 3. **Education Assessment**: Scores education levels from primary through doctorate with appropriate point values. 4. **Work Experience Evaluation**: Assigns scores based on years of relevant professional experience. 5. **Language Proficiency Rating**: Measures language skills from basic to native speaker levels. 6. **Additional Factors Analysis**: Considers in-demand skills and family connections that may enhance eligibility. 7. **Final Decision Logic**: Calculates overall scores, applies decision rules, and determines if the application should be approved, rejected, or flagged for manual review. ### Where teams use it - Government immigration departments - Visa processing centers - Consular services - Immigration law firms - Border control agencies - Refugee status determination - Work permit processing - Student visa evaluation - Permanent residency applications - Citizenship pathway assessment ## Inside the decision model Immigration Eligibility Evaluator ships as a JDM decision graph with 8 nodes, 7 decision tables and 39 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ immigrationApplication_table_ verifyDocumentation_table_ evaluateBackground_table_ assessEducation_table_ assessWorkExperience_table_ assessLanguage_table_ assessAdditionalFactors_table_ finalAssessment _01_ ### Immigration Application _input_ Four objects carry the application: documentation holds the boolean completeness checks, background the security-relevant history, qualifications the scoreable attributes, and applicant the identity details that the rules never test but the case file needs. **Sample request**_JSON_ { "applicant": { "fullName": "Jane Smith", "dateOfBirth": "1985-05-15", "nationality": "United Kingdom", "currentResidence": "France" }, "documentation": { "passportValid": true, "visaApplicationComplete": true, "proofOfFundsProvided": true, "medicalCheckComplete": true, "supportingDocuments": \[ "Reference Letter", "Property Deed", "Bank Statements" \] }, "background": { "criminalHistory": false, "immigrationViolations": false, "securityConcerns": false, "previousVisaRejections": 0 }, "qualifications": { "educationLevel": "master", "workExperienceYears": 8, "languageProficiency": "advanced", "skillsInDemand": true, "familyConnections": false } } _02_ ### Verify Documentation _table_ Completeness is screened first, with a first hit policy that surfaces the most serious gap. A false documentation.passportValid rejects immediately with a documentationScore of 0, while a missing visaApplicationComplete, proofOfFundsProvided, or medicalCheckComplete marks the file "incomplete" with partial scores of 40, 50, and 60 that record how far along it is. Only when all four flags are true does the row set "pending" with a full 100, letting the file continue toward substantive assessment. Checking formal completeness before merits is how visa processing actually works: consulates return incomplete files without adjudicating them, and an invalid passport is a hard stop rather than a curable defect. Distinguishing "rejected" from "incomplete" matters downstream, since an incomplete applicant can resubmit while a rejection ends the case. Passport Validdocumentation.passportValid Application Completedocumentation.visaApplicationComplete Proof of Fundsdocumentation.proofOfFundsProvided Medical Checkdocumentation.medicalCheckComplete Statusassessment.documentationStatus Reasonassessment.documentationReason Scoreassessment.documentationScore false \- \- \- "rejected" "Missing valid passport" 0 \- false \- \- "incomplete" "Incomplete visa application" 40 \- \- false \- "incomplete" "Missing proof of funds" 50 \- \- \- false "incomplete" "Medical check not completed" 60 true true true true "pending" "Documentation complete" 100 _03_ ### Evaluate Background _table_ Security screening ranks the flags by severity under a first hit policy. background.criminalHistory being true is terminal, "rejected" with a score of 0, while immigrationViolations and securityConcerns send the file to "review" with scores of 30 and 20. Rejection history is graded on previousVisaRejections: >= 3 forces "review" at 40, a value of 1, 2 passes as "pending" at 70 with the note "Previous rejections noted", and a clean 0 earns the full 100. The ordering mirrors grounds of inadmissibility in real immigration law, where criminal history is typically a bar and prior violations trigger heightened scrutiny rather than automatic refusal. Treating one or two past rejections as a score haircut instead of a blocker is a sensible policy choice, since reapplication after refusal is common and not itself disqualifying. Criminal Historybackground.criminalHistory Immigration Violationsbackground.immigrationViolations Security Concernsbackground.securityConcerns Previous Rejectionsbackground.previousVisaRejections Statusassessment.backgroundStatus Reasonassessment.backgroundReason Scoreassessment.backgroundScore true \- \- \- "rejected" "Criminal history detected" 0 false true \- \- "review" "Immigration violations" 30 false false true \- "review" "Security concerns" 20 false false false \>= 3 "review" "Multiple previous rejections" 40 false false false 1, 2 "pending" "Previous rejections noted" 70 false false false 0 "pending" "Background check clear" 100 _04_ ### Assess Education _table_ Educational attainment converts to points on a simple ladder: qualifications.educationLevel of "doctorate" scores 100, "master" 80, "bachelor" 60, "secondary" 40, "primary" 20, and "none" 0, each row also emitting a human-readable educationReason. The first hit policy is safe here because the enum values are mutually exclusive, so exactly one row fires. Awarding graduated points for credentials is the standard mechanic of points-based immigration systems such as Canada's Express Entry or Australia's skilled migration stream. The even 20-point steps are a modeling simplification, but the shape, with a meaningful premium for postgraduate degrees, matches how those systems weight education. Education Levelqualifications.educationLevel Scoreassessment.educationScore Reasonassessment.educationReason "doctorate" 100 "Highest education level" "master" 80 "Advanced education" "bachelor" 60 "University education" "secondary" 40 "Secondary education" "primary" 20 "Primary education only" "none" 0 "No formal education" _05_ ### Assess Work Experience _table_ Years of professional history map to points through descending threshold rows: qualifications.workExperienceYears >= 10 scores 100, >= 7 scores 80, >= 4 scores 60, >= 2 scores 40, >= 1 scores 20, and exactly 0 scores 0. Under the first hit policy the highest band an applicant clears is the one that counts, so the rows must stay sorted from most to least experience. Banding experience rather than scoring it linearly follows real skilled-migration practice, where points accrue in steps and plateau once experience stops adding predictive value, here at ten years. The bands themselves are sensible design choices rather than a transcription of any one country's schedule. Work Experience Yearsqualifications.workExperienceYears Scoreassessment.experienceScore Reasonassessment.experienceReason \>= 10 100 "Extensive work experience" \>= 7 80 "Significant work experience" \>= 4 60 "Moderate work experience" \>= 2 40 "Limited work experience" \>= 1 20 "Minimal work experience" 0 0 "No work experience" _06_ ### Assess Language _table_ Self-assessed language ability becomes a score through five enum rows: "native" gives 100, "advanced" 75, "intermediate" 50, "basic" 25, and "none" 0, written to assessment.languageScore alongside a matching languageReason. One row per value of qualifications.languageProficiency means the first hit policy resolves deterministically. Language proficiency is a pillar of every major points-based system because it predicts labor-market integration, and real programs anchor these levels to test frameworks like CEFR or CLB bands. The even 25-point spacing is a clean modeling choice standing in for those graded test scores. Language Proficiencyqualifications.languageProficiency Scoreassessment.languageScore Reasonassessment.languageReason "native" 100 "Native language proficiency" "advanced" 75 "Advanced language proficiency" "intermediate" 50 "Intermediate language proficiency" "basic" 25 "Basic language proficiency" "none" 0 "No language proficiency" _07_ ### Assess Additional Factors _table_ Two booleans combine into a bonus score covering all four cases: skillsInDemand and familyConnections together give 100, skills alone 80, family alone 70, and neither 0. Enumerating every combination explicitly, rather than adding two independent bonuses, lets the table cap the combined value at 100 so this factor cannot outweigh the core assessments. Both factors have real analogues: occupation-in-demand lists and family sponsorship provisions appear across immigration systems, and giving in-demand skills the slight edge (80 versus 70) reflects the economic-migration emphasis of points-based selection. The exact spread is a policy choice, not a statutory value. Skills In Demandqualifications.skillsInDemand Family Connectionsqualifications.familyConnections Scoreassessment.additionalFactorsScore Reasonassessment.additionalFactorsReason true true 100 "In-demand skills and family connections" true false 80 "In-demand skills" false true 70 "Family connections" false false 0 "No additional qualifying factors" _08_ ### Final Assessment _table_ Hard gates come before arithmetic in the final table. The first rows check assessment.documentationStatus and backgroundStatus: any "rejected" status propagates as a rejection carrying the original reason, "incomplete" documentation keeps the file incomplete, and a background "review" forces manual review regardless of merit. Only clean files reach the scoring rows, where the average of all six component scores divided by 6 decides the outcome: >= 70 is "approved", >= 50 is "review", and anything lower falls to the default "rejected" row, with the computed average always written to assessment.overallScore. Separating eligibility gates from the points computation reflects how real systems combine mandatory requirements with competitive scoring: no amount of education offsets a criminal bar or a missing passport. The 70 and 50 cut lines create a deliberate middle band where a human officer, not the ruleset, makes the call, which is standard practice for borderline visa files. Documentation Statusassessment.documentationStatus Background Statusassessment.backgroundStatus Average Score(assessment.documentationScore + assessment.backgroundScore + assessment.educationScore + assessment.experienceScore + assessment.languageScore + assessment.additionalFactorsScore) / 6 Final Statusassessment.finalStatus Final Reasonassessment.finalReason Overall Scoreassessment.overallScore "rejected" \- \- "rejected" assessment.documentationReason assessment.documentationScore \- "rejected" \- "rejected" assessment.backgroundReason assessment.backgroundScore "incomplete" \- \- "incomplete" assessment.documentationReason assessment.documentationScore \- "review" \- "review" assessment.backgroundReason (assessment.documentationScore + assessment.backgroundScore + assessment.educationScore + assessment.experienceScore + assessment.languageScore + assessment.additionalFactorsScore) / 6 \- \- \>= 70 "approved" "Application meets criteria" (assessment.documentationScore + assessment.backgroundScore + assessment.educationScore + assessment.experienceScore + assessment.languageScore + assessment.additionalFactorsScore) / 6 \- \- \>= 50 "review" "Application requires further review" (assessment.documentationScore + assessment.backgroundScore + assessment.educationScore + assessment.experienceScore + assessment.languageScore + assessment.additionalFactorsScore) / 6 +1 more row in the downloadable template ## Other Public Sector templates [View all templates](/templates) [_Public Sector_ ### Government Assistance Streamlined decision system that determines program eligibility based on income thresholds, household size, age factors, and special circumstances. ](/industries/public-sector/templates/government-assistance)[_Public Sector_ ### Tax Exemption Automated system that assesses organizations for 501(c)(3) tax-exempt status based on structure, activities, and financial metrics. ](/industries/public-sector/templates/tax-exemption)[_Public Sector_ ### Municipal Permit Evaluation System Automated system that evaluates building and event permits based on zoning regulations, safety requirements, and environmental impact factors. ](/industries/public-sector/templates/municipal-permit-evaluation-system) ## Make this template your own. Load Immigration Eligibility Evaluator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Grant Funding Distribution - GoRules **URL:** https://gorules.io/industries/public-sector/templates/grant-funding-distribution **Description:** Automated system that calculates grant awards based on project merit, applicant quality, budget availability, and potential community impact. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Grant Funding Distribution Automated system that calculates grant awards based on project merit, applicant quality, budget availability, and potential community impact. Download template Share ### Solution This grant funding decision system streamlines the award process by evaluating applications through multiple objective criteria. The system analyzes project scope to determine if initiatives are local, regional, or national in scale, while assessing applicant qualifications based on experience, track record, and organizational capacity. The solution incorporates sophisticated impact metrics including number of beneficiaries, innovation potential, long-term sustainability, and community need severity. Budget constraints are automatically factored in, ensuring the total allocation stays within available funding while maintaining appropriate distribution across priority levels. When determining awards, the system calculates whether applications meet minimum viable funding thresholds, providing clear approval status and funding percentages to maintain transparency throughout the process. ### How it works The decision graph processes applications through three key evaluation stages: 1. **Project Evaluation**: Analyzes project scope, applicant qualifications, and impact metrics to determine funding priority (high/medium/low) and establish a base funding ratio. 2. **Budget Constraint Analysis**: Adjusts funding based on current budget allocation status, applying different adjustment factors according to priority level and existing allocation ratio. 3. **Funding Calculation**: Determines the final grant amount by multiplying requested amount by both base funding ratio and adjustment factor, then comparing against maximum award limits and minimum viable amounts. The system automatically generates approval status (Approved, Partially Funded, or Rejected) and calculates the percentage of requested funding being awarded, giving administrators clear decision support. ### Where teams use it - Government grant programs - Foundation funding distribution - Educational research grants - Healthcare innovation funding - Arts and culture support programs - Community development initiatives - Environmental conservation grants - Nonprofit capacity building ## Inside the decision model Grant Funding Distribution ships as a JDM decision graph with 4 nodes, 2 decision tables and 16 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ project\_evaluation_table_ budget\_constraint_expression_ funding\_calculation _01_ ### Request _input_ Two top-level objects feed the graph: application carries projectScope, applicantQualifications, requestedAmount, minimumViableAmount, and the impactMetrics block whose overallScore the evaluation table reads, while budgetConstraints supplies the allocationRatio and maxAwardAmount that bound the award. **Sample request**_JSON_ { "application": { "id": "GR-2025-0042", "organizationName": "Community Health Initiative", "projectTitle": "Rural Healthcare Access Program", "projectScope": "high", "applicantQualifications": "medium", "requestedAmount": 75000, "minimumViableAmount": 50000, "impactMetrics": { "beneficiaries": 1200, "innovationScore": 72, "sustainabilityScore": 68, "communityNeedScore": 85, "overallScore": 75 } }, "budgetConstraints": { "totalBudget": 500000, "allocatedAmount": 325000, "allocationRatio": 0.65, "maxAwardAmount": 100000 } } _02_ ### Project Evaluation _table_ Merit scoring happens in one first-hit table over application.projectScope, applicantQualifications, and impactMetrics.overallScore. The rows are ordered from strongest to weakest combination: 'high' scope with 'high' qualifications and a score >= 80 earns 'high' priority and a 0.9 baseFundingRatio, mixed high/medium combinations need >= 70 for ratios of 0.8 and 0.75, mid-tier pairings need >= 60 for 0.65-0.7, and the weakest pairing, 'low' on both dimensions, still qualifies at >= 40 but only for a 0.4 ratio. Applications matching nothing fall to the default row, priority 'rejected' with a ratio of 0. Notice that the score floor drops as the qualitative pairing weakens, from 80 down to 40, so a modest project is not held to a flagship project's standard, but its funding ratio shrinks in step. This mirrors how competitive grant programs actually behave: review panels rank applications into priority tiers and routinely recommend less than the requested amount, and combining scope, applicant capacity, and a numeric impact score is the standard three-legged merit review. Project Scopeapplication.projectScope Applicant Qualificationsapplication.applicantQualifications Impact Scoreapplication.impactMetrics.overallScore Funding Priorityevaluation.fundingPriority Base Funding Ratioevaluation.baseFundingRatio 'high' 'high' \>= 80 'high' 0.9 'high' 'medium' \>= 70 'high' 0.8 'medium' 'high' \>= 70 'high' 0.75 'high' 'low' \>= 60 'medium' 0.7 'medium' 'medium' \>= 60 'medium' 0.65 'low' 'high' \>= 60 'medium' 0.6 +4 more rows in the downloadable template _03_ ### Budget Constraint _table_ Remaining budget tempers the award through an adjustmentFactor keyed on evaluation.fundingPriority and budgetConstraints.allocationRatio. 'high' priority projects take 0.95 while the allocationRatio is < 0.75 and 0.85 once it passes that mark, 'medium' projects get a full 1.0 below 0.6 spent but 0.9 above it, and 'low' priority rows keep 1.0 unconditionally since their base ratio is already small. The 'rejected' row carries the 0 forward so refused applications cannot regain funding here. Tightening awards as the program's budget fills is ordinary fiscal stewardship for a fixed appropriation: administrators shave grants late in the cycle rather than exhausting funds and rejecting every later applicant outright. The specific 0.75 and 0.6 trigger points are calibration choices, not statutory values, but the pattern of protecting headroom for future high-priority applications is true to practice. Funding Priorityevaluation.fundingPriority Budget Allocation RatiobudgetConstraints.allocationRatio Adjustment Factorevaluation.adjustmentFactor 'high' < 0.75 0.95 'high' \>= 0.75 0.85 'medium' < 0.6 1.0 'medium' \>= 0.6 0.9 'low' \- 1.0 'rejected' \- 0 _04_ ### Funding Calculation _expression_ The award comes together in four expressions. maxPossibleAmount multiplies application.requestedAmount by both evaluation.baseFundingRatio and adjustmentFactor, then grantAmount clamps it with min(\[...\]) against the requested amount and budgetConstraints.maxAwardAmount, short-circuiting to 0 for 'rejected' priority. fundingStatus compares the result to application.minimumViableAmount, labeling awards 'Approved' when the grant can actually sustain the project and 'Partially Funded' when it falls short, and fundingPercentage rounds the award as a share of the request for the administrator's decision summary. _maxPossibleAmount_`application.requestedAmount * evaluation.baseFundingRatio * evaluation.adjustmentFactor` _grantAmount_`evaluation.fundingPriority == 'rejected' ? 0 : min([$.maxPossibleAmount, application.requestedAmount, budgetConstraints.maxAwardAmount])` _fundingStatus_`evaluation.fundingPriority == 'rejected' ? 'Rejected' : $.grantAmount >= application.minimumViableAmount ? 'Approved' : 'Partially Funded'` _fundingPercentage_`application.requestedAmount > 0 ? round($.grantAmount / application.requestedAmount * 100) : 0` ## Other Public Sector templates [View all templates](/templates) [_Public Sector_ ### Government Assistance Streamlined decision system that determines program eligibility based on income thresholds, household size, age factors, and special circumstances. ](/industries/public-sector/templates/government-assistance)[_Public Sector_ ### Tax Exemption Automated system that assesses organizations for 501(c)(3) tax-exempt status based on structure, activities, and financial metrics. ](/industries/public-sector/templates/tax-exemption)[_Public Sector_ ### Municipal Permit Evaluation System Automated system that evaluates building and event permits based on zoning regulations, safety requirements, and environmental impact factors. ](/industries/public-sector/templates/municipal-permit-evaluation-system) ## Make this template your own. Load Grant Funding Distribution into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Government Assistance - GoRules **URL:** https://gorules.io/industries/public-sector/templates/government-assistance **Description:** Streamlined decision system that determines program eligibility based on income thresholds, household size, age factors, and special circumstances. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Government Assistance Streamlined decision system that determines program eligibility based on income thresholds, household size, age factors, and special circumstances. Download template Share ### Solution This eligibility determination system evaluates applicants for government assistance programs using multiple qualification factors. It first analyzes household financial status by comparing annual income against tiered thresholds that vary based on household size, ensuring appropriate support levels for different family configurations. The system then factors in age requirements, differentiating between adult assistance programs and specialized youth support options for eligible teenagers. When standard eligibility criteria aren't met, the system automatically evaluates special circumstances including disability status, veteran status, and caregiver responsibilities to identify alternative program options. For qualifying applicants, the system determines the appropriate assistance level (full or partial) and enhances benefits packages when special circumstances apply. This creates a personalized program recommendation that maximizes support while ensuring compliance with government assistance guidelines. ### How it works The decision graph evaluates eligibility through a two-stage process: 1. **Income Eligibility Assessment**: Analyzes annual income against household-size-adjusted thresholds with three distinct tiers: - Small households (1-2 members): Full assistance up to $15,000, partial from $15,001-$25,000 - Medium households (3-4 members): Full assistance up to $30,000, partial from $30,001-$50,000 - Large households (5+ members): Full assistance up to $45,000, partial from $45,001-$65,000 2. **Special Circumstances Evaluation**: Identifies qualifying conditions: - For applicants who don't qualify based on income, checks for disability, veteran status, or caregiver roles to grant specialty program access - For income-eligible applicants with special circumstances, enhances their program benefits with additional support services - Assigns specific program types based on combined eligibility factors, creating personalized assistance packages The system returns a final determination with assigned program type and eligibility status. ### Where teams use it - Social services intake processing - Government welfare program enrollment - Community assistance centers - Public health benefits screening - Housing assistance qualification - Food security program enrollment - Workforce development services - Disability support services ## Inside the decision model Government Assistance ships as a JDM decision graph with 3 nodes, 2 decision tables and 16 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ Income Eligibility_table_ Special Circumstances _01_ ### Request _input_ Everything the graph needs arrives under a single applicant object: annualIncome, householdSize, and age drive the income tiers, while the nested specialCircumstances flags (hasDisability, isVeteran, isCaregiver) feed the second-stage evaluation. **Sample request**_JSON_ { "applicant": { "annualIncome": 28000, "householdSize": 3, "age": 35, "specialCircumstances": { "hasDisability": true, "isVeteran": false, "isCaregiver": false } } } _02_ ### Income Eligibility _table_ Base eligibility is decided by matching applicant.annualIncome, applicant.householdSize, and applicant.age against tiered rows under a first hit policy, so the most generous matching row wins. Full-assistance rows run first (income <= 15000 for households of <= 2, <= 30000 for > 2 and <= 4, <= 45000 for > 4), then partial-assistance rows cover the next band up to 25000, 50000, and 65000 respectively. A separate row grants youth-assistance when age is < 18 and >= 16 with income <= 25000, and the empty catch-all row at the bottom marks everyone else baseEligibility false with programType 'ineligible'. Scaling income limits with household size is standard means-testing practice, since poverty guidelines and benefit thresholds rise with each additional household member. Splitting each tier into a full band and a partial band is how programs avoid a benefit cliff, tapering support instead of cutting it off at a single line, and the dedicated youth row is a sensible policy choice for reaching 16-17 year olds who apply outside a parental household. Annual Incomeapplicant.annualIncome Household Sizeapplicant.householdSize Ageapplicant.age Base Eligibilityeligibility.baseEligible Program Typeeligibility.programType <= 15000 <= 2 \>= 18 true 'full-assistance' <= 30000 \> 2 and <= 4 \>= 18 true 'full-assistance' <= 45000 \> 4 \>= 18 true 'full-assistance' \> 15000 and <= 25000 <= 2 \>= 18 true 'partial-assistance' \> 30000 and <= 50000 \> 2 and <= 4 \>= 18 true 'partial-assistance' \> 45000 and <= 65000 \> 4 \>= 18 true 'partial-assistance' +2 more rows in the downloadable template _03_ ### Special Circumstances _table_ After the income stage, this table takes eligibility.baseEligible together with the three specialCircumstances flags and produces the final determination, again with a first hit policy. Applicants who failed the income test but have hasDisability, isVeteran, or isCaregiver set to true are still admitted into 'disability-support', 'veterans-assistance', or 'caregiver-support'. Income-eligible applicants with a disability or veteran flag get their program upgraded via the expression eligibility.programType + '-enhanced', caregivers get programType + '-caregiver', and the two fallback rows keep the plain programType or return 'ineligible' when nothing applies. This mirrors categorical eligibility in public benefits, where certain statuses open a route into assistance independent of income testing, disability and veteran status being the classic examples. Enhancing rather than replacing the program for income-eligible applicants with special circumstances is a reasonable design choice: the base entitlement stays intact and the extra support services are layered on top. Base Eligibilityeligibility.baseEligible Has Disabilityapplicant.specialCircumstances.hasDisability Is Veteranapplicant.specialCircumstances.isVeteran Is Caregiverapplicant.specialCircumstances.isCaregiver Final Eligibilityeligibility.eligible Program Assignmenteligibility.assignedProgram false true \- \- true 'disability-support' false \- true \- true 'veterans-assistance' false \- \- true true 'caregiver-support' true true \- \- true eligibility.programType + '-enhanced' true \- true \- true eligibility.programType + '-enhanced' true \- \- true true eligibility.programType + '-caregiver' +2 more rows in the downloadable template ## Other Public Sector templates [View all templates](/templates) [_Public Sector_ ### Tax Exemption Automated system that assesses organizations for 501(c)(3) tax-exempt status based on structure, activities, and financial metrics. ](/industries/public-sector/templates/tax-exemption)[_Public Sector_ ### Municipal Permit Evaluation System Automated system that evaluates building and event permits based on zoning regulations, safety requirements, and environmental impact factors. ](/industries/public-sector/templates/municipal-permit-evaluation-system)[_Public Sector_ ### Immigration Eligibility Evaluator Rules-based system automating visa application processing by evaluating documentation completeness, background checks and qualification scoring. ](/industries/public-sector/templates/immigration-eligibility-evaluator) ## Make this template your own. Load Government Assistance into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Environmental Compliance Assessment - GoRules **URL:** https://gorules.io/industries/public-sector/templates/environment-compliance-assessment **Description:** Rules-based system that evaluates organizational compliance with environmental regulations based on industry type, emissions data, and geographical location. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Environmental Compliance Assessment Rules-based system that evaluates organizational compliance with environmental regulations based on industry type, emissions data, and geographical location. Download template Share ### Solution This automated compliance system helps organizations assess their environmental regulatory standing by analyzing multiple critical factors. It evaluates industry-specific risk levels, setting appropriate emission thresholds based on business type and location. The system calculates carbon intensity by analyzing carbon dioxide emissions against production volumes, determining if thresholds are exceeded and by what percentage. For comprehensive assessment, the system evaluates waste management practices, including hazardous and non-hazardous waste volumes, recycling percentages, and any reported violations. Water consumption and treatment metrics are similarly analyzed. When compliance issues are detected, the system provides specific status classifications (compliant, at-risk, or non-compliant), required action timeframes, and detailed recommendations tailored to the organization's risk profile and violation severity. ### How it works The decision graph processes data through a logical sequence of evaluations: 1. **Industry Risk Assessment**: Categorizes the organization's industry as high, medium, or low risk, establishing appropriate emission thresholds based on industry type and location. 2. **Emissions Calculation**: Determines carbon intensity by analyzing emissions relative to production volume. 3. **Threshold Evaluation**: Compares actual carbon intensity against the industry-specific threshold, calculating percentage over threshold when exceeded. 4. **Violation Assessment**: Identifies any waste management or water usage violations. 5. **Compliance Determination**: Evaluates industry risk level, threshold exceedance, and violation percentage to determine compliance status. 6. **Action Planning**: Generates specific timeframes for required actions based on risk level and violation severity. 7. **Recommendation Generation**: Provides tailored recommendations addressing specific compliance issues. ### Where teams use it - Manufacturing facilities seeking regulatory compliance - Energy and chemical companies managing environmental impact - Transportation and logistics operations monitoring emissions - Environmental auditing and consulting firms - Municipal and state environmental agencies - Corporate sustainability departments - Risk management and legal compliance teams ## Inside the decision model Environmental Compliance Assessment ships as a JDM decision graph with 4 nodes, 2 decision tables and 16 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ industryRiskAssessment_expression_ emissionsEvaluation_table_ complianceStatus _01_ ### Request _input_ The request combines the organization's industry and location with measured data blocks: emissions, production, waste, and water, plus an audits history object. The rules primarily consume industry, location.region, emissions.carbonDioxideMetricTons, production.volume, and the two violations counters. **Sample request**_JSON_ { "industry": "manufacturing", "location": { "country": "United States", "region": "midwest", "city": "Detroit" }, "emissions": { "carbonDioxideMetricTons": 18500, "methaneMetricTons": 120, "nitrousOxideMetricTons": 45 }, "production": { "volume": 100, "units": "million\_units" }, "waste": { "hazardousWasteMetricTons": 50, "nonHazardousWasteMetricTons": 350, "recycledPercentage": 22, "violations": 1 }, "water": { "consumptionKiloliters": 250000, "treatedPercentage": 85, "violations": 0 }, "audits": { "lastAuditDate": "2025-01-15", "previousFindings": 3, "resolvedFindings": 2 } } _02_ ### Industry Risk Assessment _table_ Sector and geography set the yardstick for everything that follows. Using a first hit policy, the table matches industry against grouped lists: 'energy', 'oil', 'gas', 'mining', 'chemical' are 'high' risk with a strict emissionThreshold of 100, manufacturing-type sectors are 'medium' at 150, and 'technology', 'services', 'retail', 'healthcare' are 'low' at 250. The one regional split gives 'transportation', 'logistics' a tighter 120 threshold when location.region is 'california', 'eu', 'uk', versus 200 elsewhere, and the empty default row assigns 'undefined' risk with a 200 threshold so unknown industries still get assessed. Scaling emission allowances inversely with sector risk mirrors how environmental regulators concentrate attention on extractive and chemical industries, which dominate emissions inventories. The California/EU/UK carve-out is grounded in reality too: those jurisdictions run notably stricter emissions regimes for transport operators than most others, so a lower threshold there is a faithful modeling choice. Industryindustry Regionlocation.region Industry Risk Levelassessment.industryRiskLevel Emission Thresholdassessment.emissionThreshold 'energy', 'oil', 'gas', 'mining', 'chemical' \- 'high' 100 'manufacturing', 'automotive', 'construction' \- 'medium' 150 'transportation', 'logistics' 'california', 'eu', 'uk' 'medium' 120 'transportation', 'logistics' \- 'medium-low' 200 'agriculture', 'food processing' \- 'medium-low' 180 'technology', 'services', 'retail', 'healthcare' \- 'low' 250 +1 more row in the downloadable template _03_ ### Emissions Evaluation _expression_ Raw tonnage becomes a comparable metric here: carbonIntensity divides emissions.carbonDioxideMetricTons by production.volume ?? 1, guarding against a missing denominator, and exceededThreshold compares it to assessment.emissionThreshold ?? 200 from the risk table. percentOverThreshold quantifies the overshoot as a percentage only when exceeded, which is exactly the severity signal the compliance table splits on, and hasWasteViolations and hasWaterViolations reduce the waste.violations and water.violations counters to booleans for the response. _carbonIntensity_`emissions.carbonDioxideMetricTons / (production.volume ?? 1)` _exceededThreshold_`$.carbonIntensity > (assessment.emissionThreshold ?? 200)` _percentOverThreshold_`$.exceededThreshold ? (($.carbonIntensity - assessment.emissionThreshold) / assessment.emissionThreshold * 100) : 0` _hasWasteViolations_`waste.violations > 0` _hasWaterViolations_`water.violations > 0` _04_ ### Compliance Status _table_ Risk level and overshoot severity cross into a status matrix under a first hit policy. For 'high' risk industries, exceeding the threshold by > 10 percent means 'non-compliant' with an 'immediate' action timeframe, under 10 percent means 'at-risk' with '30-days', and even compliant operators get 'compliant-with-monitoring' with 'quarterly' reporting. The 'medium', 'medium-low' rows use a looser 20 percent severity split with '60-days' and '90-days' timeframes, 'low' risk industries that exceed at all are merely 'at-risk' with '120-days', and the default row returns 'undefined' with a 90-day assessment recommendation rather than failing silently. Two real regulatory patterns show up in this shape. Deadlines that shorten as risk rises, from immediate remediation down to annual review, reflect risk-based enforcement, where inspection and reporting frequency track a facility's hazard profile. And keeping high-risk industries on quarterly monitoring even while compliant matches how permits for major emitters carry ongoing reporting duties that lower-risk businesses never see; the 10 and 20 percent severity cut points themselves are sensible calibration rather than fixed rules from any statute. Industry Risk Levelassessment.industryRiskLevel Exceeded ThresholdexceededThreshold Percent Over ThresholdpercentOverThreshold Compliance Statuscompliance.status Required Action Timeframecompliance.actionTimeframe Recommendationcompliance.recommendation 'high' true \> 10 'non-compliant' 'immediate' 'High-risk industry with significant threshold exceedance requires immediate remediation plan and potential reporting to authorities.' 'high' true < 10 'at-risk' '30-days' 'High-risk industry with minor threshold exceedance requires action plan within 30 days.' 'high' false \- 'compliant-with-monitoring' 'quarterly' 'High-risk industry requires quarterly monitoring and reporting despite current compliance.' 'medium', 'medium-low' true \> 20 'non-compliant' '60-days' 'Medium-risk industry with significant threshold exceedance requires remediation plan within 60 days.' 'medium', 'medium-low' true < 20 'at-risk' '90-days' 'Medium-risk industry with minor threshold exceedance requires review within 90 days.' 'medium', 'medium-low' false \- 'compliant' 'bi-annual' 'Medium-risk industry is currently compliant with bi-annual review recommendation.' +3 more rows in the downloadable template ## Other Public Sector templates [View all templates](/templates) [_Public Sector_ ### Government Assistance Streamlined decision system that determines program eligibility based on income thresholds, household size, age factors, and special circumstances. ](/industries/public-sector/templates/government-assistance)[_Public Sector_ ### Tax Exemption Automated system that assesses organizations for 501(c)(3) tax-exempt status based on structure, activities, and financial metrics. ](/industries/public-sector/templates/tax-exemption)[_Public Sector_ ### Municipal Permit Evaluation System Automated system that evaluates building and event permits based on zoning regulations, safety requirements, and environmental impact factors. ](/industries/public-sector/templates/municipal-permit-evaluation-system) ## Make this template your own. Load Environmental Compliance Assessment into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Disaster Relief Fund Allocation - GoRules **URL:** https://gorules.io/industries/public-sector/templates/disaster-relief-fund-allocation **Description:** Automated system that calculates disaster relief payments based on damage severity, household factors, income level, and insurance coverage status. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Disaster Relief Fund Allocation Automated system that calculates disaster relief payments based on damage severity, household factors, income level, and insurance coverage status. Download template Share ### Solution This disaster relief system determines appropriate financial assistance for affected individuals following natural disasters or emergencies. It starts with a damage assessment that categorizes property damage from minor to severe, establishing a baseline payment amount. The system then adjusts this base amount according to household characteristics, including family size and number of dependents. Income level modifiers ensure fair distribution of resources, providing greater support to low-income households while appropriately scaling assistance for those with more financial resources. The final payment calculation applies insurance status adjustments, recognizing that those with partial or full coverage require different levels of government assistance. Each determination includes clear reasoning for the payment amount, enabling transparent communication with recipients and ensuring equitable distribution of relief funds. ### How it works The decision graph processes applications through four sequential evaluation stages: 1. **Base Fund Allocation**: Assigns initial payment amounts (ranging from $1,000 to $10,000) based on damage severity levels (minor, moderate, major, or severe). 2. **Income Adjustment**: Modifies the base amount according to household income level, increasing payments for low-income families by 20% and reducing them by 20% for high-income households. 3. **Household Size Calculation**: Applies a multiplier based on family size, increasing support proportionally for larger households up to a maximum of 75% additional funding. 4. **Insurance Status Evaluation**: Makes final adjustments based on insurance coverage, providing full calculated amounts to uninsured applicants, 70% to partially insured individuals, and 30% to fully insured households. ### Where teams use it - Federal emergency management agencies - State disaster response programs - Local government relief operations - Humanitarian aid organizations - Disaster recovery centers - Flood and hurricane relief programs ## Inside the decision model Disaster Relief Fund Allocation ships as a JDM decision graph with 5 nodes, 3 decision tables and 13 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ baseFundAllocation_table_ incomeAdjustment_expression_ householdSizeAdjustment_table_ insuranceAdjustment _01_ ### Request _input_ Four request objects mirror the stages of the graph: assessment supplies the damageLevel that sets the base amount, income and household drive the two adjustment steps, and insurance determines the final reduction. Descriptive fields like damageDescription and provider are context only. **Sample request**_JSON_ { "assessment": { "damageLevel": "major", "propertyType": "residential", "damageDescription": "Roof collapsed in multiple areas, extensive water damage" }, "household": { "size": 4, "dependents": 2, "specialNeeds": false }, "income": { "level": "low", "annualAmount": 32000, "primarySource": "employment" }, "insurance": { "status": "partial", "deductible": 5000, "provider": "StateInsurance" } } _02_ ### Base Fund Allocation _table_ Payment starts from damage severity alone: assessment.damageLevel maps to a relief.baseAmount of 10000 for 'severe', 7500 for 'major', 5000 for 'moderate', and 2500 for 'minor', with the empty fallback row granting 1000 when the level is missing or unrecognized. First hit is effectively exact-match here since the categories are mutually exclusive. Anchoring relief to an inspected damage category rather than to claimed losses is how disaster assistance programs keep payouts fast and auditable, and the amounts sit in the realistic range of individual disaster grants, which are capped supplements rather than full compensation. A nonzero fallback reflects the humanitarian default that a verified applicant should not receive nothing because of a data gap. Damage Levelassessment.damageLevel Base Amountrelief.baseAmount 'severe' 10000 'major' 7500 'moderate' 5000 'minor' 2500 \- 1000 _03_ ### Income Adjustment _table_ Ability to recover matters next: income.level scales the base through output expressions, 'low' earns relief.baseAmount \* 1.2, 'medium' passes it unchanged, 'high' takes \* 0.8, and the blank fallback row also keeps the base amount. Writing the result to relief.incomeAdjustedAmount keeps the original baseAmount intact for audit. A plus-or-minus 20 percent band is a mild form of means-testing: low-income households have the least private capacity to absorb disaster losses, so tilting funds toward them is standard equity practice in relief programs, while treating an unknown income level as neutral avoids penalizing applicants for missing data. Income Levelincome.level Income Adjusted Amountrelief.incomeAdjustedAmount 'low' relief.baseAmount \* 1.2 'medium' relief.baseAmount 'high' relief.baseAmount \* 0.8 \- relief.baseAmount _04_ ### Household Size Adjustment _expression_ Family size enters through the formula min(\[household.size \* 0.15 + 1, 1.75\]), so each member adds 15 percent up to a hard ceiling of 1.75, reached at five members. initialAllocation multiplies relief.incomeAdjustedAmount by that householdMultiplier and becomes the figure the insurance table reduces. The cap keeps very large households from scaling a fixed relief pool without bound, the same reason benefit scales in public programs flatten after a certain household size. _householdMultiplier_`min([household.size * 0.15 + 1, 1.75])` _initialAllocation_`relief.incomeAdjustedAmount * $.householdMultiplier` _05_ ### Insurance Adjustment _table_ Coverage status makes the last cut, with insurance.status selecting the payout formula. Uninsured applicants ('none') receive the full initialAllocation, 'partial' coverage pays max(\[initialAllocation \* 0.7, 1000\]), 'full' coverage drops to max(\[initialAllocation \* 0.3, 500\]), and an unknown status takes a standard 0.5 reduction. Each row also writes a plain-language relief.paymentReason such as 'Fully insured - minimal supplemental payment' so the recipient sees why the amount changed. Reducing government relief for insured households reflects the real duplication-of-benefits principle in disaster assistance: public funds supplement, and must not double-pay, losses an insurer covers. Keeping a nonzero floor via the max() guards acknowledges deductibles and uncovered losses that even fully insured households bear, and the explanation string is the kind of transparency an appeals process depends on. Insurance Statusinsurance.status Final Paymentrelief.paymentAmount Reasonrelief.paymentReason 'none' initialAllocation 'Not insured - full payment' 'partial' max(\[initialAllocation \* 0.7, 1000\]) 'Partially insured - reduced payment' 'full' max(\[initialAllocation \* 0.3, 500\]) 'Fully insured - minimal supplemental payment' \- initialAllocation \* 0.5 'Unknown insurance status - standard reduction' ## Other Public Sector templates [View all templates](/templates) [_Public Sector_ ### Government Assistance Streamlined decision system that determines program eligibility based on income thresholds, household size, age factors, and special circumstances. ](/industries/public-sector/templates/government-assistance)[_Public Sector_ ### Tax Exemption Automated system that assesses organizations for 501(c)(3) tax-exempt status based on structure, activities, and financial metrics. ](/industries/public-sector/templates/tax-exemption)[_Public Sector_ ### Municipal Permit Evaluation System Automated system that evaluates building and event permits based on zoning regulations, safety requirements, and environmental impact factors. ](/industries/public-sector/templates/municipal-permit-evaluation-system) ## Make this template your own. Load Disaster Relief Fund Allocation into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Warehouse Storage Location - GoRules **URL:** https://gorules.io/industries/logistics/templates/warehouse-storage-location **Description:** Maximizes warehouse efficiency by strategically placing products based on turnover rates, picking frequency, and product characteristics. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Warehouse Storage Location Maximizes warehouse efficiency by strategically placing products based on turnover rates, picking frequency, and product characteristics. Download template Share ### Solution This warehouse optimization system assigns ideal storage locations for products based on multiple key factors to improve operational efficiency. The system first classifies products using monthly sales volume, turnover rates, and daily picking frequency to identify high-priority items that require strategic placement. Products are then assigned specific storage locations - from floor-level spaces to pallet racks or bin shelving - based on their classification and handling requirements. Fast-moving products with high volume are positioned in prime picking areas for quick access, while slower-moving items are stored in standard or overflow zones. The system factors in product fragility when determining vertical placement, keeping delicate items at lower heights for safer handling. Each assignment includes a priority score that helps warehouse managers plan optimal layouts, alongside specific replenishment schedules tailored to each product's turnover rate - creating a balanced approach that reduces picking times while maximizing space utilization. ### How it works The decision graph processes product data through three sequential steps: 1. **Product Classification**: Analyzes monthly units, turnover rate, and picks per day to categorize products into high-volume, medium-volume, low-volume-fast, or low-volume-standard groups, adding a fast-moving indicator for quick-rotating inventory. 2. **Location Assignment**: Determines the optimal storage type (floor-level, pallet rack positions, or bin shelving) and warehouse zone (prime picking, standard, or overflow) based on volume category, movement speed, and fragility score. 3. **Allocation Finalization**: Generates the exact storage location code, calculates a picking efficiency score, recommends optimal quantity to store, and establishes a replenishment frequency (daily, weekly, or monthly) based on turnover rate. ### Where teams use it - E-commerce fulfillment centers - Retail distribution centers - Manufacturing parts warehouses - Grocery and food distribution - Electronics and technology warehousing - Third-party logistics providers - Pharmaceutical and medical supply storage - Automotive parts distribution centers ## Inside the decision model Warehouse Storage Location ships as a JDM decision graph with 4 nodes, 2 decision tables and 13 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ classifyProduct_table_ assignLocation_expression_ finalizeAllocation _01_ ### Request _input_ One product record drives the whole slotting decision: the nested product object supplies monthlyUnits, turnoverRate, picksPerDay, and fragilityScore, along with dimensions, weight, and handling flags. Classification and placement both read from this single structure. **Sample request**_JSON_ { "product": { "id": "PRD-12345", "name": "Gaming Laptop XZ5000", "dimensions": { "length": 40, "width": 30, "height": 10, "unit": "cm" }, "weight": { "value": 3.5, "unit": "kg" }, "monthlyUnits": 2500, "turnoverRate": 0.65, "picksPerDay": 12, "fragilityScore": 4, "specialHandling": false, "hazardous": false } } _02_ ### Classify Product _table_ Classification runs top-down with a first hit policy across product.monthlyUnits, product.turnoverRate, and product.picksPerDay. Products moving more than 5000 units a month with turnover above 0.8 and over 15 picks a day become 'high-volume' with fastMoving true; the two 'medium-volume' rows split on whether turnover and picks sit above or below 0.5 and 10; a low-volume item can still earn 'low-volume-fast' when turnover exceeds 0.7 and picks exceed 8, and the blank catch-all lands everything else in 'low-volume-standard'. Requiring all three signals to agree before granting the top class is the point: monthly units alone can be inflated by one bulk order, so pairing volume with turnover and daily pick frequency filters for items that genuinely earn prime real estate. The 'low-volume-fast' row captures the classic small-but-frequent SKU, like spare parts, that velocity-based slotting would otherwise bury in overflow. Monthly Unitsproduct.monthlyUnits Turnover Rateproduct.turnoverRate Picks Per Dayproduct.picksPerDay Volume Categoryclassification.volumeCategory Fast Movingclassification.fastMoving \> 5000 \> 0.8 \> 15 'high-volume' true \> 1000 \> 0.5 \> 10 'medium-volume' true \> 1000 < 0.5 < 10 'medium-volume' false < 1000 \> 0.7 \> 8 'low-volume-fast' true \- \- \- 'low-volume-standard' false _03_ ### Assign Location _table_ Placement maps classification.volumeCategory, classification.fastMoving, and product.fragilityScore to a storage type, zone, and priority, first hit wins. Fragile high-volume items (fragility above 3) go to 'floor-level' in the 'prime-picking-area' at priority 1, sturdier ones to 'pallet-rack-bottom'; medium-volume stock spreads across 'pallet-rack-bottom', 'pallet-rack-middle', and 'pallet-rack-upper' depending on speed and fragility; 'low-volume-fast' items get 'bin-shelving-middle', the slowest sturdy items fall to 'bin-shelving-upper' in the 'overflow-area' at priority 7, and the catch-all assigns 'bin-shelving-standard'. The height logic follows standard warehouse ergonomics: fast movers belong in the golden zone at floor and bottom-rack level where pickers spend no time on ladders or lifts, and delicate items stay low so a drop costs centimeters, not meters. Pushing slow, sturdy stock to upper positions and overflow keeps the expensive ground-level slots turning, which is the whole economics of slotting. Volume Categoryclassification.volumeCategory Fast Movingclassification.fastMoving Fragilityproduct.fragilityScore Storage Typeallocation.storageType Warehouse Zoneallocation.warehouseZone Priorityallocation.priority 'high-volume' true \> 3 'floor-level' 'prime-picking-area' 1 'high-volume' true < 3 'pallet-rack-bottom' 'prime-picking-area' 2 'medium-volume' true \> 2 'pallet-rack-bottom' 'prime-picking-area' 3 'medium-volume' false \> 2 'pallet-rack-middle' 'standard-picking-area' 4 'medium-volume' false < 2 'pallet-rack-upper' 'standard-picking-area' 5 'low-volume-fast' true \- 'bin-shelving-middle' 'standard-picking-area' 6 +2 more rows in the downloadable template _04_ ### Finalize Allocation _expression_ Final outputs get assembled here: allocatedLocation concatenates allocation.warehouseZone and allocation.storageType into a single code, and pickingEfficiencyScore subtracts allocation.priority from 10 for fast movers or 5 for the rest, so a lower priority number yields a higher score. recommendedQuantity stocks half of product.monthlyUnits at the location, and replenishmentFrequency turns product.turnoverRate into a schedule, 'daily' above 0.7, 'weekly' above 0.4, otherwise 'monthly', giving the replenishment team a cadence matched to how fast the slot empties. _allocatedLocation_`allocation.warehouseZone + '-' + allocation.storageType` _pickingEfficiencyScore_`classification.fastMoving ? 10 - allocation.priority : 5 - allocation.priority` _recommendedQuantity_`product.monthlyUnits / 2` _replenishmentFrequency_`product.turnoverRate > 0.7 ? 'daily' : product.turnoverRate > 0.4 ? 'weekly' : 'monthly'` ## Other Logistics templates [View all templates](/templates) [_Logistics_ ### Shipping Carrier Selector Rule-based system that selects optimal carriers by analyzing package details, service level needs, and cost factors to streamline shipping decisions. ](/industries/logistics/templates/shipping-carrier-selector)[_Logistics_ ### Delivery Route Optimizer Smart logistics system that evaluates capacity, traffic, time windows, and distance to determine the most efficient delivery routes for maximum efficiency. ](/industries/logistics/templates/delivery-route-optimizer)[_Logistics_ ### Order Consolidation System Smart logistics system that optimizes shipping by combining orders based on location proximity, delivery timeframes, and available carrier capacity. ](/industries/logistics/templates/order-consolidation-system) ## Make this template your own. Load Warehouse Storage Location into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Warehouse Cross-Docking - GoRules **URL:** https://gorules.io/industries/logistics/templates/warehouse-cross-docking **Description:** Automated system that determines optimal handling of incoming shipments based on outbound orders, time constraints, and current warehouse capacity. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Warehouse Cross-Docking Automated system that determines optimal handling of incoming shipments based on outbound orders, time constraints, and current warehouse capacity. Download template Share ### Solution This logistics optimization system intelligently routes incoming shipments to either cross-docking or storage based on real-time warehouse conditions. It evaluates whether matching outbound orders exist and their scheduled departure times, calculating precise time windows between inbound and outbound movements. The engine assesses current warehouse capacity utilization to determine if storage space is constrained. When matching orders are identified within a short timeframe (24-48 hours) and warehouse capacity allows, the system routes shipments directly to cross-docking zones, bypassing storage entirely. For shipments with matching orders but extended time gaps, or when warehouse space is abundant, the system directs items to appropriate storage locations. Each decision includes detailed reasoning, enabling warehouse staff to quickly understand routing choices while maximizing operational efficiency. ### How it works The decision engine follows a structured evaluation process: 1. **Input Processing**: Captures inbound shipment details, associated outbound orders, timing information, and current warehouse metrics. 2. **Metrics Calculation**: Determines if matching outbound orders exist, calculates the time difference between inbound and outbound movements, and assesses current warehouse capacity percentage. 3. **Decision Rules**: Applies business rules based on order matching, time windows, and capacity utilization thresholds. 4. **Cross-Dock Evaluation**: For qualifying shipments, assigns appropriate docking bays and processing priorities. 5. **Response Generation**: Produces a final decision with supporting rationale and handling instructions. ### Where teams use it - Distribution centers handling high-volume shipments - Retail logistics operations with rapid inventory turnover - E-commerce fulfillment centers managing same-day shipping - Food and perishable goods distribution - Manufacturing facilities with just-in-time components - Third-party logistics (3PL) providers optimizing warehouse space ## Inside the decision model Warehouse Cross-Docking ships as a JDM decision graph with 6 nodes, 1 decision table and 5 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ shipmentRequest_expression_ calculateMetrics_table_ crossDockingDecision_switch_ handleCrossDocking_expression_ assignCrossDockingDetails _01_ ### Shipment Request _input_ An inbound shipment arrives described by inboundShipmentTime and outboundShipmentTime, a matchingOutboundOrders list, the inboundShipmentItems, and warehouse state via currentStorageUsed against totalStorageCapacity, plus a pre-reserved crossDockingBayAssignment. The metrics step condenses these into the three signals the routing table needs. **Sample request**_JSON_ { "inboundShipmentId": "IN-12345", "inboundShipmentTime": "2025-03-19T10:00:00Z", "outboundShipmentTime": "2025-03-20T09:00:00Z", "matchingOutboundOrders": \[ { "orderId": "ORD-789", "customerPriority": "standard", "destinationZone": "East" }, { "orderId": "ORD-790", "customerPriority": "premium", "destinationZone": "East" } \], "inboundShipmentItems": \[ { "sku": "ITEM-001", "quantity": 50, "category": "Electronics" }, { "sku": "ITEM-002", "quantity": 30, "category": "Home Goods" } \], "currentStorageUsed": 7500, "totalStorageCapacity": 10000, "crossDockingBayAssignment": "Bay-E4" } _02_ ### Calculate Metrics _expression_ Three derived signals feed the decision table: hasMatchingOutboundOrders checks len(matchingOutboundOrders) > 0, timeDifferenceHours converts the gap between outbound and inbound timestamps to hours by dividing the epoch difference by 3600, and warehouseCapacityPercentage normalizes currentStorageUsed / totalStorageCapacity to a percentage. Reducing raw shipment data to these three numbers is what lets the routing rules stay short and auditable. _hasMatchingOutboundOrders_`len(matchingOutboundOrders) > 0` _timeDifferenceHours_`(date(outboundShipmentTime) - date(inboundShipmentTime)) / 3600` _warehouseCapacityPercentage_`(currentStorageUsed / totalStorageCapacity) * 100` _03_ ### Cross Docking Decision _table_ Routing resolves through five first-hit rows over hasMatchingOutboundOrders, timeDifferenceHours, and warehouseCapacityPercentage. Matching orders departing within \[0..24\] hours with capacity at or below 36 percent cross-dock immediately; within \[0..48\] hours the capacity allowance loosens to 80 percent; above 48 hours the shipment still crosses the dock only if the warehouse is at 90 percent or more, with the reason 'High warehouse capacity, cross-dock to save space'. Gaps over 72 hours go to 'store' despite matching orders, and shipments with no matching outbound orders always store. The 24-to-48-hour window is the classic cross-docking envelope: goods can only bypass storage if an outbound trailer leaves before dock staging space itself becomes a bottleneck. The third row inverts the logic under pressure, accepting a longer dock dwell when storage is nearly full, which is a realistic trade-off, though the exact 36, 80, and 90 percent triggers are operational tuning rather than fixed industry numbers. Has Matching OrdershasMatchingOutboundOrders Time Difference (hours)timeDifferenceHours Warehouse Capacity (%)warehouseCapacityPercentage DecisioncrossDockDecision ReasondecisionReason true \[0..24\] <= 36 'cross-dock' 'Matching orders available within 24 hours with sufficient capacity' true \[0..48\] <= 80 'cross-dock' 'Matching orders available within 48 hours' true \> 48 \>= 90 'cross-dock' 'High warehouse capacity, cross-dock to save space' true \> 72 \- 'store' 'Matching orders but time difference too large' false \- \- 'store' 'No matching outbound orders' _04_ ### Handle Cross Docking _switch_ Only shipments where crossDockDecision == 'cross-dock' proceed to bay assignment; the default branch sends stored shipments straight to the response. This keeps dock-specific fields like bay and processing priority off the payload of shipments that never touch the cross-dock flow. _crossDockDecision == 'cross-dock'_ `Assign Cross Docking Details` _otherwise_ `Response` _05_ ### Assign Cross Docking Details _expression_ Cross-docked shipments pick up their execution details: dockingBay takes the crossDockingBayAssignment from the request, estimatedProcessingTime is a flat 30 minutes, and priority escalates to 'high' when timeDifferenceHours < 12, otherwise 'normal'. The urgency flag matters on the floor because a sub-12-hour turnaround leaves no slack for the shipment to wait behind routine work. _dockingBay_`crossDockingBayAssignment` _estimatedProcessingTime_`30` _priority_`timeDifferenceHours < 12 ? 'high' : 'normal'` _06_ ### Response _output_ The response carries the crossDockDecision and its decisionReason for every shipment, and for cross-docked ones the dockingBay, priority, and estimatedProcessingTime as well. Including the reason string alongside the verdict lets receiving staff act on the routing without reconstructing why the engine chose it. ## Other Logistics templates [View all templates](/templates) [_Logistics_ ### Shipping Carrier Selector Rule-based system that selects optimal carriers by analyzing package details, service level needs, and cost factors to streamline shipping decisions. ](/industries/logistics/templates/shipping-carrier-selector)[_Logistics_ ### Delivery Route Optimizer Smart logistics system that evaluates capacity, traffic, time windows, and distance to determine the most efficient delivery routes for maximum efficiency. ](/industries/logistics/templates/delivery-route-optimizer)[_Logistics_ ### Warehouse Storage Location Maximizes warehouse efficiency by strategically placing products based on turnover rates, picking frequency, and product characteristics. ](/industries/logistics/templates/warehouse-storage-location) ## Make this template your own. Load Warehouse Cross-Docking into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Supply Chain Risk Evaluator - GoRules **URL:** https://gorules.io/industries/logistics/templates/supply-chain-risk **Description:** Assessment system that analyzes supplier data, geopolitical factors, and market conditions to prioritize supply chain vulnerabilities. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Supply Chain Risk Evaluator Assessment system that analyzes supplier data, geopolitical factors, and market conditions to prioritize supply chain vulnerabilities. Download template Share ### Solution This advanced risk assessment tool helps procurement teams make informed decisions by evaluating multiple supply chain risk factors. The system analyzes supplier location risk levels, historical performance metrics, and availability of alternative sourcing options to establish a baseline risk profile. It then applies real-time adjustments based on current geopolitical tensions and market volatility to calculate a more accurate risk score. For critical components, the system provides specific mitigation recommendations tailored to each risk level, from standard monitoring procedures for low-risk scenarios to immediate action plans for critical situations. The evaluation includes lead time impact assessment and priority classification, enabling teams to focus resources on the most vulnerable parts of their supply chain. This systematic approach helps organizations reduce disruption risks, maintain business continuity, and make strategic sourcing decisions. ### How it works The decision graph evaluates supply chain risks through four sequential stages: 1. **Input Collection**: Gathers comprehensive supplier data including location, performance scores, alternative source availability, and product details along with market conditions and geopolitical factors. 2. **Baseline Risk Calculation**: A decision table evaluates supplier location risk level, historical performance metrics, and alternative sourcing options to determine an initial risk score, category, and recommended mitigation actions. 3. **Risk Factor Adjustment**: The system applies multipliers based on current geopolitical tensions (1.3x if present) and market volatility levels (1.0-1.2x depending on severity) to adjust the baseline risk score. 4. **Final Assessment**: The adjusted risk score determines the final risk category (low, medium, high, or critical), expected lead time impact, and organizational priority level for action. ### Where teams use it - Procurement and sourcing strategy development - Supply chain resilience planning - Vendor management and evaluation - Business continuity risk assessment - Strategic component sourcing decisions - Inventory management optimization - Supplier relationship management ## Inside the decision model Supply Chain Risk Evaluator ships as a JDM decision graph with 4 nodes, 2 decision tables and 11 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ supplierRiskEvaluation_expression_ geopoliticalRiskCalculation_table_ overallRiskAssessment _01_ ### Request _input_ An assessment request bundles a supplier object (location, performanceScore, alternateSourcesCount, products) with environment fields: geopoliticalTensions, marketVolatility, supplyCategory, and leadTimeData. The baseline table reads only the supplier attributes; the environment fields come in later as multipliers. **Sample request**_JSON_ { "supplier": { "name": "GlobalTech Supplies Inc.", "location": "medium\_risk\_region", "performanceScore": 82, "alternateSourcesCount": 2, "products": \[ { "id": "P123", "name": "Semiconductor Chip", "criticalComponent": true } \], "relationshipDurationMonths": 36 }, "geopoliticalTensions": true, "marketVolatility": "medium", "supplyCategory": "electronics", "leadTimeData": { "averageDays": 45, "historicalVariance": 8 } } _02_ ### Supplier Risk Evaluation _table_ Baseline risk combines supplier.location, supplier.performanceScore, and supplier.alternateSourcesCount across seven first-hit rows, each emitting a score, category, and mitigation string. A 'high\_risk\_region' supplier scoring under 70 with fewer than 2 alternatives is 'critical' at 80 points with 'Immediate action required: Identify alternative suppliers'; better performance in the same region still rates 'high' at 65. 'medium\_risk\_region' rows split at a performanceScore of 80 into 60-point 'high' with a dual-sourcing recommendation or 40-point 'medium' with quarterly reviews, 'low\_risk\_region' suppliers land at 35 or 15 depending on performance and having at least 3 alternates, and unmatched combinations default to 50 and a detailed assessment. The three axes are the standard vocabulary of supplier risk: where the supplier sits, how reliably they have delivered, and how easily they can be replaced. Making scarce alternatives the trigger for the worst scores reflects real resilience thinking, since a struggling supplier is only a crisis when there is no second source, and shipping a concrete mitigation string with each row turns the score into an action rather than a dashboard number. The point values themselves are calibration choices for the 40/60/75 bands downstream. Supplier Locationsupplier.location Historical Performance Scoresupplier.performanceScore Alternative Sources Countsupplier.alternateSourcesCount Risk Scoreassessment.baseRiskScore Risk Categoryassessment.baseRiskCategory Recommended Mitigationassessment.recommendedAction 'high\_risk\_region' < 70 < 2 80 'critical' 'Immediate action required: Identify alternative suppliers' 'high\_risk\_region' \>= 70 \- 65 'high' 'Develop backup suppliers and increase safety stock' 'medium\_risk\_region' < 80 < 3 60 'high' 'Implement dual-sourcing strategy' 'medium\_risk\_region' \>= 80 \- 40 'medium' 'Monitor supplier performance and conduct quarterly reviews' 'low\_risk\_region' < 75 \- 35 'medium' 'Schedule regular performance reviews' 'low\_risk\_region' \>= 75 \>= 3 15 'low' 'Standard monitoring procedures' +1 more row in the downloadable template _03_ ### Geopolitical Risk Calculation _expression_ Environmental stress scales the baseline: geopoliticalFactor is 1.3 when geopoliticalTensions is true, marketVolatilityFactor steps 1.2, 1.1, or 1.0 for 'high', 'medium', or calm markets, and adjustedRiskScore multiplies assessment.baseRiskScore by both, rounded and capped at 100 via min(\[...\], 100). Using multipliers rather than flat additions means external shocks amplify already-fragile suppliers more than solid ones, which is how disruption actually propagates. _geopoliticalFactor_`geopoliticalTensions == true ? 1.3 : 1.0` _marketVolatilityFactor_`marketVolatility == 'high' ? 1.2 : (marketVolatility == 'medium' ? 1.1 : 1.0)` _adjustedRiskScore_`min([round(assessment.baseRiskScore * $.geopoliticalFactor * $.marketVolatilityFactor), 100])` _04_ ### Overall Risk Assessment _table_ Final banding cuts adjustedRiskScore at three thresholds under a first hit policy: 75 or more is 'critical' with 'significant' lead time impact and 'immediate' priority, 60 or more is 'high', 40 or more is 'medium', and the catch-all is 'low' with 'minimal' impact and 'routine' priority. Because the multipliers can push a 60-point baseline past 75, the bands are what let geopolitical or market stress genuinely reclassify a supplier rather than just nudge a number. Translating the score into leadTimeImpact and priorityLevel gives procurement two operational handles, what to expect and how fast to act, which is what a risk register needs to drive workload. Adjusted Risk ScoreadjustedRiskScore Final Risk CategoryfinalAssessment.riskCategory Lead Time ImpactfinalAssessment.leadTimeImpact Priority LevelfinalAssessment.priorityLevel \>= 75 'critical' 'significant' 'immediate' \>= 60 'high' 'moderate' 'high' \>= 40 'medium' 'minor' 'medium' \- 'low' 'minimal' 'routine' ## Other Logistics templates [View all templates](/templates) [_Logistics_ ### Shipping Carrier Selector Rule-based system that selects optimal carriers by analyzing package details, service level needs, and cost factors to streamline shipping decisions. ](/industries/logistics/templates/shipping-carrier-selector)[_Logistics_ ### Delivery Route Optimizer Smart logistics system that evaluates capacity, traffic, time windows, and distance to determine the most efficient delivery routes for maximum efficiency. ](/industries/logistics/templates/delivery-route-optimizer)[_Logistics_ ### Warehouse Storage Location Maximizes warehouse efficiency by strategically placing products based on turnover rates, picking frequency, and product characteristics. ](/industries/logistics/templates/warehouse-storage-location) ## Make this template your own. Load Supply Chain Risk Evaluator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Shipping Carrier Selector - GoRules **URL:** https://gorules.io/industries/logistics/templates/shipping-carrier-selector **Description:** Rule-based system that selects optimal carriers by analyzing package details, service level needs, and cost factors to streamline shipping decisions. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Shipping Carrier Selector Rule-based system that selects optimal carriers by analyzing package details, service level needs, and cost factors to streamline shipping decisions. Download template Share ### Solution This shipping decision system automatically identifies the most suitable carriers based on precise package dimensions, weight, destination, and delivery timeline requirements. It performs initial validation of package specifications, rejecting oversized packages or invalid service requests upfront with specific error messages. The system applies tiered service level mapping to match customer delivery needs with appropriate carrier categories. For premium same-day delivery, it recommends specialized couriers, while offering more cost-effective options for standard shipping. It calculates both actual and volumetric weight to determine the true shipping cost based on whichever is higher, and accounts for oversized package surcharges. When multiple carriers are eligible, the system provides a ranked list with comparative pricing to help users make the optimal choice based on their priority factors. ### How it works The decision graph processes shipping requests through these sequential steps: 1. **Package Validation**: Checks that all dimensions and weight are positive values, within maximum limits (70kg weight, 200cm dimensions), and verifies delivery timeline options. 2. **Service Level Determination**: Maps delivery timeline requirements (same-day, express, standard) to appropriate service tiers. 3. **Carrier Eligibility**: Evaluates potential carriers based on service level, destination (domestic/international), and weight restrictions. 4. **Cost Calculation**: Computes volumetric weight (LxWxH/5000), determines the higher of actual vs. volumetric weight, and applies carrier-specific pricing formulas with oversized package surcharges. 5. **Carrier Ranking**: Filters and sorts eligible carriers according to the user's priority factor (typically cost). ### Where teams use it - E-commerce shipping departments - Logistics and fulfillment centers - Small business shipping operations - Third-party logistics providers - Warehouse management systems - Multi-carrier shipping platforms ## Inside the decision model Shipping Carrier Selector ships as a JDM decision graph with 7 nodes, 3 decision tables and 16 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ validatePackage_switch_ switch1_table_ determineServiceLevel_table_ determineEligibleCarriers_expression_ calculateCosts _01_ ### Request _input_ A shipping request arrives with the package's length, width, height, and weight alongside destination, deliveryTimeline, and priorityFactor. These seven fields drive everything downstream, from the validation limits to the per-carrier pricing formulas. **Sample request**_JSON_ { "length": 45, "width": 35, "height": 25, "weight": 12.5, "destination": "domestic", "deliveryTimeline": "express", "priorityFactor": "cost" } _02_ ### Validate Package _table_ Validation runs on a first hit policy, so the earliest failing guard wins and writes its message to validation.error while setting validation.isValid to false. Non-positive dimensions or weight are rejected first, then weight > 70 trips 'Package exceeds maximum weight limit of 70kg', any side over 200 trips the dimension error, and a deliveryTimeline outside 'standard', 'express', and 'same-day' returns 'Invalid delivery timeline option'. The empty catch-all row at the bottom marks the request valid. The 70kg ceiling matches the practical cutoff of parcel networks, which hand heavier pieces to freight services, and 200cm is a sensible girth-style limit for conveyor-sortable packages. Rejecting these upfront avoids a failed carrier booking later, and validating the timeline enum here means every later table can branch on it without re-checking for typos. Input Errorvalidation.error IsValidvalidation.isValid weight <= 0 or length <= 0 or width <= 0 or height <= 0 'Package dimensions and weight must be positive values' false weight > 70 'Package exceeds maximum weight limit of 70kg' false length > 200 or width > 200 or height > 200 'Package exceeds maximum dimension limit of 200cm' false deliveryTimeline != 'standard' and deliveryTimeline != 'express' and deliveryTimeline != 'same-day' 'Invalid delivery timeline option' false \- \- true _03_ ### Switch1 _switch_ Routing splits on validation.isValid: requests that passed validation continue to service level mapping and pricing, while the default branch sends everything else straight to the response. That keeps invalid packages from reaching the carrier tables, so the caller gets the validation.error message without any misleading pricing attached. _validation.isValid_ `Determine Service Level` _otherwise_ `Response` _04_ ### Determine Service Level _table_ Timeline-to-tier mapping is a straight first-hit lookup: an invalid request maps to 'none', 'same-day' maps to 'premium', 'express' stays 'express', and 'standard' stays 'standard'. The invalid guard sits on top so a failed validation short-circuits the mapping before any timeline row can match. Translating a customer-facing timeline into an internal serviceLevel is standard practice in multi-carrier shipping, because carriers are onboarded per service tier rather than per delivery promise. Keeping the mapping in its own table means new tiers or renamed timelines change one table instead of every eligibility rule. Input ServiceLevelserviceLevel validation.isValid == false 'none' deliveryTimeline == 'same-day' 'premium' deliveryTimeline == 'express' 'express' deliveryTimeline == 'standard' 'standard' _05_ ### Response _output_ The response returns the assembled decision to the caller: for a rejected package it carries validation.error and validation.isValid false, and for a valid one the eligible carriers with their carrierCosts. Because passThrough is enabled along the graph, the original request fields ride along, which makes the result auditable without re-querying the input. _06_ ### Determine Eligible Carriers _table_ Eligibility uses a collect hit policy, so every matching row contributes its carrier list and the results are gathered under eligibleCarriers. Rows key on serviceLevel, destination, and a weight cap: 'premium' domestic up to 15kg gets 'SpeedyExpress', 'express' domestic up to 30kg gets 'FastTrack' and 'QuickShip', international express up to 20kg gets 'GlobalExpress' and 'WorldWide', and the standard tiers list three domestic and two international options. A final row adds 'HeavyHauler' for anything between 50 and 70kg. Per-carrier weight caps like these reflect how carrier contracts really work: premium couriers optimize for light, fast parcels, while heavy pieces need a carrier with the right handling equipment. Collecting all matches instead of picking one preserves the full option set, which the ranking step needs to compare prices. Input EligibleCarrierscarriers validation.isValid == false \[\] serviceLevel == 'premium' and destination == 'domestic' and weight <= 15 \['SpeedyExpress'\] serviceLevel == 'express' and destination == 'domestic' and weight <= 30 \['FastTrack', 'QuickShip'\] serviceLevel == 'express' and destination == 'international' and weight <= 20 \['GlobalExpress', 'WorldWide'\] serviceLevel == 'standard' and destination == 'domestic' and weight <= 50 \['RegularPost', 'EcoShip', 'StandardCourier'\] serviceLevel == 'standard' and destination == 'international' and weight <= 30 \['GlobalStandard', 'WorldWide'\] +1 more row in the downloadable template _07_ ### Calculate Costs _expression_ Chargeable weight is computed here as max(\[weight, $.volumetricWeight\]), with volumetricWeight = (length \* width \* height) / 5000, the standard dimensional-weight divisor used across the air-parcel industry so bulky-but-light boxes pay for the space they occupy. The baseCosts map then prices each carrier as a base fee plus a per-kg rate, from EcoShip at 8 + 1.1/kg up to HeavyHauler at 40 + 2.0/kg, adding a flat surcharge when isOversized (any side over 100cm) is true. The final carrierCosts list pairs each eligible carrier with its computed cost for the ranking step. _eligibleCarriers_`flatten(map(eligibleCarriers, #.carriers))` _volumetricWeight_`(length * width * height) / 5000` _chargableWeight_`max([weight, $.volumetricWeight])` _isOversized_`length > 100 or width > 100 or height > 100` _baseCosts_`{ "SpeedyExpress": 25 + ($.chargableWeight * 2.5) + ($.isOversized ? 15 : 0), "FastTrack": 18 + ($.chargableWeight * 1.8) + ($.isOversized ? 12 : 0), "QuickShip": 16 + ($.chargableWeight * 1.9) + ($.isOversized ? 10 : 0), "GlobalExpress": 35 + ($.chargableWeight * 4.2) + ($.isOversized ? 25 : 0), "WorldWide": 30 + ($.chargableWeight * 3.8) + ($.isOversized ? 20 : 0), "RegularPost": 10 + ($.chargableWeight * 1.2) + ($.isOversized ? 8 : 0), "EcoShip": 8 + ($.chargableWeight * 1.1) + ($.isOversized ? 7 : 0), "StandardCourier": 12 + ($.chargableWeight * 1.3) + ($.isOversized ? 9 : 0), "GlobalStandard": 25 + ($.chargableWeight * 2.8) + ($.isOversized ? 15 : 0), "HeavyHauler": 40 + ($.chargableWeight * 2.0) + ($.isOversized ? 30 : 0) }` _carrierCosts_`filter( map($.eligibleCarriers, { 'carrier': #, 'cost': $.baseCosts[#] }), #.cost < 999999 )` ## Other Logistics templates [View all templates](/templates) [_Logistics_ ### Delivery Route Optimizer Smart logistics system that evaluates capacity, traffic, time windows, and distance to determine the most efficient delivery routes for maximum efficiency. ](/industries/logistics/templates/delivery-route-optimizer)[_Logistics_ ### Warehouse Storage Location Maximizes warehouse efficiency by strategically placing products based on turnover rates, picking frequency, and product characteristics. ](/industries/logistics/templates/warehouse-storage-location)[_Logistics_ ### Order Consolidation System Smart logistics system that optimizes shipping by combining orders based on location proximity, delivery timeframes, and available carrier capacity. ](/industries/logistics/templates/order-consolidation-system) ## Make this template your own. Load Shipping Carrier Selector into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Returns Processing System - GoRules **URL:** https://gorules.io/industries/logistics/templates/returns-processing-system **Description:** Streamlines product return processing by applying business rules based on customer status, product details, and return circumstances for optimal efficiency. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Returns Processing System Streamlines product return processing by applying business rules based on customer status, product details, and return circumstances for optimal efficiency. Download template Share ### Solution This returns management system automates and standardizes the entire returns process by applying configurable business rules. It analyzes multiple factors including product type, condition, purchase timeframe, and return reason to determine the appropriate handling path and refund amount. For electronics and appliances still under warranty, defective items receive full replacements, while damaged goods qualify for partial refunds with restocking fees. The system dynamically adjusts return policies based on customer membership tier, providing premium members with more favorable terms. It handles receipt verification, calculates appropriate refund amounts, and assigns restocking fees according to product condition and return timeframe. Each return is assigned to a specific processing department with an appropriate priority level and expected processing timeline. The system also generates the right customer communication, ensuring consistent messaging aligned with the return decision. ### How it works The decision flow processes return requests through five sequential evaluation stages: 1. **Customer Eligibility Assessment**: Analyzes customer profile data to determine high-value status, frequent returner patterns, and purchase timeframe to establish initial eligibility parameters. 2. **Return Type Classification**: Evaluates product type, condition, purchase timeframe, and return reason against a comprehensive rule set to determine the appropriate return handling type. 3. **Processing Queue Assignment**: Routes each return to the appropriate department based on return type (warranty, quality assurance, customer service, or standard returns). 4. **Priority Level Determination**: Assigns a processing priority and timeline based on customer value and item value, ensuring faster processing for high-value customers. 5. **Customer Communication Selection**: Determines the appropriate communication template based on return approval status to ensure clear and consistent messaging. ### Where teams use it - Retail e-commerce operations - Electronics and appliance retailers - Clothing and accessories stores - Omnichannel retail businesses - Customer service departments - Warranty processing centers - Quality assurance departments ## Inside the decision model Returns Processing System ships as a JDM decision graph with 6 nodes, 4 decision tables and 18 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_expression_ customerEligibility_table_ determineReturnType_table_ determineProcessingQueue_table_ determinePriorityLevel_table_ determineCommunication _01_ ### Request _input_ Three nested objects frame the request: customer with membershipTier and returnsHistoryCount, product with type, condition, daysFromPurchase, and price, and return with reason and hasReceipt. The schema pins membershipTier to standard, premium, or vip and condition to five states, which the classification table matches against directly. **Sample request**_JSON_ { "customer": { "id": "CUST-12345", "membershipTier": "premium", "returnsHistoryCount": 3 }, "product": { "type": "electronics", "condition": "damaged", "daysFromPurchase": 12, "price": 249.99 }, "return": { "reason": "defective item - won't power on", "hasReceipt": true } } _02_ ### Customer Eligibility _expression_ Four boolean flags are derived up front: isHighValueCustomer is true for a 'vip' or 'premium' customer.membershipTier, isFrequentReturner trips when customer.returnsHistoryCount > 5, isPurchaseWithinWarranty checks product.daysFromPurchase <= 30, and isHighValueItem marks product.price >= 100. Precomputing these keeps the big classification table free of repeated tier and threshold logic and lets later tables branch on single fields. _isHighValueCustomer_`customer.membershipTier == 'vip' or customer.membershipTier == 'premium'` _isFrequentReturner_`customer.returnsHistoryCount > 5` _isPurchaseWithinWarranty_`product.daysFromPurchase <= 30` _isHighValueItem_`product.price >= 100` _03_ ### Determine Return Type _table_ Eight first-hit rows cross product.type, product.condition, return.reason, product.daysFromPurchase, and return.hasReceipt into a return type, refund, and fee. Defective 'electronics' or 'appliances' in new condition within 30 days with a receipt earn 'warranty\_replacement' at full product.price; damaged or opened units within 15 days drop to 'partial\_refund' at 80% with a 10 restocking fee; clothing follows a parallel pair of rows at 100% or 70% store credit. Reasons containing 'quality' get a 'quality\_review' within 90 days, receiptless returns past 30 days become discounted 'store\_credit' where isHighValueCustomer lifts the payout from 50% to 80% and waives the 15 fee, anything past 90 days is 'denied', and the catch-all routes to 'manual\_review'. The economics behind the tiers are standard retail returns practice: opened electronics cannot be resold as new, so the refund haircut and restocking fee recover part of the remarketing loss, and receiptless returns pay out less because the purchase price cannot be verified. Softening those penalties for premium and vip customers is a deliberate retention trade, spending margin on the customers with the highest lifetime value, while the hard 90-day cutoff bounds the liability window entirely. Product Typeproduct.type Product Conditionproduct.condition Return Reasonreturn.reason Days From Purchaseproduct.daysFromPurchase Has Receiptreturn.hasReceipt Return TypereturnDetails.type Refund AmountreturnDetails.refundAmount Restocking FeereturnDetails.restockingFee 'electronics', 'appliances' 'new', 'like\_new' startsWith($, 'defect') <= 30 true 'warranty\_replacement' product.price 0 'electronics', 'appliances' 'damaged', 'opened' \- <= 15 true 'partial\_refund' product.price \* 0.8 10 'clothing', 'accessories' 'new', 'like\_new' \- <= 30 true 'full\_refund' product.price 0 'clothing', 'accessories' 'used', 'opened' \- <= 15 true 'store\_credit' product.price \* 0.7 5 \- \- contains($, 'quality') <= 90 \- 'quality\_review' isHighValueCustomer ? product.price : product.price \* 0.9 0 \- \- \- \> 30 false 'store\_credit' isHighValueCustomer ? product.price \* 0.8 : product.price \* 0.5 isHighValueCustomer ? 0 : 15 +2 more rows in the downloadable template _04_ ### Determine Processing Queue _table_ Queue routing keys on returnDetails.type alone: 'warranty\_replacement' goes to the 'warranty\_dept', 'quality\_review' to 'quality\_assurance', 'manual\_review' to 'customer\_service', and the blank catch-all sends everything else to the general 'returns\_dept'. First hit ordering makes the three specialist rows take precedence over the default. Separating queues this way matches how return operations are actually staffed: warranty claims need technicians who can test the unit, quality reviews feed defect data back to sourcing, and edge cases need a human with discretion. Keeping the mapping in its own table means a reorganization changes four rows, not the classification logic. Return TypereturnDetails.type Processing QueuereturnDetails.processingQueue 'warranty\_replacement' 'warranty\_dept' 'quality\_review' 'quality\_assurance' 'manual\_review' 'customer\_service' \- 'returns\_dept' _05_ ### Determine Priority Level _table_ Service speed pairs isHighValueCustomer with isHighValueItem: a high-value customer gets 'high' priority and 2 expected processing days regardless of item value, an ordinary customer returning an item worth 100 or more gets 'medium' and 5 days, and everything else runs 'standard' at 7 days. Putting the customer flag ahead of the item flag encodes a retention-first stance, since a premium member returning a cheap item still sees the fast lane. The 2, 5, and 7 day targets are internal SLA choices, useful mainly because publishing an expected timeline cuts the where-is-my-refund contact volume. High Value CustomerisHighValueCustomer High Value ItemisHighValueItem Priority LevelreturnDetails.priorityLevel Expected Processing DaysreturnDetails.expectedProcessingDays true \- 'high' 2 false true 'medium' 5 false false 'standard' 7 _06_ ### Determine Communication _table_ Messaging follows the verdict in three rows on returnDetails.type: 'denied' triggers the 'rejection\_notice' template, 'partial\_refund' and 'store\_credit' share the 'partial\_approval' template, and the catch-all sends 'approved' for everything else. Collapsing many return types into three templates is a sensible communications choice, because customers only need to know whether they get everything, something, or nothing. Binding the template to the decision output also guarantees the letter can never contradict the refund that was actually booked. Return TypereturnDetails.type Customer CommunicationreturnDetails.customerCommunication 'denied' 'rejection\_notice' 'partial\_refund', 'store\_credit' 'partial\_approval' \- 'approved' ## Other Logistics templates [View all templates](/templates) [_Logistics_ ### Shipping Carrier Selector Rule-based system that selects optimal carriers by analyzing package details, service level needs, and cost factors to streamline shipping decisions. ](/industries/logistics/templates/shipping-carrier-selector)[_Logistics_ ### Delivery Route Optimizer Smart logistics system that evaluates capacity, traffic, time windows, and distance to determine the most efficient delivery routes for maximum efficiency. ](/industries/logistics/templates/delivery-route-optimizer)[_Logistics_ ### Warehouse Storage Location Maximizes warehouse efficiency by strategically placing products based on turnover rates, picking frequency, and product characteristics. ](/industries/logistics/templates/warehouse-storage-location) ## Make this template your own. Load Returns Processing System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Order Consolidation System - GoRules **URL:** https://gorules.io/industries/logistics/templates/order-consolidation-system **Description:** Smart logistics system that optimizes shipping by combining orders based on location proximity, delivery timeframes, and available carrier capacity. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Order Consolidation System Smart logistics system that optimizes shipping by combining orders based on location proximity, delivery timeframes, and available carrier capacity. Download template Share ### Solution This logistics optimization system analyzes order pairs to determine when consolidation makes economic and operational sense. It evaluates key shipping factors including geographic proximity between delivery destinations, compatibility of requested delivery windows, and available carrier capacity. When these criteria align favorably, the system categorizes consolidation opportunities into high, medium, or low priority levels. For qualifying order pairs, the system calculates important metrics including combined shipment weight, expected fuel savings, and total cost reduction estimates. Based on consolidation priority, the system recommends specific actions ranging from immediate consolidation to optional consolidation pending customer approval. High-priority consolidations proceed automatically, while medium-priority ones may require scheduling adjustments. Low-priority opportunities undergo additional review and customer confirmation before processing. The system maintains delivery quality standards while reducing transportation costs and environmental impact. ### How it works The decision system follows a structured evaluation process: 1. **Factor Assessment**: Analyzes the distance between delivery locations, difference in requested delivery times, and carrier capacity. 2. **Priority Assignment**: Categorizes consolidation potential as high, medium, low, or none based on predefined thresholds. 3. **Metrics Calculation**: Computes combined order weight, expected fuel savings, and estimated cost reductions. 4. **Processing Route Selection**: Routes orders to appropriate handling pathways based on consolidation priority. 5. **Action Determination**: Assigns specific consolidation actions (immediate, scheduled, optional, or none). 6. **Delivery Scheduling**: Creates optimized delivery schedules with appropriate customer notification requirements. 7. **Savings Reporting**: Generates detailed cost savings reports showing fuel, labor, and total savings estimates. ### Where teams use it - E-commerce fulfillment centers - Third-party logistics providers - Retail distribution networks - Food and grocery delivery services - Industrial supply chains - Last-mile delivery optimization - Warehouse management systems - Regional carrier operations ## Inside the decision model Order Consolidation System ships as a JDM decision graph with 8 nodes, 1 decision table and 5 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ evaluateConsolidationFactors_expression_ calculateConsolidationMetrics_switch_ routeByConsolidationPriority_expression_ highPriorityProcessing_expression_ mediumPriorityProcessing_expression_ lowPriorityProcessing_expression_ standardProcessing _01_ ### Request _input_ A pair of orders comes in with pre-computed pairing metrics: distanceKm between the two destinations, deliveryWindowDifferenceHours, availableCarrierCapacity, and the individual orderWeight1 and orderWeight2, plus the full orders array and carrierDetails for reference. The priority table works entirely off the three pairing metrics. **Sample request**_JSON_ { "orders": \[ { "orderId": "ORD-12345", "customerName": "John Smith", "deliveryAddress": { "street": "123 Main St", "city": "Springfield", "state": "IL", "zipCode": "62704", "coordinates": { "latitude": 39.7817, "longitude": -89.6501 } }, "requestedDeliveryDate": "2025-03-25T14:00:00Z", "orderWeight": 12.5, "orderItems": 3 }, { "orderId": "ORD-12346", "customerName": "Jane Doe", "deliveryAddress": { "street": "456 Oak Ave", "city": "Springfield", "state": "IL", "zipCode": "62702", "coordinates": { "latitude": 39.8021, "longitude": -89.6443 } }, "requestedDeliveryDate": "2025-03-25T16:00:00Z", "orderWeight": 8.2, "orderItems": 2 } \], "distanceKm": 35, "deliveryWindowDifferenceHours": 24, "availableCarrierCapacity": 4, "orderWeight1": 12.5, "orderWeight2": 8.2, "carrierDetails": { "carrierId": "CAR-789", "maxCapacity": 500, "currentLoad": 320 } } _02_ ### Evaluate Consolidation Factors _table_ Consolidation priority falls out of three factors read together under a first hit policy: distanceKm, deliveryWindowDifferenceHours, and availableCarrierCapacity. Destinations under 50km apart with windows within 48 hours and capacity above 3 rate 'high'; two 'medium' rows relax either the time gap (up to 72 hours) or the distance (up to 100km); under 100km with up to 72 hours and capacity above 1 still earns 'low', and the blank catch-all returns 'none' with the explanation that orders cannot be consolidated. Each row also emits a plain-language explanation field. The graduated relaxation is the realistic part: consolidation only pays when the detour between drops is small relative to the line-haul, so distance gets the tightest bounds, while a 72-hour window difference is workable because one customer can usually be nudged a day. Requiring spare carrier capacity above a floor keeps the combined load from bumping other committed freight; the specific 50/100km and 48/72-hour cutoffs are business tuning rather than any industry standard. Distance (km)distanceKm Delivery Window Difference (hours)deliveryWindowDifferenceHours Available Carrier CapacityavailableCarrierCapacity Consolidation PriorityconsolidationPriority Explanationexplanation < 50 < 48 \> 3 'high' 'Orders are nearby, delivery window compatible, and carrier has capacity' < 50 < 72 \> 2 'medium' 'Orders are nearby with slightly different delivery windows but carrier has capacity' < 100 < 48 \> 2 'medium' 'Orders are reasonably close with compatible delivery windows and carrier has capacity' < 100 < 72 \> 1 'low' 'Orders are reasonably close with slightly different delivery windows and minimal carrier capacity' \- \- \- 'none' 'Orders cannot be consolidated due to distance, delivery timing, or carrier capacity' _03_ ### Calculate Consolidation Metrics _expression_ Pair-level metrics get computed before routing: canConsolidate is simply consolidationPriority != 'none', consolidationWeight sums orderWeight1 + orderWeight2, and the savings estimates scale with distance, expectedFuelSavings at distanceKm \* 0.15 and costSavingEstimate at distanceKm \* 0.25 + 15. Computing these once here lets every priority branch reuse the same baseline and just discount it. _canConsolidate_`consolidationPriority != 'none'` _consolidationWeight_`orderWeight1 + orderWeight2` _expectedFuelSavings_`distanceKm * 0.15` _costSavingEstimate_`distanceKm * 0.25 + 15` _04_ ### Route By Consolidation Priority _switch_ Four branches fan out on consolidationPriority: 'high', 'medium', and 'low' each get their own processing expression, and the default branch handles 'none'. Splitting the flow this way keeps each branch's action, schedule shape, and savings discount independent, so changing how low-priority pairs are handled cannot affect the automatic high-priority path. _consolidationPriority == 'high'_ `High Priority Processing` _consolidationPriority == 'medium'_ `Medium Priority Processing` _consolidationPriority == 'low'_ `Low Priority Processing` _otherwise_ `Standard Processing` _05_ ### High Priority Processing _expression_ High-priority pairs are processed without friction: consolidationAction is 'immediate\_consolidation', the deliverySchedule is typed 'consolidated' with notificationRequired false, and the costSavingsReport passes expectedFuelSavings and costSavingEstimate through at full value. No customer touchpoint is needed because both the distance and window checks were already at their tightest. _consolidationAction_`'immediate_consolidation'` _schedulingPriority_`'high'` _deliverySchedule_`{'type': 'consolidated', 'estimatedDeliveryTime': requestedDeliveryDate1, 'notificationRequired': false}` _costSavingsReport_`{'fuelSavings': expectedFuelSavings, 'laborSavings': costSavingEstimate, 'totalSavings': expectedFuelSavings + costSavingEstimate}` _06_ ### Medium Priority Processing _expression_ Medium pairs move to 'scheduled\_consolidation' with a twist on notification: customerConfirmationRequired flips true only when deliveryWindowDifferenceHours > 24, meaning a customer is asked before their delivery shifts by more than a day. The savings report is haircut to 90% of expectedFuelSavings and 80% of costSavingEstimate to reflect the extra coordination these pairs need. _consolidationAction_`'scheduled_consolidation'` _schedulingPriority_`'medium'` _deliverySchedule_`{'type': 'consolidated', 'estimatedDeliveryTime': requestedDeliveryDate1, 'customerConfirmationRequired': deliveryWindowDifferenceHours > 24}` _costSavingsReport_`{'fuelSavings': expectedFuelSavings * 0.9, 'laborSavings': costSavingEstimate * 0.8, 'totalSavings': (expectedFuelSavings * 0.9) + (costSavingEstimate * 0.8)}` _07_ ### Low Priority Processing _expression_ Low-priority pairs become 'optional\_consolidation' with additionalReview set to 'required' and customerConfirmationRequired always true; the deliverySchedule is typed 'potential\_consolidation' and brackets the range between requestedDeliveryDate1 and requestedDeliveryDate2 rather than committing to a slot. Savings drop to 70% and 60% of the fuel and labor baselines, acknowledging that marginal pairings often lose part of the theoretical gain in execution. _consolidationAction_`'optional_consolidation'` _schedulingPriority_`'low'` _deliverySchedule_`{'type': 'potential_consolidation', 'earliestDeliveryTime': requestedDeliveryDate1, 'latestDeliveryTime': requestedDeliveryDate2, 'customerConfirmationRequired': true}` _additionalReview_`'required'` _costSavingsReport_`{'fuelSavings': expectedFuelSavings * 0.7, 'laborSavings': costSavingEstimate * 0.6, 'totalSavings': (expectedFuelSavings * 0.7) + (costSavingEstimate * 0.6)}` _08_ ### Standard Processing _expression_ When no consolidation is possible the fallback keeps both orders independent: consolidationAction is 'no\_consolidation', the deliverySchedule is typed 'separate' with each order keeping its own delivery time, and the costSavingsReport zeroes out fuelSavings, laborSavings, and totalSavings. Returning an explicit zero report instead of omitting it keeps the response shape uniform for downstream reporting. _consolidationAction_`'no_consolidation'` _schedulingPriority_`'standard'` _deliverySchedule_`{'type': 'separate', 'order1DeliveryTime': requestedDeliveryDate1, 'order2DeliveryTime': requestedDeliveryDate2}` _costSavingsReport_`{'fuelSavings': 0, 'laborSavings': 0, 'totalSavings': 0}` ## Other Logistics templates [View all templates](/templates) [_Logistics_ ### Shipping Carrier Selector Rule-based system that selects optimal carriers by analyzing package details, service level needs, and cost factors to streamline shipping decisions. ](/industries/logistics/templates/shipping-carrier-selector)[_Logistics_ ### Delivery Route Optimizer Smart logistics system that evaluates capacity, traffic, time windows, and distance to determine the most efficient delivery routes for maximum efficiency. ](/industries/logistics/templates/delivery-route-optimizer)[_Logistics_ ### Warehouse Storage Location Maximizes warehouse efficiency by strategically placing products based on turnover rates, picking frequency, and product characteristics. ](/industries/logistics/templates/warehouse-storage-location) ## Make this template your own. Load Order Consolidation System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Last-Mile Delivery Assignment - GoRules **URL:** https://gorules.io/industries/logistics/templates/last-mile-delivery-assignment **Description:** Automated system that matches packages with delivery personnel by priority, weight, skills, location, and time to optimize efficiency. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Last-Mile Delivery Assignment Automated system that matches packages with delivery personnel by priority, weight, skills, location, and time to optimize efficiency. Download template Share ### Solution This intelligent delivery assignment system streamlines the last-mile logistics process by automatically matching packages with the most suitable delivery personnel. The system evaluates multiple key factors including package priority (express vs standard), package attributes (weight, fragility, signature requirements), and delivery personnel qualifications (certifications, equipment, vehicle type). The matching algorithm calculates scores based on proximity to delivery location, remaining vehicle capacity, service level agreement deadlines, and specialized handling requirements. For time-sensitive deliveries, the system prioritizes delivery personnel with express certification. When packages require signatures, only equipped personnel are considered. The system either automatically assigns packages that meet threshold requirements or flags exceptions for manual review with suggested actions, ensuring optimal resource utilization while maintaining service quality standards. ### How it works The decision graph processes package assignments through several key evaluation steps: 1. **Input Processing**: Receives package details (ID, priority, weight, dimensions, signature requirements) and delivery personnel information (skills, location, capacity, equipment). 2. **Match Score Calculation**: Evaluates package-personnel compatibility based on priority level, weight handling capabilities, and special skill requirements. 3. **Proximity Analysis**: Calculates a distance score based on how close the delivery person is to the package location. 4. **Capacity Verification**: Confirms the delivery person has sufficient remaining capacity for the package. 5. **SLA Compliance Check**: Assesses if the delivery deadline can be met based on current time and delivery person availability. 6. **Final Score Computation**: Combines all factors into a comprehensive score for assignment decision-making. 7. **Assignment Decision**: Automatically assigns packages with scores above threshold or routes to manual review with actionable recommendations. ### Where teams use it - Last-mile delivery operations - Urban courier services - E-commerce fulfillment centers - Food delivery platforms - Retail store delivery services - Same-day delivery providers - Package redistribution networks - On-demand delivery applications ## Inside the decision model Last-Mile Delivery Assignment ships as a JDM decision graph with 6 nodes, 1 decision table and 6 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ calculate\_match\_score_expression_ calculate\_final\_score_switch_ determine\_assignment_expression_ create\_assignment_expression_ require\_manual\_review _01_ ### Request _input_ Two objects arrive together: a package with priority, weight, needsSignature, distanceFromDeliveryPerson, and deliveryDeadline, and a deliveryPerson with skills, remainingCapacity, and collectSignatureEquipped. The whole graph scores this one candidate pairing rather than searching a pool. **Sample request**_JSON_ { "package": { "id": "PKG-12345", "priority": "express", "weight": 22.5, "dimensions": { "length": 45, "width": 30, "height": 25 }, "fragile": false, "needsSignature": true, "distanceFromDeliveryPerson": 5.2, "deliveryDeadline": "2025-03-19T16:00:00Z", "deliveryZone": "downtown", "specialInstructions": "Leave with doorman if recipient unavailable" }, "deliveryPerson": { "id": "DP-789", "name": "Alex Johnson", "skills": \[ "express\_certified", "heavy\_lifting", "collectSignature" \], "currentLocation": { "latitude": 40.7128, "longitude": -74.006 }, "remainingCapacity": 50, "remainingDeliveries": 8, "vehicleType": "van", "collectSignatureEquipped": true, "currentZone": "downtown", "shiftEndsAt": "2025-03-19T20:00:00Z" } } _02_ ### Calculate Match Score _table_ Compatibility scoring works through requirement-skill pairings with a first hit policy, so the strongest match rows sit on top. An 'express' package over 20kg paired with a courier whose skills contain 'heavy\_lifting' scores 10 with priorityLevel 'high', express with 'express\_certified' scores 8, standard fragile freight matched to 'fragile\_handling' scores 7, standard over 15kg with 'heavy\_lifting' scores 5, a needsSignature package with a collectSignatureEquipped courier scores 4, and the catch-all grants a baseline 2 with 'low'. Ordering rows by the difficulty of the requirement is the practical logic: express-plus-heavy is the hardest package to place, so finding a fully qualified courier is worth the most points. Skill flags like signature equipment and heavy-lifting map directly to real courier constraints, where handing a signature-required parcel to an unequipped driver produces a failed delivery attempt, and the point values themselves are tuning choices for the 15-point assignment bar downstream. Package Requirements Package Attributes Delivery Person Qualifications Match ScorematchScore Priority LevelpriorityLevel package.priority == 'express' package.weight > 20 contains(deliveryPerson.skills, 'heavy\_lifting') 10 'high' package.priority == 'express' \- contains(deliveryPerson.skills, 'express\_certified') 8 'high' package.priority == 'standard' package.fragile == true contains(deliveryPerson.skills, 'fragile\_handling') 7 'medium' package.priority == 'standard' package.weight > 15 contains(deliveryPerson.skills, 'heavy\_lifting') 5 'medium' package.needsSignature == true \- deliveryPerson.collectSignatureEquipped == true 4 'medium' \- \- \- 2 'low' _03_ ### Calculate Final Score _expression_ Score assembly happens in one pass: distanceScore is 10 - min(\[round(package.distanceFromDeliveryPerson / 2), 8\]), so proximity decays with distance but never goes below 2; capacityFactor pays 5 only when deliveryPerson.remainingCapacity covers package.weight; and slaFactor doubles from 3 to 6 when the deliveryDeadline is under 7200 seconds away, boosting urgent packages. These add to matchScore as totalScore, and recommendedAssignment becomes true at 15 or more, the single boolean the switch routes on. _distanceScore_`10 - min([round(package.distanceFromDeliveryPerson / 2), 8])` _capacityFactor_`deliveryPerson.remainingCapacity >= package.weight ? 5 : 0` _slaFactor_`date(package.deliveryDeadline) - date('now') < 7200 ? 6 : 3` _totalScore_`matchScore + $.distanceScore + $.capacityFactor + $.slaFactor` _recommendedAssignment_`$.totalScore >= 15` _04_ ### Determine Assignment _switch_ Assignment forks on recommendedAssignment == true: qualifying pairings flow to automatic assignment while the default branch sends everything else to manual review. Keeping the threshold decision in the expression and only the routing here means the 15-point bar can be tuned without touching the branch structure. _recommendedAssignment == true_ `Create Assignment` _otherwise_ `Require Manual Review` _05_ ### Create Assignment _expression_ Successful matches get an assignmentStatus of 'assigned' plus an assignmentDetails record tying deliveryPerson.id to package.id with the achieved assignmentScore. The estimatedArrival adds package.distanceFromDeliveryPerson \* 180 seconds to the current time, effectively assuming three minutes per kilometer, which gives dispatch a concrete ETA to publish rather than just a match confirmation. _assignmentStatus_`'assigned'` _assignmentDetails_`{ 'deliveryPersonId': deliveryPerson.id, 'packageId': package.id, 'estimatedArrival': date('now') + (package.distanceFromDeliveryPerson * 180), 'assignmentScore': totalScore }` _message_`'Package successfully assigned to delivery person'` _06_ ### Require Manual Review _expression_ Rejected pairings are parked with assignmentStatus 'pending' and a reason, 'Score too low for automatic assignment' when totalScore is under 15. The suggestedActions list, try a different delivery person, wait for a closer one, or escalate to the dispatch manager, turns the rejection into a queue item a dispatcher can act on instead of a dead end. _assignmentStatus_`'pending'` _reason_`totalScore < 15 ? 'Score too low for automatic assignment' : 'Unknown issue'` _suggestedActions_`['Try different delivery person', 'Wait for closer delivery person', 'Escalate to dispatch manager']` _message_`'Package requires manual review for assignment'` ## Other Logistics templates [View all templates](/templates) [_Logistics_ ### Shipping Carrier Selector Rule-based system that selects optimal carriers by analyzing package details, service level needs, and cost factors to streamline shipping decisions. ](/industries/logistics/templates/shipping-carrier-selector)[_Logistics_ ### Delivery Route Optimizer Smart logistics system that evaluates capacity, traffic, time windows, and distance to determine the most efficient delivery routes for maximum efficiency. ](/industries/logistics/templates/delivery-route-optimizer)[_Logistics_ ### Warehouse Storage Location Maximizes warehouse efficiency by strategically placing products based on turnover rates, picking frequency, and product characteristics. ](/industries/logistics/templates/warehouse-storage-location) ## Make this template your own. Load Last-Mile Delivery Assignment into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Hazardous Materials Management System - GoRules **URL:** https://gorules.io/industries/logistics/templates/hazardous-materials-management-system **Description:** Automated rules engine that classifies hazardous materials and provides handling, storage, and transportation guidelines based on regulatory requirements. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Hazardous Materials Management System Automated rules engine that classifies hazardous materials and provides handling, storage, and transportation guidelines based on regulatory requirements. Download template Share ### Solution This hazardous materials management solution automates the classification of dangerous substances and provides precise handling instructions based on material properties. The system evaluates chemical substances by analyzing their intrinsic properties, physical state, and quantity to assign appropriate hazard classifications and risk levels. It then determines the correct storage zone, handling protocols, and equipment requirements needed for safe management. The solution enforces regulatory compliance by applying transportation rules specific to different modes (road, rail, air, sea), evaluating quantity thresholds, and determining when special permits or reporting are required. For materials like corrosives, flammables, toxins, and oxidizers, the system specifies storage limits, required safety equipment, and detailed handling procedures. This ensures organizations maintain safety standards while properly documenting hazardous material movements in accordance with regulations. ### How it works The decision system follows a sequential evaluation process: 1. **Material Classification**: Analyzes the substance properties (flammable, corrosive, toxic, etc.), physical state, and quantity to assign a hazard class (A-F), hazard level, and appropriate storage zone. 2. **Handling Requirements**: Based on the classification and hazard level, the system defines the required personal protective equipment, specific handling procedures, and maximum storage quantity limitations. 3. **Regulatory Compliance**: Evaluates the material classification against the intended transportation mode and quantity to determine compliance requirements, whether permits are needed, and if regulatory reporting is mandatory. 4. **Documentation**: Throughout the process, the system maintains critical information needed for proper labeling, documentation, and record-keeping. ### Where teams use it - Chemical laboratories and manufacturing facilities - Pharmaceutical production and research - Industrial warehousing and distribution - Emergency response planning - Transportation and logistics providers - Environmental compliance departments - Academic and research institutions - Healthcare and hospital material management ## Inside the decision model Hazardous Materials Management System ships as a JDM decision graph with 4 nodes, 3 decision tables and 23 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ Material Classification_table_ Handling Requirements_table_ Regulatory Compliance _01_ ### Request _input_ Five fields describe the substance: material (a free-text name), quantity in kilograms, its physical state, a location code, and the intended transportMode. The schema constrains state to solid, liquid, or gas and transportMode to road, rail, air, sea, or internal, so the tables can match on those values safely. **Sample request**_JSON_ { "material": "Sulfuric Acid", "quantity": 75, "state": "liquid", "location": "Lab-B42", "transportMode": "road" } _02_ ### Material Classification _table_ Classification matches keywords against lower(material) using some(...) with contains, first hit wins, so a substance named 'Sulfuric Acid' hits the corrosive row via the 'acid' keyword. Flammable or combustible liquids and gases become 'Class A - Flammable' in the 'red-zone'; corrosives map to 'Class B - Corrosive' and the 'yellow-zone'; toxic materials split on quantity, 'high' hazard above 25kg and 'medium' at or below; radioactive and explosive names rate 'extreme' in the 'black-zone'; oxidizers get the 'blue-zone', and unmatched names fall to 'Unclassified' in the 'grey-zone'. Keyword-driven classing with a low-severity fallback is a pragmatic first pass for a facility system; the A-F letters and color-coded zones are an internal convention rather than the UN dangerous-goods classes, which is worth knowing before mapping this to shipping paperwork. The quantity split for toxics reflects a real principle, that hazard management scales with the amount on hand, while the 25kg line itself is a site-level choice. Material Typelower(material) Statestate Quantity (kg)quantity ClassificationhazardClassification Hazard LevelhazardLevel Storage ZonerecommendedStorageZone some(\['flammable', 'combustible'\], contains($, #)) 'liquid', 'gas' \- 'Class A - Flammable' 'high' 'red-zone' some(\['corrosive', 'acid', 'base'\], contains($, #)) \- \- 'Class B - Corrosive' 'high' 'yellow-zone' some(\['toxic', 'poison'\], contains($, #)) \- \> 25 'Class C - Toxic' 'high' 'green-zone' some(\['toxic', 'poison'\], contains($, #)) \- <= 25 'Class C - Toxic' 'medium' 'green-zone' some(\['radioactive'\], contains($, #)) \- \- 'Class D - Radioactive' 'extreme' 'black-zone' some(\['explosive'\], contains($, #)) \- \- 'Class E - Explosive' 'extreme' 'black-zone' +2 more rows in the downloadable template _03_ ### Handling Requirements _table_ Equipment, procedure, and a storage cap follow from the hazardClassification and hazardLevel pair, one row per class. Flammables call for fire-resistant gloves and non-sparking tools with a 500kg limit; corrosives allow 1000kg but require neutralizing agents on hand; high-hazard toxics get the tightest chemical cap at 250kg with a full protective suit, easing to 500kg and lab-coat-level PPE at 'medium'; radioactive and explosive stock are squeezed to 50kg and 100kg with remote handling tools or blast shields, and 'Unclassified' material runs standard PPE up to 2000kg. The inverse relationship between hazard and permitted quantity is the realistic backbone here: the storage limit is the lever that bounds worst-case incident size, so the most energetic materials get the smallest allowances. Pairing every limit with named PPE and a written procedure mirrors how safety data sheets translate into site rules, though the specific kilogram caps are policy values a facility would set to match its own containment and ventilation. Hazard ClassificationhazardClassification Hazard LevelhazardLevel Required EquipmentrequiredEquipment Handling ProcedurehandlingProcedure Storage Limit (kg)storageLimit 'Class A - Flammable' 'high' 'Fire-resistant gloves, face shield, flame-retardant clothing' 'Keep away from ignition sources, ensure proper ventilation, use non-sparking tools' 500 'Class B - Corrosive' 'high' 'Chemical-resistant gloves, face shield, apron, boots' 'Avoid contact with skin and eyes, neutralizing agents must be readily available' 1000 'Class C - Toxic' 'high' 'Chemical-resistant gloves, respirator, full protective suit' 'Use only in designated areas with proper ventilation, decontamination station required' 250 'Class C - Toxic' 'medium' 'Chemical-resistant gloves, safety goggles, lab coat' 'Use in well-ventilated area, wash hands thoroughly after handling' 500 'Class D - Radioactive' 'extreme' 'Radiation suit, dosimeter, remote handling tools' 'Special authorization required, time and distance protocols, radiation monitoring mandatory' 50 'Class E - Explosive' 'extreme' 'Anti-static clothing, specialized tools, blast shield' 'Expert personnel only, evacuation plan required, no electronic devices' 100 +2 more rows in the downloadable template _04_ ### Regulatory Compliance _table_ Transport checks combine hazardClassification, transportMode, and quantity, first hit ordering the strictest cases on top. Flammables and explosives over 5kg are refused air transport outright; 'Class D - Radioactive' on any mode demands a special permit and mandatory routing; the four chemical classes on road, rail, or sea then tier by quantity, above 1000kg requiring placards, a certified handler, and reporting, 100 to 1000kg requiring placards and safety data sheets without reporting, and up to 100kg needing only the data sheets. Movements marked 'internal' just need a movement log, and 'Unclassified' goods follow standard shipping procedures. The structure tracks how dangerous-goods transport genuinely works: air freight has far stricter quantity limits than surface modes, placarding and driver certification kick in by quantity bands, and paperwork like safety data sheets travels with even small shipments. The specific 5, 100, and 1000kg breakpoints and the permit strings are simplified stand-ins, so an implementer would swap in the thresholds from the applicable modal regulations rather than treat these as citations. Hazard ClassificationhazardClassification Transport ModetransportMode Quantity (kg)quantity Compliance RequirementscomplianceRequirements Permit RequiredpermitRequired Reporting RequiredreportingRequired 'Class A - Flammable', 'Class E - Explosive' 'air' \> 5 'Prohibited for air transport in this quantity' 'true' 'true' 'Class D - Radioactive' 'road', 'rail', 'air', 'sea' \- 'Special NRC permit required, scheduled route mandatory' 'true' 'true' 'Class A - Flammable', 'Class B - Corrosive', 'Class C - Toxic', 'Class F - Oxidizer' 'road', 'rail', 'sea' \> 1000 'HAZMAT placards required, certified driver/handler only' 'true' 'true' 'Class A - Flammable', 'Class B - Corrosive', 'Class C - Toxic', 'Class F - Oxidizer' 'road', 'rail', 'sea' \> 100 and <= 1000 'HAZMAT placards required, safety data sheets must accompany shipment' 'true' 'false' 'Class A - Flammable', 'Class B - Corrosive', 'Class C - Toxic', 'Class F - Oxidizer' 'road', 'rail', 'sea' <= 100 'Safety data sheets must accompany shipment' 'false' 'false' 'Class A - Flammable', 'Class B - Corrosive', 'Class C - Toxic', 'Class F - Oxidizer' 'internal' \- 'Internal movement log required' 'false' 'false' +1 more row in the downloadable template ## Other Logistics templates [View all templates](/templates) [_Logistics_ ### Shipping Carrier Selector Rule-based system that selects optimal carriers by analyzing package details, service level needs, and cost factors to streamline shipping decisions. ](/industries/logistics/templates/shipping-carrier-selector)[_Logistics_ ### Delivery Route Optimizer Smart logistics system that evaluates capacity, traffic, time windows, and distance to determine the most efficient delivery routes for maximum efficiency. ](/industries/logistics/templates/delivery-route-optimizer)[_Logistics_ ### Warehouse Storage Location Maximizes warehouse efficiency by strategically placing products based on turnover rates, picking frequency, and product characteristics. ](/industries/logistics/templates/warehouse-storage-location) ## Make this template your own. Load Hazardous Materials Management System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Dynamic Shipping Cost Calculator - GoRules **URL:** https://gorules.io/industries/logistics/templates/dynamic-shipping-cost-calculator **Description:** Advanced shipping rate system that automatically calculates costs based on shipment attributes, seasonal variables, and customer loyalty tiers. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Dynamic Shipping Cost Calculator Advanced shipping rate system that automatically calculates costs based on shipment attributes, seasonal variables, and customer loyalty tiers. Download template Share ### Solution This shipping cost calculator delivers accurate and fair pricing by evaluating multiple shipment variables simultaneously. Starting with the base rate determined by shipping type (standard, express, or priority) and weight brackets, the system applies dimensional weight calculations to account for bulky but lightweight items. Distance is factored in proportionally to capture fuel and operational costs that increase with delivery range. The calculator recognizes customer loyalty with built-in tier discounts for platinum, gold, and silver members, providing transparent benefits for repeat business. Seasonal adjustments are automatically applied for summer peak periods and winter weather challenges, ensuring prices reflect actual operational costs throughout the year. This multi-factor approach creates balanced shipping quotes that benefit both the carrier and customer with fair, predictable pricing. ### How it works The decision graph processes shipping information through four connected components: 1. **Base Rate Calculation**: Determines initial pricing using shipping type (standard, express, priority) and weight brackets. 2. **Season Detection**: Identifies the current time of year (winter, summer, regular) based on day number to apply appropriate seasonal factors. 3. **Shipping Factors**: Calculates dimensional weight by comparing actual weight against volume-based weight (length × width × height ÷ 5000), and determines distance factors for mileage pricing. 4. **Final Price Calculation**: Combines all previous factors with customer tier discounts (platinum, gold, silver) to produce the final shipping cost with adjustments for both seasonal challenges and customer loyalty. ### Where teams use it - E-commerce shipping rate calculators - Logistics company pricing systems - Warehouse management software - Supply chain management platforms - Customer service shipping quote tools - International shipping operations ## Inside the decision model Dynamic Shipping Cost Calculator ships as a JDM decision graph with 5 nodes, 3 decision tables and 25 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ base\_rate\_calculation_table_ determine\_season_expression_ calculate\_factors_table_ calculate\_final\_price _01_ ### Request _input_ Quotes start from seven flat fields: shippingType, weight, the length, width, and height dimensions, distance, and customerTier. The graph fans this out to the base-rate and season tables in parallel before merging everything into the final price. **Sample request**_JSON_ { "shippingType": "express", "weight": 25, "length": 40, "width": 30, "height": 20, "distance": 250, "customerTier": "gold" } _02_ ### Base Rate Calculation _table_ A nine-row matrix crosses shippingType against weight brackets under a first hit policy, writing the result to baseRate. Each service has three bands, under 20kg, \[20..50\], and above 50kg: 'standard' runs 10, 15, 25, 'express' runs 20, 30, 45, and 'priority' runs 35, 50, 75. Bracketed base rates like this mirror how published carrier rate cards work, where a handful of weight breaks keep quoting predictable instead of pricing every kilogram continuously. The roughly 2x step from standard to express and again to priority within each band is a business choice that keeps the speed premium consistent across weights. Shipping TypeshippingType Weight (kg)weight Base RatebaseRate 'standard' < 20 10 'standard' \[20..50\] 15 'standard' \> 50 25 'express' < 20 20 'express' \[20..50\] 30 'express' \> 50 45 +3 more rows in the downloadable template _03_ ### Determine Season _table_ Season detection reads dayOfYear('now') rather than any request field: days below 80 or above 355 map to 'winter', days between 172 and 265 map to 'summer', and the blank catch-all returns 'regular'. First hit ordering means the two winter rows cover both ends of the calendar before the summer band is checked. Those cutoffs approximate the northern-hemisphere solstice-to-equinox calendar, so the surcharge windows track the periods when winter weather disruption and summer peak demand genuinely raise operating cost. Because the clock is evaluated at run time, the same request prices differently across the year with no caller input, which is exactly how seasonal tariffs behave in practice. Day of YeardayOfYear('now') Current SeasoncurrentSeason < 80 'winter' \> 355 'winter' \> 172 and < 265 'summer' \- 'regular' _04_ ### Calculate Factors _expression_ Three pricing factors are derived before the rate table runs: dimensionalWeight as (length \* width \* height) / 5000, effectiveWeight as max(\[weight, $.dimensionalWeight\]), and distanceFactor as distance / 100. The 5000 divisor is the dimensional-weight convention parcel carriers use so light but bulky boxes are billed for the space they consume, and normalizing distance per 100km keeps the downstream multiplier small and legible. _dimensionalWeight_`(length * width * height) / 5000` _effectiveWeight_`max([weight, $.dimensionalWeight])` _distanceFactor_`distance / 100` _05_ ### Calculate Final Price _table_ Pricing crosses customerTier with currentSeason across twelve first-hit rows, all sharing the same backbone formula, baseRate \* (effectiveWeight / weight) \* (1 + distanceFactor \* 0.1), then layering tier and season multipliers. 'platinum' pays 0.8 in every season, 'gold' pays 0.9 with a 1.1 winter or 1.05 summer factor, 'silver' pays 0.95 with the same seasonal factors, and the tierless rows at the bottom apply only the seasonal 1.1 or 1.05, or nothing. The tierDiscount output records which multiplier applied. Two realistic pricing ideas are encoded here: seasonal surcharges cover the genuinely higher cost of winter weather handling and summer peak volume, and loyalty tiers buy those surcharges down, with platinum insulated from them entirely since its rows carry no seasonal factor. The specific 5, 10, and 20 percent steps are calibration choices, but the structure, a stable formula with stacked multipliers, is how carriers keep dynamic pricing explainable on an invoice. Customer TiercustomerTier SeasoncurrentSeason Final PricefinalPrice Tier DiscounttierDiscount 'platinum' 'winter' baseRate \* (effectiveWeight / weight) \* (1 + distanceFactor \* 0.1) \* 0.8 0.8 'platinum' 'summer' baseRate \* (effectiveWeight / weight) \* (1 + distanceFactor \* 0.1) \* 0.8 0.8 'platinum' 'regular' baseRate \* (effectiveWeight / weight) \* (1 + distanceFactor \* 0.1) \* 0.8 0.8 'gold' 'winter' baseRate \* (effectiveWeight / weight) \* (1 + distanceFactor \* 0.1) \* 0.9 \* 1.1 0.9 'gold' 'summer' baseRate \* (effectiveWeight / weight) \* (1 + distanceFactor \* 0.1) \* 0.9 \* 1.05 0.9 'gold' 'regular' baseRate \* (effectiveWeight / weight) \* (1 + distanceFactor \* 0.1) \* 0.9 0.9 +6 more rows in the downloadable template ## Other Logistics templates [View all templates](/templates) [_Logistics_ ### Shipping Carrier Selector Rule-based system that selects optimal carriers by analyzing package details, service level needs, and cost factors to streamline shipping decisions. ](/industries/logistics/templates/shipping-carrier-selector)[_Logistics_ ### Delivery Route Optimizer Smart logistics system that evaluates capacity, traffic, time windows, and distance to determine the most efficient delivery routes for maximum efficiency. ](/industries/logistics/templates/delivery-route-optimizer)[_Logistics_ ### Warehouse Storage Location Maximizes warehouse efficiency by strategically placing products based on turnover rates, picking frequency, and product characteristics. ](/industries/logistics/templates/warehouse-storage-location) ## Make this template your own. Load Dynamic Shipping Cost Calculator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Delivery Route Optimizer - GoRules **URL:** https://gorules.io/industries/logistics/templates/delivery-route-optimizer **Description:** Smart logistics system that evaluates capacity, traffic, time windows, and distance to determine the most efficient delivery routes for maximum efficiency. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Delivery Route Optimizer Smart logistics system that evaluates capacity, traffic, time windows, and distance to determine the most efficient delivery routes for maximum efficiency. Download template Share ### Solution This route optimization system maximizes delivery efficiency by analyzing multiple critical factors before selecting the optimal path. It evaluates vehicle capacity utilization to ensure resources are used effectively while considering real-time traffic congestion data to avoid delays. The system factors in delivery time windows to prioritize time-sensitive deliveries and calculates route distances to minimize fuel consumption and delivery times. Each route receives a comprehensive scoring based on these factors, with classifications ranging from "optimal" to "not recommended." The system provides clear approval status and detailed reasoning for each route decision, allowing logistics managers to quickly identify the most efficient options. This enables faster deliveries, reduced operational costs, and improved customer satisfaction through reliable delivery timing. ### How it works The decision graph evaluates delivery routes through four key stages: 1. **Input Processing**: Receives route data including capacity utilization, traffic congestion, delivery window timeframes, and distance metrics. 2. **Base Score Calculation**: Assigns initial scores based on capacity utilization and traffic conditions, with priority levels from very low to high. 3. **Additional Score Computation**: Calculates supplementary scores for delivery time windows and distance factors, with higher scores for shorter timeframes and distances. 4. **Route Classification**: Determines the final route classification by evaluating the total score against predefined thresholds, resulting in a clear approval status with supporting message. ### Where teams use it - Last-mile delivery operations - Food delivery services - Parcel and package delivery - Grocery delivery services - Field service technician routing - Multi-stop urban deliveries - Fleet management optimization ## Inside the decision model Delivery Route Optimizer ships as a JDM decision graph with 4 nodes, 2 decision tables and 10 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ evaluate\_base\_score_expression_ calculate\_additional\_scores_table_ determine\_route\_approval _01_ ### Request _input_ Each candidate arrives as a single route object carrying capacityUtilization, trafficCongestionMinutes, deliveryWindowMinutes, and distanceKm, plus an id and name for reporting. The scoring stages read these fields directly, so no enrichment happens before evaluation. **Sample request**_JSON_ { "route": { "id": "R1234", "name": "Downtown Loop", "capacityUtilization": 0.85, "trafficCongestionMinutes": 12, "deliveryWindowMinutes": 45, "distanceKm": 8.5, "otherCondition": "normal" } } _02_ ### Evaluate Base Score _table_ Base scoring pairs route.capacityUtilization with route.trafficCongestionMinutes under a first hit policy, so the fullest, least congested combination wins. Utilization above 0.8 with congestion under 15 minutes scores 100 with 'high' priority, the same utilization in heavier traffic drops to 80 and 'medium', mid-range utilization above 0.5 lands at 70 or 60 around a 20-minute traffic split, light loads under 0.5 with congestion below 30 minutes get 50, and the blank catch-all row assigns 30 with 'very\_low'. Weighting vehicle fill ahead of traffic reflects how route economics work: an underfilled van spreads its fixed cost over fewer stops, which no amount of clear road can recover. The 0.8 and 0.5 cutoffs and the minute thresholds are sensible operational choices rather than industry standards, tuned so a well-loaded route only loses its top band when congestion becomes material. Capacity Utilizationroute.capacityUtilization Traffic Congestion (min)route.trafficCongestionMinutes Other Conditionroute.otherCondition Base ScorerouteScores.baseScore PriorityrouteScores.priority \> 0.8 < 15 \- 100 'high' \> 0.8 \> 15 \- 80 'medium' \> 0.5 < 20 \- 70 'medium' \> 0.5 \> 20 \- 60 'low' < 0.5 < 30 \- 50 'low' \- \- \- 30 'very\_low' _03_ ### Calculate Additional Scores _expression_ Two supplementary scores get computed here: timeWindowScore awards 50 points when route.deliveryWindowMinutes <= 30, 30 up to 60 minutes, and 10 beyond, while distanceScore steps from 40 at route.distanceKm <= 5 down to 10 past 20km. Both are added to routeScores.baseScore to form totalScore, the single number the approval table thresholds against. Rewarding tight windows and short hops means urgent, nearby work outranks distant slack deliveries. _timeWindowScore_`route.deliveryWindowMinutes <= 30 ? 50 : (route.deliveryWindowMinutes <= 60 ? 30 : 10)` _distanceScore_`route.distanceKm <= 5 ? 40 : (route.distanceKm <= 10 ? 30 : (route.distanceKm <= 20 ? 20 : 10))` _totalScore_`routeScores.baseScore + $.timeWindowScore + $.distanceScore` _04_ ### Determine Route Approval _table_ Approval bands cut totalScore with a first hit policy: above 160 the route is classified 'optimal', above 120 'recommended', above 90 'acceptable', all with routeResult.isApproved set to true, and the blank catch-all writes 'not\_recommended' with false and the message 'Route is not recommended due to low score.' Each band also emits a human-readable routeResult.message for the dispatcher. Against the maximum achievable 190 points (100 base plus 50 window plus 40 distance), the 160 bar reserves 'optimal' for routes that are strong on every factor, while 90 marks the floor where running the route still beats replanning it. Splitting classification from the boolean flag lets a dispatch system auto-release approved routes and queue only the rejected ones for manual review, which is a common pattern in fleet operations. Total ScoretotalScore Route ClassificationrouteResult.classification Is ApprovedrouteResult.isApproved MessagerouteResult.message \> 160 'optimal' true 'Route is optimal with high score.' \> 120 'recommended' true 'Route is recommended with good score.' \> 90 'acceptable' true 'Route is acceptable with moderate score.' \- 'not\_recommended' false 'Route is not recommended due to low score.' ## Other Logistics templates [View all templates](/templates) [_Logistics_ ### Shipping Carrier Selector Rule-based system that selects optimal carriers by analyzing package details, service level needs, and cost factors to streamline shipping decisions. ](/industries/logistics/templates/shipping-carrier-selector)[_Logistics_ ### Warehouse Storage Location Maximizes warehouse efficiency by strategically placing products based on turnover rates, picking frequency, and product characteristics. ](/industries/logistics/templates/warehouse-storage-location)[_Logistics_ ### Order Consolidation System Smart logistics system that optimizes shipping by combining orders based on location proximity, delivery timeframes, and available carrier capacity. ](/industries/logistics/templates/order-consolidation-system) ## Make this template your own. Load Delivery Route Optimizer into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Vehicle Claims Resolution - GoRules **URL:** https://gorules.io/industries/insurance/templates/vehicle-claims-resolution **Description:** Automated decision system for determining optimal insurance claim resolution based on damage severity, vehicle age, and parts availability. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Vehicle Claims Resolution Automated decision system for determining optimal insurance claim resolution based on damage severity, vehicle age, and parts availability. Download template Share ### Solution This decision engine streamlines the vehicle insurance claims process by determining whether to repair, replace, or offer cash settlement for damaged vehicles. The system evaluates the extent of vehicle damage through a percentage assessment, categorizing cases as minor, moderate, severe, or total loss. For vehicles with significant damage but not qualifying as total loss, the solution factors in the vehicle's age and parts availability status. When dealing with older vehicles that have severe damage and limited parts availability, the system typically recommends cash settlements to avoid lengthy repairs with uncertain outcomes. For newer vehicles with similar damage profiles, it might recommend replacement when parts cannot be sourced. In cases where damage is repairable and necessary parts are available or can be obtained with reasonable delay, the system recommends repair. Each recommendation comes with a clear explanation of the decision factors, helping adjusters communicate effectively with policyholders while ensuring consistent claim handling. ### How it works The decision graph processes vehicle claims through three sequential evaluation steps: 1. **Damage Assessment**: Analyzes the damage percentage to classify severity as minor (under 30%), moderate (30-59%), severe (60-79%), or total loss (80%+). 2. **Parts Availability Check**: Evaluates the availability of replacement parts based on the vehicle's age and reported parts status (available, limited, discontinued). 3. **Resolution Determination**: Combines damage level, parts availability, and vehicle age to recommend the optimal resolution: - Total loss claims automatically receive cash settlement recommendations - Severe damage with unavailable parts triggers cash settlement for older vehicles (>8 years) or replacement for newer ones - Moderate damage with unavailable parts leads to cash settlement for vehicles older than 6 years - All minor damage and repairable moderate/severe damage with obtainable parts defaults to repair recommendations Each recommendation includes a detailed explanation of the decision factors. ### Where teams use it - Auto insurance claim processing - Fleet vehicle management - Leasing company damage assessments - Rental car company vehicle evaluations - Body shop repair vs. replace decisions - Salvage and total loss determinations ## Inside the decision model Vehicle Claims Resolution ships as a JDM decision graph with 4 nodes, 3 decision tables and 16 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ assessDamage_table_ checkPartsAvailability_table_ determineRepairMethod _01_ ### Request _input_ Three request objects set up the decision: claim.damagePercentage grades the loss, vehicle.ageYears qualifies parts sourcing and settlement choices, and parts.status reports what the supply chain looks like. **Sample request**_JSON_ { "claim": { "id": "CL-20250318-001", "damagePercentage": 65 }, "vehicle": { "make": "Toyota", "model": "Camry", "year": 2015, "ageYears": 10 }, "parts": { "status": "limited" } } _02_ ### Assess Damage _table_ Severity grading buckets claim.damagePercentage with a first hit policy: >= 80 marks the file 'total\_loss' and flips assessment.isTotalLoss to true, >= 60 grades 'severe', >= 30 'moderate', and the blank fallback row grades 'minor'. Descending thresholds make the overlapping >= conditions unambiguous. An 80 percent trigger stands in for the total-loss thresholds adjusters really apply, where a vehicle is written off once repair cost plus salvage approaches its actual cash value; many jurisdictions set that trigger somewhere between 60 and 100 percent. Using damage as a percentage rather than a repair estimate keeps the template independent of any particular estimating platform. Damage Percentageclaim.damagePercentage Damage Assessmentassessment.damageLevel Is Total Lossassessment.isTotalLoss \>= 80 'total\_loss' true \>= 60 'severe' false \>= 30 'moderate' false \- 'minor' false _03_ ### Check Parts Availability _table_ Sourcing risk only bites for older vehicles: rows for vehicle.ageYears > 10 translate a parts.status of 'discontinued' into 'unavailable' and 'limited' into 'delayed', while 'available' passes through. Vehicles <= 10 years old and the blank catch-all resolve to 'available' regardless of reported status. Treating age as the gate matches how the parts market behaves, since OEM production and aftermarket coverage stay dense for roughly the first decade of a model's life and thin out afterward. Downgrading 'limited' to a delay rather than an outright unavailability keeps repair on the table where the wait, not the part, is the real cost. Vehicle Agevehicle.ageYears Parts Statusparts.status Parts Availabilityparts.availability \> 10 'discontinued' 'unavailable' \> 10 'limited' 'delayed' \> 10 'available' 'available' <= 10 \- 'available' \- \- 'available' _04_ ### Determine Repair Method _table_ Resolution combines all three signals in a first hit table. A 'total\_loss' grade goes straight to 'cash\_settlement' regardless of the other columns; 'severe' damage with 'unavailable' parts splits on vehicle.ageYears, cash settlement above 8 years and 'replacement' at or below it; 'moderate' damage with unavailable parts settles in cash only past 6 years; and every row where parts are 'delayed' or 'available', plus all 'minor' damage, lands on 'repair' with a matching explanation string. The ordering encodes standard claims economics: once a car is totaled, cash against actual cash value is the only sensible outcome, and for older vehicles with unsourceable parts a settlement avoids open-ended rental and storage costs during a stalled repair. Offering replacement only for newer vehicles reflects that a like-kind substitute is realistic early in a model's life, while the 8 and 6 year cutoffs are tunable business choices rather than industry rules. Damage Levelassessment.damageLevel Parts Availabilityparts.availability Vehicle Agevehicle.ageYears Repair Methodrecommendation.method Explanationrecommendation.explanation 'total\_loss' \- \- 'cash\_settlement' 'Vehicle is a total loss; cash settlement recommended' 'severe' 'unavailable' \> 8 'cash\_settlement' 'Severe damage with unavailable parts for older vehicle; cash settlement recommended' 'severe' 'unavailable' <= 8 'replacement' 'Severe damage with unavailable parts for newer vehicle; replacement recommended' 'severe' 'delayed', 'available' \- 'repair' 'Severe damage with obtainable parts; repair recommended' 'moderate' 'unavailable' \> 6 'cash\_settlement' 'Moderate damage with unavailable parts for older vehicle; cash settlement recommended' 'moderate' 'delayed', 'available' \- 'repair' 'Moderate damage with obtainable parts; repair recommended' +1 more row in the downloadable template ## Other Insurance templates [View all templates](/templates) [_Insurance_ ### Policy Eligibility Analyzer Automated rule-based system that evaluates customer eligibility for insurance policies based on age, location, and specific risk factors. ](/industries/insurance/templates/policy-eligibility-analyzer)[_Insurance_ ### Auto Insurance Premium Calculator Dynamic pricing system that determines accurate premiums based on driver profile, vehicle specifications, and coverage options for personalized insurance rates. ](/industries/insurance/templates/auto-insurance-premium-calculator)[_Insurance_ ### Insurance Claim Validation System Automated verification that validates insurance claims against policy status, timeframe requirements, and claim details before investigation. ](/industries/insurance/templates/claim-validation-system) ## Make this template your own. Load Vehicle Claims Resolution into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Policy Eligibility Analyzer - GoRules **URL:** https://gorules.io/industries/insurance/templates/policy-eligibility-analyzer **Description:** Automated rule-based system that evaluates customer eligibility for insurance policies based on age, location, and specific risk factors. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Policy Eligibility Analyzer Automated rule-based system that evaluates customer eligibility for insurance policies based on age, location, and specific risk factors. Download template Share ### Solution This insurance eligibility system streamlines the underwriting process by automatically evaluating potential policyholders against key criteria. The system analyzes customer age to verify compliance with minimum and maximum age requirements, ensuring appropriate risk categorization. Location assessment filters applicants from high-risk geographic areas or regions outside service boundaries, maintaining portfolio balance across territories. The risk assessment component evaluates both the quantity and nature of customer risk factors, considering them alongside health scores to determine overall insurability. When eligibility criteria are not met, the system provides specific denial reasons, enabling agents to clearly communicate decisions to applicants. This automated approach ensures consistent application of underwriting standards while accelerating the decision process for straightforward cases, allowing underwriters to focus on more complex applications. ### How it works The decision graph processes applications through multiple evaluation stages: 1. **Age Verification**: Checks if the applicant falls within acceptable age ranges (18-75). 2. **Location Analysis**: Evaluates the applicant's state/region against excluded high-risk areas and verifies the location is within supported territories. 3. **Risk Assessment**: Evaluates the number of risk factors and their interaction with the applicant's health score. 4. **Eligibility Determination**: Combines all evaluations to make a final decision, collecting specific reasons when applications are denied. Each evaluation node operates independently but contributes to the final determination, with the system producing a clear approved/denied decision along with detailed reasoning. ### Where teams use it - Individual life insurance underwriting - Health insurance application processing - Auto insurance eligibility screening - Property insurance risk assessment - Small business insurance qualification - Travel insurance eligibility verification ## Inside the decision model Policy Eligibility Analyzer ships as a JDM decision graph with 5 nodes, 3 decision tables and 9 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ Age Eligibility_table_ Location Eligibility_table_ Risk Factor Assessment_expression_ Final Determination _01_ ### Request _input_ A single customer object carries everything the graph needs: customer.age, customer.location.state, customer.healthScore, and customer.riskFactors.count drive every eligibility check downstream. **Sample request**_JSON_ { "customer": { "age": 45, "location": { "country": "US", "state": "CA", "city": "San Francisco" }, "healthScore": 85, "riskFactors": { "count": 2, "factors": \[ "previous\_claim", "family\_history" \] } } } _02_ ### Age Eligibility _table_ Age screening runs with a first hit policy over customer.age. Applicants under 18 are declined with 'Age below minimum requirement', anyone over 75 gets 'Age exceeds maximum limit', and the empty catch-all row returns true with 'Age requirements met', so every applicant leaves this table with a flag and a reason. An 18 to 75 issue-age window is typical for standard individual products: minors cannot enter an insurance contract on their own, and past the mid-70s carriers usually route applicants to specialized senior products instead of standard issue. Emitting the reason string alongside the boolean is what lets the final step return an explainable denial rather than a bare false. Agecustomer.age Eligibleeligibility.age.isEligible Reasoneligibility.age.reason < 18 false 'Age below minimum requirement' \> 75 false 'Age exceeds maximum limit' \- true 'Age requirements met' _03_ ### Location Eligibility _table_ Territory checks fire in order under a first hit policy on customer.location.state. A row matching contains(\['FL', 'LA', 'TX'\], $) declines with 'High risk location', a second row declines anything failing the \['US', 'CA', 'UK'\] membership test with 'Location not supported', and the catch-all passes with 'Location requirements met'. FL, LA, and TX are the classic hurricane and coastal catastrophe states where carriers routinely restrict new business or require separate wind programs, so excluding them at intake is a realistic screen. The supported-territory list simply reflects where this book is licensed to write, which is a business footprint choice rather than a risk judgment. State/Regioncustomer.location.state Eligibleeligibility.location.isEligible Reasoneligibility.location.reason contains(\['FL', 'LA', 'TX'\], $) false 'High risk location' !contains(\['US', 'CA', 'UK'\], $) false 'Location not supported' \- true 'Location requirements met' _04_ ### Risk Factor Assessment _table_ Hazard accumulation is judged from customer.riskFactors.count with a first hit policy. More than 3 factors declines outright with 'Too many high-risk factors', exactly 3 factors combined with customer.healthScore < 70 declines with 'Combination of risk factors and low health score', and everything else passes with 'Risk factor assessment passed'. The layered structure mirrors how underwriters treat marginal files: a borderline factor count does not decline on its own, but paired with a weak health score it does. The cutoffs of 3 factors and a 70 health score are sensible business choices for this template rather than industry-mandated thresholds, and they are easy to retune as loss experience comes in. Risk Factors Countcustomer.riskFactors.count Eligibleeligibility.riskFactors.isEligible Reasoneligibility.riskFactors.reason \> 3 false 'Too many high-risk factors' \== 3 and customer.healthScore < 70 false 'Combination of risk factors and low health score' \- true 'Risk factor assessment passed' _05_ ### Final Determination _expression_ Three booleans are ANDed into isEligible, so one failed check is enough to deny the application. The denialReasons expression filters the three reason strings down to actual failures by dropping pass messages like 'Age requirements met', and policyDecision packages { 'approved': isEligible, 'reasons': denialReasons } so the caller gets both the verdict and the specific grounds for it. _isEligible_`eligibility.age.isEligible and eligibility.location.isEligible and eligibility.riskFactors.isEligible` _denialReasons_`filter([eligibility.age.reason, eligibility.location.reason, eligibility.riskFactors.reason], # != 'Age requirements met' and # != 'Location requirements met' and # != 'Risk factor assessment passed')` _policyDecision_`{ 'approved': isEligible, 'reasons': denialReasons }` ## Other Insurance templates [View all templates](/templates) [_Insurance_ ### Auto Insurance Premium Calculator Dynamic pricing system that determines accurate premiums based on driver profile, vehicle specifications, and coverage options for personalized insurance rates. ](/industries/insurance/templates/auto-insurance-premium-calculator)[_Insurance_ ### Insurance Claim Validation System Automated verification that validates insurance claims against policy status, timeframe requirements, and claim details before investigation. ](/industries/insurance/templates/claim-validation-system)[_Insurance_ ### Policy Discount Calculator Automated system that calculates personalized insurance discounts based on customer loyalty, policy bundling, and vehicle safety features. ](/industries/insurance/templates/policy-discount-calculator) ## Make this template your own. Load Policy Eligibility Analyzer into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Policy Discount Calculator - GoRules **URL:** https://gorules.io/industries/insurance/templates/policy-discount-calculator **Description:** Automated system that calculates personalized insurance discounts based on customer loyalty, policy bundling, and vehicle safety features. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Policy Discount Calculator Automated system that calculates personalized insurance discounts based on customer loyalty, policy bundling, and vehicle safety features. Download template Share ### Solution This insurance discount calculator automatically applies appropriate premium reductions by evaluating multiple factors in the customer's profile. The system first analyzes customer loyalty, rewarding long-term clients with tiered discounts based on their years with the company. It then evaluates policy bundling, offering increased savings for customers with multiple policies across different insurance types. For auto insurance specifically, the system identifies safety features installed in the vehicle and applies corresponding discounts for each qualifying feature. Anti-theft systems, dash cams, and advanced driver assistance systems (ADAS) all trigger specific discount percentages. After calculating individual discount categories, the system combines them while ensuring the total doesn't exceed the maximum allowable discount cap. The final premium is then calculated by applying the consolidated discount to the base premium amount. ### How it works The decision graph processes insurance data through four sequential evaluation nodes: 1. **Customer Loyalty Analysis**: Examines customer tenure and assigns appropriate percentage discounts (5-15%) based on years with the company. 2. **Policy Bundle Evaluation**: Determines additional discounts (7-12%) based on the number of policies the customer holds. 3. **Safety Feature Assessment**: Identifies installed vehicle safety features and assigns specific discount percentages for each qualifying feature (anti-theft: 3%, dash cam: 2%, ADAS: 5%). 4. **Discount Calculation**: Sums all applicable discounts, caps the total at a maximum of 25% if necessary, and calculates the final premium by applying the discount to the base premium. ### Where teams use it - Auto insurance premium calculation - Home insurance discount determination - Multi-policy bundle pricing - Customer retention incentive programs - New safety feature promotion campaigns - Insurance quote generation systems ## Inside the decision model Policy Discount Calculator ships as a JDM decision graph with 5 nodes, 3 decision tables and 10 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ customerLoyaltyDiscounts_table_ bundledPoliciesDiscounts_table_ safetyFeaturesDiscounts_expression_ calculateTotalDiscount _01_ ### Request _input_ Two objects drive the whole calculation: customer supplies yearsAsCustomer and numberOfPolicies, while policy carries the basePremium and the safetyFeatures list that the collect table scans. **Sample request**_JSON_ { "customer": { "id": "C12345", "name": "Jane Smith", "yearsAsCustomer": 4, "numberOfPolicies": 2 }, "policy": { "id": "P98765", "type": "auto", "basePremium": 1200, "safetyFeatures": \[ "antiTheftSystem", "advancedDriverAssistance" \] } } _02_ ### Customer Loyalty Discounts _table_ Tenure is read off customer.yearsAsCustomer with a first hit policy, so the most generous row wins: >= 5 years earns 15 with 'Premium loyalty discount', >= 3 earns 10, >= 1 earns 5, and the blank fallback row writes 0 with 'No loyalty discount'. Ordering the rows from largest threshold down is what makes the overlapping >= conditions safe. Stepped tenure discounts are a common retention lever because renewal books are cheaper to service and better risks on average than new business, and 5 to 15 percent is a plausible band for that credit. The specific breakpoints at 1, 3, and 5 years are a business choice for this template rather than any market convention. Years as Customercustomer.yearsAsCustomer Loyalty Discount Percentagediscounts.loyalty.percentage Loyalty Discount Descriptiondiscounts.loyalty.description \>= 5 15 'Premium loyalty discount' \>= 3 10 'Standard loyalty discount' \>= 1 5 'Basic loyalty discount' \- 0 'No loyalty discount' _03_ ### Bundled Policies Discounts _table_ Bundle credit hinges on customer.numberOfPolicies: >= 3 policies earn 12 as a 'Multi-policy premium discount', exactly 2 earn 7 as a 'Dual policy discount', and everything else falls to the 0 row. First hit ordering again puts the richest tier on top. Multi-policy discounts are among the most widely used offers in personal lines because bundled households lapse far less often, which lets carriers give back part of the retention gain as premium credit. The 7 and 12 point values are sensible template numbers in the range such programs actually offer. Number of Policiescustomer.numberOfPolicies Bundle Discount Percentagediscounts.bundle.percentage Bundle Discount Descriptiondiscounts.bundle.description \>= 3 12 'Multi-policy premium discount' 2 7 'Dual policy discount' \- 0 'No bundle discount' _04_ ### Safety Features Discounts _table_ Unlike the earlier tables this one uses a collect hit policy over policy.safetyFeatures, so every matching row fires: contains($, 'antiTheftSystem') adds a 3 point row, contains($, 'dashCam') adds 2, and contains($, 'advancedDriverAssistance') adds 5. The results land as an array under the discounts.safetyFeatures output path, each row carrying its percentage and description. Per-feature credits mirror how auto insurers price equipment: anti-theft devices cut theft severity, and ADAS reduces at-fault collision frequency, which justifies it carrying the largest credit at 5 points. A dash cam mostly helps liability disputes rather than preventing losses, so its smaller 2 point value is a reasonable business choice. Safety Featurespolicy.safetyFeatures Feature Discountpercentage Feature Descriptiondescription contains($, 'antiTheftSystem') 3 'Anti-theft system discount' contains($, 'dashCam') 2 'Dash cam discount' contains($, 'advancedDriverAssistance') 5 'ADAS discount' _05_ ### Calculate Total Discount _expression_ Summation happens here: totalDiscountPercentage adds the loyalty and bundle percentages to sum(map(discounts.safetyFeatures, #.percentage)), then maximumDiscountPercentage clamps the result with min(\[$.totalDiscountPercentage, 25\]). The finalPremium expression applies that capped figure to policy.basePremium, and the 25 percent ceiling is what keeps stacked discounts from eroding the rate below its actuarial floor. _totalDiscountPercentage_`discounts.loyalty.percentage + discounts.bundle.percentage + sum(map(discounts.safetyFeatures, #.percentage))` _maximumDiscountPercentage_`min([$.totalDiscountPercentage, 25])` _finalPremium_`policy.basePremium * (1 - ($.maximumDiscountPercentage / 100))` ## Other Insurance templates [View all templates](/templates) [_Insurance_ ### Policy Eligibility Analyzer Automated rule-based system that evaluates customer eligibility for insurance policies based on age, location, and specific risk factors. ](/industries/insurance/templates/policy-eligibility-analyzer)[_Insurance_ ### Auto Insurance Premium Calculator Dynamic pricing system that determines accurate premiums based on driver profile, vehicle specifications, and coverage options for personalized insurance rates. ](/industries/insurance/templates/auto-insurance-premium-calculator)[_Insurance_ ### Insurance Claim Validation System Automated verification that validates insurance claims against policy status, timeframe requirements, and claim details before investigation. ](/industries/insurance/templates/claim-validation-system) ## Make this template your own. Load Policy Discount Calculator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Insurance Underwriting Risk - GoRules **URL:** https://gorules.io/industries/insurance/templates/insurance-underwriting-risk **Description:** Automated system that evaluates insurance applications against risk factors to determine whether manual underwriting review is necessary. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Insurance Underwriting Risk Automated system that evaluates insurance applications against risk factors to determine whether manual underwriting review is necessary. Download template Share ### Solution This underwriting decision system automates application screening by evaluating key risk factors against established thresholds. The system analyzes medical history indicators like high-risk conditions, recent hospitalizations, and multiple pre-existing conditions, assigning specific risk points to each factor. It also considers occupational hazards and age-related risks that may increase claim likelihood. Beyond health factors, the system evaluates coverage amount thresholds, application completeness, information discrepancies, and foreign residency status. When applications contain multiple risk factors, the system calculates a cumulative risk score. Applications exceeding risk thresholds or containing certain automatic referral triggers are flagged for expert underwriter review with a specific reason code. This approach ensures high-risk applications receive appropriate scrutiny while simplifying approval for lower-risk applicants. ### How it works The decision system processes applications through a multi-step evaluation workflow: 1. **Application Intake**: Captures applicant details and questionnaire responses about medical history, occupation, and personal information. 2. **Risk Factor Analysis**: Evaluates individual risk indicators such as medical conditions, hospitalizations, age, and occupation against predefined criteria. 3. **Score Calculation**: Assigns point values to each identified risk factor and calculates a cumulative risk score. 4. **Threshold Evaluation**: Compares the total risk score and coverage amount against automatic approval thresholds. 5. **Administrative Check**: Verifies application completeness and checks for information discrepancies or foreign residency. 6. **Decision Determination**: Based on all factors, determines whether the application can proceed automatically or requires manual underwriter review. 7. **Referral Documentation**: For applications requiring review, generates a specific reason code to streamline the underwriting process. ### Where teams use it - Life insurance application processing - Health insurance underwriting - Disability insurance risk assessment - Long-term care insurance evaluation - Group insurance policy administration - Reinsurance risk assessment - Specialty insurance products ## Inside the decision model Insurance Underwriting Risk ships as a JDM decision graph with 4 nodes, 2 decision tables and 11 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ application_table_ risk\_factors_expression_ calculate\_risk\_score_table_ referral\_decision _01_ ### Application _input_ An application arrives with an applicationId and a flat answers questionnaire: boolean medical and administrative flags plus age and coverageAmount, which together supply every column the two tables read. **Sample request**_JSON_ { "applicationId": "APP-12345", "applicantName": "Jane Smith", "answers": { "hasHighRiskMedicalCondition": true, "recentHospitalization": false, "multiplePreExistingConditions": true, "hazardousOccupation": false, "age": 58, "coverageAmount": 1200000, "hasIncompleteInformation": false, "hasInformationDiscrepancy": true, "hasForeignResidency": false } } _02_ ### Risk Factors _table_ Because this table runs with a collect hit policy, every matching row contributes rather than the first one winning: answers.hasHighRiskMedicalCondition adds 10 points, recentHospitalization 15, multiplePreExistingConditions 20, hazardousOccupation 25, and age > 65 another 15 as 'Advanced age applicant'. Each hit lands in the riskFactors array with its points and description, so the sample applicant with two true flags collects 10 and 20. The weights order the way a life underwriter would triage impairments: a hazardous occupation and stacked pre-existing conditions raise both frequency and severity for the life of the policy, so they outweigh a single flagged condition. The 65 age trigger reflects the steepening mortality curve at older issue ages, though the point values themselves are template calibrations, not industry constants. Has High Risk Medical Conditionanswers.hasHighRiskMedicalCondition Recent Hospitalizationanswers.recentHospitalization Multiple Pre-existing Conditionsanswers.multiplePreExistingConditions Hazardous Occupationanswers.hazardousOccupation Ageanswers.age Risk Pointspoints Risk Descriptiondescription true \- \- \- \- 10 'High risk medical condition' \- true \- \- \- 15 'Recent hospitalization' \- \- true \- \- 20 'Multiple pre-existing conditions' \- \- \- true \- 25 'Hazardous occupation' \- \- \- \- \> 65 15 'Advanced age applicant' _03_ ### Calculate Risk Score _expression_ Aggregation is two expressions: totalRiskScore is sum(map(riskFactors ?? \[\], #.points)) and riskDescriptions collects the matching description strings. The ?? \[\] guard matters because a fully clean applicant produces no riskFactors array at all, and the referral table still needs a numeric 0 to compare against its threshold. _totalRiskScore_`sum(map(riskFactors ?? [], #.points))` _riskDescriptions_`map(riskFactors ?? [], #.description)` _04_ ### Referral Decision _table_ Any single trigger forces referral in this first hit table: answers.coverageAmount > 1500000 refers with 'Coverage amount exceeds automatic approval threshold', totalRiskScore > 40 with 'Risk score exceeds threshold', and true values on incomplete information, information discrepancy, or foreign residency each carry their own reason. Only the all-blank final row returns false with 'No referral required', and the first matching row's reason becomes the single referralReason code. This mirrors how automated underwriting engines actually work: straight-through processing applies below a coverage ceiling and risk budget, and anything above goes to a human. A face amount cap on auto-approval is universal practice in life underwriting, and discrepancies or foreign residency are classic mandatory-referral triggers because they need judgment and document review rather than more rules. The 1500000 and 40 point levels are this template's chosen thresholds. Coverage Amountanswers.coverageAmount Risk ScoretotalRiskScore Incomplete Informationanswers.hasIncompleteInformation Information Discrepancyanswers.hasInformationDiscrepancy Foreign Residencyanswers.hasForeignResidency Needs Manual Reviewunderwriting.needsManualReview Referral Reasonunderwriting.referralReason \> 1500000 \- \- \- \- true 'Coverage amount exceeds automatic approval threshold' \- \> 40 \- \- \- true 'Risk score exceeds threshold' \- \- true \- \- true 'Application has incomplete information' \- \- \- true \- true 'Discrepancy in personal information' \- \- \- \- true true 'Foreign residency or citizenship' \- \- \- \- \- false 'No referral required' ## Other Insurance templates [View all templates](/templates) [_Insurance_ ### Policy Eligibility Analyzer Automated rule-based system that evaluates customer eligibility for insurance policies based on age, location, and specific risk factors. ](/industries/insurance/templates/policy-eligibility-analyzer)[_Insurance_ ### Auto Insurance Premium Calculator Dynamic pricing system that determines accurate premiums based on driver profile, vehicle specifications, and coverage options for personalized insurance rates. ](/industries/insurance/templates/auto-insurance-premium-calculator)[_Insurance_ ### Insurance Claim Validation System Automated verification that validates insurance claims against policy status, timeframe requirements, and claim details before investigation. ](/industries/insurance/templates/claim-validation-system) ## Make this template your own. Load Insurance Underwriting Risk into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Insurance Coverage Calculator - GoRules **URL:** https://gorules.io/industries/insurance/templates/insurance-coverage-calculator **Description:** Personalized insurance coverage recommendations based on property value, location risk factors, and claim history to optimize protection and cost. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Insurance Coverage Calculator Personalized insurance coverage recommendations based on property value, location risk factors, and claim history to optimize protection and cost. Download template Share ### Solution This intelligent insurance recommendation system evaluates multiple property and risk factors to suggest the most appropriate coverage package for homeowners. The tool analyzes the property's value, age, and type alongside geographic risk levels to determine an initial coverage package category (premium, standard, basic, or minimal). The system then calculates specific coverage amounts across five key areas: dwelling coverage, personal property protection, liability coverage, medical payments, and recommended deductible levels. For properties in flood or earthquake zones, the calculator evaluates additional risk factors and suggests supplemental coverage when warranted. Insurance agents can instantly provide tailored recommendations that balance comprehensive protection with cost-effective premiums, all based on objective risk assessment criteria. ### How it works The decision system follows a structured evaluation process: 1. **Risk Assessment**: Evaluates property value and area risk level to determine the appropriate base package. 2. **Coverage Calculation**: Applies package-specific formulas to calculate precise coverage amounts for dwelling, personal property, liability, and medical payments. 3. **Deductible Assignment**: Assigns appropriate deductible levels based on the selected coverage package. 4. **Special Risk Analysis**: Evaluates flood and earthquake risks separately to determine if additional coverage is warranted. 5. **Supplemental Coverage Calculation**: For identified special risks, calculates recommended coverage amounts as a percentage of dwelling coverage. 6. **Complete Package Assembly**: Combines all recommendations into a comprehensive coverage proposal. ### Where teams use it - Independent insurance agents providing quotes - Direct-to-consumer online insurance portals - Insurance call centers handling inquiries - Property management companies advising clients - Mortgage lenders recommending coverage to borrowers - Real estate agents advising new homebuyers ## Inside the decision model Insurance Coverage Calculator ships as a JDM decision graph with 4 nodes, 3 decision tables and 17 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ determineBasePackage_table_ calculateCoverageLevels_table_ additionalCoverageRecommendations _01_ ### Request _input_ Three request blocks matter: customerData.propertyValue sets the package tier, riskAssessment.areaRiskLevel qualifies it, and the additionalRisks array of type and level pairs feeds the supplemental coverage loop. **Sample request**_JSON_ { "customerData": { "propertyValue": 450000, "propertyAge": 15, "propertyType": "single-family", "preferredDeductible": 1500 }, "riskAssessment": { "areaRiskLevel": "medium", "claimHistory": { "pastClaims": 1, "severityLevel": "low" } }, "additionalRisks": \[ { "type": "flood", "level": "medium" }, { "type": "earthquake", "level": "low" } \] } _02_ ### Determine Base Package _table_ Package selection reads customerData.propertyValue against riskAssessment.areaRiskLevel with a first hit policy. Homes worth >= 500000 in a 'high' risk area get the 'premium' package, the same value in a 'medium' area drops to 'standard', >= 300000 splits between 'standard' and 'basic' depending on the area, >= 200000 in a 'low' area still earns 'basic', and the blank row defaults everything else to 'minimal'. Pairing value with territory reflects that exposure, not price alone, should set coverage richness: an expensive home in a hazardous area needs the fullest package, while the same home in a calm territory is well served by standard limits. The 200000 to 500000 breakpoints are sensible template values an agency would tune to its local housing market. Property ValuecustomerData.propertyValue Risk AreariskAssessment.areaRiskLevel Base PackagebasePackage \>= 500000 'high' 'premium' \>= 300000 'high' 'standard' \>= 500000 'medium' 'standard' \>= 300000 'medium' 'basic' \>= 200000 'low' 'basic' \- \- 'minimal' _03_ ### Calculate Coverage Levels _table_ Formulas rather than constants fill most of the output columns here: the 'premium' row insures the full propertyValue with personal property at propertyValue \* 0.5, liability of 500000, medical payments of 10000, and a 1000 deductible, while lower tiers step the dwelling multiplier down through 0.9, 0.8, and 0.7 and push the deductible up to 2500. Each basePackage value matches exactly one row, so the tier fully determines all five coverageLevels fields. Setting personal property at 35 to 50 percent of dwelling value tracks the homeowners convention of contents limits around half the dwelling limit, and liability between 100000 and 500000 with small medical payments limits is the standard shape of an HO policy. The inverse relation between package richness and deductible is realistic too: buyers of fuller coverage usually want lower retentions. Base PackagebasePackage Dwelling CoveragecoverageLevels.dwellingCoverage Personal Property CoveragecoverageLevels.personalPropertyCoverage Liability CoveragecoverageLevels.liabilityCoverage Medical Payments CoveragecoverageLevels.medicalPaymentsCoverage DeductiblecoverageLevels.deductible 'premium' propertyValue propertyValue \* 0.5 500000 10000 1000 'standard' propertyValue \* 0.9 propertyValue \* 0.45 300000 7500 1500 'basic' propertyValue \* 0.8 propertyValue \* 0.4 200000 5000 2000 'minimal' propertyValue \* 0.7 propertyValue \* 0.35 100000 2500 2500 _04_ ### Additional Coverage Recommendations _table_ Running in loop execution mode over the additionalRisks array, this table evaluates each type and level pair separately and writes one result per risk to additionalCoverageRecommendations. 'flood' at 'high' or 'medium' level recommends coverage at 25 or 20 percent of coverageLevels.dwellingCoverage, 'earthquake' at 'high' goes to 30 percent, and both perils at 'low' level, like the blank catch-all, return false with an amount of 0. Flood and earthquake are the textbook perils excluded from standard homeowners forms and bought as separate policies or endorsements, so surfacing them as supplemental recommendations rather than folding them into the base package matches real placement practice. Sizing the recommendation as a fraction of dwelling coverage is a reasonable simplification of what would otherwise come from flood zone maps and seismic ratings, which is exactly what the level field abstracts. Disaster TypeadditionalRisks.type Risk LeveladditionalRisks.level RecommendadditionalCoverage.recommended Coverage AmountadditionalCoverage.amount 'flood' 'high' true coverageLevels.dwellingCoverage \* 0.25 'flood' 'medium' true coverageLevels.dwellingCoverage \* 0.2 'flood' 'low' false 0 'earthquake' 'high' true coverageLevels.dwellingCoverage \* 0.3 'earthquake' 'medium' true coverageLevels.dwellingCoverage \* 0.2 'earthquake' 'low' false 0 +1 more row in the downloadable template ## Other Insurance templates [View all templates](/templates) [_Insurance_ ### Policy Eligibility Analyzer Automated rule-based system that evaluates customer eligibility for insurance policies based on age, location, and specific risk factors. ](/industries/insurance/templates/policy-eligibility-analyzer)[_Insurance_ ### Auto Insurance Premium Calculator Dynamic pricing system that determines accurate premiums based on driver profile, vehicle specifications, and coverage options for personalized insurance rates. ](/industries/insurance/templates/auto-insurance-premium-calculator)[_Insurance_ ### Insurance Claim Validation System Automated verification that validates insurance claims against policy status, timeframe requirements, and claim details before investigation. ](/industries/insurance/templates/claim-validation-system) ## Make this template your own. Load Insurance Coverage Calculator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Insurance Agent Commission - GoRules **URL:** https://gorules.io/industries/insurance/templates/insurance-agent-commission **Description:** Dynamic commission calculation system that determines agent payouts based on policy type, premium value, and agent performance metrics. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Insurance Agent Commission Dynamic commission calculation system that determines agent payouts based on policy type, premium value, and agent performance metrics. Download template Share ### Solution This commission system automatically calculates insurance agent payouts through a tiered structure that reflects both policy characteristics and agent performance. The system first determines a base commission rate according to the specific policy type (auto, home, or life) and the premium amount, recognizing the varying complexity and value of different insurance products. Higher premium policies within each category earn increased commission percentages, incentivizing agents to pursue more valuable policies. After establishing the base commission, the system applies performance tier multipliers that reward high-achieving agents. Agents are classified into platinum, gold, silver, or standard tiers based on their sales performance metrics. Top performers receive substantial commission boosts, with platinum agents earning 50% more than the base rate and gold tier agents receiving a 25% enhancement. This performance-based structure motivates continuous improvement while ensuring fair compensation that aligns with both policy value and agent achievement. ### How it works The decision graph processes agent commissions through three main components: 1. **Base Commission Calculation**: Analyzes the policy type and premium amount to determine the appropriate base commission rate from a comprehensive table of rates. Auto policies range from 10-15%, home policies from 15-18%, and life policies from 20-25%, with higher rates for larger premiums. 2. **Initial Commission Computation**: Applies the determined rate to the premium amount to calculate the base commission value. 3. **Performance Tier Adjustment**: Evaluates the agent's performance tier (platinum, gold, silver, or standard) and applies the corresponding multiplier to the base commission. Platinum agents receive a 1.5x multiplier, gold agents 1.25x, silver agents 1.1x, while standard agents receive the base commission. The final output provides both the tier multiplier used and the exact commission amount to be paid. ### Where teams use it - Insurance brokerage firms - Independent agency networks - Captive agent compensation systems - Multi-line insurance carriers - Sales team performance management - Agent recruitment and retention programs ## Inside the decision model Insurance Agent Commission ships as a JDM decision graph with 4 nodes, 2 decision tables and 13 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ baseCommissionRates_expression_ calculateBaseCommission_table_ performanceTierMultipliers _01_ ### Request _input_ Just three flat fields drive the payout: policyType and premiumAmount pick the base rate, and performanceTier selects the multiplier applied at the end. **Sample request**_JSON_ { "policyType": "home", "premiumAmount": 2000, "performanceTier": "gold" } _02_ ### Base Commission Rates _table_ Rate lookup pairs policyType with premiumAmount bands under a first hit policy: 'auto' business earns 0.10 to 0.15 as premiums cross 1000 and 2000, 'home' pays 0.15 or 0.18 above 1500, and 'life' runs richest at 0.20 to 0.25 with breaks at 2500 and 5000. A blank fallback row pays 0.08 on anything unrecognized, so no sale goes uncommissioned. Life products out-paying property lines is how real first-year commission scales work, since life sales carry longer advice cycles and are typically paid heavily up front, while auto and home renew with far less agent effort. Escalating the rate with premium size inside each line is a straightforward production incentive, and the specific breakpoints are business choices for this template. Policy TypepolicyType Premium AmountpremiumAmount Base Commission RatebaseCommissionRate 'auto' \> 2000 0.15 'auto' \> 1000 0.12 'auto' \- 0.10 'home' \> 1500 0.18 'home' \- 0.15 'life' \> 5000 0.25 +3 more rows in the downloadable template _03_ ### Calculate Base Commission _expression_ One multiplication turns the rate into money: baseCommission is premiumAmount \* baseCommissionRate, so the sample 2000 home premium at 0.18 yields 360 before any tier adjustment. Keeping this as its own step lets the tier table read a clean baseCommission field instead of repeating the formula. _baseCommission_`premiumAmount * baseCommissionRate` _04_ ### Performance Tier Multipliers _table_ Tier uplift resolves from performanceTier alone: 'platinum' rows emit a tierMultiplier of 1.5 and finalCommission of baseCommission \* 1.5, 'gold' pays 1.25, 'silver' 1.1, and the blank default row passes baseCommission through at 1.0. Both the multiplier and the computed amount are returned, so payroll can audit the math. Performance-tiered overrides like this are standard in agency compensation plans, where qualifying production levels unlock enhanced payout schedules for the period. A 10 to 50 percent uplift band is a plausible spread, and defaulting unknown tiers to 1.0 fails safe by paying the base plan rather than an inflated one. Performance TierperformanceTier Tier MultipliertierMultiplier Final CommissionfinalCommission 'platinum' 1.5 baseCommission \* 1.5 'gold' 1.25 baseCommission \* 1.25 'silver' 1.1 baseCommission \* 1.1 \- 1.0 baseCommission ## Other Insurance templates [View all templates](/templates) [_Insurance_ ### Policy Eligibility Analyzer Automated rule-based system that evaluates customer eligibility for insurance policies based on age, location, and specific risk factors. ](/industries/insurance/templates/policy-eligibility-analyzer)[_Insurance_ ### Auto Insurance Premium Calculator Dynamic pricing system that determines accurate premiums based on driver profile, vehicle specifications, and coverage options for personalized insurance rates. ](/industries/insurance/templates/auto-insurance-premium-calculator)[_Insurance_ ### Insurance Claim Validation System Automated verification that validates insurance claims against policy status, timeframe requirements, and claim details before investigation. ](/industries/insurance/templates/claim-validation-system) ## Make this template your own. Load Insurance Agent Commission into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Customer Lifetime Value - GoRules **URL:** https://gorules.io/industries/insurance/templates/customer-lifetime-value **Description:** Insurance calculation system that determines customer value metrics to optimize retention strategies and set appropriate service tiers for policyholders. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Customer Lifetime Value Insurance calculation system that determines customer value metrics to optimize retention strategies and set appropriate service tiers for policyholders. Download template Share ### Solution This insurance analytics system evaluates customer profitability by processing purchase history data to calculate meaningful lifetime value metrics. It transforms raw transaction data into actionable insights by analyzing order values, purchase frequency, gross margins, and retention rates. The system automatically accounts for acquisition costs when determining a customer's true profitability over their projected relationship with the insurer. Based on calculated lifetime value metrics, the system categorizes customers into appropriate service tiers (platinum, gold, silver, or standard) and recommends specific retention strategies. Platinum customers receive high-touch service and exclusive offers, while other tiers receive progressively standardized service levels. This strategic segmentation allows insurance providers to allocate resources efficiently, customize retention efforts, and maximize long-term profitability across their customer portfolio. ### How it works The decision graph processes customer data through two key components: 1. **Value Calculation Node**: Processes customer purchase history to derive essential metrics: - Average order value from historical policy premiums - Purchase frequency normalized to annual basis - Gross margin percentage converted to decimal format - Expected customer lifetime based on retention probability - Basic lifetime value calculation using the standard CLV formula - Acquisition cost ratio to evaluate marketing efficiency - Adjusted lifetime value with acquisition costs subtracted 2. **Segmentation Decision Table**: Evaluates the adjusted lifetime value against predefined thresholds: - Assigns customer tier classification (platinum, gold, silver, standard) - Provides specific service and retention recommendations for each tier - Ensures consistent treatment of customers with similar value profiles ### Where teams use it - Optimizing retention spending across insurance customer base - Identifying high-value customers for premium service allocation - Setting appropriate service levels based on customer profitability - Evaluating acquisition channel effectiveness against lifetime value - Improving renewal strategies based on customer segments - Determining appropriate marketing investment per customer ## Inside the decision model Customer Lifetime Value ships as a JDM decision graph with 3 nodes, 1 decision table and 4 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_expression_ clv\_calculation_table_ customer\_segmentation _01_ ### Request _input_ Two request blocks feed the math: customer contributes the acquisitionCost to net out, while purchaseHistory supplies orderValues, customerDurationMonths, averageGrossMarginPercent, and retentionRate. **Sample request**_JSON_ { "customer": { "id": "CUST-12345", "name": "John Doe", "segment": "retail", "acquisitionCost": 150, "acquisitionChannel": "paid\_search" }, "purchaseHistory": { "orderValues": \[ 120, 89, 245, 78, 310 \], "customerDurationMonths": 18, "averageGrossMarginPercent": 35, "retentionRate": 85 } } _02_ ### Clv Calculation _expression_ Seven chained expressions assemble the value model: averageOrderValue and an annualized purchaseFrequency come from purchaseHistory.orderValues, customerLifetimeMonths applies the retention formula 1 / (1 - retentionRate / 100) \* 12, and basicLTV multiplies those factors with grossMargin. adjustedLTV then subtracts customer.acquisitionCost, which is the figure the segmentation table actually reads, while acquisitionCostRatio survives as a separate marketing-efficiency readout for comparing channels. _averageOrderValue_`sum(purchaseHistory.orderValues) / len(purchaseHistory.orderValues)` _purchaseFrequency_`len(purchaseHistory.orderValues) / purchaseHistory.customerDurationMonths * 12` _grossMargin_`purchaseHistory.averageGrossMarginPercent / 100` _customerLifetimeMonths_`1 / (1 - purchaseHistory.retentionRate / 100) * 12` _basicLTV_`$.averageOrderValue * $.purchaseFrequency * $.grossMargin * $.customerLifetimeMonths` _acquisitionCostRatio_`customer.acquisitionCost / $.basicLTV` _adjustedLTV_`$.basicLTV - customer.acquisitionCost` _03_ ### Customer Segmentation _table_ Segmentation reads the computed adjustedLTV under a first hit policy with the richest tier on top: > 2000 assigns 'platinum' with 'High-touch service, premium offers, exclusive events', > 1000 assigns 'gold', > 500 'silver', and the blank fallback row leaves everyone else on 'standard' with general promotions. Each row pairs the tier with a concrete recommendedStrategy string, so the output is directly actionable rather than a bare label. Tiering on value net of acquisition cost, instead of raw premium volume, is the right basis for retention spend because it points money at policyholders who are actually profitable to keep. The 500, 1000, and 2000 breakpoints are sensible template values a carrier would recalibrate against its own book's lifetime value distribution. Adjusted LTVadjustedLTV Customer TiercustomerInsights.tier Recommended StrategycustomerInsights.recommendedStrategy \> 2000 'platinum' 'High-touch service, premium offers, exclusive events' \> 1000 'gold' 'Priority service, personalized offers, loyalty bonuses' \> 500 'silver' 'Enhanced service, targeted offers, occasional perks' \- 'standard' 'Standard service, general promotions' ## Other Insurance templates [View all templates](/templates) [_Insurance_ ### Policy Eligibility Analyzer Automated rule-based system that evaluates customer eligibility for insurance policies based on age, location, and specific risk factors. ](/industries/insurance/templates/policy-eligibility-analyzer)[_Insurance_ ### Auto Insurance Premium Calculator Dynamic pricing system that determines accurate premiums based on driver profile, vehicle specifications, and coverage options for personalized insurance rates. ](/industries/insurance/templates/auto-insurance-premium-calculator)[_Insurance_ ### Insurance Claim Validation System Automated verification that validates insurance claims against policy status, timeframe requirements, and claim details before investigation. ](/industries/insurance/templates/claim-validation-system) ## Make this template your own. Load Customer Lifetime Value into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Insurance Claim Validation System - GoRules **URL:** https://gorules.io/industries/insurance/templates/claim-validation-system **Description:** Automated verification that validates insurance claims against policy status, timeframe requirements, and claim details before investigation. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Insurance Claim Validation System Automated verification that validates insurance claims against policy status, timeframe requirements, and claim details before investigation. Download template Share ### Solution This insurance claim validation system provides a standard approach to initial claim screening, ensuring only valid claims proceed to detailed investigation. The system performs comprehensive verification checks across multiple dimensions - evaluating claim information completeness, confirming active policy status, and validating that timeframe requirements are met. When claims fail validation, the system immediately identifies the specific issue with precise reasoning - whether it's an invalid claim number format, an expired policy, or an incident date that falls outside acceptable reporting windows. This enables claims handlers to quickly communicate issues to policyholders or route valid claims for further processing. By automating these fundamental verification steps, insurance companies can reduce processing time, maintain consistent evaluation standards, and focus investigative resources only on claims that meet basic eligibility criteria. ### How it works The decision graph evaluates insurance claims through four sequential validation stages: 1. **Claim Details Validation**: Verifies basic claim information including claim number format, incident date validity, policy number format, and ensures damage amount is greater than zero. 2. **Policy Status Check**: Confirms the policy is active and not expired, canceled, or suspended before proceeding with further validation. 3. **Timeframe Evaluation**: Validates that the incident date is logical - ensuring it's not in the future, occurred after the policy began, and was reported within the required 60-day window. 4. **Outcome Determination**: Combines all validation results to make a final decision, generating a clear validation message and determining whether the claim should proceed to investigation or be rejected. ### Where teams use it - Property and casualty insurance claims processing - Auto insurance claim intake systems - Home insurance damage assessment workflows - Business insurance claim validation - Medical insurance claim screening - Travel insurance claim verification - Accident insurance claim assessment ## Inside the decision model Insurance Claim Validation System ships as a JDM decision graph with 5 nodes, 3 decision tables and 15 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ claimRequest_table_ validateClaimDetails_table_ checkPolicyStatus_table_ evaluateTimeframes_expression_ determineOutcome _01_ ### Claim Request _input_ Claims arrive as one flat payload: claimNumber, policyNumber, policyStatus, policyStartDate, incidentDate, and damageAmount are the fields the three validation tables inspect in sequence. **Sample request**_JSON_ { "claimNumber": "CLM12345", "policyNumber": "POL98765432", "policyStatus": "active", "policyStartDate": 1609459200, "incidentDate": 1640995200, "damageAmount": 1500, "claimType": "property", "description": "Water damage from burst pipe in kitchen" } _02_ ### Validate Claim Details _table_ Format checks run top to bottom with a first hit policy, each failure short-circuiting with its own reason: len(trim(claimNumber ?? '')) < 5 fails as 'Invalid claim number format', a non-numeric incidentDate as 'Incident date is missing or invalid', a policyNumber shorter than 8 characters as 'Invalid policy number format', and damageAmount <= 0 as 'Damage amount must be greater than zero'. The empty final row passes with a blank reason. Running cheap structural checks before any policy verification is normal claims-intake hygiene: a malformed claim or policy number means the loss cannot be matched to a file at all, and a zero or negative damage amount signals a data entry error rather than a real loss. The minimum lengths of 5 and 8 characters belong to this template's numbering scheme, not to any industry standard. Input IsValidvalidation.claimDetailsValid Reasonvalidation.claimDetailsReason len(trim(claimNumber ?? '')) < 5 false 'Invalid claim number format' type(incidentDate) != 'number' false 'Incident date is missing or invalid' len(trim(policyNumber ?? '')) < 8 false 'Invalid policy number format' damageAmount <= 0 false 'Damage amount must be greater than zero' \- true '' _03_ ### Check Policy Status _table_ Before touching status, the first row forwards any upstream failure: !validation.claimDetailsValid re-emits validation.claimDetailsReason so the earliest error survives to the final message. The remaining rows decline when policyStatus equals 'expired', 'canceled', or 'suspended', each with its own reason string, and the catch-all treats anything else as valid. Coverage has to be in force on the date of loss, so nothing other than an active policy should reach investigation. Keeping expired, canceled, and suspended as distinct reasons matters operationally: an expiry is a renewal conversation, a cancellation may still cover losses that predate the cancellation, and a suspension is often a lapsed payment the insured can cure. Input IsValidvalidation.policyStatusValid Reasonvalidation.policyStatusReason !validation.claimDetailsValid false validation.claimDetailsReason policyStatus == 'expired' false 'Policy has expired' policyStatus == 'canceled' false 'Policy has been canceled' policyStatus == 'suspended' false 'Policy is currently suspended' \- true \- _04_ ### Evaluate Timeframes _table_ Chained like the previous step, the first row propagates !validation.policyStatusValid with its reason. Then date arithmetic takes over: date('now') - incidentDate > 60 \* 24 \* 60 \* 60 rejects claims reported more than 60 days after the incident, an incidentDate later than now fails as 'Incident date cannot be in the future', and policyStartDate > incidentDate fails as 'Incident occurred before policy start date'. Prompt-notice requirements are genuine policy conditions, and a 60-day reporting window sits in the range many property forms use, though the exact figure here is a template choice. The other two rows guard against fraud and bad data: a future-dated loss is impossible, and a loss that predates inception is simply not covered under the policy period. Input IsValidvalidation.timeframesValid Reasonvalidation.timeframesReason !validation.policyStatusValid false validation.policyStatusReason date('now') - incidentDate > 60 \* 24 \* 60 \* 60 false 'Claim reported more than 60 days after incident' incidentDate > date('now') false 'Incident date cannot be in the future' policyStartDate > incidentDate false 'Incident occurred before policy start date' \- true '' _05_ ### Determine Outcome _expression_ One AND across the three validation flags yields isValid, while validationMessage picks the first failing stage's reason through nested ternaries and defaults to 'Claim validation passed'. The nextStep expression then routes the file to 'investigation' or 'rejection', giving downstream systems a single field to dispatch on. _isValid_`validation.claimDetailsValid and validation.policyStatusValid and validation.timeframesValid` _validationMessage_`validation.claimDetailsValid ? (validation.policyStatusValid ? (validation.timeframesValid ? 'Claim validation passed' : validation.timeframesReason) : validation.policyStatusReason) : validation.claimDetailsReason` _nextStep_`$.isValid ? 'investigation' : 'rejection'` ## Other Insurance templates [View all templates](/templates) [_Insurance_ ### Policy Eligibility Analyzer Automated rule-based system that evaluates customer eligibility for insurance policies based on age, location, and specific risk factors. ](/industries/insurance/templates/policy-eligibility-analyzer)[_Insurance_ ### Auto Insurance Premium Calculator Dynamic pricing system that determines accurate premiums based on driver profile, vehicle specifications, and coverage options for personalized insurance rates. ](/industries/insurance/templates/auto-insurance-premium-calculator)[_Insurance_ ### Policy Discount Calculator Automated system that calculates personalized insurance discounts based on customer loyalty, policy bundling, and vehicle safety features. ](/industries/insurance/templates/policy-discount-calculator) ## Make this template your own. Load Insurance Claim Validation System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Auto Insurance Premium Calculator - GoRules **URL:** https://gorules.io/industries/insurance/templates/auto-insurance-premium-calculator **Description:** Dynamic pricing system that determines accurate premiums based on driver profile, vehicle specifications, and coverage options for personalized insurance rates. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Auto Insurance Premium Calculator Dynamic pricing system that determines accurate premiums based on driver profile, vehicle specifications, and coverage options for personalized insurance rates. Download template Share ### Solution This auto insurance premium calculator delivers tailored quotes by analyzing key risk indicators across multiple dimensions. The system evaluates driver risk by examining age brackets and incident history, assigning specific risk multipliers and categories that reflect statistical likelihood of claims. Vehicle assessment factors incorporate both type (sedan, SUV, sports car) and age considerations, recognizing that newer vehicles typically present lower risk profiles but higher replacement costs. Coverage evaluation adjusts pricing based on policy type and deductible selection, with comprehensive coverage commanding higher premiums while higher deductibles reduce monthly costs. The calculator applies these risk factors to a base premium rate calculated per thousand dollars of coverage. This modular approach allows for transparent, consistent pricing while ensuring each quote accurately reflects the specific risk combination presented by each customer's unique circumstances. ### How it works The decision graph follows a sequential evaluation process: 1. **Driver Risk Assessment**: Evaluates the driver's age and incident history (accidents and violations), assigning both a numerical risk factor and categorical risk level. 2. **Base Premium Calculation**: Determines the foundational premium by multiplying a standard rate per thousand dollars against the requested coverage amount. 3. **Vehicle Risk Evaluation**: Analyzes vehicle type and age to apply an appropriate risk multiplier, recognizing that sports cars and older vehicles typically represent higher insurance risks. 4. **Coverage Adjustment**: Modifies the premium based on selected coverage type (basic, standard, comprehensive) and deductible amount, with more extensive coverage and lower deductibles increasing the final premium. 5. **Final Premium Calculation**: Combines all risk factors and applies them to the base premium to determine the customer's personalized insurance rate. ### Where teams use it - Online insurance quote systems - Agent quoting tools for in-person consultations - Mobile insurance apps with instant pricing - Price comparison platforms for insurance marketplaces - Underwriting automation for insurance carriers - Risk-based pricing for fleet management companies ## Inside the decision model Auto Insurance Premium Calculator ships as a JDM decision graph with 5 nodes, 3 decision tables and 27 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ driverRiskAssessment_expression_ calculateBasePremium_table_ vehicleRiskAssessment_table_ finalPremiumCalculation _01_ ### Request _input_ Quotes start from two objects: customer, with age and the drivingHistory incident counts, and policy, carrying coverageAmount, coverageType, deductible, vehicleAge, and vehicleType. These are the only fields the rater reads. **Sample request**_JSON_ { "customer": { "age": 35, "gender": "female", "creditScore": 720, "drivingHistory": { "accidentsLast3Years": 0, "violationsLast3Years": 1 } }, "policy": { "coverageAmount": 300000, "coverageType": "comprehensive", "deductible": 500, "vehicleAge": 3, "vehicleType": "sedan" } } _02_ ### Driver Risk Assessment _table_ Driver pricing crosses customer.age bands against a derived Total Incidents column, customer.drivingHistory.accidentsLast3Years plus violationsLast3Years, under a first hit policy. Drivers under 25 with more than 1 incident take the worst ageRiskFactor of 1.5 and a 'high' category, \[25..65\] drivers with zero incidents rate 1.0 and 'low', and over-65 drivers land at 1.1 or 1.3 depending on whether they have any incidents at all. Collapsing accidents and violations into one incident count is a simplification of the surcharge points real raters use, but the shape matches loss experience: youthful operators and incident frequency are the two strongest predictors of auto claims, which is why no under-25 row rates better than 1.3. The mild senior loading reflects the gradual frequency uptick past retirement age rather than any hard cutoff. Agecustomer.age Total Incidentscustomer.drivingHistory.accidentsLast3Years + customer.drivingHistory.violationsLast3Years Age Risk FactorriskFactors.ageRiskFactor Driver Risk CategoryriskFactors.driverRiskCategory < 25 \> 1 1.5 'high' < 25 0, 1 1.3 'medium-high' \[25..65\] \> 2 1.4 'medium-high' \[25..65\] 1, 2 1.2 'medium' \[25..65\] 0 1.0 'low' \> 65 \> 0 1.3 'medium-high' +1 more row in the downloadable template _03_ ### Calculate Base Premium _expression_ A flat rate of 5.5 per thousand anchors the price: coverageAmountInThousands divides policy.coverageAmount by 1000 and basePremium multiplies the two, so the sample 300000 policy starts at 1650 before any risk factors apply. Rate-per-thousand is the standard way carriers express base rates, which keeps the starting number legible to underwriters. _basePremiumPerThousand_`5.5` _coverageAmountInThousands_`policy.coverageAmount / 1000` _basePremium_`$.basePremiumPerThousand * $.coverageAmountInThousands` _04_ ### Vehicle Risk Assessment _table_ Each vehicle row pairs policy.vehicleType with a policy.vehicleAge band: sedans run from 0.9 under 3 years to 1.1 past 7, an 'suv' runs 1.1 to 1.3, and 'sports' cars climb from 1.5 to 1.8 over the same age bands. A blank catch-all row assigns 1.2 to any unrecognized type, so the table always prices. Sports cars carrying roughly double the sedan factor tracks how symbol-based vehicle rating penalizes performance vehicles on both claim frequency and severity. Loading older vehicles more within each type is a sensible choice for this template: aging cars lack current safety and anti-theft equipment, even though their lower replacement cost cuts the other way on physical damage. Vehicle Typepolicy.vehicleType Vehicle Agepolicy.vehicleAge Vehicle Risk FactorriskFactors.vehicleRiskFactor 'sedan' < 3 0.9 'sedan' \[3..7\] 1.0 'sedan' \> 7 1.1 'suv' < 3 1.1 'suv' \[3..7\] 1.2 'suv' \> 7 1.3 +4 more rows in the downloadable template _05_ ### Final Premium Calculation _table_ The last table maps policy.coverageType against deductible bands with a first hit policy: 'basic' cover with a deductible above 1000 earns the cheapest coverageFactor of 0.8, 'comprehensive' with a deductible under 500 tops out at 1.3, and a blank fallback row emits a neutral 1.0. Its outputs also declare the premium field the graph returns. Deductible credits of this shape are ordinary retention pricing: every dollar the insured keeps reduces expected paid losses and suppresses small-claim frequency, so within each coverage type a higher deductible always moves the factor down. The gap between 'basic' and 'comprehensive' rows reflects that comprehensive adds first-party physical damage perils on top of liability, which is genuinely more exposure, not just a richer tier name. Coverage Typepolicy.coverageType Deductiblepolicy.deductible Coverage FactorriskFactors.coverageFactor Final Premiumpremium 'basic' \> 1000 0.8 \- 'basic' \[500..1000\] 0.9 \- 'basic' < 500 1.0 \- 'standard' \> 1000 0.9 \- 'standard' \[500..1000\] 1.0 \- 'standard' < 500 1.1 \- +4 more rows in the downloadable template ## Other Insurance templates [View all templates](/templates) [_Insurance_ ### Policy Eligibility Analyzer Automated rule-based system that evaluates customer eligibility for insurance policies based on age, location, and specific risk factors. ](/industries/insurance/templates/policy-eligibility-analyzer)[_Insurance_ ### Insurance Claim Validation System Automated verification that validates insurance claims against policy status, timeframe requirements, and claim details before investigation. ](/industries/insurance/templates/claim-validation-system)[_Insurance_ ### Policy Discount Calculator Automated system that calculates personalized insurance discounts based on customer loyalty, policy bundling, and vehicle safety features. ](/industries/insurance/templates/policy-discount-calculator) ## Make this template your own. Load Auto Insurance Premium Calculator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Applicant Risk Assessment - GoRules **URL:** https://gorules.io/industries/insurance/templates/application-risk-assessment **Description:** Scoring system that evaluates credit history, income stability, and debt ratios to categorize insurance applicants into risk tiers. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Applicant Risk Assessment Scoring system that evaluates credit history, income stability, and debt ratios to categorize insurance applicants into risk tiers. Download template Share ### Solution This automated risk assessment system evaluates insurance applicants across multiple financial dimensions to determine risk categories and appropriate next steps. The system analyzes credit profiles by examining credit scores, payment history, and established credit duration. It then evaluates financial stability through employment tenure, income verification status, and banking history. The debt analysis component calculates risk based on debt-to-income ratios and existing loan obligations. After processing all factors, the system assigns a comprehensive risk score and classifies applicants as low, medium, or high risk. Each classification triggers specific actions, including automatic approval, manual review requirements, or additional verification processes. The system also determines appropriate interest rate modifications based on risk level, allowing insurers to price policies accurately while streamlining the underwriting process. ### How it works The decision graph contains multiple evaluation nodes that systematically assess risk: 1. **Credit History Scoring**: Evaluates credit score, late payment history, and credit history length, assigning points based on predefined thresholds. 2. **Income Stability Assessment**: Analyzes employment duration, income verification completeness, and bank account standing to determine financial reliability. 3. **Debt Burden Calculation**: Measures debt-to-income ratio and number of outstanding loans to evaluate financial obligations. 4. **Risk Score Aggregation**: Combines all component scores and identifies any concerning factors where applicants scored zero points. 5. **Risk Classification**: Categorizes applicants into low, medium, or high risk tiers based on total score and number of negative factors. 6. **Action Determination**: Assigns appropriate approval status and interest rate adjustments based on risk category. ### Where teams use it - Insurance policy underwriting - Premium calculation and risk-based pricing - Policy renewal assessments - Fraud prevention screening - Automated application processing - Agent-assisted policy issuance ## Inside the decision model Applicant Risk Assessment ships as a JDM decision graph with 9 nodes, 3 decision tables and 13 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ scoreCreditHistory_table_ scoreIncomeStability_table_ scoreDebtToIncome_expression_ calculateRiskScore_switch_ classifyRisk_expression_ lowRiskAction_expression_ mediumRiskAction_expression_ highRiskAction _01_ ### Request _input_ Everything hangs off a single applicant object: creditScore, latePayments, creditHistoryMonths, employmentMonths, incomeVerification, bankAccountStanding, debtToIncomeRatio, and outstandingLoans feed the three scoring tables. **Sample request**_JSON_ { "applicant": { "creditScore": 710, "latePayments": 1, "creditHistoryMonths": 48, "employmentMonths": 36, "incomeVerification": "complete", "bankAccountStanding": "good", "debtToIncomeRatio": 0.35, "outstandingLoans": 2 } } _02_ ### Score Credit History _table_ Credit strength earns up to 30 points when all three columns line up: a creditScore above 750 with fewer than 2 latePayments and more than 60 months of history takes the top row, the \[650..750\] band with under 4 late payments and over 36 months scores 20, \[600..650) scores 10, and the blank fallback row scores 0. First hit ordering means an applicant has to clear every column in a row to collect its points. The bands roughly track familiar consumer credit tiers, with 750 marking prime territory and 650 the near-prime boundary, so the breakpoints read naturally to underwriters even though the point values are template choices. Requiring history length alongside the score matters because a thin file can show a high number with little evidence behind it, and credit-based insurance scoring genuinely relies on these same ingredients where it is permitted. creditScoreapplicant.creditScore latePaymentsapplicant.latePayments creditHistoryLengthapplicant.creditHistoryMonths creditHistoryScorescores.creditHistory \> 750 < 2 \> 60 30 \[650..750\] < 4 \> 36 20 \[600..650) < 6 \> 24 10 \- \- \- 0 _03_ ### Score Income Stability _table_ Stability points demand agreement across three columns: more than 60 employmentMonths with 'complete' incomeVerification and 'good' bankAccountStanding scores 25, the same qualitative pair over 24 months scores 20, 'partial' verification with 'fair' standing past 12 months scores 15, any tenure over 6 months salvages 5 points regardless of the other columns, and the fallback gives 0. Employment tenure is the classic proxy for income continuity, and letting documented income outrank stated income mirrors the verification tiers lenders and underwriters actually use. The 6, 12, 24, and 60 month breakpoints are sensible template values rather than fixed industry standards, chosen so each step upgrades both duration and documentation together. employmentLengthapplicant.employmentMonths incomeVerificationapplicant.incomeVerification bankAccountStandingapplicant.bankAccountStanding incomeStabilityScorescores.incomeStability \> 60 'complete' 'good' 25 \> 24 'complete' 'good' 20 \> 12 'partial' 'fair' 15 \> 6 \- \- 5 \- \- \- 0 _04_ ### Score Debt To Income _table_ Debt burden is scored from applicant.debtToIncomeRatio paired with outstandingLoans: under 0.2 with fewer than 2 loans earns 25 points, under 0.4 with fewer than 3 earns 15, under 0.6 with fewer than 5 earns 5, and the empty row gives 0. Because matching is first hit, a low ratio with many loans slides down to whichever row it fully satisfies. These breakpoints echo lending practice, where ratios around a third of income are treated as comfortable and anything approaching half as stretched, so rewarding sub-0.2 borrowers most is realistic. Counting loans separately catches applicants who keep the ratio low across many small obligations, a pattern that still signals payment complexity. debtToIncomeRatioapplicant.debtToIncomeRatio outstandingLoansapplicant.outstandingLoans debtToIncomeScorescores.debtToIncome < 0.2 < 2 25 < 0.4 < 3 15 < 0.6 < 5 5 \- \- 0 _05_ ### Calculate Risk Score _expression_ Component sums come together as totalRiskScore, the sum of scores.creditHistory, scores.incomeStability, and scores.debtToIncome, for a maximum of 80. The negativeFactors filter collects every component that scored 0 and negativeFactorsCount measures how many, so the classifier can tell a mediocre-everywhere applicant apart from one with a single failed dimension. _totalRiskScore_`scores.creditHistory + scores.incomeStability + scores.debtToIncome` _negativeFactors_`filter([scores.creditHistory == 0, scores.incomeStability == 0, scores.debtToIncome == 0], # == true)` _negativeFactorsCount_`len($.negativeFactors)` _06_ ### Classify Risk _switch_ Routing runs on two signals at once: totalRiskScore >= 60 and negativeFactorsCount == 0 takes the low-risk branch, totalRiskScore >= 30 or (totalRiskScore >= 20 and negativeFactorsCount < 2) goes to medium, and the default statement sweeps the rest into high risk. Making the top tier require zero failed components keeps a file with one blank dimension out of auto-approval no matter how strong the rest of it is. _totalRiskScore >= 60 and negativeFactorsCount == 0_ `Low Risk Action` _totalRiskScore >= 30 or (totalRiskScore >= 20 and negativeFactorsCount < 2)_ `Medium Risk Action` _otherwise_ `High Risk Action` _07_ ### Low Risk Action _expression_ Files that reach this branch get riskCategory 'low', approvalStatus 'auto-approved', and an interestRateModifier of -0.5, a small pricing credit. Auto-approving only the cleanest tier is the straight-through processing pattern that keeps underwriters off routine applications. _riskCategory_`'low'` _approvalStatus_`'auto-approved'` _interestRateModifier_`-0.5` _08_ ### Medium Risk Action _expression_ The middle branch sets approvalStatus to 'manual-review' with a neutral interestRateModifier of 0, so pricing stays standard while a person decides. Holding the modifier flat until an underwriter has looked is a conservative default for borderline scores. _riskCategory_`'medium'` _approvalStatus_`'manual-review'` _interestRateModifier_`0` _09_ ### High Risk Action _expression_ Anything falling through the default statement lands here: riskCategory 'high', approvalStatus 'additional-verification', and a 1.5 point interestRateModifier. Requesting more documentation instead of declining outright preserves the sale, while the surcharge prices the extra uncertainty in the meantime. _riskCategory_`'high'` _approvalStatus_`'additional-verification'` _interestRateModifier_`1.5` ## Other Insurance templates [View all templates](/templates) [_Insurance_ ### Policy Eligibility Analyzer Automated rule-based system that evaluates customer eligibility for insurance policies based on age, location, and specific risk factors. ](/industries/insurance/templates/policy-eligibility-analyzer)[_Insurance_ ### Auto Insurance Premium Calculator Dynamic pricing system that determines accurate premiums based on driver profile, vehicle specifications, and coverage options for personalized insurance rates. ](/industries/insurance/templates/auto-insurance-premium-calculator)[_Insurance_ ### Insurance Claim Validation System Automated verification that validates insurance claims against policy status, timeframe requirements, and claim details before investigation. ](/industries/insurance/templates/claim-validation-system) ## Make this template your own. Load Applicant Risk Assessment into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Preventive Care Recommendation - GoRules **URL:** https://gorules.io/industries/healthcare/templates/preventive-care-recommendation **Description:** Data-driven system that generates personalized preventive healthcare recommendations based on patient demographics and risk factors. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Preventive Care Recommendation Data-driven system that generates personalized preventive healthcare recommendations based on patient demographics and risk factors. Download template Share ### Solution This healthcare decision engine creates tailored preventive care plans by analyzing patient demographics and medical risk factors. The system evaluates the patient's age to determine appropriate screenings, examinations, and immunizations based on established medical guidelines. It applies gender-specific recommendations for appropriate screenings like mammograms, cervical cancer testing, or prostate health evaluations based on both gender and age range. The system also factors in family medical history and personal risk factors to identify necessary additional screenings. For patients with family histories of conditions like diabetes or cancer, it recommends earlier and more frequent specialized testing. Similarly, lifestyle factors such as smoking trigger specific screening recommendations like lung cancer assessments. The final output combines all recommendations into a comprehensive preventive care plan personalized to each patient's specific health profile. ### How it works The decision graph processes patient information through four specialized components: 1. **Patient Data Collection**: Captures essential information including age, gender, family history, risk factors, and previous medical checkups. 2. **Age-Based Assessment**: Evaluates patient age against medical guidelines to recommend appropriate screenings like blood pressure, cholesterol, and cancer screenings. 3. **Gender-Specific Evaluation**: Determines recommended tests based on gender and age ranges, such as mammograms for women or prostate screenings for men. 4. **Risk Factor Analysis**: Examines family medical history and lifestyle factors to identify additional necessary screenings. 5. **Recommendation Consolidation**: Combines all assessments into a single, prioritized list of preventive care recommendations. ### Where teams use it - Primary care practices - Preventive medicine clinics - Health insurance wellness programs - Patient portal applications - Annual physical preparation - Corporate wellness programs - Telemedicine providers - Public health screening initiatives ## Inside the decision model Preventive Care Recommendation ships as a JDM decision graph with 5 nodes, 3 decision tables and 18 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ patientData_table_ ageBasedRecommendations_table_ sexBasedRecommendations_table_ riskBasedRecommendations_expression_ finalRecommendations _01_ ### Patient Data _input_ Demographics plus history drive everything here: age and sex select rows in the screening tables, the familyHistory and riskFactors arrays feed the risk table, and firstName and lastName are recombined into the patient name in the final summary while lastCheckup rides along as context. **Sample request**_JSON_ { "firstName": "Jane", "lastName": "Smith", "age": 42, "sex": "female", "familyHistory": \[ "breast cancer", "diabetes" \], "riskFactors": \[ "smoking" \], "lastCheckup": "2023-10-15" } _02_ ### Age Based Recommendations _table_ Five age bands each emit four recommendations into recommendations.ageBasedRecommendations, primary through quaternary. Under 18 centers on annual physicals, immunizations, vision, and six-month dental checkups; 18 to 39 adds depression and skin cancer screening with cholesterol every 5 years; 40 to 49 introduces diabetes screening every 3 years; 50 to 64 adds colorectal cancer screening and moves cholesterol to annual; 65 and older makes diabetes screening annual and adds a fall risk assessment. The bands are mutually exclusive, so the collect hit policy still yields exactly one matching row. The milestones track published preventive guidance: colorectal screening entering at midlife, cholesterol checks intensifying with age, and fall risk assessment from 65 mirror USPSTF-style recommendations and routine geriatric practice. Band edges are simplified for the template, which is why colorectal screening appears at 50 here even though current US guidance has moved the start age to 45. Ageage Recommendation1recommendations.ageBasedRecommendations.primary Recommendation2recommendations.ageBasedRecommendations.secondary Recommendation3recommendations.ageBasedRecommendations.tertiary Recommendation4recommendations.ageBasedRecommendations.quaternary < 18 "Annual physical examination" "Immunizations as per schedule" "Vision screening" "Dental checkup every 6 months" \>= 18 and < 40 "Blood pressure screening" "Cholesterol screening every 5 years" "Depression screening" "Skin cancer screening" \>= 40 and < 50 "Blood pressure screening" "Cholesterol screening every 5 years" "Diabetes screening every 3 years" "Eye exam every 2-4 years" \>= 50 and < 65 "Blood pressure screening" "Cholesterol screening annually" "Diabetes screening every 3 years" "Colorectal cancer screening" \>= 65 "Blood pressure screening" "Cholesterol screening annually" "Diabetes screening annually" "Fall risk assessment" _03_ ### Sex Based Recommendations _table_ Sex and an age interval combine in every row, and collect gathers whichever applies. Women aged \[21..30) get cervical cancer screening every 3 years plus annual chlamydia screening, \[30..40) swaps in HPV testing every 5 years, \[40..50) starts mammograms every 1-2 years framed as a discussion with the doctor, and \[50..75) moves to mammograms every 2 years with bone density screening noted for 65 plus. Men have two bands: \[40..55) pairs a prostate health discussion with a testicular exam, and \[55..70) adds prostate cancer screening plus abdominal aortic aneurysm screening for those who ever smoked. The intervals map closely onto real US screening guidance: cervical cytology from age 21, HPV testing options in the 30s, biennial mammography from 50 with an individualized-decision window in the 40s, shared decision-making on prostate screening from 55, and AAA screening reserved for older men with a smoking history. Upper bounds like 75 reflect the evidence-based stopping ages in those same recommendations rather than arbitrary limits. Sexsex Ageage GenderRecommendation1recommendations.genderBasedRecommendations.primary GenderRecommendation2recommendations.genderBasedRecommendations.secondary 'female' \[21..30) "Cervical cancer screening every 3 years" "Chlamydia screening annually (if sexually active)" 'female' \[30..40) "Cervical cancer screening every 3 years" "HPV testing every 5 years" 'female' \[40..50) "Mammogram every 1-2 years (discuss with doctor)" "Cervical cancer screening every 3 years" 'female' \[50..75) "Mammogram every 2 years" "Bone density screening (65+ or at risk)" 'male' \[40..55) "Prostate health discussion with doctor" "Testicular exam" 'male' \[55..70) "Prostate cancer screening (discuss with doctor)" "Abdominal aortic aneurysm screening (if ever smoked)" _04_ ### Risk Based Recommendations _table_ Seven independent contains() checks run under a collect policy, so every matching history or lifestyle item appends its own line to recommendations.riskBasedRecommendations. Family history of diabetes, heart disease, colorectal cancer, or breast cancer each pull the relevant screening earlier and make it more frequent, with the colorectal row explicitly targeting screening before age 45, while riskFactors entries add lung cancer screening for smoking, extra diabetes and heart checks for obesity, and liver function tests for alcohol abuse. First-degree family history genuinely shifts screening start ages in clinical guidelines, most visibly for colorectal and breast cancer where earlier surveillance is standard in affected families, and low-dose CT lung screening is indicated by smoking history rather than age alone. Collect is the right policy because risk factors stack: a smoker with a family history of diabetes should see both recommendations, not whichever row sits higher. Risk Assessment RiskRecommendationrecommendations.riskBasedRecommendations contains(familyHistory, "diabetes") "Earlier and more frequent diabetes screening" contains(familyHistory, "heart disease") "Earlier and more frequent cholesterol and blood pressure monitoring" contains(familyHistory, "colorectal cancer") "Earlier colorectal cancer screening (before age 45)" contains(familyHistory, "breast cancer") "Earlier and more frequent mammograms" contains(riskFactors, "smoking") "Lung cancer screening" contains(riskFactors, "obesity") "More frequent diabetes and heart disease screenings" +1 more row in the downloadable template _05_ ### Final Recommendations _expression_ Consolidation folds the age, sex, and risk outputs into one flat summarizedRecommendations list by flattening values(recommendations), counts it into totalRecommendations, and formats patientName from firstName and lastName alongside a recommendationDate stamped from the current date. A testResults key is set to null as a placeholder, and with passThrough off the response is the summary alone rather than the nested intermediate structure. _summarizedRecommendations_`flatMap(flatten(values(recommendations)), #.recommendations)` _patientName_`` `${firstName} ${lastName}` `` _recommendationDate_`dateString(date("now"))` _totalRecommendations_`len($.summarizedRecommendations)` _testResults_`null` ## Other Healthcare templates [View all templates](/templates) [_Healthcare_ ### Patient Triage System Rules-based medical triage system that prioritizes patients in emergency departments based on vital signs, symptoms, and chief complaints. ](/industries/healthcare/templates/patient-triage-system)[_Healthcare_ ### Clinical Pathway Selection Decision system that determines optimal treatment pathways based on diagnosis severity, comorbidities, and patient characteristics for personalized care plans. ](/industries/healthcare/templates/clinical-pathway-selection)[_Healthcare_ ### Medication Dosage Calculator Clinical decision system that calculates precise medication dosages based on patient weight, age, and organ function to maximize safety and efficacy. ](/industries/healthcare/templates/medication-dosage-calculator) ## Make this template your own. Load Preventive Care Recommendation into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Patient Triage System - GoRules **URL:** https://gorules.io/industries/healthcare/templates/patient-triage-system **Description:** Rules-based medical triage system that prioritizes patients in emergency departments based on vital signs, symptoms, and chief complaints. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Patient Triage System Rules-based medical triage system that prioritizes patients in emergency departments based on vital signs, symptoms, and chief complaints. Download template Share ### Solution This triage system quickly identifies the appropriate care priority for patients in emergency departments. Using medical best practices, it evaluates vital signs including temperature, heart rate, respiratory rate, blood pressure, and oxygen saturation. The system analyzes reported symptoms, assigning higher scores for severe conditions like chest pain or difficulty breathing, while giving lower scores to mild symptoms like coughs or minor injuries. Chief complaints are categorized by severity, with life-threatening conditions like stroke or cardiac arrest receiving immediate attention. The system calculates a comprehensive priority score by combining vital signs, symptoms, and complaint assessments. Each patient is then assigned a specific priority level from 1 (Immediate) to 5 (Non-Urgent), with recommended maximum wait times ranging from immediate treatment to 120 minutes based on medical urgency. ### How it works The decision graph evaluates patients through four distinct assessment phases: 1. **Vital Signs Assessment**: Analyzes key physiological indicators including temperature, heart rate, respiratory rate, blood pressure, and oxygen saturation, assigning scores and flags based on deviation from normal ranges. 2. **Symptom Evaluation**: Reviews reported symptoms, categorizing them into severity levels from severe (red flag) to minor (green flag) with corresponding scores. 3. **Chief Complaint Analysis**: Assesses the patient's primary complaint, with life-threatening conditions receiving highest priority scores. 4. **Priority Calculation**: Combines all assessment scores and flags to determine final priority level (1-5), establishing maximum wait times and identifying the highest risk factors. ### Where teams use it - Hospital emergency departments - Urgent care centers - Disaster response triage - Military field hospitals - Telehealth initial assessment - Mass casualty incident management ## Inside the decision model Patient Triage System ships as a JDM decision graph with 5 nodes, 4 decision tables and 21 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ vital\_signs\_assessment_table_ symptom\_assessment_table_ chief\_complaint\_assessment_table_ calculate\_priority\_level _01_ ### Request _input_ Every downstream table reads from three top-level request fields: a vitals object carrying the five measured signs, a symptoms array of reported complaints, and a chiefComplaint string naming the presenting problem. **Sample request**_JSON_ { "vitals": { "temperature": 38.7, "heartRate": 115, "respiratoryRate": 24, "systolicBP": 165, "oxygenSaturation": 94 }, "symptoms": \[ "moderate pain", "fever", "dizziness" \], "chiefComplaint": "fracture" } _02_ ### Vital Signs Assessment _table_ Five vital-sign columns are checked worst-first under a first hit policy. The red row requires a temperature above 39.5 together with heart rate outside 40 to 160, respiratory rate outside 8 to 30, systolic pressure outside 80 to 200, and oxygen saturation below 90, writing 30 to scores.vitalScore and 'red' to flags.vitalFlag. The orange and yellow rows repeat the pattern with tighter bands, fever above 38.5 or 38.0 and saturation below 93 or 95, scoring 20 and 10, and the empty catch-all row scores 0 with a 'green' flag. The bands track standard adult reference ranges: saturation under 90 percent signals hypoxemia needing prompt attention, 95 percent sits at the lower edge of normal, and the fever gradations separate high-grade from low-grade pyrexia. The red-to-green flag ladder mirrors the color coding of five-level triage scales such as the Manchester Triage System, so later steps can combine the flag and the score without re-reading raw vitals. Temperature (°C)vitals.temperature Heart Rate (bpm)vitals.heartRate Respiratory Rate (bpm)vitals.respiratoryRate Systolic BP (mmHg)vitals.systolicBP O2 Saturation (%)vitals.oxygenSaturation Scorescores.vitalScore Flagflags.vitalFlag \> 39.5 )40..160( )8..30( )80..200( < 90 30 'red' \> 38.5 )50..150( )10..25( )90..180( < 93 20 'orange' \> 38.0 )55..140( )12..22( )100..170( < 95 10 'yellow' \- \- \- \- \- 0 'green' _03_ ### Symptom Assessment _table_ Reported complaints are matched with some(symptoms, # in \[...\]) expressions rather than a single field, so one hit anywhere in the list is enough to fire a row. Severe findings such as chest pain, difficulty breathing, unconscious, and active bleeding score 30 with a 'red' flag, the moderate list (vomiting, dehydration, fever, head injury) scores 20 with 'orange', minor items like rash and cough score 10 with 'yellow', and the first hit policy guarantees the most severe matching tier wins before the empty fallback row scores 0 as 'green'. Grouping symptoms into red, orange, and yellow tiers reflects how nurse triage protocols separate immediately life-threatening presentations, chiefly airway, breathing, and circulation problems, from complaints that can safely wait. The 30/20/10 weights are a business calibration chosen so that a single severe symptom outweighs any combination of minor ones in the final sum. Expression Scorescores.symptomScore Flagflags.symptomFlag some(symptoms, # in \["severe pain", "chest pain", "difficulty breathing", "unconscious", "unresponsive", "active bleeding"\]) 30 'red' some(symptoms, # in \["moderate pain", "vomiting", "dehydration", "fever", "dizziness", "head injury"\]) 20 'orange' some(symptoms, # in \["mild pain", "nausea", "minor injury", "rash", "cough"\]) 10 'yellow' \- 0 'green' _04_ ### Chief Complaint Assessment _table_ A single chiefComplaint field drives this table, each row listing its accepted matches. Life-threatening presentations (stroke, heart attack, cardiac arrest, trauma, anaphylaxis, overdose, seizure) score 40, the highest single score in the graph, with a 'red' flag. Urgent but stable complaints such as fracture, deep cut, burn, and pregnancy complication score 20 with 'orange', routine ones like sprain, cold, flu, and medication refill score 10 with 'yellow', and an unrecognized complaint falls through to 0 with 'green'. Weighting this tier at 40 instead of 30 means a stated stroke or cardiac arrest alone can push the total into Level 2 territory even with unremarkable vitals, which matches emergency practice: outcomes for stroke and cardiac events are strongly time-dependent, so triage errs toward over-prioritizing the stated complaint before vitals confirm it. The middle and lower lists are sensible operational groupings rather than a regulated taxonomy. Chief ComplaintchiefComplaint Scorescores.complaintScore Flagflags.complaintFlag "stroke", "heart attack", "cardiac arrest", "trauma", "anaphylaxis", "overdose", "seizure" 40 'red' "fracture", "deep cut", "burn", "allergic reaction", "infection", "pregnancy complication" 20 'orange' "sprain", "minor cut", "cold", "flu", "ear pain", "medication refill" 10 'yellow' \- 0 'green' _05_ ### Calculate Priority Level _table_ Both inputs here are derived: values(flags) collects the three color flags and the second column sums scores.vitalScore + scores.symptomScore + scores.complaintScore. Under the first hit policy, a 'red' flag with a total of at least 60 yields 'Level 1 - Immediate' and a 0-minute wait, red or orange with at least 40 yields 'Level 2 - Very Urgent' at 10 minutes, totals of 20 or more map to 'Level 3 - Urgent' at 30 minutes, 10 or more to 'Level 4 - Standard' at 60 minutes, and the final empty row assigns 'Level 5 - Non-Urgent' with a 120-minute maximum wait. A five-level output with explicit maximum wait times follows the structure of established ED acuity scales such as the Emergency Severity Index and the Manchester Triage System, which likewise run from immediate to non-urgent. Requiring both a red flag and a score of 60 for Level 1 stops one noisy input from consuming resuscitation resources, while the paired flag-plus-threshold rows (contains($, 'red') alongside the score cut) let either strong signal escalate a borderline patient one level. All flagsvalues(flags) Total Scorescores.vitalScore + scores.symptomScore + scores.complaintScore Priority LevelpriorityLevel Max Wait Time (minutes)maxWaitTimeMinutes Highest FlaghighestFlag contains($, 'red') \>= 60 'Level 1 - Immediate' 0 'red' contains($, 'red') \>= 40 'Level 2 - Very Urgent' 10 'red' contains($, 'orange') \>= 40 'Level 2 - Very Urgent' 10 'orange' \- \>= 40 'Level 2 - Very Urgent' 10 'orange' contains($, 'orange') \>= 20 'Level 3 - Urgent' 30 'orange' \- \>= 20 'Level 3 - Urgent' 30 'yellow' +3 more rows in the downloadable template ## Other Healthcare templates [View all templates](/templates) [_Healthcare_ ### Clinical Pathway Selection Decision system that determines optimal treatment pathways based on diagnosis severity, comorbidities, and patient characteristics for personalized care plans. ](/industries/healthcare/templates/clinical-pathway-selection)[_Healthcare_ ### Medication Dosage Calculator Clinical decision system that calculates precise medication dosages based on patient weight, age, and organ function to maximize safety and efficacy. ](/industries/healthcare/templates/medication-dosage-calculator)[_Healthcare_ ### Insurance Prior Authorization Automated system that evaluates insurance requirements for medical services based on carrier rules, diagnosis codes, and service details. ](/industries/healthcare/templates/insurance-prior-authorization) ## Make this template your own. Load Patient Triage System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Medication Dosage Calculator - GoRules **URL:** https://gorules.io/industries/healthcare/templates/medication-dosage-calculator **Description:** Clinical decision system that calculates precise medication dosages based on patient weight, age, and organ function to maximize safety and efficacy. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Medication Dosage Calculator Clinical decision system that calculates precise medication dosages based on patient weight, age, and organ function to maximize safety and efficacy. Download template Share ### Solution This medication dosage calculator provides healthcare providers with precise pharmaceutical dosing guidance that adapts to individual patient characteristics. The system analyzes patient weight, age, kidney function (GFR), and liver status to determine optimal medication amounts. It applies evidence-based dosage adjustments for children, elderly patients, and those with impaired organ function to prevent adverse events while maintaining therapeutic efficacy. For medications like vancomycin, the calculator automatically applies weight-based calculations with kidney function adjustments. The system handles pediatric cases with specialized weight-based formulas distinct from adult dosing protocols. For hepatically metabolized drugs like warfarin, the calculator integrates liver function assessments to modify standard dosing. Each recommendation includes the appropriate dose amount, unit measurement, administration route, and frequency interval, along with clear documentation of any adjustments made. ### How it works The decision system follows a three-step evaluation process: 1. **Patient Data Collection**: Captures essential clinical parameters including patient ID, medication name, weight, age, kidney function (GFR), liver status, allergies, and current medications. 2. **Clinical Parameter Analysis**: Evaluates multiple patient factors including: - Age classification (pediatric vs adult vs elderly) - Renal function assessment - Liver function assessment - Weight-based adjustment factors - Organ-specific dosing modification requirements 3. **Medication-Specific Dosing**: Applies medication-specific rules that consider: - Different dosing protocols for children versus adults - Renal impairment adjustments for kidney-cleared medications - Hepatic adjustment factors for liver-metabolized drugs - Age-appropriate dosing for elderly patients - Standard versus adjusted administration frequencies ### Where teams use it - Hospital inpatient medication ordering - Outpatient prescription systems - Emergency department medication administration - Pediatric dosing calculations - Geriatric medication management - Clinical pharmacy services - Medication safety programs - Electronic health record integration ## Inside the decision model Medication Dosage Calculator ships as a JDM decision graph with 3 nodes, 1 decision table and 10 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ patientData_expression_ calculateParameters_table_ calculateDosage _01_ ### Patient Data _input_ Dosing starts from a flat request validated against a JSON schema: medication, weightKg, ageYears, and gfrValue are required, liverFunction is constrained to the values normal through severe, and allergies plus currentMedications ride along for clinical context. **Sample request**_JSON_ { "patientId": "P12345", "medication": "vancomycin", "weightKg": 65, "ageYears": 72, "gfrValue": 45, "liverFunction": "normal", "allergies": \[ "penicillin", "sulfa" \], "currentMedications": \[ "metformin", "lisinopril" \] } _02_ ### Calculate Parameters _expression_ Eight derived flags and factors turn raw demographics into dosing inputs: isChild (ageYears < 18), isElderly (ageYears >= 65), hasRenalImpairment (gfrValue < 60), and stepped multipliers where renalAdjustmentFactor drops to 0.75 below a GFR of 60 and 0.5 below 30 while liverAdjustmentFactor scales from 0.9 for 'mild' down to 0.5 for 'severe'. The dosage table matches on the flags and multiplies base doses by the factors, so every threshold judgment lives in this one node. _isChild_`ageYears < 18` _isElderly_`ageYears >= 65` _hasRenalImpairment_`gfrValue < 60` _hasLiverImpairment_`liverFunction != 'normal'` _weightFactorAdult_`weightKg / 70` _weightFactorChild_`weightKg / 30` _renalAdjustmentFactor_`gfrValue < 30 ? 0.5 : (gfrValue < 60 ? 0.75 : 1)` _liverAdjustmentFactor_`liverFunction == 'severe' ? 0.5 : (liverFunction == 'moderate' ? 0.75 : (liverFunction == 'mild' ? 0.9 : 1))` _03_ ### Calculate Dosage _table_ One column matches the medication name and four boolean columns pick the patient variant, first hit wins. 'amoxicillin' doses children at 50 \* weightKg mg every 8 hours and adults at 500 \* weightFactorAdult; 'paracetamol' gives children 15 \* weightKg every 6 hours, renally impaired adults 500 \* renalAdjustmentFactor with the reason 'adjusted for renal function', and other adults a flat 1000 mg; 'vancomycin' runs 15 \* weightKg intravenously every 12 hours, multiplied by renalAdjustmentFactor when hasRenalImpairment is true; 'warfarin' starts at 5 mg daily, cut to 2 or 3 \* liverAdjustmentFactor for liver impairment or isElderly. Row order settles conflicts, so an elderly patient with liver impairment takes the liver-adjusted warfarin row before the elderly one. The formulas mirror real dosing conventions: pediatric drugs are dosed per kilogram rather than as flat amounts, vancomycin at 15 mg per kg twice daily with a renal reduction matches standard practice for a renally cleared, nephrotoxic antibiotic, and trimming warfarin initiation for elderly or hepatically impaired patients reflects its liver metabolism and narrow therapeutic index. The 0.75 and 0.5 multiplier steps are simplified stand-ins for the graded reductions found in drug monographs, a sensible template choice rather than values lifted from any single label. Medicationmedication Is ChildisChild Is ElderlyisElderly Has Renal ImpairmenthasRenalImpairment Has Liver ImpairmenthasLiverImpairment Dose AmountcalculatedDose.amount Dose UnitcalculatedDose.unit Frequency (hours)calculatedDose.frequencyHours RoutecalculatedDose.route Adjustment ReasoncalculatedDose.adjustmentReason 'amoxicillin' true \- \- \- 50 \* weightKg 'mg' '8' 'oral' 'standard' 'amoxicillin' false \- \- \- 500 \* weightFactorAdult 'mg' '8' 'oral' 'standard' 'paracetamol' true \- \- \- 15 \* weightKg 'mg' '6' 'oral' 'standard' 'paracetamol' false \- \- true 500 \* renalAdjustmentFactor 'mg' '8' 'oral' 'adjusted for renal function' 'paracetamol' false \- \- \- 1000 'mg' '6' 'oral' 'standard' 'vancomycin' \- \- true \- 15 \* weightKg \* renalAdjustmentFactor 'mg' '12' 'intravenous' 'adjusted for renal function' +4 more rows in the downloadable template ## Other Healthcare templates [View all templates](/templates) [_Healthcare_ ### Patient Triage System Rules-based medical triage system that prioritizes patients in emergency departments based on vital signs, symptoms, and chief complaints. ](/industries/healthcare/templates/patient-triage-system)[_Healthcare_ ### Clinical Pathway Selection Decision system that determines optimal treatment pathways based on diagnosis severity, comorbidities, and patient characteristics for personalized care plans. ](/industries/healthcare/templates/clinical-pathway-selection)[_Healthcare_ ### Insurance Prior Authorization Automated system that evaluates insurance requirements for medical services based on carrier rules, diagnosis codes, and service details. ](/industries/healthcare/templates/insurance-prior-authorization) ## Make this template your own. Load Medication Dosage Calculator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Medical Appointment Priority System - GoRules **URL:** https://gorules.io/industries/healthcare/templates/medical-appointment-priority-system **Description:** Scheduling system that prioritizes patients by clinical severity, risk factors, and wait times to optimize care and resource allocation. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Medical Appointment Priority System Scheduling system that prioritizes patients by clinical severity, risk factors, and wait times to optimize care and resource allocation. Download template Share ### Solution This medical appointment prioritization system ensures patients receive timely care based on clinical need. The solution evaluates multiple patient factors to determine scheduling urgency, assigning a comprehensive priority score that guides clinical staff. It analyzes condition severity from mild to critical, factoring in whether appointments are follow-ups to ongoing treatment plans. The system incorporates key patient risk factors including age over 65, chronic conditions, immunocompromised status, and recent hospitalizations. Wait time analysis prevents patients from falling through the cracks by escalating priority for those waiting longer than standard timeframes. Based on the calculated score, patients receive one of five priority levels (Low to Urgent) with specific scheduling recommendations, ensuring the most vulnerable and acute patients receive prompt care while maintaining efficient clinic operations. ### How it works The appointment prioritization system follows a systematic evaluation process: 1. **Risk Factor Assessment**: Evaluates patient demographics and medical history including age, chronic conditions, immune status, and recent hospitalizations. 2. **Condition Severity Analysis**: Determines clinical urgency based on reported severity (mild to critical) and whether the appointment is a follow-up. 3. **Wait Time Evaluation**: Calculates additional priority points based on how long the patient has been waiting for an appointment. 4. **Priority Score Calculation**: Combines all factors into a comprehensive numerical score. 5. **Priority Assignment**: Translates the numerical score into actionable priority levels (Urgent, High, Medium, Standard, Low) with specific scheduling timeframe recommendations. ### Where teams use it - Primary care practice appointment scheduling - Specialist referral prioritization - Emergency department triage support - Post-discharge follow-up management - Chronic disease management scheduling - Limited resource allocation in healthcare settings ## Inside the decision model Medical Appointment Priority System ships as a JDM decision graph with 7 nodes, 4 decision tables and 20 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ calculateRiskFactorScore_expression_ riskFactorSummary_table_ evaluateConditionSeverity_table_ calculateWaitTimeScore_expression_ calculateTotalPriorityScore_table_ assignPriorityLevel _01_ ### Request _input_ Appointment requests split into two schema-validated objects: patient carries age plus three booleans (hasChronicCondition, immunocompromised, recentHospitalization), and appointment carries conditionSeverity constrained to mild through critical, daysWaiting, and isFollowUp. **Sample request**_JSON_ { "patient": { "age": 72, "hasChronicCondition": true, "immunocompromised": false, "recentHospitalization": true }, "appointment": { "conditionSeverity": "moderate", "daysWaiting": 12, "isFollowUp": true } } _02_ ### Calculate Risk Factor Score _table_ Every true condition counts here because the hit policy is collect: patient.age > 65 contributes 10 points as 'Age over 65', a chronic condition 15, immunocompromised status 20, and a recent hospitalization 15, each row emitting a score and message pair into the riskFactors array via the outputPath. A 72-year-old with a chronic condition and recent discharge therefore banks three separate rows, not just the largest one. Weighting immunocompromised patients heaviest is clinically sound, since delayed care carries infection risk they cannot absorb, and scoring recent hospitalization reflects the care-management norm that timely post-discharge follow-up reduces readmissions. Age 65 is the conventional geriatric line; the 10/15/20 point values themselves are calibration choices for this scheduler. Condition Scorescore Reasonmessage patient.age > 65 10 'Age over 65' patient.hasChronicCondition 15 'Chronic condition' patient.immunocompromised 20 'Immunocompromised' patient.recentHospitalization 15 'Recent hospitalization' _03_ ### Risk Factor Summary _expression_ Collected rows get rolled up next: scores.riskFactors takes sum(map(riskFactors, #.score)), reasons.riskFactors keeps the messages with map(riskFactors, #.message), and the raw riskFactors array is nulled out. That puts the risk contribution into the same scores and reasons shape the severity and wait-time tables write into, so the final sum can treat all three alike. _scores.riskFactors_`sum(map(riskFactors, #.score))` _reasons.riskFactors_`map(riskFactors, #.message)` _riskFactors_`null` _04_ ### Evaluate Condition Severity _table_ Severity anchors the score: 'critical' is worth 50 and 'severe' 30 regardless of appointment.isFollowUp, while 'moderate' splits 20/15 and 'mild' splits 10/5 depending on whether the visit is a follow-up. First hit keeps the pairs unambiguous, and each row writes both scores.conditionSeverity and a plain-language reason. Making the top severity worth 50, more than double the largest risk-factor row, keeps clinical acuity the primary driver of scheduling rather than demographics. The follow-up bump for moderate and mild cases reflects continuity-of-care practice, where a lapsed follow-up after active treatment risks quiet deterioration; the exact point spread is a business calibration. Condition Severityappointment.conditionSeverity Is Follow Upappointment.isFollowUp Scorescores.conditionSeverity Reasonreasons.conditionSeverity 'critical' \- 50 'Critical condition' 'severe' \- 30 'Severe condition' 'moderate' true 20 'Moderate condition with follow-up' 'moderate' false 15 'Moderate condition' 'mild' true 10 'Mild condition with follow-up' 'mild' false 5 'Mild condition' _05_ ### Calculate Wait Time Score _table_ Waiting days convert to escalation points in descending bands: appointment.daysWaiting above 30 adds 25 as 'Excessive wait time (> 30 days)', above 14 adds 15, above 7 adds 10, above 3 adds 5, and the blank row scores 0 for 'Minimal wait time (0-3 days)'. Ordering from the largest threshold down is what makes the first hit policy pick the correct band. Aging-based escalation is the standard anti-starvation mechanism in access management: publicly funded systems publish maximum wait-time targets, and ratcheting priority with days waited is how schedulers keep low-acuity patients from being deferred indefinitely. The 3/7/14/30 breakpoints are operational choices that map naturally onto scheduling horizons of days, a week, a fortnight, and a month. Days Waitingappointment.daysWaiting Scorescores.waitTime Reasonreasons.waitTime \> 30 25 'Excessive wait time (> 30 days)' \> 14 15 'Long wait time (15-30 days)' \> 7 10 'Moderate wait time (8-14 days)' \> 3 5 'Short wait time (4-7 days)' \- 0 'Minimal wait time (0-3 days)' _06_ ### Calculate Total Priority Score _expression_ Aggregation is a single sum(values(scores)) into totalScore, with priorityFactors flattening the reasons lists into one audit trail. The reasons, patient, and appointment keys are then set to null, so what reaches priority assignment is just the number and the explanations that produced it. _totalScore_`sum(values(scores))` _priorityFactors_`flatten(values(reasons))` _reasons_`null` _patient_`null` _appointment_`null` _07_ ### Assign Priority Level _table_ Five bands translate totalScore into action: 85 or more is 'URGENT' with 'Schedule immediately', 60 or more 'HIGH' within 24-48 hours, 40 or more 'MEDIUM' within 1 week, 20 or more 'STANDARD' within 2 weeks, and anything below falls to 'LOW', scheduled as available. Both result.priority and result.recommendation come out of the same row, so the label and the timeframe can never disagree. The bands are sized against the upstream weights: a 'critical' condition alone (50 points) lands in MEDIUM, reaches HIGH with modest risk factors, and only hits URGENT when vulnerability or accumulated wait stacks on top, which keeps the top tier scarce enough to mean something. Fixed scheduling windows per tier match how clinics actually operationalize prioritization, though the specific cutoffs are program choices rather than mandated standards. Total ScoretotalScore Priorityresult.priority Recommendationresult.recommendation \>= 85 'URGENT' 'Schedule immediately' \>= 60 'HIGH' 'Schedule within 24-48 hours' \>= 40 'MEDIUM' 'Schedule within 1 week' \>= 20 'STANDARD' 'Schedule within 2 weeks' \- 'LOW' 'Schedule as available' ## Other Healthcare templates [View all templates](/templates) [_Healthcare_ ### Patient Triage System Rules-based medical triage system that prioritizes patients in emergency departments based on vital signs, symptoms, and chief complaints. ](/industries/healthcare/templates/patient-triage-system)[_Healthcare_ ### Clinical Pathway Selection Decision system that determines optimal treatment pathways based on diagnosis severity, comorbidities, and patient characteristics for personalized care plans. ](/industries/healthcare/templates/clinical-pathway-selection)[_Healthcare_ ### Medication Dosage Calculator Clinical decision system that calculates precise medication dosages based on patient weight, age, and organ function to maximize safety and efficacy. ](/industries/healthcare/templates/medication-dosage-calculator) ## Make this template your own. Load Medical Appointment Priority System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Insurance Prior Authorization - GoRules **URL:** https://gorules.io/industries/healthcare/templates/insurance-prior-authorization **Description:** Automated system that evaluates insurance requirements for medical services based on carrier rules, diagnosis codes, and service details. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Insurance Prior Authorization Automated system that evaluates insurance requirements for medical services based on carrier rules, diagnosis codes, and service details. Download template Share ### Solution This insurance authorization system streamlines healthcare administrative workflows by automatically determining when prior approval is needed for medical services. The solution evaluates multiple factors including the patient's insurance type (Medicaid, Medicare, or Commercial), specific diagnosis codes, service category, CPT/HCPCS codes, and associated costs. For each insurance type, the system applies carrier-specific rules to determine authorization requirements. Medicaid evaluations focus on service costs, with thresholds varying by service type. Medicare determinations analyze procedure codes and service categories, while Commercial insurance assessments include specialty medication indicators and specific procedure code lists. The system also identifies clinical exceptions where authorization requirements are waived, such as chemotherapy encounters, pregnancy-related services, and COVID-19 imaging studies, regardless of the initial determination. ### How it works The system follows a structured decision process: 1. **Input Processing**: Captures patient insurance information, diagnosis codes, service type, and details including CPT/HCPCS code, cost, and emergency status. 2. **Insurance Classification**: Routes the request to the appropriate ruleset based on insurance type (Medicaid, Medicare, or Commercial). 3. **Rule Application**: Applies carrier-specific criteria based on service type and details: - Medicaid: Evaluates service cost thresholds - Medicare: Reviews procedure codes and service categories - Commercial: Checks specific procedure lists and specialty designations 4. **Clinical Exclusion Review**: Examines diagnosis codes to identify exceptions that waive authorization requirements, such as chemotherapy, pregnancy, or COVID-19 related services. 5. **Final Determination**: Generates a timestamped decision with clear reasoning for the authorization requirement or exemption. ### Where teams use it - Hospital admissions departments - Outpatient imaging centers - Medical practice management - Insurance verification systems - Revenue cycle management - Pharmacy benefit management ## Inside the decision model Insurance Prior Authorization ships as a JDM decision graph with 7 nodes, 4 decision tables and 20 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_switch_ Insurance Type Check_table_ Medicaid Rules_table_ Medicare Rules_table_ Commercial Rules_table_ Diagnosis Code Exclusions_expression_ Final Determination _01_ ### Request _input_ Authorization requests carry four blocks: patientInfo.insuranceType (limited by the schema to Medicaid, Medicare, or Commercial), an array of diagnosisCodes, a serviceType, and serviceDetails holding the billing code, cost, and emergency flag. **Sample request**_JSON_ { "patientInfo": { "insuranceType": "Commercial" }, "diagnosisCodes": \[ "M54.5", "M51.26" \], "serviceType": "Imaging", "serviceDetails": { "code": "70551", "cost": 1200, "isEmergency": false } } _02_ ### Insurance Type Check _switch_ Carrier routing happens before any rule fires: patientInfo.insuranceType == 'Medicaid' takes the first branch, 'Medicare' the second, 'Commercial' the third, and an unconnected isDefault statement catches unrecognized carriers. Splitting by payer up front keeps each ruleset small enough to be owned by the team that manages that contract. _patientInfo.insuranceType == 'Medicaid'_ `Medicaid Rules` _patientInfo.insuranceType == 'Medicare'_ `Medicare Rules` _patientInfo.insuranceType == 'Commercial'_ `Commercial Rules` _otherwise_ _03_ ### Medicaid Rules _table_ Cost thresholds do most of the work in the Medicaid branch: 'Medication' over 200 and 'Procedure' over 500 require authorization, 'Equipment' over 300 triggers the 'DME over threshold' reason, and 'Imaging' requires authorization at any price since its serviceDetails.cost cell is empty. The final blank row returns requiresAuthorization false with the standard-service reason, and under the first hit policy it only fires when no service-specific row matched. State Medicaid programs run on constrained budgets and lean on utilization management harder than most payers, so dollar-threshold gates and blanket prior authorization for imaging are realistic levers. Durable medical equipment gets its own threshold because DME is a recurring focus of Medicaid program-integrity reviews; the specific 200/500/300 amounts are sensible plan-level choices rather than mandated figures. Service TypeserviceType CostserviceDetails.cost Requires AuthorizationrequiresAuthorization ReasonauthorizationReason 'Medication' \> 200 true 'High-cost medication requires prior authorization' 'Procedure' \> 500 true 'High-cost procedure requires prior authorization' 'Imaging' \- true 'All imaging services require prior authorization' 'Equipment' \> 300 true 'DME over threshold requires prior authorization' \- \- false 'Standard service does not require prior authorization' _04_ ### Medicare Rules _table_ Procedure codes, not prices, drive this branch. A 'Medication' whose code contains 'J' is flagged as a 'Part B medication', 'Imaging' codes that start with 'CT' or 'MRI' count as advanced imaging, and the 'Procedure' and 'Equipment' rows convert the code with number($) and compare it against 1000 and 500. Anything else drops to the blank row and clears as a standard Medicare service. J-codes are real HCPCS billing codes for drugs administered in clinical settings, which is the population Medicare Part B actually covers, and singling out CT and MRI mirrors how utilization management concentrates on advanced imaging rather than plain films. Treating the code itself as a number in the procedure and equipment rows is a simplified stand-in for the code-range lookups a production Medicare ruleset would maintain. Service TypeserviceType CodeserviceDetails.code Requires AuthorizationrequiresAuthorization ReasonauthorizationReason 'Medication' contains($, 'J') true 'Part B medication requires prior authorization' 'Procedure' number($) > 1000 true 'High-cost procedure requires prior authorization' 'Imaging' startsWith($, 'CT') or startsWith($, 'MRI') true 'Advanced imaging requires prior authorization' 'Equipment' number($) > 500 true 'DME over threshold requires prior authorization' \- \- false 'Standard Medicare service does not require prior authorization' _05_ ### Commercial Rules _table_ Explicit code lists define the commercial checks: 'Medication' codes containing 'SPE' mark specialty drugs, 'Procedure' matches the contiguous CPT block 33361 through 33364, and 'Imaging' matches 70450 through 70553, the head CT and brain MRI families that include the sample request's 70551. 'Equipment' switches back to a serviceDetails.cost > 1000 test, and two closing rows clear everything else: serviceDetails.isEmergency == true returns false with the emergency reason, and the final blank row clears standard services. Specialty-drug gating and short lists of high-cost procedures are the standard shape of commercial utilization management, and 33361 to 33364 are genuine transcatheter aortic valve replacement codes, the kind of intervention plans review case by case. The emergency carve-out reflects the prudent layperson standard that governs emergency coverage under the ACA, though in this table it only applies once no specific code rule has already fired. Service TypeserviceType Additional Check Requires AuthorizationrequiresAuthorization ReasonauthorizationReason 'Medication' contains(serviceDetails.code, 'SPE') true 'Specialty medication requires prior authorization' 'Procedure' serviceDetails.code in \['33361', '33362', '33363', '33364'\] true 'Specific procedures require prior authorization' 'Imaging' serviceDetails.code in \['70450', '70460', '70470', '70551', '70552', '70553'\] true 'Advanced imaging requires prior authorization' 'Equipment' serviceDetails.cost > 1000 true 'High-cost equipment requires prior authorization' \- serviceDetails.isEmergency == true false 'Emergency services do not require prior authorization' \- \- false 'Standard commercial service does not require prior authorization' _06_ ### Diagnosis Code Exclusions _table_ After the carrier tables run, this override scans the diagnosisCodes array with some() expressions: codes starting with 'Z51', the encounter-for-chemotherapy prefix, flip requiresAuthorization back to false, as do the O09.51 supervision-of-pregnancy codes, and 'U07.1' does the same when the second column confirms serviceType == 'Imaging'. Each exemption row also requires requiresAuthorization == true, and the final row passes requiresAuthorization and authorizationReason through untouched. Layering exemptions after the payer tables means they hold regardless of carrier, which is how clinical carve-outs work in practice: oncology and pregnancy care are time-sensitive, and delaying them for paperwork is a common target of prior-authorization reform. The codes are real ICD-10 entries, Z51 for chemotherapy encounters, O09.51 for supervision of pregnancy, and U07.1 as the COVID-19 diagnosis code, so coders can maintain the exemption list without touching payer logic. Diagnosis CodesdiagnosisCodes Current Authorization Status Final Authorization RequiredrequiresAuthorization Final ReasonauthorizationReason some($, startsWith(#, 'Z51')) requiresAuthorization == true false 'Encounter for chemotherapy exempt from prior authorization' some($, # in \['O09.511', 'O09.512', 'O09.513', 'O09.519'\]) requiresAuthorization == true false 'Pregnancy-related services exempt from prior authorization' some($, # in \['U07.1'\]) requiresAuthorization == true and serviceType == 'Imaging' false 'COVID-19 related imaging exempt from prior authorization' \- \- requiresAuthorization authorizationReason _07_ ### Final Determination _expression_ Output shrinks to three keys because passThrough is off: requiresAuthorization, the human-readable reason, and a timestamp set with date('now'). Recording when the determination was made matters for prior-authorization audit trails, where decision turnaround times can be contractually and legally bound. _requiresAuthorization_`requiresAuthorization` _reason_`authorizationReason` _timestamp_`date('now')` ## Other Healthcare templates [View all templates](/templates) [_Healthcare_ ### Patient Triage System Rules-based medical triage system that prioritizes patients in emergency departments based on vital signs, symptoms, and chief complaints. ](/industries/healthcare/templates/patient-triage-system)[_Healthcare_ ### Clinical Pathway Selection Decision system that determines optimal treatment pathways based on diagnosis severity, comorbidities, and patient characteristics for personalized care plans. ](/industries/healthcare/templates/clinical-pathway-selection)[_Healthcare_ ### Medication Dosage Calculator Clinical decision system that calculates precise medication dosages based on patient weight, age, and organ function to maximize safety and efficacy. ](/industries/healthcare/templates/medication-dosage-calculator) ## Make this template your own. Load Insurance Prior Authorization into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Clinical Trial Eligibility Screener - GoRules **URL:** https://gorules.io/industries/healthcare/templates/clinical-trial-eligibility-screener **Description:** Automated patient screening system that evaluates medical criteria to determine clinical trial eligibility based on multiple health factors. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Clinical Trial Eligibility Screener Automated patient screening system that evaluates medical criteria to determine clinical trial eligibility based on multiple health factors. Download template Share ### Solution This eligibility screening system streamlines the clinical trial recruitment process by automating patient qualification assessment. It evaluates candidates against six key medical criteria: diagnosis type, disease stage, current medications, age, treatment history, and comorbidities. The system flags patients with qualifying diagnoses (breast, lung, or colorectal cancer) while excluding those with advanced stage IV disease. The screening tool identifies medication conflicts that could compromise trial outcomes, particularly immunosuppressants, anticancer agents, and corticosteroids. Age verification ensures patients fall within the 18-75 year trial parameters. Treatment history analysis prevents enrollment of heavily pre-treated patients, limiting prior treatments to two or fewer. The system also screens for disqualifying comorbidities including autoimmune disorders, heart failure, and uncontrolled diabetes, providing detailed justification for each eligibility determination. ### How it works The eligibility assessment follows this process: 1. **Input Collection**: Captures comprehensive patient data including diagnosis, disease stage, current medications, age, prior treatments, and comorbidities. 2. **Diagnosis Verification**: Validates if the patient's condition matches targeted cancer types (breast, lung, colorectal). 3. **Stage Evaluation**: Confirms disease progression is within acceptable parameters (stages I-III). 4. **Medication Screening**: Identifies contraindicated medications that would exclude participation. 5. **Age Validation**: Verifies patient age falls within protocol-defined range. 6. **Treatment History**: Ensures limited prior therapy exposure (≤2 treatments). 7. **Comorbidity Assessment**: Screens for exclusionary concurrent medical conditions. 8. **Eligibility Determination**: Aggregates all criteria results to produce a final eligibility decision with detailed reasoning. ### Where teams use it - Clinical research organizations - Pharmaceutical trial management - Hospital research departments - Oncology centers - Medical research institutions - Patient recruitment services ## Inside the decision model Clinical Trial Eligibility Screener ships as a JDM decision graph with 8 nodes, 6 decision tables and 14 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ patient_table_ diagnosisEligibility_table_ diseaseStageEligibility_table_ medicationEligibility_table_ ageEligibility_table_ priorTreatmentEligibility_table_ comorbidityEligibility_expression_ eligibilitySummary _01_ ### Patient _input_ One patient object carries all six screened attributes, diagnosis, diseaseStage, currentMedications, age, priorTreatments, and comorbidities, and the graph fans it out to six criterion checks that run in parallel before the summary merges their flags. **Sample request**_JSON_ { "patient": { "id": "P67890", "name": "John Smith", "age": 68, "diagnosis": "lung\_cancer", "diseaseStage": "IV", "currentMedications": \[ "immunosuppressants", "albuterol", "omeprazole" \], "priorTreatments": 3, "comorbidities": \[ "autoimmune\_disease", "COPD" \], "lastLabResults": { "wbc": 3.8, "hgb": 10.9, "plt": 150, "creatinine": 1.2 } } } _02_ ### Diagnosis Eligibility _table_ Qualifying cancers are enumerated directly: a patient.diagnosis of 'breast\_cancer', 'lung\_cancer', or 'colorectal\_cancer' sets eligibility.diagnosis.flag true, and anything else falls to the false row with 'Diagnosis does not match trial criteria'. Enumerating target indications is exactly how oncology protocols define their study population, so this list is the first thing a protocol amendment would touch. Diagnosispatient.diagnosis DiagnosisFlageligibility.diagnosis.flag DiagnosisReasoneligibility.diagnosis.reason 'breast\_cancer', 'lung\_cancer', 'colorectal\_cancer' true 'Diagnosis matches trial criteria' \- false 'Diagnosis does not match trial criteria' _03_ ### Disease Stage Eligibility _table_ Stages 'I', 'II', and 'III' pass with 'Disease stage matches trial criteria', 'IV' is rejected by its own row with 'Stage IV patients excluded from trial', and the blank fallback fails safe with 'Unknown or invalid disease stage'. Giving stage IV a dedicated row means the reason string names the actual exclusion instead of a generic mismatch. Excluding metastatic disease from a stage I to III protocol reflects standard trial design, since stage IV patients differ in prognosis and treatment intent and are typically studied under separate protocols. Failing closed on an unknown stage is sound screening practice as well: eligibility must be demonstrated rather than assumed, which is how research coordinators treat incomplete records. Stagepatient.diseaseStage StageFlageligibility.stage.flag StageReasoneligibility.stage.reason 'I', 'II', 'III' true 'Disease stage matches trial criteria' 'IV' false 'Stage IV patients excluded from trial' \- false 'Unknown or invalid disease stage' _04_ ### Medication Eligibility _table_ A some($, # in \['immunosuppressants', 'anticancer\_agents', 'corticosteroids'\]) check over patient.currentMedications ?? \[\] fails the criterion with 'Patient taking excluded medications'; otherwise the empty row passes with 'No conflicting medications'. These three classes are classic prohibited-medication entries because immunosuppression and concurrent anticancer therapy would confound both the safety and efficacy readouts the trial exists to measure. Medicationspatient.currentMedications ?? \[\] MedicationFlageligibility.medication.flag MedicationReasoneligibility.medication.reason some($, # in \['immunosuppressants', 'anticancer\_agents', 'corticosteroids'\]) false 'Patient taking excluded medications' \- true 'No conflicting medications' _05_ ### Age Eligibility _table_ The )18..75( condition matches values outside the interval, so any patient.age beyond 18 to 75 fails with 'Age outside eligible range (18-75)' while everyone else passes. An adult 18-to-75 window is typical protocol design, anchored by consent age at the bottom and rising competing health risks at the top, though the specific ceiling is a sponsor choice rather than a regulation. PatientAgepatient.age AgeFlageligibility.age.flag AgeReasoneligibility.age.reason )18..75( false 'Age outside eligible range (18-75)' \- true 'Age within eligible range' _06_ ### Prior Treatment Eligibility _table_ More than 2 patient.priorTreatments fails the check as 'Too many prior treatments', a count of 2 or fewer passes as an 'Acceptable number of prior treatments', and a missing value passes through its own row with 'No prior treatments recorded'. Splitting the pass into two rows keeps the reason strings honest about whether a history was actually reviewed. Capping prior lines of therapy is standard oncology-trial design: heavily pre-treated patients respond differently and carry accumulated toxicity, which muddies attribution of the study drug's effect. A limit of two or fewer prior treatments is a common shape for this criterion, but the exact number is protocol-specific rather than mandated by any regulator. PriorTreatmentspatient.priorTreatments TreatmentFlageligibility.priorTreatment.flag TreatmentReasoneligibility.priorTreatment.reason \> 2 false 'Too many prior treatments' <= 2 true 'Acceptable number of prior treatments' \- true 'No prior treatments recorded' _07_ ### Comorbidity Eligibility _table_ Exclusionary conditions are matched with some($, # in \['autoimmune\_disease', 'heart\_failure', 'uncontrolled\_diabetes'\]) over patient.comorbidities ?? \[\], failing with 'Excluded comorbidity present' or passing as 'No exclusionary comorbidities'. All three are realistic oncology exclusions: autoimmune disease interacts badly with immunotherapy, and uncontrolled cardiac or metabolic disease raises the odds that adverse events obscure the drug's own safety signal. Comorbiditiespatient.comorbidities ?? \[\] ComorbidityFlageligibility.comorbidity.flag ComorbidityReasoneligibility.comorbidity.reason some($, # in \['autoimmune\_disease', 'heart\_failure', 'uncontrolled\_diabetes'\]) false 'Excluded comorbidity present' \- true 'No exclusionary comorbidities' _08_ ### Eligibility Summary _expression_ Aggregation is strict conjunction: isEligible takes all(values(eligibility), #.flag), so one failed criterion disqualifies the patient. failedCriteria filters keys(eligibility) for flags equal to false, eligibilityReasons preserves every reason for the audit trail, and decisionSummary renders 'Patient is eligible for clinical trial' or its negative, the line recruitment staff read first. _isEligible_`all(values(eligibility), #.flag)` _eligibilityReasons_`filter(values(eligibility), #.reason != null)` _decisionSummary_`$.isEligible ? 'Patient is eligible for clinical trial' : 'Patient is not eligible for clinical trial'` _failedCriteria_`filter(keys(eligibility), eligibility[#].flag == false)` ## Other Healthcare templates [View all templates](/templates) [_Healthcare_ ### Patient Triage System Rules-based medical triage system that prioritizes patients in emergency departments based on vital signs, symptoms, and chief complaints. ](/industries/healthcare/templates/patient-triage-system)[_Healthcare_ ### Clinical Pathway Selection Decision system that determines optimal treatment pathways based on diagnosis severity, comorbidities, and patient characteristics for personalized care plans. ](/industries/healthcare/templates/clinical-pathway-selection)[_Healthcare_ ### Medication Dosage Calculator Clinical decision system that calculates precise medication dosages based on patient weight, age, and organ function to maximize safety and efficacy. ](/industries/healthcare/templates/medication-dosage-calculator) ## Make this template your own. Load Clinical Trial Eligibility Screener into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Clinical Treatment Protocol - GoRules **URL:** https://gorules.io/industries/healthcare/templates/clinical-treatment-protocol **Description:** Decision system that selects personalized medical treatments based on diagnosis, patient characteristics, and risk factors for optimal healthcare outcomes. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Clinical Treatment Protocol Decision system that selects personalized medical treatments based on diagnosis, patient characteristics, and risk factors for optimal healthcare outcomes. Download template Share ### Solution This healthcare decision system determines optimal treatment protocols by evaluating multiple patient-specific factors. It begins by classifying condition severity based on diagnostic measurements, such as blood glucose levels for diabetes or peak flow for asthma. The system then factors in patient demographics, identifying special considerations for elderly, pediatric, or pregnant patients. Risk assessment is performed by analyzing comorbidities and previous adverse reactions, automatically adjusting treatment intensity and follow-up frequency based on risk levels. The system generates comprehensive treatment protocols that include appropriate medication selection, dosage modifications, monitoring requirements, and follow-up schedules. This ensures treatments are tailored to each patient's unique clinical profile while adhering to evidence-based guidelines. ### How it works The decision graph processes patient information through six key evaluation steps: 1. **Diagnosis Evaluation**: Classifies condition severity and determines baseline treatment approach based on measurement values (HbA1c for diabetes, blood pressure for hypertension, etc.). 2. **Patient Factor Analysis**: Evaluates age and pregnancy status to determine risk category and appropriate dosage modifications. 3. **Comorbidity Evaluation**: Assesses additional health conditions and previous adverse reactions to calculate overall risk level. 4. **Intensity Determination**: Sets the treatment protocol intensity based on the patient's risk profile. 5. **Follow-up Planning**: Establishes appropriate monitoring frequency ranging from weekly to quarterly checkups. 6. **Treatment Protocol Assembly**: Combines all decisions into a final personalized treatment plan with specific instructions for medication, dosing, monitoring, and follow-up care. ### Where teams use it - Primary care clinics for standardized treatment selection - Hospital systems implementing evidence-based protocols - Clinical decision support for new practitioners - Telemedicine platforms for consistent remote care - Medical training and education simulation - Rural healthcare settings with limited specialist access ## Inside the decision model Clinical Treatment Protocol ships as a JDM decision graph with 7 nodes, 5 decision tables and 28 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ diagnosisEvaluation_table_ patientFactors_table_ comorbidityEvaluation_table_ intensityDetermination_table_ followUpDetermination_expression_ finalTreatmentSelection _01_ ### Request _input_ Two scalars and a patient object drive the whole graph: diagnosis names the condition, measurement\_value carries the diagnosis-specific reading (HbA1c, systolic pressure, or peak flow), and patient holds age plus yes/no strings for pregnancy, comorbidities, and prior adverse reactions. **Sample request**_JSON_ { "diagnosis": "diabetes\_type2", "measurement\_value": 8.2, "patient": { "age": 67, "is\_pregnant": "no", "has\_comorbidities": "yes", "previous\_adverse\_reaction": "no" } } _02_ ### Diagnosis Evaluation _table_ Severity is read off diagnosis plus measurement\_value, with first hit resolving the bands. 'diabetes\_type2' splits at readings below 7.0 ('mild\_diabetes', 'lifestyle\_modification'), 7.0 to 8.5 ('moderate\_diabetes', 'oral\_medication'), and above 8.5 ('severe\_diabetes', 'insulin\_therapy'); 'hypertension' maps \[140..160) to 'stage1\_hypertension' with 'lifestyle\_and\_monotherapy' and 160 or higher to 'dual\_therapy'; 'asthma' inverts the direction since higher peak flow is better, grading above 80 as mild and below 60 as 'severe\_asthma' on 'multiple\_controllers'. An unmatched diagnosis lands on 'unclassified' with 'standard\_care'. The bands track real guideline structure: an HbA1c below 7.0 is the common glycemic target in type 2 diabetes care, and escalating from lifestyle change to oral agents to insulin follows standard stepwise therapy. The 140 and 160 systolic cutoffs match the stage 1 and stage 2 boundaries used in international hypertension guidance, where stage 2 typically starts on two agents, and the 80 percent peak-flow line sits where asthma action plans draw their green zone; the 60 percent split below it is a model calibration. Diagnosisdiagnosis MeasurementValuemeasurement\_value Severitydiagnosis\_severity BaseTreatmentbase\_treatment 'diabetes\_type2' < 7.0 'mild\_diabetes' 'lifestyle\_modification' 'diabetes\_type2' \[7.0..8.5\] 'moderate\_diabetes' 'oral\_medication' 'diabetes\_type2' \> 8.5 'severe\_diabetes' 'insulin\_therapy' 'hypertension' \[140..160) 'stage1\_hypertension' 'lifestyle\_and\_monotherapy' 'hypertension' \>= 160 'stage2\_hypertension' 'dual\_therapy' 'asthma' \> 80 'mild\_asthma' 'as\_needed\_bronchodilator' +3 more rows in the downloadable template _03_ ### Patient Factors _table_ Age pairs with pregnancy status here, most specific row first: a patient of 65 or older who is pregnant maps to a 'high' patient\_risk\_category with 'reduced\_dosage', 65 or older otherwise gets 'moderate' and 'standard\_elderly', under 18 becomes 'special' with 'pediatric\_dosage', pregnancy at any other age yields 'elevated' with 'monitor\_closely', and everyone else passes as 'standard' with 'standard\_dosage'. Using 65 as the geriatric line reflects the conventional cutoff in geriatric pharmacology, where reduced renal and hepatic clearance argues for dose caution, and carving out under-18s acknowledges that pediatric dosing is a separate discipline rather than a scaled-down adult dose. Flagging pregnancy for closer monitoring is standard practice given teratogenicity and physiologic changes; the specific category labels are model vocabulary. Agepatient.age Pregnancypatient.is\_pregnant PatientRiskCategorypatient\_risk\_category DosageModificationdosage\_modification \>= 65 'yes' 'high' 'reduced\_dosage' \>= 65 'no' 'moderate' 'standard\_elderly' < 18 \- 'special' 'pediatric\_dosage' \- 'yes' 'elevated' 'monitor\_closely' \- \- 'standard' 'standard\_dosage' _04_ ### Comorbidity Evaluation _table_ Comorbidity history and prior adverse reactions form a complete two-by-two grid, so no default row is needed: 'yes' on both has\_comorbidities and previous\_adverse\_reaction returns 'critical' with a 'specialist\_consult', comorbidities alone return 'high' with 'modified\_treatment', a reaction alone returns 'moderate' with 'additional\_monitoring', and 'no' on both returns 'low' with 'standard\_approach'. Escalating a documented adverse reaction plus comorbidity to specialist review mirrors pharmacovigilance practice, since re-exposing a complex patient to a drug class that already caused harm is exactly the situation where protocolized care should hand off to a clinician. The exhaustive grid is also good rule hygiene: every combination is stated explicitly instead of leaking into a catch-all. HasComorbiditiespatient.has\_comorbidities PreviousAdverseReactionpatient.previous\_adverse\_reaction ComorbidityRiskLevelcomorbidity\_risk\_level RiskAdjustmentrisk\_adjustment 'yes' 'yes' 'critical' 'specialist\_consult' 'yes' 'no' 'high' 'modified\_treatment' 'no' 'yes' 'moderate' 'additional\_monitoring' 'no' 'no' 'low' 'standard\_approach' _05_ ### Intensity Determination _table_ A single-column lookup translates comorbidity\_risk\_level into a care intensity: 'critical' becomes 'urgent', 'high' becomes 'intensive', 'moderate' becomes 'standard', 'low' becomes 'routine', and the blank fallback row emits 'regular'. Keeping this translation in its own table is a maintainability choice rather than a clinical rule: governance can rename or remap intensity tiers without touching the risk logic upstream, and the fallback guarantees the assembled protocol always carries an intensity value. RiskLevelcomorbidity\_risk\_level ProtocolIntensityprotocol\_intensity 'critical' 'urgent' 'high' 'intensive' 'moderate' 'standard' 'low' 'routine' \- 'regular' _06_ ### Follow Up Determination _table_ Visit cadence keys off the same comorbidity\_risk\_level: 'critical' patients are seen 'weekly', 'high' 'bi-weekly', 'moderate' 'monthly', 'low' 'quarterly', and anything unmatched defaults to 'as\_needed'. Scaling follow-up frequency inversely with risk is the standard shape of chronic-disease management, where stable patients get quarterly reviews and unstable ones weekly contact; the specific cadences here are program-level choices rather than mandated intervals. RiskLevelcomorbidity\_risk\_level FollowUpSchedulefollow\_up\_schedule 'critical' 'weekly' 'high' 'bi-weekly' 'moderate' 'monthly' 'low' 'quarterly' \- 'as\_needed' _07_ ### Final Treatment Selection _expression_ Assembly happens last: protocol\_name concatenates base\_treatment + '\_' + patient\_risk\_category, and treatment\_protocol packages a protocol\_id built from that name plus protocol\_intensity together with the dosage, risk adjustment, follow-up, and severity fields. With passThrough off, callers receive one self-describing plan object instead of the intermediate scoring fields. _protocol\_name_`base_treatment + '_' + patient_risk_category` _treatment\_protocol_``{ 'protocol_id': `${$.protocol_name}_${protocol_intensity}`, 'base_treatment': base_treatment, 'dosage_instruction': dosage_modification, 'risk_adjustment': risk_adjustment, 'follow_up_frequency': follow_up_schedule, 'severity_level': diagnosis_severity, 'protocol_intensity': protocol_intensity }`` ## Other Healthcare templates [View all templates](/templates) [_Healthcare_ ### Patient Triage System Rules-based medical triage system that prioritizes patients in emergency departments based on vital signs, symptoms, and chief complaints. ](/industries/healthcare/templates/patient-triage-system)[_Healthcare_ ### Clinical Pathway Selection Decision system that determines optimal treatment pathways based on diagnosis severity, comorbidities, and patient characteristics for personalized care plans. ](/industries/healthcare/templates/clinical-pathway-selection)[_Healthcare_ ### Medication Dosage Calculator Clinical decision system that calculates precise medication dosages based on patient weight, age, and organ function to maximize safety and efficacy. ](/industries/healthcare/templates/medication-dosage-calculator) ## Make this template your own. Load Clinical Treatment Protocol into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Clinical Pathway Selection - GoRules **URL:** https://gorules.io/industries/healthcare/templates/clinical-pathway-selection **Description:** Decision system that determines optimal treatment pathways based on diagnosis severity, comorbidities, and patient characteristics for personalized care plans. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Clinical Pathway Selection Decision system that determines optimal treatment pathways based on diagnosis severity, comorbidities, and patient characteristics for personalized care plans. Download template Share ### Solution This clinical pathway selection system guides healthcare providers in choosing appropriate treatment regimens tailored to individual patient needs. The system evaluates primary diagnosis and severity score to determine the clinical domain and establish a base risk assessment. It factors in comorbidities, giving special attention to high-risk conditions like kidney disease, COPD, and immunocompromised status to calculate additional risk factors. The evaluation includes patient-specific factors such as age and BMI to further refine risk stratification. Based on comprehensive risk scoring, the system recommends one of three care pathways: standard, enhanced, or intensive, each with specific follow-up frequencies and monitoring requirements. This ensures patients receive proportionate care based on their clinical needs, optimizing resource allocation while maintaining quality care standards. ### How it works The decision graph evaluates patients through multiple assessment nodes: 1. **Initial Diagnosis Assessment**: Categorizes the primary diagnosis (heart failure, pneumonia, diabetes, stroke) into clinical domains and assigns a base risk score. 2. **Comorbidity Evaluation**: Counts total comorbidities and identifies high-risk conditions (kidney disease, COPD, immunocompromised status) to calculate a comorbidity risk score. 3. **Patient Factor Analysis**: Evaluates age and BMI to determine additional risk factors and assigns a patient risk category. 4. **Pathway Selection**: Uses the total risk score to route patients to one of three treatment pathways: - Intensive Pathway: Daily follow-up with comprehensive monitoring for high-risk patients - Enhanced Pathway: Twice-weekly follow-up with extended monitoring for moderate-risk patients - Standard Pathway: Weekly follow-up with basic monitoring for lower-risk patients ### Where teams use it - Primary care management of chronic conditions - Hospital discharge planning and follow-up protocols - Integrated care coordination for complex patients - Remote patient monitoring program design - Clinical resource allocation optimization - Standardization of care for common diagnoses - Risk stratification for population health management ## Inside the decision model Clinical Pathway Selection ships as a JDM decision graph with 8 nodes, 2 decision tables and 12 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ diagnosisEvaluation_expression_ comorbidityEvaluation_table_ patientFactorsEvaluation_switch_ pathwaySelection_expression_ standardPathway_expression_ enhancedPathway_expression_ intensivePathway _01_ ### Request _input_ A single patient object supplies everything the graph needs: primaryDiagnosis and severityScore feed the first table, comorbidities feed the risk expression, and age and bmi feed the patient-factor table, while medications, vital signs, and labs pass through as context. **Sample request**_JSON_ { "patient": { "id": "P1234567", "primaryDiagnosis": "heart\_failure", "severityScore": 3, "age": 72, "bmi": 24, "comorbidities": \[ "diabetes", "hypertension", "kidney\_disease" \], "currentMedications": \[ { "name": "Lisinopril", "dosage": "10mg", "frequency": "daily" }, { "name": "Metformin", "dosage": "500mg", "frequency": "twice daily" }, { "name": "Furosemide", "dosage": "40mg", "frequency": "daily" } \], "vitalSigns": { "bloodPressure": { "systolic": 142, "diastolic": 85 }, "heartRate": 88, "oxygenSaturation": 94, "temperature": 37.1 }, "labResults": { "bnp": 450, "creatinine": 1.4, "potassium": 4.2, "hba1c": 7.8 } } } _02_ ### Diagnosis Evaluation _table_ Pairs of patient.primaryDiagnosis and patient.severityScore map each condition to a clinical domain and a base risk, first hit wins. 'heart\_failure' with severity above 2 scores 8 in the 'cardiac' domain against 5 otherwise, 'pneumonia' splits 7/4 in 'respiratory', 'diabetes' splits 6/3 in 'endocrine' with its severe cut at 8.5, 'stroke' carries the steepest scores of 9 and 6 in 'neurological', and anything unlisted lands in 'general' with a base of 2. Putting stroke and decompensated heart failure at the top of the base-risk ladder is consistent with how care-management programs stratify: both drive high readmission rates and need early follow-up, and CMS readmission measures specifically target heart failure and pneumonia. The severity splits themselves (2, 1, 8.5, 1) are calibration choices for this model rather than published cutoffs. Primary Diagnosispatient.primaryDiagnosis Severity Scorepatient.severityScore Clinical Domainevaluation.clinicalDomain Base Risk Scoreevaluation.baseRiskScore 'heart\_failure' \> 2 'cardiac' 8 'heart\_failure' \- 'cardiac' 5 'pneumonia' \> 1 'respiratory' 7 'pneumonia' \- 'respiratory' 4 'diabetes' \> 8.5 'endocrine' 6 'diabetes' \- 'endocrine' 3 +3 more rows in the downloadable template _03_ ### Comorbidity Evaluation _expression_ Four chained expressions build the running risk total: comorbidityCount takes len(patient.comorbidities ?? \[\]), hasHighRiskComorbidity flags 'kidney\_disease', 'copd', or 'immunocompromised', and comorbidityRiskScore weights the count at 2 points each plus 3 for any high-risk hit. The final totalRiskScore adds that to evaluation.baseRiskScore, so multimorbidity compounds the diagnosis risk before pathway selection. _comorbidityCount_`len(patient.comorbidities ?? [])` _hasHighRiskComorbidity_`contains(patient.comorbidities ?? [], 'kidney_disease') or contains(patient.comorbidities ?? [], 'copd') or contains(patient.comorbidities ?? [], 'immunocompromised')` _comorbidityRiskScore_`$.comorbidityCount * 2 + ($.hasHighRiskComorbidity ? 3 : 0)` _totalRiskScore_`evaluation.baseRiskScore + $.comorbidityRiskScore` _04_ ### Patient Factors Evaluation _table_ Age and BMI act together in each row: a patient over 80 with a BMI under 20 adds 3 to evaluation.additionalRiskScore and gets a 'high' patientRiskCategory, over 70 with BMI under 25 adds 2 as 'moderate', and everyone else passes with 0 as 'standard'. Because the hit policy is first, a very old underweight patient never falls into the milder row. Pairing advanced age with low BMI is deliberate: in geriatric assessment, being underweight is a recognized marker of frailty and malnutrition, and it predicts complications far more strongly in an 80-year-old than in a younger adult. The exact 80/20 and 70/25 cutoffs are practical stratification choices rather than a formal frailty index. Agepatient.age BMIpatient.bmi Additional Risk Scoreevaluation.additionalRiskScore Patient Risk Categoryevaluation.patientRiskCategory \> 80 < 20 3 'high' \> 70 < 25 2 'moderate' \- \- 0 'standard' _05_ ### Pathway Selection _switch_ Routing runs on total burden: a totalRiskScore + evaluation.additionalRiskScore of 12 or more branches to the intensive path, 8 or more to enhanced, and the isDefault statement sends everything else to standard. Ordering matters because the first hit policy checks the highest threshold first, so a score of 14 never reaches the enhanced branch. _totalRiskScore + evaluation.additionalRiskScore >= 12_ `Intensive Pathway` _totalRiskScore + evaluation.additionalRiskScore >= 8_ `Enhanced Pathway` _otherwise_ `Standard Pathway` _06_ ### Standard Pathway _expression_ Low-risk patients get the lightest plan: selectedPathway 'standard', a 'weekly' followupFrequency, and recommendedMonitoring limited to 'basic\_vitals' and 'medication\_adherence'. Keeping this branch minimal reserves clinical time for the two higher tiers. _selectedPathway_`'standard'` _followupFrequency_`'weekly'` _recommendedMonitoring_`['basic_vitals', 'medication_adherence']` _07_ ### Enhanced Pathway _expression_ Moderate scorers move to 'twice\_weekly' follow-up with recommendedMonitoring extended to 'lifestyle\_factors' on top of vitals and adherence checks. This middle tier lets a rising-risk patient be watched more closely without committing daily-visit resources. _selectedPathway_`'enhanced'` _followupFrequency_`'twice_weekly'` _recommendedMonitoring_`['extended_vitals', 'medication_adherence', 'lifestyle_factors']` _08_ ### Intensive Pathway _expression_ High-risk patients are seen 'daily' with 'comprehensive\_vitals', 'lifestyle\_factors', and a 'specialist\_consultation' added to the monitoring list. Gating the intensive tier at a combined score of 12 keeps its resource cost proportional to genuine clinical need. _selectedPathway_`'intensive'` _followupFrequency_`'daily'` _recommendedMonitoring_`['comprehensive_vitals', 'medication_adherence', 'lifestyle_factors', 'specialist_consultation']` ## Other Healthcare templates [View all templates](/templates) [_Healthcare_ ### Patient Triage System Rules-based medical triage system that prioritizes patients in emergency departments based on vital signs, symptoms, and chief complaints. ](/industries/healthcare/templates/patient-triage-system)[_Healthcare_ ### Medication Dosage Calculator Clinical decision system that calculates precise medication dosages based on patient weight, age, and organ function to maximize safety and efficacy. ](/industries/healthcare/templates/medication-dosage-calculator)[_Healthcare_ ### Insurance Prior Authorization Automated system that evaluates insurance requirements for medical services based on carrier rules, diagnosis codes, and service details. ](/industries/healthcare/templates/insurance-prior-authorization) ## Make this template your own. Load Clinical Pathway Selection into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Clinical Lab Results Interpreter - GoRules **URL:** https://gorules.io/industries/healthcare/templates/clinical-lab-result-interpreter **Description:** Automated system that evaluates laboratory test results against patient context to determine abnormalities and urgent follow-up actions. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Clinical Lab Results Interpreter Automated system that evaluates laboratory test results against patient context to determine abnormalities and urgent follow-up actions. Download template Share ### Solution This clinical decision support system analyzes laboratory test results to flag abnormal values and recommend appropriate follow-up actions. The solution evaluates key lab parameters such as glucose, potassium, hemoglobin, and creatinine against established medical thresholds, identifying critical values that require immediate intervention versus those needing routine monitoring. The system enhances clinical decision-making by incorporating patient-specific context, including medical conditions, current medications, and known allergies. For patients with diabetes, the system evaluates glucose readings alongside medication regimens to assess risk levels. Similarly, for patients with kidney conditions, creatinine values trigger specialized recommendations. Based on this comprehensive analysis, the solution assigns urgency levels to each case-from routine to urgent-providing clear guidance on required follow-up timeframes and actions, ensuring critical abnormalities receive prompt attention while preventing unnecessary escalations. ### How it works The decision system follows a structured evaluation process: 1. **Lab Data Input**: Processes incoming test results along with patient history including existing conditions, medications, and allergies. 2. **Basic Lab Evaluation**: Analyzes each test result against standard clinical thresholds to identify abnormal or critical values. 3. **Patient Context Analysis**: Evaluates abnormal results within the context of the patient's medical history and current medications. 4. **Risk Assessment**: Assigns risk levels based on the combination of test results and patient-specific factors. 5. **Urgency Determination**: Classifies cases from routine to urgent based on the presence of critical values and risk assessment. 6. **Follow-up Recommendation**: Provides specific action steps and timeframes for clinical follow-up, ranging from immediate provider notification to routine review at next visit. ### Where teams use it - Primary care clinics processing daily lab results - Hospital settings for inpatient monitoring - Specialty clinics managing chronic disease patients - Telehealth platforms for remote patient monitoring - Emergency departments for rapid triage of lab results - Clinical laboratories for automated flagging of critical values ## Inside the decision model Clinical Lab Results Interpreter ships as a JDM decision graph with 5 nodes, 4 decision tables and 19 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ labResults_table_ basicLabEvaluation_table_ patientContextEvaluation_table_ urgencyAssessment_table_ followUpDetermination _01_ ### Lab Results _input_ Lab data arrives as a testResults array, each entry carrying a testType, value, and date, plus a patientHistory object whose conditions, medications, and allergies later put abnormal readings into clinical context. **Sample request**_JSON_ { "testResults": \[ { "testType": "glucose", "value": 260, "date": "2025-03-15" }, { "testType": "potassium", "value": 3.2, "date": "2025-03-15" }, { "testType": "hemoglobin", "value": 10.2, "date": "2025-03-15" }, { "testType": "creatinine", "value": 1.7, "date": "2025-03-15" } \], "patientHistory": { "conditions": \[ "diabetes", "hypertension" \], "medications": \[ "metformin", "lisinopril", "atorvastatin" \], "allergies": \[ "penicillin" \] } } _02_ ### Basic Lab Evaluation _table_ Each entry in testResults is evaluated separately because the table runs in loop mode over that array, writing flag, condition, and recommendation back onto every result. Potassium below 3.5 or above 6.0 is 'critical' ('Hypokalemia', 'Hyperkalemia') with urgent electrolyte and cardiac-monitoring guidance, glucose below 70 is critical 'Hypoglycemia' while above 200 is 'abnormal' 'Hyperglycemia', hemoglobin outside 8.5 to 18.0 flags 'Anemia' or 'Polycythemia', and creatinine above 1.5 flags 'Elevated Creatinine' with a prompt to reassess kidney function and dosing. The thresholds sit at recognized reference-range boundaries: 70 is the standard hypoglycemia line and 3.5 the lower limit of normal potassium, and reserving the 'critical' flag for potassium and low glucose reflects the arrhythmia and neuroglycopenia risks that develop within hours. Automated flagging of this kind supports the critical-results reporting that laboratory accreditation and Joint Commission patient-safety goals require, though the exact cutoffs here are template simplifications of a lab's own critical-value list. Valuevalue Test TypetestType Flagflag Conditioncondition Recommendationrecommendation < 3.5 'potassium' 'critical' 'Hypokalemia' 'Urgent electrolyte replacement; ECG monitoring required' \> 6.0 'potassium' 'critical' 'Hyperkalemia' 'Urgent intervention required; cardiac monitoring advised' < 8.5 'hemoglobin' 'abnormal' 'Anemia' 'Evaluate for blood loss or chronic disease' \> 18.0 'hemoglobin' 'abnormal' 'Polycythemia' 'Evaluate for underlying conditions' \> 200 'glucose' 'abnormal' 'Hyperglycemia' 'Monitor closely; adjust diabetes management if applicable' < 70 'glucose' 'critical' 'Hypoglycemia' 'Immediate glucose administration; evaluate medication regimen' +1 more row in the downloadable template _03_ ### Patient Context Evaluation _table_ Condition, medication, and result combine in each row: 'diabetes' in patientHistory.conditions plus a glucose-lowering drug ('metformin', 'insulin', 'glipizide') and a glucose above 250 yields 'high-risk' with follow-up inside 48 hours; 'heart\_failure' pairs 'furosemide' or 'spironolactone' with a potassium reading above 3.0 to trigger electrolyte replacement and a diuretic review; 'kidney\_disease' with creatinine above 2.0 calls for a nephrology consult; and 'warfarin' with an INR above 3.5 holds the next dose and watches for bleeding. There is no default row, so riskAssessment.level only appears when a recognized pattern fires. Drug-lab interaction checks like these are standard clinical pharmacology: diuretics disturb potassium in both directions, furosemide wasting it and spironolactone retaining it, so heart failure patients on them get the tightest electrolyte scrutiny, and holding warfarin for a supratherapeutic INR above 3.5 matches routine anticoagulation-clinic protocol. The 250 and 2.0 cutoffs are stricter follow-up triggers than the generic flags upstream, which is the point: known chronic disease lowers the bar for action. ConditionpatientHistory.conditions MedicationspatientHistory.medications Additional condition Risk LevelriskAssessment.level Clinical RecommendationriskAssessment.clinicalRecommendation 'diabetes' in $ some($, # in \['metformin', 'insulin', 'glipizide'\]) some(testResults, #.testType == 'glucose' and #.value > 250) 'high-risk' 'Schedule follow-up within 48 hours; consider insulin adjustment' 'heart\_failure' in $ some($, # in \['furosemide', 'spironolactone'\]) some(testResults, #.testType == 'potassium' and #.value > 3.0) 'high-risk' 'Urgent electrolyte replacement; evaluate diuretic dosage' 'kidney\_disease' in $ \- some(testResults, #.testType == 'creatinine' and #.value > 2.0) 'high-risk' 'Nephrology consult; adjust medication dosages' \- 'warfarin' in $ some(testResults, #.testType == 'inr' and #.value > 3.5) 'high-risk' 'Hold next warfarin dose; monitor for bleeding' _04_ ### Urgency Assessment _table_ Escalation runs on the derived flags: some(testResults, #.flag == 'critical') maps straight to 'urgent', riskAssessment.level == 'high-risk' to 'high', any 'abnormal' flag to 'moderate', and the empty final row to 'routine'. Row order encodes precedence, so a critical lab value outranks the patient-context assessment no matter what it concluded. Collapsing everything into a single four-tier urgencyLevel mirrors how critical-value escalation works in practice, where a panic value always takes priority over chronic-disease context, and it gives downstream consumers one field to route on. Four tiers rather than a numeric score is a sensible business choice that keeps the follow-up table trivially auditable. Condition Urgency LevelurgencyLevel some(testResults, #.flag == 'critical') 'urgent' riskAssessment.level == 'high-risk' 'high' some(testResults, #.flag == 'abnormal') 'moderate' \- 'routine' _05_ ### Follow Up Determination _table_ Timeframes attach last: 'urgent' cases require 'Immediate provider notification required' within '24 hours', 'high' recommends notification within '72 hours', 'moderate' folds into routine review inside '1 week', and 'routine' waits for the 'Next scheduled visit'. Both outputs land under followUp, giving the caller an action and a deadline in one place. Putting explicit windows on follow-up reflects how clinics operationalize results-management policies, where notification and review times are documented and auditable rather than left to individual judgment. The specific 24-hour and 72-hour windows are program-level choices, tightened or relaxed per organization rather than set by regulation. UrgencyurgencyLevel Action RequiredfollowUp.actionRequired TimeframefollowUp.timeframe 'urgent' 'Immediate provider notification required' '24 hours' 'high' 'Provider notification recommended' '72 hours' 'moderate' 'Include in routine provider review' '1 week' 'routine' 'No immediate action required' 'Next scheduled visit' ## Other Healthcare templates [View all templates](/templates) [_Healthcare_ ### Patient Triage System Rules-based medical triage system that prioritizes patients in emergency departments based on vital signs, symptoms, and chief complaints. ](/industries/healthcare/templates/patient-triage-system)[_Healthcare_ ### Clinical Pathway Selection Decision system that determines optimal treatment pathways based on diagnosis severity, comorbidities, and patient characteristics for personalized care plans. ](/industries/healthcare/templates/clinical-pathway-selection)[_Healthcare_ ### Medication Dosage Calculator Clinical decision system that calculates precise medication dosages based on patient weight, age, and organ function to maximize safety and efficacy. ](/industries/healthcare/templates/medication-dosage-calculator) ## Make this template your own. Load Clinical Lab Results Interpreter into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Care Team Assignment System - GoRules **URL:** https://gorules.io/industries/healthcare/templates/care-team-assignment-system **Description:** Automated system for assigning optimal healthcare providers to patients based on medical conditions, age, care complexity, and personal needs. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Care Team Assignment System Automated system for assigning optimal healthcare providers to patients based on medical conditions, age, care complexity, and personal needs. Download template Share ### Solution This intelligent care coordination system transforms the patient-provider matching process by creating personalized care teams based on comprehensive assessment of patient needs. The system evaluates each patient's medical conditions, age demographics, mobility limitations, and care complexity to determine the optimal mix of healthcare providers. For patients with multiple chronic conditions like diabetes or heart disease, the system automatically incorporates appropriate specialists. When mental health needs are identified, psychiatric professionals are seamlessly included. The system accounts for patient mobility scores, requiring physical therapy integration when necessary, while also considering language preferences to eliminate communication barriers. Advanced complexity scoring ensures high-needs patients receive additional support through care coordinators, creating right-sized teams that balance comprehensive care with efficiency. This systematic approach eliminates manual provider selection, reduces care gaps, and ensures every patient receives appropriate specialized attention. ### How it works The decision graph processes patient information through these key steps: 1. **Complexity Assessment**: Evaluates the patient's care complexity level (high, medium, low) and determines appropriate team size 2. **Age Categorization**: Classifies patients as pediatric, adult, or senior to match with age-appropriate providers 3. **Needs Evaluation**: Identifies specific requirements including specialist care for chronic conditions, mental health support, nutrition guidance, and mobility assistance 4. **Provider Assignment**: Matches qualified healthcare professionals based on the patient's conditions, applying appropriate priority levels to each role 5. **Coordination Determination**: For complex cases with multiple providers, adds a care coordinator or case manager to ensure integrated care delivery ### Where teams use it - Hospital discharge planning and transition management - Primary care practices managing complex chronic conditions - Integrated health systems with diverse specialist networks - Home health agencies assigning appropriate care resources - Telehealth networks matching remote providers to patient needs - Long-term care facilities optimizing staffing assignments ## Inside the decision model Care Team Assignment System ships as a JDM decision graph with 6 nodes, 4 decision tables and 22 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ determine\_complexity_table_ age\_category_expression_ evaluate\_patient\_needs_table_ assign\_providers_table_ assign\_coordinator _01_ ### Request _input_ Three request blocks come in: a patient record with careComplexity, mobilityScore, a conditions list, and care preferences, a facility descriptor, and an availableProviders roster whose roles, specialties, and languages describe who could staff the team. **Sample request**_JSON_ { "patient": { "id": "PT12345", "name": "John Smith", "age": 67, "gender": "male", "careComplexity": "high", "mobilityScore": 35, "conditions": \[ "diabetes", "heart\_disease", "hypertension", "depression" \], "primaryLanguage": "english", "insuranceType": "medicare", "carePreferences": { "preferredGender": "any", "preferredLanguage": "english", "requiresTranslator": false } }, "facility": { "id": "FAC789", "name": "Memorial Medical Center", "department": "Internal Medicine" }, "availableProviders": \[ { "id": "DR001", "name": "Dr. Sarah Johnson", "role": "primary\_physician", "specialties": \[ "internal\_medicine", "geriatrics" \], "languages": \[ "english", "spanish" \] }, { "id": "DR002", "name": "Dr. Michael Chen", "role": "cardiologist", "specialties": \[ "cardiology" \], "languages": \[ "english", "mandarin" \] }, { "id": "DR003", "name": "Dr. Lisa Peterson", "role": "diabetes\_specialist", "specialties": \[ "endocrinology" \], "languages": \[ "english" \] }, { "id": "NP001", "name": "Nancy Williams", "role": "nurse\_practitioner", "specialties": \[ "primary\_care" \], "languages": \[ "english" \] }, { "id": "RN001", "name": "Robert Garcia", "role": "nurse", "specialties": \[ "geriatric\_care" \], "languages": \[ "english", "spanish" \] }, { "id": "MH001", "name": "Dr. Emily Cohen", "role": "mental\_health\_provider", "specialties": \[ "psychiatry", "geriatric\_psychiatry" \], "languages": \[ "english" \] }, { "id": "PT001", "name": "James Wilson", "role": "physical\_therapist", "specialties": \[ "geriatric\_physical\_therapy" \], "languages": \[ "english" \] }, { "id": "CC001", "name": "Maria Rodriguez", "role": "care\_coordinator", "specialties": \[ "complex\_care\_coordination" \], "languages": \[ "english", "spanish" \] } \] } _02_ ### Determine Complexity _table_ Care intensity maps one-to-one here: patient.careComplexity values of "high", "medium", and "low" set careTeam.complexityLevel and a teamSize of "3", "2", or "1", and a blank fallback row repeats the low result so a missing complexity value never blocks assignment. Tiering team size to a three-level complexity flag mirrors how care-management programs size caseloads, with high-complexity patients justifying a multi-provider team while stable ones keep a single clinician. Defaulting the unknown case to the smallest team is a conservative operational choice that avoids over-committing scarce staff before an assessment confirms need. Care Complexitypatient.careComplexity Complexity LevelcareTeam.complexityLevel Team SizecareTeam.teamSize "high" "high" "3" "medium" "medium" "2" "low" "low" "1" \- "low" "1" _03_ ### Age Category _table_ Age brackets stay minimal: patient.age under 18 maps to "pediatric", under 65 to "adult", and the blank fallback row labels everyone else "senior". Because rows resolve first-match, the middle row effectively covers 18 through 64 without stating both bounds. The 18 and 65 boundaries are the customary edges of pediatric and geriatric medicine, with 65 also aligning to Medicare eligibility in the US, and the categories translate directly into staffing since the provider table keys on ageCategory to add a geriatric specialist or a pediatrician. Publishing the bracket as its own field keeps that downstream rule readable. Patient agepatient.age Age categoryageCategory < 18 "pediatric" < 65 "adult" \- "senior" _04_ ### Evaluate Patient Needs _expression_ Need flags get precomputed before matching: requiresSpecialist scans patient.conditions for 'diabetes', 'heart\_disease', or 'kidney\_disease', requiresMentalHealthSupport for 'depression', 'anxiety', or 'ptsd', requiresNutritionSupport for 'obesity', 'diabetes', or 'malnutrition', and mobilityIssues fires when patient.mobilityScore < 50. The same node then nulls patient, availableProviders, and facility, slimming the payload down to the derived flags and the careTeam object. _requiresSpecialist_`some(patient.conditions, # in ['diabetes', 'heart_disease', 'kidney_disease'])` _requiresMentalHealthSupport_`some(patient.conditions, # in ['depression', 'anxiety', 'ptsd'])` _requiresNutritionSupport_`some(patient.conditions, # in ['obesity', 'diabetes', 'malnutrition'])` _mobilityIssues_`patient.mobilityScore < 50` _patient_`null` _availableProviders_`null` _facility_`null` _05_ ### Assign Providers _table_ Collect turns this table into a roster builder: every matching row appends a role, priority, and specialtyFocus entry into careTeam.providers. Complexity picks the backbone, pairing a "primary\_physician" with a "nurse\_practitioner" at "high" priority for high-complexity patients versus a physician-and-nurse pair at "medium" for lower tiers, while ageCategory == "senior" or "pediatric" adds a "geriatric\_specialist" or "pediatrician". Condition rows contribute a "diabetes\_specialist", "cardiologist", or "nephrologist" at high priority with a matching specialtyFocus, and the derived flags pull in a "mental\_health\_provider", "nutritionist", or "physical\_therapist". Team composition tracks the patient-centered medical home model, where a primary clinician and nursing support form the core and specialists attach per condition. Escalating diabetes, cardiac, and renal disease to named specialist roles reflects chronic-disease co-management norms, and staffing physical therapy off a mobility score below 50 or behavioral health off a depression diagnosis mirrors how integrated-care programs plan for functional and mental health needs, not just diagnoses. The priority labels exist for downstream schedulers, not as clinical rankings from any regulation. Complexity LevelcareTeam.complexityLevel Patient Condition Provider Rolerole Prioritypriority Specialty FocusspecialtyFocus "high" \- "primary\_physician" "high" \- "medium", "low" \- "primary\_physician" "medium" \- \- ageCategory == "senior" "geriatric\_specialist" "medium" \- \- ageCategory == "pediatric" "pediatrician" "medium" \- \- "diabetes" in patient.conditions "diabetes\_specialist" "high" "diabetes" \- "heart\_disease" in patient.conditions "cardiologist" "high" "heart\_disease" +6 more rows in the downloadable template _06_ ### Assign Coordinator _table_ Oversight is assigned last: "high" complexity with len(careTeam.providers) > 5 earns a dedicated "care\_coordinator" at high priority, any remaining high or medium case gets a "case\_manager", and low-complexity teams record "none". First hit ordering means the coordinator row is tested before the broader case-manager row can claim a complex patient. Adding a coordinator only when the roster exceeds five providers is realistic: fragmentation and handoff risk grow with team size, and absorbing that overhead is what coordination roles in programs like Medicare chronic care management exist to do. Splitting coordinator from case manager by caseload intensity is a sensible operational distinction rather than a regulatory requirement. Complexity LevelcareTeam.complexityLevel Team Size$ Coordinator RolecareTeam.coordinator.role Coordinator PrioritycareTeam.coordinator.priority "high" len(careTeam.providers) > 5 "care\_coordinator" "high" "high", "medium" \- "case\_manager" "medium" \- \- "none" "low" ## Other Healthcare templates [View all templates](/templates) [_Healthcare_ ### Patient Triage System Rules-based medical triage system that prioritizes patients in emergency departments based on vital signs, symptoms, and chief complaints. ](/industries/healthcare/templates/patient-triage-system)[_Healthcare_ ### Clinical Pathway Selection Decision system that determines optimal treatment pathways based on diagnosis severity, comorbidities, and patient characteristics for personalized care plans. ](/industries/healthcare/templates/clinical-pathway-selection)[_Healthcare_ ### Medication Dosage Calculator Clinical decision system that calculates precise medication dosages based on patient weight, age, and organ function to maximize safety and efficacy. ](/industries/healthcare/templates/medication-dosage-calculator) ## Make this template your own. Load Care Team Assignment System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Financial Transaction Compliance Classifier - GoRules **URL:** https://gorules.io/industries/financial/templates/transaction-compliance-classifier **Description:** Automated system that classifies financial transactions, assigns risk scores, identifies compliance issues, and determines regulatory reporting requirements. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Financial Transaction Compliance Classifier Automated system that classifies financial transactions, assigns risk scores, identifies compliance issues, and determines regulatory reporting requirements. Download template Share ### Solution This solution streamlines financial regulatory compliance by automatically classifying transactions based on type and amount, applying appropriate jurisdiction-specific rules, and calculating comprehensive risk scores. It evaluates multiple risk factors including transaction amount, priority level, customer risk profile, suspicious activity history, and jurisdiction requirements. The system flags potential compliance issues through detailed condition checking that identifies incomplete KYC verification, high-risk jurisdictions, suspicious activity patterns, potential structuring, and unusual transaction behavior. For each identified issue, it generates specific alerts with descriptive reasons. The solution determines precise reporting deadlines, form requirements, and filing urgency based on risk assessment and compliance flags, enabling financial institutions to prioritize high-risk transactions for immediate review while maintaining standard monitoring for lower-risk activities. ### How it works The decision graph processes financial transactions through these key components: 1. **Transaction Classification**: Determines priority level and report type based on transaction type and amount. 2. **Jurisdiction Rules**: Applies specific regulatory requirements based on customer jurisdiction and report type. 3. **Risk Score Calculation**: Computes a comprehensive risk score considering transaction amount, priority, customer risk status, suspicious activity history, and jurisdiction. 4. **Regulatory Threshold Evaluation**: Determines if compliance review is required based on risk score and priority. 5. **Compliance Issue Identification**: Detects potential regulatory issues including incomplete KYC, high-risk jurisdictions, suspicious patterns, structuring, and unusual activity. 6. **Reporting Requirement Determination**: Sets reporting deadlines, identifies required forms, and establishes filing urgency based on risk level and compliance flags. ### Where teams use it - Banking transaction monitoring - Anti-money laundering (AML) compliance - Know Your Customer (KYC) verification - Securities trading compliance - Cryptocurrency transaction monitoring - Cross-border payment screening - Cash transaction reporting - Suspicious activity detection - Regulatory filing management - Financial risk assessment ## Inside the decision model Financial Transaction Compliance Classifier ships as a JDM decision graph with 7 nodes, 4 decision tables and 22 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ classify\_transaction_table_ apply\_jurisdiction\_rules_expression_ calculate\_risk\_score_table_ regulatory\_thresholds_table_ identify\_compliance\_issues_expression_ determine\_reporting\_requirements _01_ ### Request _input_ The transaction block supplies the type, amount, and flags like structuring\_suspected, while the customer block adds jurisdiction, kyc\_verified status, risk indicators, and normal\_activity\_patterns for behavioral comparison. **Sample request**_JSON_ { "transaction": { "id": "TX123456789", "type": "cash\_deposit", "amount": 15000, "date": "2025-03-15T10:30:00Z", "currency": "USD", "description": "Business cash deposit", "high\_risk\_country": false, "structuring\_suspected": false }, "customer": { "id": "CUST98765", "name": "Acme Corporation", "type": "business", "jurisdiction": "US", "kyc\_verified": true, "high\_risk": false, "suspicious\_activity\_count": 0, "normal\_activity\_patterns": \[ "cash\_deposit", "domestic\_wire", "check\_deposit" \], "account\_opening\_date": "2020-01-15", "risk\_category": "medium" } } _02_ ### Classify Transaction _table_ Type and amount pairs assign priority and paperwork under a first hit policy: a 'cash\_deposit' over 10000 is 'high\_priority' with a 'CTR', an 'international\_wire' over 3000 maps to 'FBAR', a 'securities\_trade' over 5000 to 'SEC\_REPORT', a 'crypto\_transaction' over 3000 to a 'high\_priority' 'CRYPTO\_SAR', and any 'structured\_deposit' straight to 'SAR' with no amount test. Domestic wires over 10000 file a 'WIRE\_REPORT' at 'low\_priority', and everything else falls to 'standard' and 'STANDARD'. The 10000 cash threshold is the genuine Bank Secrecy Act trigger for a Currency Transaction Report, and routing suspected structured deposits directly to a SAR reflects that structuring is itself reportable regardless of amount. The 3000 and 5000 thresholds on wires, securities, and crypto are tighter than statutory minimums, a conservative screening choice that surfaces activity for review before it reaches mandatory reporting levels. Transaction Typetransaction.type Amounttransaction.amount Priorityclassification.priority Report Typeclassification.report\_type 'cash\_deposit' \> 10000 'high\_priority' 'CTR' 'international\_wire' \> 3000 'medium\_priority' 'FBAR' 'securities\_trade' \> 5000 'medium\_priority' 'SEC\_REPORT' 'crypto\_transaction' \> 3000 'high\_priority' 'CRYPTO\_SAR' 'structured\_deposit' \- 'high\_priority' 'SAR' 'domestic\_wire' \> 10000 'low\_priority' 'WIRE\_REPORT' +1 more row in the downloadable template _03_ ### Apply Jurisdiction Rules _table_ Reporting mechanics come from crossing customer.jurisdiction with the classification.report\_type: a 'US' 'CTR' allows 15 days on 'FinCEN Form 112' with a jurisdiction score of 15, a 'US' 'SAR' 30 days on 'FinCEN Form 111', 'EU' cases get 10 days on the 'EU Suspicious Transaction Report', 'UK' cases 7 days on an 'NCA SAR', and the default grants 30 days on a 'Standard Reporting Form' with the lowest score of 5. The US rows match actual FinCEN practice: Form 112 is the Currency Transaction Report with a 15-day filing window, and Form 111 is the Suspicious Activity Report, generally due within 30 days of detection. UK suspicious activity reports really are filed with the National Crime Agency; the day counts on the EU row and the jurisdiction scores are the template's own risk weighting rather than a single statutory figure. Jurisdictioncustomer.jurisdiction Report Typeclassification.report\_type Days to Reportreporting.days\_to\_report Form Namereporting.form\_name Jurisdiction Scorerisk.jurisdiction\_score 'US' 'CTR' 15 'FinCEN Form 112' 15 'US' 'SAR' 30 'FinCEN Form 111' 30 'EU' 'CTR', 'SAR' 10 'EU Suspicious Transaction Report' 10 'UK' 'CTR', 'SAR' 7 'NCA SAR' 10 \- \- 30 'Standard Reporting Form' 5 _04_ ### Calculate Risk Score _expression_ Additive scoring builds total\_risk\_score from five parts: amount\_score steps 5/10/15/25 at the 5000, 10000, and 50000 marks, priority\_score gives 'high\_priority' 25 points, customer\_score adds 20 for a high\_risk customer, transaction\_history\_score adds up to 20 as suspicious\_activity\_count grows, and the jurisdiction score from the previous table completes the sum. Keeping each factor a separate key makes the final score auditable term by term. _base\_risk\_score_`0` _amount\_score_`transaction.amount > 50000 ? 25 : (transaction.amount > 10000 ? 15 : (transaction.amount > 5000 ? 10 : 5))` _priority\_score_`classification.priority == 'high_priority' ? 25 : (classification.priority == 'medium_priority' ? 15 : 5)` _customer\_score_`customer.high_risk == true ? 20 : 0` _transaction\_history\_score_`customer.suspicious_activity_count > 2 ? 20 : (customer.suspicious_activity_count > 0 ? 10 : 0)` _total\_risk\_score_`$.base_risk_score + $.amount_score + $.priority_score + $.customer_score + $.transaction_history_score + risk.jurisdiction_score` _05_ ### Regulatory Thresholds _table_ Review necessity resolves from score and priority together: a total\_risk\_score over 75 combined with 'high\_priority' demands immediate review, over 60 requires compliance review at any priority, and scores in the \[40..60\] band only escalate when the priority is high. The two remaining rows return requires\_review false with standard monitoring messaging. Two-dimensional cutoffs like this are how monitoring teams triage alert queues: pure score thresholds either flood analysts or miss context, so priority acts as a tiebreaker in the ambiguous middle band. The 40/60/75 boundaries are tuning parameters an institution would calibrate against its own alert volumes, not values fixed by regulation. Risk Scoretotal\_risk\_score Priorityclassification.priority Requires Reviewcompliance.requires\_review Review Reasoncompliance.review\_reason \> 75 'high\_priority' true 'Requires immediate review - High risk score and priority' \> 60 \- true 'High risk score requires compliance review' \[40..60\] 'high\_priority' true 'Medium risk score with high priority requires review' \[40..60\] \- false 'Medium risk score - standard monitoring' \- \- false 'Standard monitoring - no flags' _06_ ### Identify Compliance Issues _table_ Because the hit policy is collect, every matching condition appends a flag object to compliance.flags: 'KYC\_INCOMPLETE' when transaction.amount > 10000 and customer.kyc\_verified != true, 'HIGH\_RISK\_JURISDICTION' for amounts over 5000 touching a high\_risk\_country, 'PATTERN\_ALERT' when prior suspicious\_activity\_count exists on transactions over 3000, 'STRUCTURING' whenever structuring\_suspected is true, and 'UNUSUAL\_ACTIVITY' for amounts over 50000 outside customer.normal\_activity\_patterns. These mirror the red flags AML programs actually monitor: unverified identity on large transactions, exposure to high-risk jurisdictions, repeat suspicious behavior, structuring below reporting thresholds, and out-of-pattern activity are all staples of transaction monitoring typologies. Emitting typed flags with descriptions, rather than one boolean, gives case management systems the detail needed to open targeted investigations. Condition 1 Condition 2 Flag Raisedraised Flag Typetype Flag Descriptiondescription transaction.amount > 10000 customer.kyc\_verified != true true 'KYC\_INCOMPLETE' 'Customer KYC verification incomplete for large transaction' transaction.amount > 5000 transaction.high\_risk\_country == true true 'HIGH\_RISK\_JURISDICTION' 'Transaction involves high-risk jurisdiction' customer.suspicious\_activity\_count > 0 transaction.amount > 3000 true 'PATTERN\_ALERT' 'Multiple suspicious activities detected with customer' transaction.structuring\_suspected == true \- true 'STRUCTURING' 'Potential structuring activity detected' transaction.amount > 50000 !contains(customer.normal\_activity\_patterns ?? \[\], transaction.type) true 'UNUSUAL\_ACTIVITY' 'Transaction outside of normal customer activity patterns' _07_ ### Determine Reporting Requirements _expression_ Deadlines and urgency are finalized here: reporting\_deadline adds reporting.days\_to\_report (as seconds, days \* 86400) to the transaction date, requires\_immediate\_filing fires when review is required or flags coincide with 'high\_priority', and reporting\_status grades the case as 'urgent\_filing\_required', 'filing\_required', or 'standard\_reporting'. The report\_instructions string names the form and window, such as 'File ' + reporting.form\_name + ' within 24 hours', so compliance staff receive an actionable directive. _reporting\_deadline_`date(transaction.date) + (reporting.days_to_report * 86400)` _has\_compliance\_flags_`len(compliance.flags ?? []) > 0` _requires\_immediate\_filing_`compliance.requires_review == true or ($.has_compliance_flags and classification.priority == 'high_priority')` _reporting\_status_`$.requires_immediate_filing ? 'urgent_filing_required' : ($.has_compliance_flags ? 'filing_required' : 'standard_reporting')` _report\_instructions_`$.requires_immediate_filing ? 'File ' + reporting.form_name + ' within 24 hours' : 'File ' + reporting.form_name + ' within ' + string(reporting.days_to_report) + ' days'` ## Other Financial templates [View all templates](/templates) [_Financial_ ### Loan Approval Automated system that evaluates credit scores, income, debt ratios, and employment history to determine mortgage eligibility and personalized interest rates. ](/industries/financial/templates/loan-approval)[_Financial_ ### Real-Time Fraud Detection Advanced transaction monitoring system that identifies suspicious financial activities using location analysis, spending patterns, and behavioral anomalies. ](/industries/financial/templates/realtime-fraud-detection)[_Financial_ ### Customer Onboarding KYC Verification Automated compliance checks that validate identity documents, screen against watchlists, and apply risk-based due diligence during onboarding. ](/industries/financial/templates/customer-onboarding-kyc-verification) ## Make this template your own. Load Financial Transaction Compliance Classifier into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Smart Financial Product Matcher - GoRules **URL:** https://gorules.io/industries/financial/templates/smart-financial-product-matcher **Description:** Personalized banking product recommendations based on credit score and income, matching customers with the right financial products for their unique situation. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Smart Financial Product Matcher Personalized banking product recommendations based on credit score and income, matching customers with the right financial products for their unique situation. Download template Share ### Solution This intelligent recommendation system helps financial institutions match customers with appropriate products by analyzing key customer data points. It evaluates credit scores against defined thresholds, categorizing them as excellent, good, fair, or poor. The system similarly assesses annual income, classifying it as high, medium, or low based on predetermined ranges. By combining these financial profile elements, the system generates targeted product recommendations tailored to each customer's specific situation. High-credit customers with substantial income receive premium offerings like wealth management services, while those building credit are matched with secured cards and credit-builder loans. Each recommendation includes personalized messaging that explains the benefits and value proposition, helping customers understand why specific products align with their needs and financial standing. ### How it works The financial product matching process follows three key evaluation steps: 1. **Credit Evaluation**: Analyzes the customer's credit score and assigns a category (excellent: 750+, good: 700-749, fair: 650-699, poor: below 650). 2. **Income Assessment**: Evaluates annual income against defined thresholds (high: $120,000+, medium: $60,000-$119,999, low: below $60,000). 3. **Product Matching**: Combines credit and income categories to recommend appropriate financial products from the institution's portfolio. 4. **Personalized Messaging**: Generates customized recommendation text explaining why the suggested products are suitable for the customer's financial profile. The system maintains all customer information while adding these evaluations and recommendations, ensuring a complete customer context is preserved throughout the process. ### Where teams use it - Digital banking platforms and mobile apps - In-branch financial consultation tools - Customer onboarding optimization - Cross-selling campaigns for existing customers - Targeted marketing initiatives - Financial advisory services ## Inside the decision model Smart Financial Product Matcher ships as a JDM decision graph with 4 nodes, 3 decision tables and 13 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ customerProfile_table_ evaluateCreditScore_table_ evaluateIncome_table_ recommendProducts _01_ ### Customer Profile _input_ Everything rides in a single customerProfile object; the two fields that actually drive the tables are creditScore and annualIncome, with the rest (financialGoals, riskTolerance, existingProducts) preserved as context for whoever consumes the recommendation. **Sample request**_JSON_ { "customerProfile": { "customerId": "C12345", "name": "Jane Smith", "age": 35, "creditScore": 720, "annualIncome": 85000, "employmentStatus": "employed", "existingProducts": \[ "checking\_account" \], "financialGoals": \[ "home\_purchase", "retirement\_savings" \], "riskTolerance": "moderate" } } _02_ ### Evaluate Credit Score _table_ Scores collapse into four labels with a first hit policy reading top down: 750 and above is 'excellent', 700 and above 'good', 650 and above 'fair', and the empty catch-all row makes everything below 650 'poor'. Only creditCategory is added by this table; the raw creditScore passes through untouched. The bands sit where consumer credit tiers are conventionally drawn, with the mid-700s widely treated as the boundary of top-tier pricing and the mid-600s as the edge of near-prime. Coarse labels are the right granularity for product matching, since a marketing decision does not need the precision an underwriting scorecard would. Credit ScorecreditScore Credit CategorycreditCategory \>= 750 'excellent' \>= 700 'good' \>= 650 'fair' \- 'poor' _03_ ### Evaluate Income _table_ Income compresses to three levels: 120000 and above returns 'high', 60000 and above 'medium', and the catch-all row labels the remainder 'low'. With first hit ordering, the open-ended '>= 60000' row is only reached once the high band has failed, so each customer gets exactly one incomeCategory. The 60000 and 120000 breakpoints are business calibration, roughly bracketing median household income territory on the low side and comfortable premium-product territory on the high side. Two thresholds are enough because income only refines the credit-led matching in the next table rather than driving it. Annual IncomeannualIncome Income CategoryincomeCategory \>= 120000 'high' \>= 60000 'medium' \- 'low' _04_ ### Recommend Products _table_ Credit and income categories cross to pick a product basket: 'excellent' with 'high' income earns the premium set including 'wealth\_management' and 'high\_yield\_savings', 'good' credit at 'high' or 'medium' income maps to 'rewards\_credit\_card', 'personal\_loan', and 'investment\_account', while 'fair' credit swaps in 'secured\_credit\_card' and 'credit\_builder\_loan'. 'poor' credit at any income and any credit at 'low' income both land on starter products like 'basic\_checking', and each row pairs its list with a tailored recommendationMessage. Matching product risk to customer standing is basic suitability practice: secured cards and credit-builder loans are the industry's standard rehabilitation path because they cap issuer exposure while still reporting payment history, and wealth management only makes sense for high-income, high-score clients. Keeping the message text in the table means compliance can review exactly what each segment is told. Credit CategorycreditCategory Income CategoryincomeCategory Recommended ProductsrecommendedProducts Recommendation MessagerecommendationMessage 'excellent' 'high' \['premium\_credit\_card', 'investment\_account', 'high\_yield\_savings', 'wealth\_management'\] 'You qualify for our premium services with competitive rates and exclusive benefits.' 'excellent' 'medium' \['rewards\_credit\_card', 'investment\_account', 'high\_yield\_savings'\] 'You qualify for our premium credit products and investment services.' 'good' 'high', 'medium' \['rewards\_credit\_card', 'personal\_loan', 'investment\_account'\] 'Based on your good credit and income, we recommend these financial products.' 'fair' 'high', 'medium' \['secured\_credit\_card', 'savings\_account', 'credit\_builder\_loan'\] 'These products can help you build credit while meeting your financial needs.' 'poor' \- \['secured\_credit\_card', 'basic\_checking', 'credit\_builder\_loan'\] 'Start rebuilding your credit with these financial tools.' \- 'low' \['basic\_checking', 'savings\_account', 'secured\_credit\_card'\] 'These accounts have minimal fees and are designed to help you manage your finances.' ## Other Financial templates [View all templates](/templates) [_Financial_ ### Loan Approval Automated system that evaluates credit scores, income, debt ratios, and employment history to determine mortgage eligibility and personalized interest rates. ](/industries/financial/templates/loan-approval)[_Financial_ ### Real-Time Fraud Detection Advanced transaction monitoring system that identifies suspicious financial activities using location analysis, spending patterns, and behavioral anomalies. ](/industries/financial/templates/realtime-fraud-detection)[_Financial_ ### Customer Onboarding KYC Verification Automated compliance checks that validate identity documents, screen against watchlists, and apply risk-based due diligence during onboarding. ](/industries/financial/templates/customer-onboarding-kyc-verification) ## Make this template your own. Load Smart Financial Product Matcher into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Real-Time Fraud Detection - GoRules **URL:** https://gorules.io/industries/financial/templates/realtime-fraud-detection **Description:** Advanced transaction monitoring system that identifies suspicious financial activities using location analysis, spending patterns, and behavioral anomalies. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Real-Time Fraud Detection Advanced transaction monitoring system that identifies suspicious financial activities using location analysis, spending patterns, and behavioral anomalies. Download template Share ### Solution This fraud detection system provides immediate identification of potentially suspicious financial transactions by examining multiple risk factors simultaneously. The solution analyzes transaction location against the customer's home country and travel history to spot geographic anomalies. It compares current transaction amounts with established spending patterns, flagging values that significantly exceed historical averages or maximum thresholds. The system evaluates transaction timing, identifying unusual activity during non-standard hours, and monitors transaction frequency to detect rapid successive purchases that may indicate fraudulent behavior. Each transaction receives a calculated risk score with clear reason codes, enabling immediate action for high-risk transactions while minimizing interruptions for legitimate activity. This balanced approach helps financial institutions reduce fraud losses while maintaining positive customer experiences by limiting false positives. ### How it works The fraud detection graph processes transactions through several key evaluation steps: 1. **Input Processing**: Captures transaction details (amount, location, time) and user profile data (home country, spending patterns, frequent locations). 2. **Location Analysis**: Compares transaction location against customer's home country and frequently visited locations. 3. **Amount Verification**: Evaluates transaction value against customer's average and maximum historical spending. 4. **Time Pattern Matching**: Identifies transactions occurring outside normal activity hours. 5. **Frequency Monitoring**: Detects unusual patterns of multiple transactions in short timeframes. 6. **Risk Scoring**: Calculates a numeric risk score based on combined risk factors. 7. **Decision Logic**: Determines whether to allow, flag for review, or block transactions based on configured thresholds. ### Where teams use it - Credit card transaction monitoring - Bank transfer fraud detection - E-commerce payment protection - Mobile payment security - Cross-border transaction validation - ATM withdrawal monitoring - Corporate expense anomaly detection - New account fraud prevention ## Inside the decision model Real-Time Fraud Detection ships as a JDM decision graph with 3 nodes, 1 decision table and 7 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ detectSuspiciousActivity_expression_ calculateRiskScore _01_ ### Request _input_ Two objects arrive in the request: transaction, with the amount, location, time, and recentCount under evaluation, and userProfile, which supplies the customer's baseline of homeCountry, frequentCountries, averageTransactionAmount, and usual activity hours. **Sample request**_JSON_ { "transaction": { "id": "tx-28473", "amount": 1250, "location": "Germany", "time": "23:45", "recentCount": 4, "merchantCategory": "Electronics", "date": "2023-03-18" }, "userProfile": { "id": "user-5932", "homeCountry": "USA", "frequentCountries": \[ "Canada", "UK" \], "averageTransactionAmount": 350, "maxTransactionAmount": 800, "usualMerchantCategories": \[ "Groceries", "Dining", "Retail" \], "usualTransactionTimeRange": \[ "08:00", "21:00" \] } } _02_ ### Detect Suspicious Activity _table_ Seven rows run under a first hit policy, ordered so the strongest combinations win: a transaction.amount over 4x userProfile.averageTransactionAmount with recentCount > 3 scores 80, an unusual transaction.location (outside userProfile.homeCountry and frequentCountries) combined with an amount over 3x average scores 75, and a foreign transaction at night between time('22:00') and time('06:00') with an amount over 2x average scores 65, all flagged 'high'. Milder single-signal rows score 50 and 45 as 'medium', and the empty catch-all returns 0 with 'low' and 'No suspicious patterns detected'. Layering geography, spend deviation, timing, and velocity is how card issuers actually monitor transactions, since no single signal separates fraud from travel or a large purchase. The multiplier approach (2x to 4x of the customer's own average) adapts thresholds to each profile instead of using a fixed dollar cap, which keeps false positives down for high spenders; the specific multipliers are business calibration rather than any regulatory standard. Transaction Locationtransaction.location Transaction Amounttransaction.amount Transaction Timetransaction.time Recent Transactions Counttransaction.recentCount Risk Scorefraud.riskScore Risk Flagfraud.flag Risk Reasonfraud.reason != userProfile.homeCountry and != userProfile.frequentCountries \> userProfile.averageTransactionAmount \* 3 \- \- 75 'high' 'Unusual location with amount significantly above average' != userProfile.homeCountry \> userProfile.averageTransactionAmount \* 2 time($) > time('22:00') and time($) < time('06:00') \- 65 'high' 'Foreign transaction at night with high value' \- \> userProfile.averageTransactionAmount \* 4 \- \> 3 80 'high' 'Multiple high-value transactions in short timeframe' != userProfile.homeCountry \- \- \> 5 70 'high' 'Multiple foreign transactions in short timeframe' \- \> userProfile.averageTransactionAmount \* 2 time($) > time('22:00') and time($) < time('06:00') \- 50 'medium' 'Night transaction with amount above average' \- \- \- \> 3 45 'medium' 'Multiple transactions in short timeframe' +1 more row in the downloadable template _03_ ### Calculate Risk Score _expression_ Three operational outputs come out of the table's verdict: finalRiskScore normalizes fraud.riskScore with number(), requiresReview is true when fraud.flag == 'high' or the score exceeds 60, and blockTransaction only trips above 75. Separating review from blocking lets the institution hold marginal transactions for analysts while reserving hard declines for the strongest signals. _finalRiskScore_`number(fraud.riskScore)` _requiresReview_`fraud.flag == 'high' or $.finalRiskScore > 60` _blockTransaction_`$.finalRiskScore > 75` _reason_`fraud.reason` ## Other Financial templates [View all templates](/templates) [_Financial_ ### Loan Approval Automated system that evaluates credit scores, income, debt ratios, and employment history to determine mortgage eligibility and personalized interest rates. ](/industries/financial/templates/loan-approval)[_Financial_ ### Customer Onboarding KYC Verification Automated compliance checks that validate identity documents, screen against watchlists, and apply risk-based due diligence during onboarding. ](/industries/financial/templates/customer-onboarding-kyc-verification)[_Financial_ ### Portfolio Risk Monitor Dynamic portfolio management system that continuously evaluates investment holdings against market conditions to implement appropriate risk mitigation actions. ](/industries/financial/templates/portfolio-risk-monitor) ## Make this template your own. Load Real-Time Fraud Detection into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Portfolio Risk Monitor - GoRules **URL:** https://gorules.io/industries/financial/templates/portfolio-risk-monitor **Description:** Dynamic portfolio management system that continuously evaluates investment holdings against market conditions to implement appropriate risk mitigation actions. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Portfolio Risk Monitor Dynamic portfolio management system that continuously evaluates investment holdings against market conditions to implement appropriate risk mitigation actions. Download template Share ### Solution This intelligent portfolio monitoring system safeguards investments by continuously evaluating customer holdings against changing market conditions. The system analyzes market volatility, downward trends, and economic indicators to calculate current risk exposure. It assesses portfolio composition, focusing on high-risk asset percentages, current volatility levels, and deviation from target allocations. Based on comprehensive risk calculations, the system determines appropriate actions using weighted factors from market conditions, portfolio exposure, and volatility metrics. When moderate risk is detected, customized alerts are generated with specific recommendations. For portfolios that have drifted significantly from targets or face high risk, the system suggests precise rebalancing actions with detailed allocation adjustments. In critical scenarios, immediate risk mitigation strategies are implemented, including automatic defensive reallocation for clients who have enabled this feature. ### How it works The decision graph processes portfolio data through a series of specialized evaluation nodes: 1. **Market Condition Assessment**: Evaluates current volatility index and market trend percentage to determine overall market conditions and assigns a risk factor. 2. **Portfolio Exposure Analysis**: Calculates risk exposure based on high-risk asset percentage and current market conditions. 3. **Volatility Assessment**: Measures portfolio volatility against market risk factors to determine susceptibility to market movements. 4. **Risk Score Calculation**: Computes a weighted risk score using market, exposure, and volatility factors to categorize overall portfolio risk. 5. **Action Determination**: Based on risk category, portfolio drift, and market conditions, the system selects the appropriate response. 6. **Response Execution**: Implements one of four actions: generating alerts, suggesting portfolio rebalancing, implementing risk mitigation strategies, or confirming no action is required. ### Where teams use it - Wealth management firms overseeing client portfolios - Robo-advisor platforms providing automated investment services - Financial advisory practices managing retirement accounts - Investment management companies offering managed funds - Private banking services for high-net-worth individuals - Self-directed investment platforms with risk monitoring features ## Inside the decision model Portfolio Risk Monitor ships as a JDM decision graph with 10 nodes, 3 decision tables and 17 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ marketConditionsAssessment_table_ portfolioExposureAssessment_table_ portfolioVolatilityAssessment_expression_ calculateRiskScore_switch_ determineAction_function_ generateAlert_function_ suggestRebalancing_function_ implementRiskMitigation_expression_ noActionNeeded _01_ ### Request _input_ Three request objects drive the monitor: customer preferences (including allowAutomaticAdjustments), the portfolio with its volatility, highRiskPercentage, and current versus target allocations, and a market snapshot carrying volatilityIndex and trendPercentage. **Sample request**_JSON_ { "customer": { "id": "cust-78945", "name": "John Smith", "riskTolerance": "moderate", "investmentHorizon": "long-term", "preferences": { "allowAutomaticAdjustments": true, "alertThreshold": "moderate", "communicationPreference": "email" } }, "portfolio": { "id": "port-12345", "name": "Retirement Portfolio", "totalValue": 750000, "creationDate": "2019-05-12", "lastRebalance": 95, "volatility": 22.5, "highRiskPercentage": 35, "currentAllocation": { "equity": 65, "bonds": 25, "cash": 10 }, "targetAllocation": { "equity": 60, "bonds": 35, "cash": 5 }, "holdings": \[ { "symbol": "VTI", "category": "equity", "percentage": 30, "value": 225000 }, { "symbol": "VXUS", "category": "equity", "percentage": 20, "value": 150000 }, { "symbol": "VGT", "category": "equity", "percentage": 15, "value": 112500 }, { "symbol": "BND", "category": "bonds", "percentage": 25, "value": 187500 }, { "symbol": "CASH", "category": "cash", "percentage": 10, "value": 75000 } \] }, "market": { "volatilityIndex": 28.5, "trendPercentage": -12.5, "interestRate": 3.75, "sectorPerformance": { "technology": -15.2, "healthcare": -5.1, "financials": -18.4, "consumerStaples": -3.2, "utilities": 1.5 }, "economicIndicators": { "gdpGrowth": 0.8, "inflation": 4.2, "unemploymentRate": 4.1 } } } _02_ ### Market Conditions Assessment _table_ Market state comes from crossing market.volatilityIndex with market.trendPercentage under a first hit policy: volatility above 30 with a trend below -15 reads 'severe' at a 0.8 risk factor, above 25 with below -10 'high' at 0.7, and above 20 with below -5 'moderate' at 0.5. High volatility with a positive trend above 5 is only 'neutral' at 0.3, single-signal rows cover 'elevated' volatility and a 'negative' trend, and the default is 'normal' at 0.2. The volatility cutoffs echo how practitioners read the VIX, where sustained values above 30 signal a stressed market, and the -10 to -15 trend bands sit in the range commonly described as a correction. Pairing the two signals matters because volatility alone is ambiguous: the 'neutral' row explicitly downgrades risk when prices are volatile but rising. Market Volatility Indexmarket.volatilityIndex Market Trend Percentmarket.trendPercentage Market Conditionassessment.marketCondition Market Risk Factorassessment.marketRiskFactor Market Assessmentassessment.marketAssessment \> 30 < -15 'severe' 0.8 'Highly volatile market with significant downward trend' \> 25 < -10 'high' 0.7 'Elevated volatility with substantial market decline' \> 20 < -5 'moderate' 0.5 'Increased volatility with market decline' \> 25 \> 5 'neutral' 0.3 'High volatility but positive market trend' \> 15 \- 'elevated' 0.4 'Elevated market volatility' \- < -10 'negative' 0.6 'Significant market decline' +1 more row in the downloadable template _03_ ### Portfolio Exposure Assessment _table_ Exposure combines portfolio.highRiskPercentage with the upstream market read: more than 50 percent in high-risk assets during a 'severe' or 'high' market is 'critical' at a 0.9 factor, more than 40 percent in the same conditions 'high' at 0.7, and more than 30 percent whenever assessment.marketCondition != 'normal' is 'elevated' at 0.5. Calmer books fall through to 'moderate' above 20 percent or 'low' at 0.1. Making concentration conditional on market state is the realistic part: a 45 percent allocation to risky assets is tolerable in quiet markets but becomes the main loss driver in a drawdown, which is why the same percentage maps to different levels. The specific 20/30/40/50 breakpoints are house risk-appetite settings rather than an external standard. High-Risk Asset Percentageportfolio.highRiskPercentage Market Condition Check Exposure Levelassessment.exposureLevel Exposure Factorassessment.exposureFactor \> 50 assessment.marketCondition == 'severe' or assessment.marketCondition == 'high' 'critical' 0.9 \> 40 assessment.marketCondition == 'severe' or assessment.marketCondition == 'high' 'high' 0.7 \> 30 assessment.marketCondition != 'normal' 'elevated' 0.5 \> 20 \- 'moderate' 0.3 \- \- 'low' 0.1 _04_ ### Portfolio Volatility Assessment _table_ Realized portfolio.volatility is judged against the market backdrop: above 30 with a marketRiskFactor over 0.6 rates 'high' at a 0.8 factor, above 25 with a factor over 0.4 'elevated' at 0.6, then unconditional bands step down through 'moderate' above 20, 'low' above 15, and 'minimal' at 0.1 for everything else. Requiring both a volatile portfolio and a risky market for the top ratings keeps the monitor from over-reacting to a strategy that is volatile by design, such as an equity-heavy long-horizon allocation. The tiered factors feed the weighted score next, so this table effectively decides how much the portfolio's own turbulence contributes to the final category. Portfolio Volatilityportfolio.volatility Market Risk Factorassessment.marketRiskFactor Volatility Levelassessment.volatilityLevel Volatility Factorassessment.volatilityFactor \> 30 \> 0.6 'high' 0.8 \> 25 \> 0.4 'elevated' 0.6 \> 20 \- 'moderate' 0.4 \> 15 \- 'low' 0.2 \- \- 'minimal' 0.1 _05_ ### Calculate Risk Score _expression_ A weighted blend produces the headline number: riskScore multiplies the market, exposure, and volatility factors by weights of 0.3, 0.4, and 0.3, giving exposure the largest say. The same node derives portfolioDrift as abs(portfolio.currentAllocation.equity - portfolio.targetAllocation.equity) and buckets riskScore into a riskCategory of 'critical', 'high', 'moderate', or 'low' at the 0.7, 0.5, and 0.3 cutpoints that the switch reads next. _marketWeight_`0.3` _exposureWeight_`0.4` _volatilityWeight_`0.3` _riskScore_`assessment.marketRiskFactor * $.marketWeight + assessment.exposureFactor * $.exposureWeight + assessment.volatilityFactor * $.volatilityWeight` _portfolioDrift_`abs(portfolio.currentAllocation.equity - portfolio.targetAllocation.equity)` _riskCategory_`$.riskScore >= 0.7 ? 'critical' : $.riskScore >= 0.5 ? 'high' : $.riskScore >= 0.3 ? 'moderate' : 'low'` _06_ ### Determine Action _switch_ Four branches resolve in order under a first hit policy: an alert when riskCategory == 'moderate' and the market is not 'normal', a rebalance when portfolioDrift > 10 or a 'high' category coincides with portfolio.lastRebalance > 90 days, mitigation when the category is 'critical' or 'high' in a 'severe' market, and a default no-action path. The ordering means a moderately risky but drifted portfolio alerts rather than rebalances, so branch sequence is part of the policy. _riskCategory == 'moderate' and assessment.marketCondition != 'normal'_ `Generate Alert` _portfolioDrift > 10 or (riskCategory == 'high' and portfolio.lastRebalance > 90)_ `Suggest Rebalancing` _riskCategory == 'critical' or (riskCategory == 'high' and assessment.marketCondition == 'severe')_ `Implement Risk Mitigation` _otherwise_ `No Action Needed` _07_ ### Generate Alert _function_ On the alert branch a notification payload is assembled: alertDetails carries the customer and portfolio ids, a dayjs-formatted date, the riskScore and riskCategory, and a message embedding the market assessment, with recommendedAction fixed at 'Review portfolio allocation'. The outcome block reports status 'alert\_generated', which downstream systems can use to log or dispatch the notice. _08_ ### Suggest Rebalancing _function_ Getting back to target is expressed as concrete deltas: suggestedChanges subtracts each of portfolio.currentAllocation.equity, bonds, and cash from the matching targetAllocation values, and driftPercentage carries the measured drift into the message. Returning signed adjustments per asset class means an order-management layer can act on the output directly, and the outcome status 'rebalance\_suggested' keeps the action auditable. _09_ ### Implement Risk Mitigation _function_ Defensive de-risking is computed from the target book: suggestedEquity drops the equity target by 15 points, bonds rise by up to 10, and cash absorbs the remainder so the allocation still sums to 100. The automaticChanges flag only turns true when the market is 'severe', the category 'critical', and the customer has opted in via allowAutomaticAdjustments, so the system never reallocates without consent. _10_ ### No Action Needed _expression_ Quiet portfolios exit through this step, which emits an outcome of { status: 'no\_action\_required' } stamped with the riskScore and a timestamp from date('now'). Recording the score even when nothing happens gives the monitoring history a baseline to compare against on the next run. _outcome_`{ status: 'no_action_required', riskScore: riskScore, timestamp: string(date('now')) }` ## Other Financial templates [View all templates](/templates) [_Financial_ ### Loan Approval Automated system that evaluates credit scores, income, debt ratios, and employment history to determine mortgage eligibility and personalized interest rates. ](/industries/financial/templates/loan-approval)[_Financial_ ### Real-Time Fraud Detection Advanced transaction monitoring system that identifies suspicious financial activities using location analysis, spending patterns, and behavioral anomalies. ](/industries/financial/templates/realtime-fraud-detection)[_Financial_ ### Customer Onboarding KYC Verification Automated compliance checks that validate identity documents, screen against watchlists, and apply risk-based due diligence during onboarding. ](/industries/financial/templates/customer-onboarding-kyc-verification) ## Make this template your own. Load Portfolio Risk Monitor into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Payment Routing & Fee Calculator - GoRules **URL:** https://gorules.io/industries/financial/templates/payment-routing-and-fee-calculator **Description:** Intelligent payment processing that determines optimal routing paths, calculates precise fees, and applies security measures per transaction. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Payment Routing & Fee Calculator Intelligent payment processing that determines optimal routing paths, calculates precise fees, and applies security measures per transaction. Download template Share ### Solution This payment processing system dynamically routes transactions through the most appropriate payment channels while calculating precise fees and enforcing security measures tailored to each transaction. The solution evaluates payment type (credit card, debit card, bank transfer, cryptocurrency, digital wallet) and automatically selects the optimal processor with appropriate base fee rates. Channel-specific routing logic adjusts fees and risk assessments based on whether transactions occur via web, mobile, point-of-sale, or API integrations. Transaction amount thresholds trigger graduated security measures, from standard verification for small amounts to enhanced 3D Secure and manual review for large transactions. The system calculates final fees by combining base percentages with channel and amount-based adjustments, while implementing appropriate security protocols including fraud scanning, velocity checks, and verification requirements matched to the risk profile. ### How it works The payment routing system follows a logical sequence: 1. **Payment Type Analysis**: Identifies the transaction type (credit card, debit, ACH, crypto, digital wallet) and assigns the corresponding processor, base fee, and initial risk score. 2. **Channel Evaluation**: Assesses the submission channel (web, mobile, POS, API) and adjusts fees and risk scores accordingly. 3. **Amount-Based Processing**: Applies graduated fee adjustments and security requirements based on transaction value, with special rules for specific payment routes. 4. **Fee Calculation**: Combines all fee components (base percentage, channel additions, amount adjustments) to determine the final fee amount, enforcing minimum fee requirements. 5. **Security Verification**: Calculates total risk score from all factors to determine necessary verification methods, fraud scan levels, velocity checks, and potential manual review requirements. ### Where teams use it - E-commerce payment processing - Omnichannel retail transactions - Subscription billing systems - Marketplace payment distribution - Cross-border commerce - High-value B2B transactions ## Inside the decision model Payment Routing & Fee Calculator ships as a JDM decision graph with 6 nodes, 3 decision tables and 20 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ payment-request_table_ payment-type-processing_table_ channel-routing_table_ amount-based-processing_expression_ fee-calculation_expression_ security-verification _01_ ### Payment Request _input_ A payment object with the type, amount, and channel does most of the work downstream, while the merchant profile and session context (device, location) travel along for enrichment. **Sample request**_JSON_ { "payment": { "id": "pmt\_12345678", "type": "credit\_card", "amount": 2500, "currency": "USD", "channel": "web", "timestamp": "2025-03-18T10:30:45Z", "customer\_id": "cust\_87654321", "metadata": { "card\_last\_four": "4242", "card\_network": "Visa", "save\_for\_future": true } }, "merchant": { "id": "merch\_98765432", "category": "retail", "country": "US", "processing\_history": { "total\_transactions": 1256, "average\_amount": 175.5, "chargeback\_rate": 0.2 } }, "session": { "ip\_address": "192.168.1.1", "device\_id": "dev\_abcdef123456", "browser": "Chrome", "location": { "country": "US", "state": "CA", "city": "San Francisco" } } } _02_ ### Payment Type Processing _table_ Each payment.type maps to a processor, a base fee, and a starting risk score under a first hit policy: 'credit\_card' routes to 'credit\_processor' at 2.9 percent with a risk score of 25, 'debit\_card' to 'debit\_processor' at 1.5 and 15, 'bank\_transfer' to 'ach\_processor' at 1.0 and 10, 'cryptocurrency' to 'crypto\_processor' at 1.8 and 35, and 'digital\_wallet' to 'wallet\_processor' at 2.5 and 20. Unrecognized types hit the default row at 3.5 percent and a risk score of 50. The fee ladder tracks real acquiring economics: 2.9 percent is a common headline rate for card-not-present credit card processing, debit interchange runs materially cheaper, and ACH transfers are the cheapest rail of all. Cryptocurrency starts with the highest risk score of the named types because settlement is irreversible, and pricing the unknown default worst is a standard defensive posture. Payment Typepayment.type Processor Routerouting.processor Base Fee Percentagefee.base\_percentage Risk Scoresecurity.base\_risk\_score 'credit\_card' 'credit\_processor' 2.9 25 'debit\_card' 'debit\_processor' 1.5 15 'bank\_transfer' 'ach\_processor' 1.0 10 'cryptocurrency' 'crypto\_processor' 1.8 35 'digital\_wallet' 'wallet\_processor' 2.5 20 \- 'default\_processor' 3.5 50 _03_ ### Channel Routing _table_ Fees and risk are adjusted per payment.channel, with each of 'web', 'mobile', and 'pos' split on whether the base risk score exceeds 30: web adds 0.5 fee and 15 risk in the high-risk split versus 0.3 and 5 below it, mobile runs 0.8/20 against 0.5/10, and 'pos' adds at most 5 risk. The 'api' row applies a flat 0.1 fee addition with 'high' priority regardless of score, and the default channel is priced at 1.0 with 25 risk and 'low' priority. Card-present POS traffic carrying the lowest risk additions mirrors the industry's card-present versus card-not-present distinction, since a physically presented card is far harder to abuse than a typed-in number. The near-free 'api' row reflects trusted server-to-server integrations where the merchant has already been vetted, and the priority field lets clean channels jump the processing queue. Channelpayment.channel Base Risk Scoresecurity.base\_risk\_score Channel Fee Additionfee.channel\_addition Channel Risk Additionsecurity.channel\_risk\_addition Processing Priorityrouting.priority 'web' \> 30 0.5 15 'low' 'web' <= 30 0.3 5 'medium' 'mobile' \> 30 0.8 20 'low' 'mobile' <= 30 0.5 10 'medium' 'pos' \> 30 1.0 5 'medium' 'pos' <= 30 0.8 0 'high' +2 more rows in the downloadable template _04_ ### Amount Based Processing _table_ Value tiers set both a fee adjustment and a security posture: payments of 10000 or more take a -0.5 fee discount but add 30 to security risk and demand '3ds\_and\_manual' verification, the 5000 to 10000 band gets -0.3 with '3ds', 1000 to 5000 keeps fees flat with a 'cvv\_check', and under 1000 pays a 0.5 premium with 'standard' checks. Two route-specific rows at the bottom define ach\_processor and crypto\_processor handling at 5000 and above ('account\_verification' and 'blockchain\_verification'), though under the first hit policy the generic amount rows above them match first. Discounting large transactions while hardening their verification is standard acquiring practice: percentage fees over-recover on big tickets, so processors rebate them, while absolute fraud exposure grows with size, which is why 3D Secure and manual review gate the top tier. The 1000/5000/10000 breakpoints themselves are business calibration, not a regulatory schedule. Payment Amountpayment.amount Processor Routerouting.processor Amount-based Fee Adjustmentfee.amount\_adjustment Amount-based Security Additionsecurity.amount\_risk\_addition Verification Methodsecurity.verification\_method \>= 10000 \- \-0.5 30 '3ds\_and\_manual' \>= 5000, < 10000 \- \-0.3 20 '3ds' \>= 1000, < 5000 \- 0 10 'cvv\_check' < 1000 \- 0.5 0 'standard' \>= 5000 'ach\_processor' \-0.8 15 'account\_verification' \>= 5000 'crypto\_processor' 0 40 'blockchain\_verification' _05_ ### Fee Calculation _expression_ All three components merge here: final\_fee\_percentage sums fee.base\_percentage, fee.channel\_addition, and fee.amount\_adjustment, fee\_amount applies that rate to payment.amount, and a floor expression keeps fee.final\_amount at no less than 0.5. The node also derives payment.net\_amount, the figure the merchant actually receives, so settlement logic downstream needs no arithmetic of its own. _final\_fee\_percentage_`fee.base_percentage + fee.channel_addition + fee.amount_adjustment` _fee\_amount_`payment.amount * ($.final_fee_percentage / 100)` _fee.final\_amount_`$.fee_amount < 0.5 ? 0.5 : $.fee_amount` _payment.net\_amount_`payment.amount - $.fee.final_amount` _06_ ### Security Verification _expression_ Risk contributions from type, channel, and amount are added into security.total\_risk\_score, which then gates everything else: a high\_risk\_flag at 50 or more triggers manual review, velocity\_check\_required starts at 30, and fraud\_scan\_level steps through 'minimal', 'basic', 'standard', and 'enhanced' at the 25, 50, and 75 marks. The final processing\_instructions object packages processor, priority, and every security decision into one directive for the payment gateway. _security.total\_risk\_score_`security.base_risk_score + security.channel_risk_addition + security.amount_risk_addition` _security.high\_risk\_flag_`$.security.total_risk_score >= 50` _security.velocity\_check\_required_`$.security.total_risk_score >= 30` _security.fraud\_scan\_level_`$.security.total_risk_score >= 75 ? "enhanced" : $.security.total_risk_score >= 50 ? "standard" : $.security.total_risk_score >= 25 ? "basic" : "minimal"` _routing.processing\_instructions_`{ "priority": routing.priority, "processor": routing.processor, "verification_required": security.verification_method, "fraud_scan": $.security.fraud_scan_level, "velocity_check": $.security.velocity_check_required, "manual_review": $.security.high_risk_flag }` ## Other Financial templates [View all templates](/templates) [_Financial_ ### Loan Approval Automated system that evaluates credit scores, income, debt ratios, and employment history to determine mortgage eligibility and personalized interest rates. ](/industries/financial/templates/loan-approval)[_Financial_ ### Real-Time Fraud Detection Advanced transaction monitoring system that identifies suspicious financial activities using location analysis, spending patterns, and behavioral anomalies. ](/industries/financial/templates/realtime-fraud-detection)[_Financial_ ### Customer Onboarding KYC Verification Automated compliance checks that validate identity documents, screen against watchlists, and apply risk-based due diligence during onboarding. ](/industries/financial/templates/customer-onboarding-kyc-verification) ## Make this template your own. Load Payment Routing & Fee Calculator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Loan Approval - GoRules **URL:** https://gorules.io/industries/financial/templates/loan-approval **Description:** Automated system that evaluates credit scores, income, debt ratios, and employment history to determine mortgage eligibility and personalized interest rates. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Loan Approval Automated system that evaluates credit scores, income, debt ratios, and employment history to determine mortgage eligibility and personalized interest rates. Download template Share ### Solution This intelligent loan approval system streamlines the mortgage application process by analyzing key financial factors to make consistent, data-driven decisions. The engine evaluates credit scores against defined thresholds, categorizing them from excellent to very poor while assigning appropriate risk points. It verifies annual income, classifying applicants into income level brackets with corresponding qualification points. The system calculates precise debt-to-income ratios by comparing monthly obligations to income. Employment stability is assessed through a combination of employment type and tenure, with full-time long-term employees receiving the highest stability ratings. Based on these evaluations, the engine generates specific rejection reasons when necessary or calculates personalized interest rates for approved applications by factoring in the applicant's total risk score. This standardized approach ensures fair, transparent lending decisions while reducing processing time. ### How it works The decision graph follows a systematic evaluation process: 1. **Credit Assessment**: Analyzes credit scores and assigns ratings (excellent to very poor) with corresponding risk points. 2. **Income Verification**: Categorizes annual income into levels (high to very low) and assigns qualification points. 3. **Debt-to-Income Calculation**: Computes the percentage of monthly debt payments relative to monthly income. 4. **Employment Evaluation**: Assesses stability based on employment status (full-time, part-time, self-employed) and years of employment. 5. **Rejection Analysis**: Identifies specific rejection reasons when applicants fail to meet minimum requirements. 6. **Approval Decision**: Determines if the application should be approved based on collected rejection reasons. 7. **Interest Rate Calculation**: For approved loans, computes personalized interest rates based on the total risk score. ### Where teams use it - Mortgage lending institutions - Online mortgage application platforms - Credit unions processing home loans - Financial technology companies - Bank loan departments - Mortgage broker services ## Inside the decision model Loan Approval ships as a JDM decision graph with 9 nodes, 4 decision tables and 21 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ loanApplication_table_ creditScoreEvaluation_table_ incomeVerification_expression_ debtToIncomeRatio_table_ employmentHistory_table_ determineLoanRejectionReason_switch_ loanApprovalDecision_expression_ interestRateCalculation_expression_ rejection _01_ ### Loan Application _input_ Nine flat fields drive the decision: creditScore, annualIncome, monthlyDebt and monthlyIncome, employmentStatus with employmentYears, plus applicantId, loanAmount, and loanTerm for context. The four scoring stages downstream each read a different slice of this request. **Sample request**_JSON_ { "applicantId": "APL-12345", "creditScore": 685, "annualIncome": 72000, "monthlyDebt": 1800, "monthlyIncome": 6000, "employmentYears": 4, "employmentStatus": "full\_time", "loanAmount": 250000, "loanTerm": 30 } _02_ ### Credit Score Evaluation _table_ A first hit policy walks the creditScore bands from the top: '>= 750' returns "excellent" with 30 creditScorePoints, \[700..749\] "good" with 25, \[650..699\] "fair" with 15, \[600..649\] "poor" with 5, and anything under 600 "very\_poor" with 0. Ordering the rows from best to worst means each application lands in exactly one band. The cutoffs track the credit-score tiers most US lenders work with, where scores in the mid-700s and above price as prime and anything under 600 reads as subprime. Weighting the top band at 30 points, the largest single contribution in this graph, reflects how heavily mortgage underwriting relies on credit history as a default predictor. Credit ScorecreditScore Credit RatingcreditRating Score PointscreditScorePoints \>= 750 "excellent" 30 \[700..749\] "good" 25 \[650..699\] "fair" 15 \[600..649\] "poor" 5 < 600 "very\_poor" 0 _03_ ### Income Verification _table_ Annual income falls into one of four brackets under a first hit policy: '>= 100000' maps to "high" with 25 incomePoints, \[60000..99999\] to "medium" with 20, \[30000..59999\] to "low" with 10, and below 30000 to "very\_low" with 0. These breakpoints are a business calibration rather than a regulatory requirement: 60000 sits near a typical household income for a mid-size mortgage, and the 0-point floor under 30000 stops low earners from accumulating qualification points on income alone. The incomePoints feed both the rejection check and the risk-priced rate later in the graph. Annual IncomeannualIncome Income LevelincomeLevel Income PointsincomePoints \>= 100000 "high" 25 \[60000..99999\] "medium" 20 \[30000..59999\] "low" 10 < 30000 "very\_low" 0 _04_ ### Debt To Income Ratio _expression_ Dividing monthlyDebt by monthlyIncome and multiplying by 100 produces dtiRatio, the percentage of gross monthly income already committed to debt service. Debt-to-income is the standard affordability measure in mortgage underwriting, and the value computed here is tested against the 40 threshold in the rejection table and folded into the risk score that prices the loan. _dtiRatio_`(monthlyDebt / monthlyIncome) * 100` _05_ ### Employment History _table_ Stability is scored from paired conditions on employmentStatus and employmentYears with a first hit policy: full\_time with 5 or more years earns "very\_stable" and 20 employmentPoints, full\_time at 2 or more years "stable" and 15, self\_employed needs 3 years for the same "stable" 15, part\_time tops out at "moderate" with 5, and unemployed is always "unstable" with 0. Requiring a longer track record from self\_employed applicants than from salaried ones mirrors standard mortgage practice, where lenders typically want around two years of documented self-employment income before treating it as stable. The part\_time ceiling and the zero for unemployed reflect income continuity risk rather than any regulatory rule. Employment Status StabilityemploymentStability Employment PointsemploymentPoints employmentStatus == "full\_time" and employmentYears >= 5 "very\_stable" 20 employmentStatus == "full\_time" and employmentYears >= 2 "stable" 15 employmentStatus == "full\_time" and employmentYears < 2 "new" 10 employmentStatus == "part\_time" and employmentYears >= 2 "moderate" 5 employmentStatus == "part\_time" and employmentYears < 2 "unstable" 0 employmentStatus == "self\_employed" and employmentYears >= 3 "stable" 15 +2 more rows in the downloadable template _06_ ### Determine Loan Rejection Reason _table_ Every failing check contributes here because the hit policy is collect: creditScorePoints < 15 adds "Poor credit history", incomePoints < 10 adds "Insufficient income", dtiRatio > 40 adds "High debt-to-income ratio", and employmentPoints < 10 adds "Unstable employment history". The messages accumulate into the rejectionReasons array via the table's outputPath, so an applicant can fail on several grounds at once. Returning specific reasons instead of a bare decline matches US adverse action practice, where ECOA and Regulation B require lenders to state the principal reasons for a denial. The 40 percent DTI cutoff sits just under the 43 percent benchmark long associated with qualified mortgage rules, while the point floors simply restate the weaker bands of the upstream scoring tables. Rejection Conditions Messagemessage creditScorePoints < 15 "Poor credit history" incomePoints < 10 "Insufficient income" dtiRatio > 40 "High debt-to-income ratio" employmentPoints < 10 "Unstable employment history" _07_ ### Loan Approval Decision _switch_ Applications split on a single test: len(rejectionReasons) == 0 sends the request down the approval branch to interest rate pricing, and the default branch catches everything else as a rejection. Keeping the branch condition tied to the collected reasons list means the approval logic never restates the underwriting thresholds themselves. _len(rejectionReasons) == 0_ `Interest Rate Calculation` _otherwise_ `Rejection` _08_ ### Interest Rate Calculation _expression_ Approved applicants get risk-based pricing: totalRiskScore sums creditScorePoints, incomePoints, employmentPoints, and dtiRatio, then riskAdjustment is computed as 100 - $.totalRiskScore and the final interestRate adds 0.05 points per adjustment unit to a 5.5 baseRate. Stronger applicants therefore pay closer to the base rate, which is how lenders translate a scorecard into a personalized offer. _totalRiskScore_`creditScorePoints + incomePoints + employmentPoints + dtiRatio` _approval_`true` _baseRate_`5.5` _riskAdjustment_`100 - $.totalRiskScore` _interestRate_`$.baseRate + ($.riskAdjustment * 0.05)` _09_ ### Rejection _expression_ On the declined branch the response is reduced to two keys: rejectionReasons carries the collected messages forward and approval is set to false. With passThrough disabled, the caller receives a clean rejection payload instead of the full scoring state. _rejectionReasons_`rejectionReasons` _approval_`false` ## Other Financial templates [View all templates](/templates) [_Financial_ ### Real-Time Fraud Detection Advanced transaction monitoring system that identifies suspicious financial activities using location analysis, spending patterns, and behavioral anomalies. ](/industries/financial/templates/realtime-fraud-detection)[_Financial_ ### Customer Onboarding KYC Verification Automated compliance checks that validate identity documents, screen against watchlists, and apply risk-based due diligence during onboarding. ](/industries/financial/templates/customer-onboarding-kyc-verification)[_Financial_ ### Portfolio Risk Monitor Dynamic portfolio management system that continuously evaluates investment holdings against market conditions to implement appropriate risk mitigation actions. ](/industries/financial/templates/portfolio-risk-monitor) ## Make this template your own. Load Loan Approval into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Customer Service Escalation - GoRules **URL:** https://gorules.io/industries/financial/templates/customer-service-escalation **Description:** Intelligent routing system that prioritizes customer inquiries based on customer value, issue complexity, and financial impact for optimal support allocation. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Customer Service Escalation Intelligent routing system that prioritizes customer inquiries based on customer value, issue complexity, and financial impact for optimal support allocation. Download template Share ### Solution This customer service escalation system automatically routes financial service inquiries to the appropriate support level based on key factors including customer tier, issue complexity, and potential financial impact. Premium customers with high-complexity issues and significant financial implications receive immediate executive attention, while other scenarios are precisely routed to senior or standard support teams. The system applies differentiated service level agreements based on customer value and issue urgency, ensuring that critical cases receive faster resolution times. By evaluating multiple factors simultaneously, the system balances resource allocation with customer importance, preventing both the underserving of valuable accounts and the overcommitment of executive resources to routine matters. All escalation decisions include specific team assignments and clear resolution timeframes. ### How it works The decision graph evaluates customer service inquiries through a structured process: 1. **Input Processing**: Captures essential data about the customer (tier, account age) and the issue (type, complexity, financial impact). 2. **Tier Assessment**: Evaluates customer status (premium, standard, trial) as a primary factor in determining service level. 3. **Complexity Analysis**: Considers issue complexity (high, medium, low) to determine the expertise level required. 4. **Financial Impact Calculation**: Quantifies the monetary significance of the issue to prioritize accordingly. 5. **Escalation Assignment**: Routes to appropriate teams (Executive Response, Senior Support, Standard Support). 6. **SLA Generation**: Assigns specific resolution timeframes based on the combined factors. 7. **Timestamp Addition**: Records when the escalation occurred for compliance and reporting purposes. ### Where teams use it - Financial services customer support - Banking client relationship management - Insurance claims prioritization - Investment services issue resolution - Wealth management client service - Corporate banking support allocation ## Inside the decision model Customer Service Escalation ships as a JDM decision graph with 2 nodes, 1 decision table and 7 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ determine\_escalation\_level _01_ ### Request _input_ The customer block (tier, accountAge) and the issue block (complexity, financialImpact, type) arrive together, and the single routing table reads three of those fields directly. **Sample request**_JSON_ { "customer": { "id": "C123456", "name": "Acme Corporation", "tier": "premium", "accountAge": 36 }, "issue": { "id": "ISS-789", "type": "service\_outage", "complexity": "high", "financialImpact": 7500, "description": "Complete service outage affecting all production systems" } } _02_ ### Determine Escalation Level _table_ Routing crosses customer.tier, issue.complexity, and issue.financialImpact under a first hit policy: a 'premium' customer with 'high' complexity and impact over 5000 triggers 'immediate\_executive' at priority 1 with a 30-minute SLA to the 'Executive Response Team'. Premium cases that miss that bar ('high' complexity at or under 5000, or lesser complexity with impact over 1000) route to the 'Senior Support Team' at 120 minutes, 'standard' customers reach the same team at 180 minutes when 'high' complexity exceeds 2000 or 'medium' complexity exceeds 5000, a 'trial' customer still gets senior support at priority 3 and 240 minutes when a 'high' complexity issue exceeds 5000, and the catch-all sends everything else to 'standard\_support' with a 480-minute window. Tiered SLAs of this shape are standard service operations design rather than regulation: response time is the scarce resource, so it is allocated by customer value and financial exposure. The guardrail rows are the interesting part, where even a trial account can escalate on a large enough impact, protecting the institution from reputational or monetary damage, while premium status alone, without complexity or impact behind it, does not consume executive attention. Customer Tiercustomer.tier Issue Complexityissue.complexity Financial Impactissue.financialImpact Escalation Levelescalation.level Action Descriptionescalation.description Priorityescalation.priority SLA Minutesescalation.slaMinutes Assigned Teamescalation.assignedTeam 'premium' 'high' \> 5000 'immediate\_executive' 'Immediate executive team escalation required' 1 30 'Executive Response Team' 'premium' 'high' <= 5000 'senior\_support' 'Escalate to senior support team' 2 120 'Senior Support Team' 'premium' 'medium', 'low' \> 1000 'senior\_support' 'Escalate to senior support team' 2 120 'Senior Support Team' 'standard' 'high' \> 2000 'senior\_support' 'Escalate to senior support team' 2 180 'Senior Support Team' 'standard' 'medium' \> 5000 'senior\_support' 'Escalate to senior support team' 2 180 'Senior Support Team' 'trial' 'high' \> 5000 'senior\_support' 'Escalate to senior support team' 3 240 'Senior Support Team' +1 more row in the downloadable template ## Other Financial templates [View all templates](/templates) [_Financial_ ### Loan Approval Automated system that evaluates credit scores, income, debt ratios, and employment history to determine mortgage eligibility and personalized interest rates. ](/industries/financial/templates/loan-approval)[_Financial_ ### Real-Time Fraud Detection Advanced transaction monitoring system that identifies suspicious financial activities using location analysis, spending patterns, and behavioral anomalies. ](/industries/financial/templates/realtime-fraud-detection)[_Financial_ ### Customer Onboarding KYC Verification Automated compliance checks that validate identity documents, screen against watchlists, and apply risk-based due diligence during onboarding. ](/industries/financial/templates/customer-onboarding-kyc-verification) ## Make this template your own. Load Customer Service Escalation into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Customer Onboarding KYC Verification - GoRules **URL:** https://gorules.io/industries/financial/templates/customer-onboarding-kyc-verification **Description:** Automated compliance checks that validate identity documents, screen against watchlists, and apply risk-based due diligence during onboarding. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Customer Onboarding KYC Verification Automated compliance checks that validate identity documents, screen against watchlists, and apply risk-based due diligence during onboarding. Download template Share ### Solution This KYC verification system streamlines financial customer onboarding through multi-layered risk evaluation and identity verification. It calculates customer risk scores based on geographic location, politically exposed person status, business type, and transaction amounts. Document validation ensures appropriate credentials match the assigned risk level, preventing acceptance of expired or insufficient documentation for high-risk scenarios. The system performs thorough watchlist screening against sanctions lists, PEP databases, and adverse media sources, automatically triggering rejection for sanctioned individuals. Based on risk assessment, it determines the appropriate due diligence level (standard, enhanced, or blocked) and specifies exactly which additional verification requirements apply, such as source of funds documentation or face verification. This reduces compliance costs while ensuring regulatory requirements are met across all customer risk profiles. ### How it works The decision graph applies a systematic approach to KYC verification: 1. **Customer Risk Scoring**: Evaluates customer data including location, PEP status, business type, and transaction values to generate a risk score and classification. 2. **Document Verification**: Validates ID documents against the assigned risk level, ensuring appropriate documentation types for each risk category. 3. **Watchlist Screening**: Checks customer information against sanctions lists, PEP databases, and adverse media sources. 4. **Due Diligence Determination**: Calculates the appropriate due diligence level based on risk factors and watchlist results. 5. **Additional Requirements**: Identifies specific verification requirements like source of funds documentation or enhanced monitoring. 6. **Verification Result**: Produces a final decision (approved, pending, or rejected) with clear next steps for each customer. ### Where teams use it - Banking customer onboarding - Investment account setup - Cryptocurrency exchanges - Payment service providers - Lending platforms - Insurance policy applications - Wealth management services - Fintech user verification ## Inside the decision model Customer Onboarding KYC Verification ships as a JDM decision graph with 7 nodes, 4 decision tables and 25 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ customerRiskScoring_table_ documentVerification_table_ watchlistCheck_expression_ dueDiligenceLevel_table_ additionalChecks_expression_ verificationResult _01_ ### Request _input_ Four request objects feed the checks: customer (address country, isPoliticallyExposed, isHighRiskBusiness), financialInfo with the estimatedTransactionValue, verification carrying the identity document details, and watchlist with pre-computed sanctions, PEP, and adverse media match flags. **Sample request**_JSON_ { "customer": { "id": "CUST12345", "firstName": "John", "lastName": "Smith", "dateOfBirth": "1985-06-15", "email": "john.smith@example.com", "phone": "+1-555-123-4567", "address": { "line1": "123 Main Street", "line2": "Apt 4B", "city": "New York", "state": "NY", "postalCode": "10001", "country": "US" }, "isPoliticallyExposed": false, "isHighRiskBusiness": false, "occupation": "Software Engineer", "employerName": "Tech Company Inc." }, "financialInfo": { "estimatedTransactionValue": 25000, "accountPurpose": "Savings and Investment", "sourceOfFunds": "Employment Income" }, "verification": { "documentType": "passport", "documentStatus": "valid", "documentNumber": "P123456789", "documentExpiry": "2028-05-20", "documentIssuingCountry": "US" }, "watchlist": { "sanctionsMatch": false, "pepListMatch": false, "adverseMediaMatch": false } } _02_ ### Customer Risk Scoring _table_ Risk is scored on four inputs with a first hit policy. Customers from the low-risk country list ('US', 'CA', 'GB', 'AU', 'NZ', 'JP', 'DE', 'FR') with no PEP or business flags score 10 'low' under 10000 of estimatedTransactionValue and 30 'medium' up to 100000; a PEP from those same countries jumps to 75 'high' and a high-risk business to 70. Any customer from the 'RU', 'IR', 'KP', 'CU', 'SY', 'VE' list scores 100 'very-high' regardless of other fields, combined PEP and high-risk business status elsewhere scores 90, transactions of 100000 or more score 60, and the fallback is 40 'medium'. This is the risk-based approach FATF guidance expects, where geography, customer type, and transaction size each move the rating. Treating PEPs as high risk regardless of transaction value follows FATF Recommendation 12, and the very-high country list corresponds to jurisdictions under comprehensive sanctions programs; the specific 10000 and 100000 breakpoints are the institution's own calibration. Countrycustomer.address.country PEP Statuscustomer.isPoliticallyExposed High Risk Businesscustomer.isHighRiskBusiness Transaction ValuefinancialInfo.estimatedTransactionValue Risk Scoreassessment.riskScore Risk Levelassessment.riskLevel 'US', 'CA', 'GB', 'AU', 'NZ', 'JP', 'DE', 'FR' false false < 10000 10 'low' 'US', 'CA', 'GB', 'AU', 'NZ', 'JP', 'DE', 'FR' false false \>= 10000, < 100000 30 'medium' 'US', 'CA', 'GB', 'AU', 'NZ', 'JP', 'DE', 'FR' true \- \- 75 'high' 'US', 'CA', 'GB', 'AU', 'NZ', 'JP', 'DE', 'FR' \- true \- 70 'high' 'RU', 'IR', 'KP', 'CU', 'SY', 'VE' \- \- \- 100 'very-high' \- true true \- 90 'very-high' +2 more rows in the downloadable template _03_ ### Document Verification _table_ Acceptance depends on both the document and the risk it must support: a valid 'passport' verifies every tier, producing 'standard' verification at 'low' or 'medium' risk and 'enhanced' with extra checks at 'high' or 'very-high'; a 'driving\_license' only verifies 'low' risk customers and comes back 'insufficient' above that, while a 'national\_id' covers 'low' and 'medium'. Any document with status 'expired', 'damaged', or 'suspicious' is 'rejected' outright, and the final catch-all marks the case 'missing'. Tiering documents this way reflects their assurance value in customer due diligence: passports are government-issued, internationally standardized, and hardest to forge, so they anchor the higher tiers, while a driving licence is acceptable evidence only where exposure is small. The exact pairings of document type to risk level are the firm's own policy choice, but demanding stronger identity evidence as risk rises is the substance of a risk-based CDD program. Document Typeverification.documentType Document Statusverification.documentStatus Risk Levelassessment.riskLevel Document Verifiedverification.isDocumentVerified Verification Statusverification.documentVerificationStatus Additional Verification Requiredverification.requiresAdditionalVerification 'passport' 'valid' 'low', 'medium' true 'standard' false 'passport' 'valid' 'high', 'very-high' true 'enhanced' true 'driving\_license' 'valid' 'low' true 'standard' false 'driving\_license' 'valid' 'medium', 'high', 'very-high' false 'insufficient' true 'national\_id' 'valid' 'low', 'medium' true 'standard' false 'national\_id' 'valid' 'high', 'very-high' false 'insufficient' true +2 more rows in the downloadable template _04_ ### Watchlist Check _table_ Screening outcomes cascade in severity order under a first hit policy: sanctionsMatch true immediately returns 'reject' with 'Customer appears on sanctions list', a pepListMatch or adverseMediaMatch each return 'review' for manual handling, and a clean result across all three passes with 'No watchlist hits found'. The asymmetry is deliberate and mirrors real compliance obligations: a sanctions hit cannot be risk-managed, since dealing with sanctioned persons is prohibited, so it hard-blocks onboarding. PEP status and adverse media are not prohibitions under FATF guidance, they are triggers for enhanced scrutiny, which is why those rows route to human review instead of rejection. Sanctions Matchwatchlist.sanctionsMatch PEP Matchwatchlist.pepListMatch Adverse Mediawatchlist.adverseMediaMatch Watchlist Passedwatchlist.passed Watchlist Statuswatchlist.status Watchlist Messagewatchlist.message true \- \- false 'reject' 'Customer appears on sanctions list' false true \- true 'review' 'Customer appears on PEP list - requires manual review' false false true true 'review' 'Customer has adverse media - requires manual review' false false false true 'pass' 'No watchlist hits found' _05_ ### Due Diligence Level _expression_ Two booleans set up the tier: requiresEDD fires when assessment.riskLevel is 'high' or 'very-high' or the watchlist came back 'review', and isSanctioned mirrors a watchlist 'reject'. The nested ternary then resolves dueDiligenceLevel to 'blocked', 'enhanced', or 'standard', the single value the requirements table keys on next. _requiresEDD_`assessment.riskLevel == 'high' or assessment.riskLevel == 'very-high' or watchlist.status == 'review'` _isSanctioned_`watchlist.status == 'reject'` _dueDiligenceLevel_`$.isSanctioned ? 'blocked' : ($.requiresEDD ? 'enhanced' : 'standard')` _06_ ### Additional Checks _table_ Verification obligations scale with the tier: 'enhanced' due diligence with a riskScore of 60 or more switches on all four requirements (sourceOfFunds, addressVerification, faceVerification, enhancedMonitoring), while 'enhanced' below 60 drops only faceVerification. 'standard' customers need addressVerification when their score is 40 or above and nothing extra below that, and the 'blocked' row returns false across the board since no verification can cure a sanctions match. Collecting source of funds and applying ongoing monitoring for enhanced-tier customers matches the enhanced due diligence measures FATF and national AML rules describe for higher-risk relationships, including PEPs. Graduating the burden keeps onboarding friction proportional: low-risk applicants clear with baseline document checks, which is the cost-control argument for risk-based compliance. Due Diligence LeveldueDiligenceLevel Risk Scoreassessment.riskScore Requires Source of Fundsrequirements.sourceOfFunds Requires Address Verificationrequirements.addressVerification Requires Face Verificationrequirements.faceVerification Requires Enhanced Monitoringrequirements.enhancedMonitoring 'enhanced' \>= 60 true true true true 'enhanced' < 60 true true false true 'standard' \>= 40 false true false false 'standard' < 40 false false false false 'blocked' \- false false false false _07_ ### Verification Result _expression_ Everything converges into a final verdict: verificationStatus resolves to 'rejected' when dueDiligenceLevel is 'blocked', 'approved' when the document verified and the watchlist passed, and 'pending' otherwise. Alongside it, requiredActionsCount counts the true flags in requirements with count(values(requirements), # == true), and nextSteps renders the matching operator instruction, so the caller gets a decision plus a work queue in one payload. _verificationStatus_`dueDiligenceLevel == 'blocked' ? 'rejected' : (verification.isDocumentVerified and watchlist.passed ? 'approved' : 'pending')` _requiredActionsCount_`count(values(requirements), # == true)` _nextSteps_`dueDiligenceLevel == 'blocked' ? 'Application rejected due to sanctions match' : ($.verificationStatus == 'pending' ? 'Additional verification required' : 'Onboarding approved')` _requirements_`requirements` ## Other Financial templates [View all templates](/templates) [_Financial_ ### Loan Approval Automated system that evaluates credit scores, income, debt ratios, and employment history to determine mortgage eligibility and personalized interest rates. ](/industries/financial/templates/loan-approval)[_Financial_ ### Real-Time Fraud Detection Advanced transaction monitoring system that identifies suspicious financial activities using location analysis, spending patterns, and behavioral anomalies. ](/industries/financial/templates/realtime-fraud-detection)[_Financial_ ### Portfolio Risk Monitor Dynamic portfolio management system that continuously evaluates investment holdings against market conditions to implement appropriate risk mitigation actions. ](/industries/financial/templates/portfolio-risk-monitor) ## Make this template your own. Load Customer Onboarding KYC Verification into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Credit Limit Adjustment - GoRules **URL:** https://gorules.io/industries/financial/templates/credit-limit-adjustment **Description:** Data-driven solution that evaluates payment history, utilization, and financial behavior to automatically recommend credit limit changes. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Credit Limit Adjustment Data-driven solution that evaluates payment history, utilization, and financial behavior to automatically recommend credit limit changes. Download template Share ### Solution This credit limit adjustment system evaluates customer accounts to identify optimal credit limit modifications based on multiple risk factors. The system analyzes payment reliability through on-time payment percentages and recent late payment occurrences. It examines credit utilization by assessing current usage percentages and six-month average patterns to identify healthy borrowing behaviors. The solution also evaluates broader financial stability indicators including recent credit inquiries, relationship longevity with the financial institution, income verification status, and product portfolio diversity. By combining these factors into a weighted scoring system, it generates percentage-based recommendations for increasing or decreasing credit limits with detailed justifications. Each recommendation includes specific dollar amounts for limit adjustments based on the customer's existing credit allocation. ### How it works The decision system processes account information through multiple evaluation stages: 1. **Payment History Analysis**: Evaluates on-time payment percentage and recent late payments to assign a payment history rating and score. 2. **Utilization Assessment**: Analyzes current utilization percentage and 6-month average to determine credit usage patterns and apply a utilization score. 3. **Financial Behavior Evaluation**: Reviews credit inquiries, relationship tenure, and income verification status to establish a financial behavior rating and score. 4. **Score Aggregation**: Combines all evaluation scores into a total adjustment score to determine the overall account strength. 5. **Recommendation Calculation**: Maps the total score to specific percentage-based credit limit adjustments with supporting justifications. 6. **Final Determination**: Calculates the exact dollar amount change and new credit limit based on the recommended percentage adjustment. ### Where teams use it - Retail banking credit card portfolio management - Consumer lending risk optimization - Credit line increase campaigns - Customer retention and relationship expansion - Risk-based pricing adjustments - Automated account review processes - Regulatory compliance for responsible lending ## Inside the decision model Credit Limit Adjustment ships as a JDM decision graph with 7 nodes, 4 decision tables and 26 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ payment\_history\_evaluation_table_ utilization\_evaluation_table_ financial\_behavior\_evaluation_expression_ calculate\_total\_score_table_ credit\_limit\_recommendation_expression_ calculate\_final\_amounts _01_ ### Request _input_ One account object carries everything: payment\_history with on-time percentages and late payment counts, utilization with current and six-month figures, financial\_behavior covering inquiries, tenure, and income verification, plus the current\_credit\_limit the final step adjusts. **Sample request**_JSON_ { "account": { "customer\_id": "CUST10025", "current\_credit\_limit": 5000, "payment\_history": { "on\_time\_payment\_percentage": 98, "late\_payments\_last\_12\_months": 0, "total\_payments": 24 }, "utilization": { "current\_percentage": 25, "average\_last\_6\_months": 40, "highest\_balance": 2800 }, "financial\_behavior": { "credit\_inquiries\_last\_12\_months": 0, "years\_with\_institution": 4, "income\_verified": true, "has\_other\_products": true } } } _02_ ### Payment History Evaluation _table_ Repayment quality is read from two fields at once under a first hit policy: an on\_time\_payment\_percentage of 95 or better with zero late\_payments\_last\_12\_months rates 'excellent' and +30, 90 with at most 1 late payment rates 'good' and +20, 80 with up to 2 is score-neutral 'average', 70 with up to 3 is 'below\_average' at -10, and the fallback is 'poor' at -30. Giving payment history the widest score swing in the graph (a 60-point spread) parallels how consumer credit models weight it; in the FICO model payment history is the single largest component at about 35 percent. Requiring both a high on-time rate and few recent lates catches accounts whose lifetime average looks fine but which have deteriorated lately. On-time Payment Percentageaccount.payment\_history.on\_time\_payment\_percentage Late Payments (Last 12 Months)account.payment\_history.late\_payments\_last\_12\_months Payment History Ratingevaluation.payment\_history\_rating Payment History Scoreevaluation.payment\_history\_score \>= 95 <= 0 'excellent' 30 \>= 90 <= 1 'good' 20 \>= 80 <= 2 'average' 0 \>= 70 <= 3 'below\_average' \-10 \- \- 'poor' \-30 _03_ ### Utilization Evaluation _table_ Usage patterns pair the snapshot with the trend: a current\_percentage under 30 alongside a six-month average under 50 rates 'low' and +25, the 30 to 50 band with a 50 to 70 average is 'moderate' at +15, and successively heavier bands step through 'high' (0), 'very\_high' (-15), and the 'excessive' catch-all at -25. The 30 percent line is the utilization guideline most credit scoring commentary converges on, below which revolving usage is considered healthy. Testing average\_last\_6\_months as well as the current reading separates a customer who briefly ran up a balance from one who is persistently maxed out, and only the latter should cost limit headroom. Current Utilization Percentageaccount.utilization.current\_percentage Average Utilization (Last 6 Months)account.utilization.average\_last\_6\_months Utilization Ratingevaluation.utilization\_rating Utilization Scoreevaluation.utilization\_score < 30 < 50 'low' 25 \>= 30, < 50 \>= 50, < 70 'moderate' 15 \>= 50, < 70 \>= 70, < 85 'high' 0 \>= 70, < 85 \>= 85, < 95 'very\_high' \-15 \- \- 'excessive' \-25 _04_ ### Financial Behavior Evaluation _table_ Three signals combine into one rating: fewer than 1 credit inquiry in 12 months, 3 or more years\_with\_institution, and income\_verified true earns 'excellent' at +25; slightly looser combinations grade 'good' (+15) and 'average' (+5), while fewer than 4 inquiries with under a year of tenure and unverified income falls to 'below\_average' at -10, and the catch-all is 'poor' at -20. Inquiry counts proxy for credit-seeking pressure, and long tenure gives the bank observed behavior it can trust more than bureau data alone. Verified income matters beyond risk appetite: US card issuers must consider a customer's ability to pay before raising a limit under the CARD Act, so an increase recommendation built on unverified income would be hard to action. Credit Inquiries (Last 12 Months)account.financial\_behavior.credit\_inquiries\_last\_12\_months Years with Institutionaccount.financial\_behavior.years\_with\_institution Income Verificationaccount.financial\_behavior.income\_verified Financial Behavior Ratingevaluation.financial\_behavior\_rating Financial Behavior Scoreevaluation.financial\_behavior\_score < 1 \>= 3 true 'excellent' 25 < 2 \>= 2 true 'good' 15 < 3 \>= 1 \- 'average' 5 < 4 < 1 false 'below\_average' \-10 \- \- \- 'poor' \-20 _05_ ### Calculate Total Score _expression_ A single sum produces total\_adjustment\_score by adding evaluation.payment\_history\_score, evaluation.utilization\_score, and evaluation.financial\_behavior\_score. The unweighted addition keeps each table's internal point scale as its implicit weight, and the result is the only input the recommendation ladder needs. _total\_adjustment\_score_`evaluation.payment_history_score + evaluation.utilization_score + evaluation.financial_behavior_score` _06_ ### Credit Limit Recommendation _table_ Eleven descending bands convert total\_adjustment\_score into recommendation.percent\_change with a first hit policy: above 50 grants a 30 percent increase, then 25, 20, 15, 10, and 5 percent steps down to scores just above 0, while negative territory maps to a hold at 0 and cuts of -5, -10, -15, and finally -20 percent below -40. Every row also emits a plain-language justification, from 'Significant increase recommended' down to 'Major decrease recommended due to severe risk factors'. Graduated moves in the 5 to 30 percent range match how issuers actually manage lines, since small periodic adjustments avoid sudden exposure jumps and customer shocks. The asymmetry is notable: the best score earns +30 percent but the worst only cuts -20, a common posture because aggressive decreases can trigger utilization spikes and attrition among salvageable accounts, and each row's justification text doubles as the explanation a customer or reviewer would see. Total Adjustment Scoretotal\_adjustment\_score Percent Changerecommendation.percent\_change Justificationrecommendation.justification \> 50 30 'Significant increase recommended based on excellent history and behavior.' \> 40 25 'Strong increase recommended based on very good history and behavior.' \> 30 20 'Moderate increase recommended based on good history and behavior.' \> 20 15 'Increase recommended based on above average history and behavior.' \> 10 10 'Small increase recommended based on satisfactory history and behavior.' \> 0 5 'Minimal increase recommended based on acceptable history and behavior.' +5 more rows in the downloadable template _07_ ### Calculate Final Amounts _expression_ Dollar figures come last: recommendation.amount\_change rounds account.current\_credit\_limit times percent\_change over 100, and recommendation.new\_credit\_limit adds that change back to the current limit. Emitting concrete numbers means the account system can apply the decision without re-deriving the percentage math. _recommendation.amount\_change_`round(account.current_credit_limit * (recommendation.percent_change / 100))` _recommendation.new\_credit\_limit_`account.current_credit_limit + $.recommendation.amount_change` ## Other Financial templates [View all templates](/templates) [_Financial_ ### Loan Approval Automated system that evaluates credit scores, income, debt ratios, and employment history to determine mortgage eligibility and personalized interest rates. ](/industries/financial/templates/loan-approval)[_Financial_ ### Real-Time Fraud Detection Advanced transaction monitoring system that identifies suspicious financial activities using location analysis, spending patterns, and behavioral anomalies. ](/industries/financial/templates/realtime-fraud-detection)[_Financial_ ### Customer Onboarding KYC Verification Automated compliance checks that validate identity documents, screen against watchlists, and apply risk-based due diligence during onboarding. ](/industries/financial/templates/customer-onboarding-kyc-verification) ## Make this template your own. Load Credit Limit Adjustment into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Account Dormancy Management - GoRules **URL:** https://gorules.io/industries/financial/templates/account-dormancy-management **Description:** Proactive banking solution that identifies inactive accounts, determines appropriate interventions, and ensures compliance with regulatory requirements. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Account Dormancy Management Proactive banking solution that identifies inactive accounts, determines appropriate interventions, and ensures compliance with regulatory requirements. Download template Share ### Solution This account dormancy management system helps financial institutions identify and address inactive accounts before they become dormant. It calculates the time since last account activity and determines how close accounts are to reaching dormancy thresholds. Based on these calculations, the system assigns a status to each account: active, warning, at-risk, or dormant. For accounts requiring attention, the system recommends specific actions based on the dormancy status and customer tier. Premium customers receive preferential treatment such as fee waivers and account reviews, while standard customers may receive final notices or automatic account closure procedures. Each recommended action includes a priority level to help bank staff efficiently allocate resources. This ensures regulatory compliance while maintaining positive customer relationships and reducing the administrative burden of managing dormant accounts. ### How it works The decision graph processes account information through these key steps: 1. **Input Processing**: Receives account details including type, balance, customer tier, last activity date, and regional information. 2. **Dormancy Calculation**: Computes days since last activity and days remaining until the account reaches dormancy threshold. 3. **Status Assignment**: Categorizes accounts as "active," "warning" (60 days before threshold), "at\_risk" (30 days before threshold), or "dormant" (past threshold). 4. **Status Routing**: Directs active accounts to normal processing while flagging others for intervention. 5. **Action Determination**: Recommends specific interventions based on dormancy status and customer tier, such as notifications, fee waivers, account reviews, or closure procedures. 6. **Priority Allocation**: Assigns priority levels to each action, helping staff focus on the most urgent cases first. ### Where teams use it - Retail banking account management - Corporate account administration - Credit union member services - Wealth management client monitoring - Digital banking platforms - Multi-regional financial institutions - Regulatory compliance programs ## Inside the decision model Account Dormancy Management ships as a JDM decision graph with 5 nodes, 2 decision tables and 9 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_expression_ calculate\_dormancy_table_ dormancy\_status_switch_ route\_by\_status_table_ determine\_action _01_ ### Request _input_ Flat request fields drive the flow: lastActivityDate and dormancyThreshold feed the day math, while customerTier steers the intervention choice and accountBalance, region, and regulatoryJurisdiction travel through as context. **Sample request**_JSON_ { "accountId": "ACC98765432", "accountType": "savings", "customerTier": "premium", "lastActivityDate": "2024-11-15", "dormancyThreshold": 180, "accountBalance": 25750.45, "currency": "USD", "region": "NORTH\_AMERICA", "contactPreference": "email", "customerEmail": "customer@example.com", "customerPhone": "+15551234567", "regulatoryJurisdiction": "US-NY" } _02_ ### Calculate Dormancy _expression_ Elapsed time is computed first: daysSinceLastActivity subtracts date(lastActivityDate) from date('now'), and daysToThreshold subtracts that figure from the account's dormancyThreshold. A negative daysToThreshold therefore means the account has already crossed into dormancy, which is exactly the signal the status table keys on. _daysSinceLastActivity_`date('now') - date(lastActivityDate)` _daysToThreshold_`dormancyThreshold - $.daysSinceLastActivity` _03_ ### Dormancy Status _table_ Status falls out of daysToThreshold with a first hit policy: below 0 the account is already 'dormant', under 30 days remaining marks it 'at\_risk', under 60 'warning', and the empty catch-all leaves it 'active'. Ordering from most to least severe means each account receives exactly one dormancyStatus. The escalating 60- and 30-day windows exist because dormancy carries real regulatory weight: once accounts go unclaimed long enough, unclaimed property laws in many jurisdictions require balances to be escheated to the state, and reactivating a customer beforehand is far cheaper than that process. Taking the threshold itself from the request (180 days in the sample) lets one table serve products and regions with different dormancy definitions. Days To ThresholddaysToThreshold StatusdormancyStatus < 0 'dormant' < 30 'at\_risk' < 60 'warning' \- 'active' _04_ ### Route By Status _switch_ A single condition splits the flow: dormancyStatus != 'active' routes accounts needing intervention to the action table, while the default branch lets active accounts pass with no further processing. Filtering here keeps the action logic from needing an explicit do-nothing row for healthy accounts. _dormancyStatus != 'active'_ `Determine Action` _otherwise_ _05_ ### Determine Action _table_ Interventions pair dormancyStatus with customerTier: 'dormant' premium accounts get a 'fee\_waiver' at 'high' priority while other dormant accounts move to 'auto\_close' at 'medium', 'at\_risk' premium customers receive an 'account\_review' and the rest a 'final\_notice', both at 'high' priority, and every 'warning' account simply gets a 'notification'. Blank tier cells act as catch-alls, so with the first hit policy the premium rows must sit above them to take effect. Splitting treatment by tier reflects retention economics: waiving fees or scheduling a review for a premium relationship costs less than losing the balances it represents, while automatic closure workflows are the standard low-cost path for unprofitable dormant accounts. The priority field maps to urgency sensibly, with 'at\_risk' cases marked 'high' because they are the last window where outreach can still prevent dormancy. StatusdormancyStatus Customer TiercustomerTier ActionrecommendedAction PriorityactionPriority 'dormant' 'premium' 'fee\_waiver' 'high' 'dormant' \- 'auto\_close' 'medium' 'at\_risk' 'premium' 'account\_review' 'high' 'at\_risk' \- 'final\_notice' 'high' 'warning' \- 'notification' 'medium' ## Other Financial templates [View all templates](/templates) [_Financial_ ### Loan Approval Automated system that evaluates credit scores, income, debt ratios, and employment history to determine mortgage eligibility and personalized interest rates. ](/industries/financial/templates/loan-approval)[_Financial_ ### Real-Time Fraud Detection Advanced transaction monitoring system that identifies suspicious financial activities using location analysis, spending patterns, and behavioral anomalies. ](/industries/financial/templates/realtime-fraud-detection)[_Financial_ ### Customer Onboarding KYC Verification Automated compliance checks that validate identity documents, screen against watchlists, and apply risk-based due diligence during onboarding. ](/industries/financial/templates/customer-onboarding-kyc-verification) ## Make this template your own. Load Account Dormancy Management into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Airline Seat Map Display Rules - GoRules **URL:** https://gorules.io/industries/aviation/templates/seat-map-optimization **Description:** Dynamic seat map system that personalizes seat availability based on loyalty tier, fare class, group size and cabin occupancy levels. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Airline Seat Map Display Rules Dynamic seat map system that personalizes seat availability based on loyalty tier, fare class, group size and cabin occupancy levels. Download template Share ### Solution This airline seat management system delivers personalized seat map experiences by evaluating multiple factors to determine what seats each passenger can view and select. The system considers the customer's loyalty status, analyzing whether they hold platinum, gold, silver or standard tier membership. It factors in the passenger's fare class, distinguishing between first class, business class, economy plus, and standard economy tickets. The solution adds intelligence by calculating real-time cabin fill percentages and factoring in group booking requirements for families or parties traveling together. Premium loyalty members and higher fare classes unlock access to preferred seating areas, while restricted seats become available when cabin occupancy exceeds certain thresholds or for groups needing adjacent seating. This creates a seamless, personalized booking experience while optimizing airline seat inventory management. ### How it works The decision graph processes passenger and flight data through four key nodes: 1. **Input Processing**: Receives customer profile information (tier, fare class, group size), cabin details (total seats, occupied seats, seat types), and flight information. 2. **Cabin Fill Calculation**: Computes the percentage of occupied seats and determines if adjacent seating is required based on group size. 3. **Seat Availability Rules**: Applies a decision table with 12 prioritized rules that evaluate customer tier, fare class, cabin occupancy percentage, and group size to determine which seat types to display. 4. **Display Adjustment**: Calculates total available seats, determines the appropriate seat map version (standard or premium), and generates appropriate messaging based on cabin occupancy. ### Where teams use it - Airline seat selection systems - Airport check-in kiosks - Mobile airline apps - Travel agency booking platforms - Third-party flight reservation systems - Corporate travel management platforms ## Inside the decision model Airline Seat Map Display Rules ships as a JDM decision graph with 4 nodes, 1 decision table and 12 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_expression_ calculateCabinFill_table_ determineSeatAvailability_expression_ adjustSeatAvailability _01_ ### Request _input_ Seat map requests carry a customer block with tier, fareClass, and groupSize, a cabin block with totalSeats, occupiedSeats, and the premium, standard, and restricted seat counts, plus flight identifiers; tier, fare, fill, and group size are the four signals the rules actually branch on. **Sample request**_JSON_ { "customer": { "id": "CUS123456", "tier": "gold", "fareClass": "economy\_plus", "groupSize": 3, "hasSpecialNeeds": false, "previousFlights": 24 }, "cabin": { "id": "CAB789", "name": "main cabin", "totalSeats": 180, "occupiedSeats": 108, "premiumSeats": 32, "standardSeats": 138, "restrictedSeats": 10 }, "flight": { "flightNumber": "FL722", "departureTime": "2025-04-15T08:30:00Z", "arrivalTime": "2025-04-15T11:45:00Z", "aircraft": "Boeing 737-800" } } _02_ ### Calculate Cabin Fill _expression_ Two derived figures set up the table: cabinFillPercentage is (cabin.occupiedSeats / cabin.totalSeats) \* 100, and adjacentSeatsNeeded passes customer.groupSize through only when it exceeds 1, otherwise 0. Expressing occupancy as a percentage lets the display rules use readable thresholds like 70 or 85 regardless of aircraft size. _cabinFillPercentage_`(cabin.occupiedSeats / cabin.totalSeats) * 100` _adjacentSeatsNeeded_`customer.groupSize > 1 ? customer.groupSize : 0` _03_ ### Determine Seat Availability _table_ Twelve prioritized rows resolve top down with first hit, matching customer.tier, customer.fareClass, cabinFillPercentage, and adjacentSeatsNeeded against four display switches. 'platinum' or 'gold' members on 'first' or 'business' fares see everything including restricted seats with unlockPremiumSeats true, the same tiers in economy keep premium access only while cabin fill stays under 70, 'silver' members lose preferred visibility once fill reaches 60, 'standard' customers never see preferred seating at all, and near the bottom two override rows open restricted seats for groups needing more than 2 adjacent seats or once fill passes 85, ahead of a plain default of standard seats only. Holding preferred inventory back from lower tiers while the cabin is empty protects seats airlines sell or award as elite benefits, and releasing them as occupancy climbs mirrors seat-inventory practice, since an unsold premium seat is worth more filled than protected. Opening restricted rows for larger groups reflects the operational need to seat parties together; the 70, 60, 50, and 85 fill thresholds are inventory-management tuning, not regulatory values. Customer Tiercustomer.tier Fare Classcustomer.fareClass Cabin Fill %cabinFillPercentage Adjacent Seats NeededadjacentSeatsNeeded Show Preferred SeatsseatDisplay.showPreferredSeats Show Standard SeatsseatDisplay.showStandardSeats Show Restricted SeatsseatDisplay.showRestrictedSeats Unlock Premium SeatsseatDisplay.unlockPremiumSeats 'platinum', 'gold' 'first', 'business' \- \- true true true true 'platinum', 'gold' 'economy\_plus', 'economy' < 70 \- true true false true 'silver' 'business' \- \- true true false true 'silver' 'economy\_plus', 'economy' < 60 \- true true false false 'silver' 'economy\_plus', 'economy' \>= 60 \- false true false false 'standard' 'business' \- \- false true false false +6 more rows in the downloadable template _04_ ### Adjust Seat Availability _expression_ Presentation details close out the run: seatDisplay.totalAvailableSeats subtracts occupiedSeats from totalSeats, seatMapVersion renders 'premium' whenever unlockPremiumSeats came back true, and displayMessage switches to 'Limited seats available' once cabinFillPercentage passes 80. A scarcity message at high fill is a familiar booking-flow conversion tactic, kept honest here by tying it to actual occupancy. _seatDisplay.totalAvailableSeats_`cabin.totalSeats - cabin.occupiedSeats` _seatDisplay.seatMapVersion_`seatDisplay.unlockPremiumSeats ? 'premium' : 'standard'` _seatDisplay.displayMessage_`cabinFillPercentage > 80 ? 'Limited seats available' : 'Select your seats'` ## Other Aviation templates [View all templates](/templates) [_Aviation_ ### Flight Dispatch Decision System Rules-based aviation system that evaluates weather, aircraft, crew, and weight factors to ensure regulatory compliance and safe flight operations. ](/industries/aviation/templates/flight-dispatch-decision-system)[_Aviation_ ### Dynamic Airline Ticket Pricing Engine Automated fare optimization system that sets ticket prices based on time to departure, seat availability, market demand, and competitor pricing. ](/industries/aviation/templates/dynamic-ticket-pricing)[_Aviation_ ### Booking Personalization System Dynamic flight booking platform that tailors UI, discounts, and features based on customer loyalty status, device type, booking history, and traffic source. ](/industries/aviation/templates/booking-personalization-system) ## Make this template your own. Load Airline Seat Map Display Rules into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Online Check-in Eligibility System - GoRules **URL:** https://gorules.io/industries/aviation/templates/online-checkin-eligibility **Description:** Automated passenger validation system that determines online check-in eligibility based on travel documents, flight timing, and special assistance requirements. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Online Check-in Eligibility System Automated passenger validation system that determines online check-in eligibility based on travel documents, flight timing, and special assistance requirements. Download template Share ### Solution This decision system streamlines the passenger check-in process by evaluating multiple eligibility factors before allowing online check-in. The system verifies that passengers have all required travel documentation, including valid passports and visas when needed for international destinations. It checks the proximity to departure time, preventing online check-in when too close to flight time. For passengers requiring special assistance, the system directs them to airport check-in counters where staff can provide personalized support. When passengers meet all requirements, the system confirms eligibility and provides information about additional services like seat selection and extra baggage options. By delivering clear status messages with specific reasons for ineligibility, the system helps passengers understand next steps and reduces airport counter congestion. ### How it works The decision graph evaluates passenger eligibility through several sequential steps: 1. **Data Processing**: Calculates time until departure and verifies document requirements based on destination. 2. **Time Check**: Validates that check-in is being attempted within the allowed time window (more than 90 minutes before departure). 3. **Document Verification**: Confirms passengers have valid passports and appropriate visas when required for their destination. 4. **Assistance Need Assessment**: Identifies passengers requiring special assistance who need in-person check-in. 5. **Service Options**: For eligible passengers, determines available additional services like seat selection and baggage options. 6. **Response Generation**: Provides clear status messages with specific reasons for ineligibility or confirmation of successful check-in. ### Where teams use it - Commercial airline passenger check-in - International flight documentation verification - Airport resource optimization - Passenger flow management - Mobile check-in applications - Self-service kiosk integration ## Inside the decision model Online Check-in Eligibility System ships as a JDM decision graph with 6 nodes, 1 decision table and 4 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_expression_ preprocessData_table_ checkEligibility_switch_ eligibilityCheck_expression_ additionalServices_expression_ nonEligible _01_ ### Request _input_ Two objects drive the check: passenger with hasValidPassport, hasValidVisa, and requiresSpecialAssistance, and flight with departureTime, requiresVisa, and the service flags hasSeatSelection and allowsExtraBaggage. **Sample request**_JSON_ { "passenger": { "id": "P12345678", "name": "John Smith", "hasValidPassport": true, "hasValidVisa": true, "requiresSpecialAssistance": false, "frequentFlyerStatus": "gold" }, "flight": { "flightNumber": "BA123", "departureTime": "2025-03-20T10:30:00Z", "origin": "LHR", "destination": "JFK", "requiresVisa": true, "hasSeatSelection": true, "allowsExtraBaggage": true, "hasSpecialMealOptions": true } } _02_ ### Preprocess Data _expression_ Preprocessing turns raw fields into decision-ready values: hoursUntilDeparture is computed from date(flight.departureTime) against a fixed reference currentTime, and hasRequiredDocuments demands passenger.hasValidPassport plus a visa state that matches flight.requiresVisa, defaulting to false when the flag is absent. Folding the visa test into one boolean means the eligibility table never has to know whether the route is international. _flightDepartureTime_`date(flight.departureTime)` _currentTime_`date('2025-03-20T08:30:00Z')` _hoursUntilDeparture_`($.flightDepartureTime - $.currentTime) / 3600` _hasRequiredDocuments_`passenger.hasValidPassport == true and passenger.hasValidVisa == (flight.requiresVisa ?? false)` _03_ ### Check Eligibility _table_ Eligibility gates run in strict order with first hit on free-form conditions: hoursUntilDeparture < 1.5 returns 'check\_in\_closed', !hasRequiredDocuments returns 'missing\_documents', passenger.requiresSpecialAssistance routes to 'special\_assistance', and only the empty final row grants isEligible true with 'You are eligible for online check-in.' Closing online check-in 90 minutes before departure reflects the cutoffs airlines publish so baggage drop, security, and boarding still work downstream, though the exact window is carrier and airport policy rather than regulation. Sending document problems and assistance requests to the counter matches practice: travel-document checks against systems like IATA's Timatic and wheelchair or medical support both need a human agent. Condition Is EligibleisEligible Status CodestatusCode Messagemessage hoursUntilDeparture < 1.5 false 'check\_in\_closed' 'Online check-in is closed. Please proceed to the airport for assistance.' !hasRequiredDocuments false 'missing\_documents' 'Missing required travel documents. Please check-in at the airport.' passenger.requiresSpecialAssistance false 'special\_assistance' 'Special assistance required. Please check-in at the airport.' \- true 'eligible' 'You are eligible for online check-in.' _04_ ### Eligibility Check _switch_ Routing splits on a single statement: isEligible == true takes the top branch to the services step, while the default branch handles every refusal. Keeping the branch condition on the table's output instead of re-testing raw fields keeps the eligibility logic in exactly one place. _isEligible == true_ `Additional Services` _otherwise_ `Non Eligible` _05_ ### Additional Services _expression_ Service options are assembled for passengers who pass: canSelectSeat mirrors flight.hasSeatSelection, canAddBaggage mirrors flight.allowsExtraBaggage, and statusCode and message carry through unchanged from the table. With pass-through disabled, only these response fields leave the graph, which keeps the API answer small and stable. _isEligible_`false` _canSelectSeat_`flight.hasSeatSelection == true` _canAddBaggage_`flight.allowsExtraBaggage == true` _statusCode_`statusCode` _message_`message` _06_ ### Non Eligible _expression_ Refusals produce a minimal payload: isEligible is pinned to false while the statusCode and message set by the eligibility table pass through as the explanation. Trimming everything else off the response gives the check-in front end exactly what it needs to show the right instruction. _isEligible_`false` _statusCode_`statusCode` _message_`message` ## Other Aviation templates [View all templates](/templates) [_Aviation_ ### Flight Dispatch Decision System Rules-based aviation system that evaluates weather, aircraft, crew, and weight factors to ensure regulatory compliance and safe flight operations. ](/industries/aviation/templates/flight-dispatch-decision-system)[_Aviation_ ### Dynamic Airline Ticket Pricing Engine Automated fare optimization system that sets ticket prices based on time to departure, seat availability, market demand, and competitor pricing. ](/industries/aviation/templates/dynamic-ticket-pricing)[_Aviation_ ### Booking Personalization System Dynamic flight booking platform that tailors UI, discounts, and features based on customer loyalty status, device type, booking history, and traffic source. ](/industries/aviation/templates/booking-personalization-system) ## Make this template your own. Load Online Check-in Eligibility System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Flight Rebooking Fee Calculator - GoRules **URL:** https://gorules.io/industries/aviation/templates/flight-rebooking-fee-calculator **Description:** Dynamic fee system for airline booking modifications that adjusts charges based on fare class, time to departure, loyalty status, and change history. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Flight Rebooking Fee Calculator Dynamic fee system for airline booking modifications that adjusts charges based on fare class, time to departure, loyalty status, and change history. Download template Share ### Solution This automated flight modification system determines appropriate rebooking fees through a multi-factor approach that balances airline revenue protection with customer satisfaction. The calculator evaluates the original booking's fare class, setting base fees that increase as you move from premium to economy classes. It analyzes the time remaining before departure, with longer notice periods receiving more favorable rates across all fare categories. The system incorporates customer loyalty standing by applying significant discounts for higher-tier members, including complete fee waivers for platinum travelers. It also tracks modification history, applying scaled surcharges for repeated changes to discourage excessive rebooking. For last-minute changes, special same-day processing fees apply, with considerations for premium customers. This balanced approach ensures fees remain fair to customers while covering airline administrative costs and potential revenue impacts from seat inventory changes. ### How it works The decision graph evaluates booking modifications through these sequential steps: 1. **Base Fee Determination**: Analyzes the original fare class (First/Business/Economy) and days remaining to departure, establishing an initial fee according to a tiered structure. 2. **Change Frequency Assessment**: Checks how many previous modifications have been made to this booking, applying increasing multipliers for repeated changes. 3. **Loyalty Status Evaluation**: Applies discounts based on the customer's loyalty tier, with Platinum members receiving full waivers, Gold receiving 50% off, and Silver receiving 25% off. 4. **Fee Calculation**: Combines the base fee with applicable multipliers and discounts to determine the adjusted modification charge. 5. **Final Fee Rules**: Applies special considerations like same-day change minimum fees, maximum fee caps, and final eligibility checks. ### Where teams use it - Airline booking modification systems - Travel agency rebooking platforms - Corporate travel management tools - Online travel agency modification interfaces - Airline customer service systems - Mobile app flight change functionality ## Inside the decision model Flight Rebooking Fee Calculator ships as a JDM decision graph with 6 nodes, 4 decision tables and 23 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ bookingModificationRequest_table_ baseFeeCalculation_table_ frequencyMultiplier_table_ loyaltyFactor_expression_ calculateAdjustedFee_table_ finalFeeAssessment _01_ ### Booking Modification Request _input_ Change requests arrive with fareClass, daysToDeparture, changeFrequency, and loyaltyTier at top level, plus passengerDetails and the original and new departure dates; those four scalar fields are what every fee table keys on. **Sample request**_JSON_ { "bookingId": "BK-12345678", "fareClass": "Economy", "originalDepartureDate": "2025-05-15T10:30:00Z", "newDepartureDate": "2025-05-20T14:15:00Z", "daysToDeparture": 12, "passengerDetails": { "firstName": "Jane", "lastName": "Smith", "loyaltyTier": "Silver", "loyaltyNumber": "LM789012" }, "changeFrequency": 2, "loyaltyTier": "Silver" } _02_ ### Base Fee Calculation _table_ Base fees form a matrix over fareClass and daysToDeparture, resolved with first hit: 'First' changes are free beyond 14 days and cost 50 inside it, 'Business' steps 75, 100, and 150 across the over-21, 7-21, and 7-or-fewer day bands, 'Economy' climbs 100, 150, 200, 250 as the window shrinks from over 30 days down to 3 or fewer, and an unmatched fare class defaults to 300. Cheaper cabins paying higher and earlier-rising change fees is standard fare-fencing logic: flexibility is part of what a premium fare buys, so economy tickets carry the tightest restrictions. Fees stepping up as departure approaches track the airline's shrinking chance to resell the vacated seat; the specific bands and amounts are commercial policy, not regulation. Fare ClassfareClass Days to DeparturedaysToDeparture Base FeemodificationFee.baseFee Base Fee ReasonmodificationFee.baseFeeReason 'First' \> 14 0 'No fee for First Class with >14 days to departure' 'First' <= 14 50 'Minimal fee for First Class with ≤14 days to departure' 'Business' \> 21 75 'Standard fee for Business Class with >21 days to departure' 'Business' \> 7 and <= 21 100 'Medium fee for Business Class with 7-21 days to departure' 'Business' <= 7 150 'Higher fee for Business Class with ≤7 days to departure' 'Economy' \> 30 100 'Standard fee for Economy with >30 days to departure' +4 more rows in the downloadable template _03_ ### Frequency Multiplier _table_ Repeat behavior scales the fee next: a changeFrequency of at most 1 keeps the frequencyMultiplier at 1 with 'No additional charge for first change', 2 to 3 changes raise it to 1.25, more than 3 raises it to 1.5 as a '50% surcharge for frequent changes', and a missing value defaults to 1. Escalating surcharges for serial rebooking discourage treating changes as free options on seat inventory, a real cost since every change reopens revenue accounting and inventory control. The 25% and 50% steps are deterrence tuning rather than any industry standard. Change FrequencychangeFrequency Frequency MultipliermodificationFee.frequencyMultiplier Frequency ReasonmodificationFee.frequencyReason <= 1 1 'No additional charge for first change' \> 1 and <= 3 1.25 '25% surcharge for 2-3 changes' \> 3 1.5 '50% surcharge for frequent changes' \- 1 'Default multiplier' _04_ ### Loyalty Factor _table_ Status pays off here: a loyaltyTier of 'Platinum' zeroes the fee through a loyaltyFactor of 0, 'Gold' halves it at 0.5, 'Silver' takes 25% off at 0.75, and everyone else keeps a factor of 1 with 'No loyalty discount applied'. Concentrating full fee waivers at the top tier mirrors how change-fee forgiveness is marketed as an elite benefit in real frequent-flyer programs, since the fee revenue given up is small next to the retention value of high-yield flyers. The 50 and 25 percent ladder below it is plausible program design, not a rule. Loyalty TierloyaltyTier Loyalty FactormodificationFee.loyaltyFactor Loyalty ReasonmodificationFee.loyaltyReason 'Platinum' 0 'Platinum members receive fee waiver' 'Gold' 0.5 'Gold members receive 50% discount' 'Silver' 0.75 'Silver members receive 25% discount' \- 1 'No loyalty discount applied' _05_ ### Calculate Adjusted Fee _expression_ One line settles the arithmetic: adjustedFee rounds modificationFee.baseFee \* frequencyMultiplier \* loyaltyFactor. Multiplying instead of adding keeps both the surcharge and the discount proportional to the base fee, so a Platinum factor of 0 wins regardless of change history. _adjustedFee_`round(modificationFee.baseFee * modificationFee.frequencyMultiplier * modificationFee.loyaltyFactor)` _06_ ### Final Fee Assessment _table_ Overrides get the last word through ordered conditions: loyaltyTier == 'Platinum' with daysToDeparture > 1 waives everything, an adjustedFee of 0 passes through as 'No fee applicable', same-day 'First' changes still pay a 100 minimum, any other change with daysToDeparture <= 1 pays max(\[200, adjustedFee\]), and the default row carries adjustedFee forward as the 'Standard modification fee', in every case with modificationFee.allowed set true. A same-day floor exists because last-minute changes hit operations hardest, leaving no time to resell the seat, so even heavily discounted fees are clamped upward. Exempting Platinum members from that floor only while more than a day out puts a deliberate limit on the waiver; the 200 and 100 floors are business amounts, not mandated fees. Condition Final FeemodificationFee.finalFee Fee DescriptionmodificationFee.description Modification AllowedmodificationFee.allowed loyaltyTier == 'Platinum' and daysToDeparture > 1 0 'Waived - Platinum member benefit' true adjustedFee == 0 0 'No fee applicable' true fareClass == 'First' and daysToDeparture <= 1 100 'Minimum fee for same-day changes' true daysToDeparture <= 1 max(\[200, adjustedFee\]) 'Same-day change fee applied' true \- adjustedFee 'Standard modification fee' true ## Other Aviation templates [View all templates](/templates) [_Aviation_ ### Flight Dispatch Decision System Rules-based aviation system that evaluates weather, aircraft, crew, and weight factors to ensure regulatory compliance and safe flight operations. ](/industries/aviation/templates/flight-dispatch-decision-system)[_Aviation_ ### Dynamic Airline Ticket Pricing Engine Automated fare optimization system that sets ticket prices based on time to departure, seat availability, market demand, and competitor pricing. ](/industries/aviation/templates/dynamic-ticket-pricing)[_Aviation_ ### Booking Personalization System Dynamic flight booking platform that tailors UI, discounts, and features based on customer loyalty status, device type, booking history, and traffic source. ](/industries/aviation/templates/booking-personalization-system) ## Make this template your own. Load Flight Rebooking Fee Calculator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Flight Dispatch Decision System - GoRules **URL:** https://gorules.io/industries/aviation/templates/flight-dispatch-decision-system **Description:** Rules-based aviation system that evaluates weather, aircraft, crew, and weight factors to ensure regulatory compliance and safe flight operations. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Flight Dispatch Decision System Rules-based aviation system that evaluates weather, aircraft, crew, and weight factors to ensure regulatory compliance and safe flight operations. Download template Share ### Solution This automated dispatch system ensures flight safety by analyzing multiple critical factors before approving takeoff. It checks if current weather conditions fall within aircraft operational parameters, evaluating both wind speed and visibility against specific thresholds. The system verifies aircraft readiness by confirming no pending maintenance is required and adequate fuel reserves are available. For crew validation, the system ensures all rest requirements are met and sufficient crew members are present for the specific flight. The weight assessment component calculates total passenger weight based on headcount, adds cargo weight, and confirms the combined weight with aircraft empty weight doesn't exceed maximum takeoff limitations. When any safety parameter fails, the system provides immediate identification of the specific issue with detailed reasoning. This enables dispatchers to efficiently address problems or implement necessary restrictions, ensuring all regulatory requirements are satisfied before clearance. ### How it works The decision graph contains multiple evaluation nodes that work together: 1. **Input Processing**: Receives flight data including weather conditions, aircraft specifications, crew information, and passenger/cargo manifest. 2. **Weight Calculations**: Computes total passenger weight, cargo load, and estimated takeoff weight. 3. **Weather Eligibility**: Evaluates wind speed and visibility against safety requirements and aircraft limitations. 4. **Aircraft Eligibility**: Assesses maintenance status and fuel reserves for airworthiness. 5. **Crew Eligibility**: Verifies rest compliance and sufficient staffing levels. 6. **Weight Verification**: Confirms takeoff weight is within aircraft's maximum limitation. 7. **Dispatch Summary**: Consolidates all evaluations and produces a final decision with detailed reasoning. ### Where teams use it - Commercial airline flight operations - Charter flight services - Cargo transport operations - Flight schools and training centers - Private aviation management - Military flight operations ## Inside the decision model Flight Dispatch Decision System ships as a JDM decision graph with 7 nodes, 4 decision tables and 13 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ flightDispatchRequest_expression_ weightCalculations_table_ weightEligibility_table_ crewEligibility_table_ aircraftEligibility_table_ weatherEligibility_expression_ dispatchSummary _01_ ### Flight Dispatch Request _input_ A dispatch request arrives with five top-level blocks - weather, aircraft, manifest, crew, and flight - and every safety gate downstream reads directly from fields like weather.windSpeed, aircraft.fuelReserves, and manifest.cargoWeight. **Sample request**_JSON_ { "weather": { "windSpeed": 90, "visibility": 6500, "precipitation": "light", "temperature": 15 }, "aircraft": { "emptyWeight": 41500, "maxTakeoffWeight": 78000, "fuelReserves": 1.5, "maintenanceRequired": false, "type": "B737-800" }, "manifest": { "passengers": \[ "P001", "P002", "P003", "P004", "P005", "P006", "P007", "P008", "P009", "P010" \], "cargoWeight": 2500 }, "crew": { "restCompliant": true, "members": \[ "C001", "C002", "C003" \] }, "flight": { "number": "FL123", "origin": "LAX", "destination": "JFK", "scheduledDeparture": "2025-03-19T08:00:00Z" } } _02_ ### Weight Calculations _expression_ Before any gate runs, this step derives the load figures: totalPassengers counts manifest.passengers, passengerWeight applies a flat 85 per head, and estimatedTakeoffWeight adds aircraft.emptyWeight, totalCargo, and passengerWeight together. Using a standard mass of 85 instead of weighing individuals mirrors the standard-passenger-mass method airlines use in load planning, and the resulting figure feeds the weight gate directly. _totalPassengers_`len(manifest.passengers)` _passengerWeight_`$.totalPassengers * 85` _totalCargo_`manifest.cargoWeight` _estimatedTakeoffWeight_`aircraft.emptyWeight + $.totalCargo + $.passengerWeight` _03_ ### Weight Eligibility _table_ One comparison settles the load check: when estimatedTakeoffWeight exceeds aircraft.maxTakeoffWeight the flag goes false with 'Aircraft exceeds maximum takeoff weight', otherwise the flight passes with 'Weight within acceptable limits'. Comparing against certified maximum takeoff weight is exactly how load control signs off a departure, since exceeding it invalidates the performance and certification basis of the aircraft. TakeoffWeightestimatedTakeoffWeight WeightFlagdispatch.weight.flag WeightReasondispatch.weight.reason \> aircraft.maxTakeoffWeight false 'Aircraft exceeds maximum takeoff weight' \- true 'Weight within acceptable limits' _04_ ### Crew Eligibility _table_ Legality of the crew resolves in order: crew.restCompliant equal to false trips 'Crew rest requirements not met', a computed len(crew.members) below 2 trips 'Insufficient crew members', and otherwise the table returns 'Crew requirements satisfied'. Rest is checked first because flight and duty time limitation schemes such as FAA Part 117 make an unrested crew member ineligible no matter how many people are rostered. The floor of 2 reflects the two-pilot flight deck required on transport-category aircraft; a production system would also count required cabin crew against seat count, so this is a deliberately minimal staffing check. CrewRestCompliantcrew.restCompliant CrewCountlen(crew.members) CrewFlagdispatch.crew.flag CrewReasondispatch.crew.reason false \- false 'Crew rest requirements not met' \- < 2 false 'Insufficient crew members' \- \- true 'Crew requirements satisfied' _05_ ### Aircraft Eligibility _table_ Airworthiness comes down to two gates evaluated with first hit ordering: aircraft.maintenanceRequired set to true fails immediately with 'Aircraft requires maintenance', then aircraft.fuelReserves below 1 fails with 'Insufficient fuel reserves', and the final row confirms 'Aircraft is operational'. Checking open maintenance before fuel matches line-maintenance practice, where a reported defect must be cleared or deferred under the minimum equipment list before the aircraft can be released. Requiring reserves of at least 1 echoes the final-reserve idea in fuel planning, but the exact threshold is a simplified stand-in for the fuller fuel policy an operator would actually file. MaintenanceRequiredaircraft.maintenanceRequired FuelReservesaircraft.fuelReserves AircraftFlagdispatch.aircraft.flag AircraftReasondispatch.aircraft.reason true \- false 'Aircraft requires maintenance' \- < 1 false 'Insufficient fuel reserves' \- \- true 'Aircraft is operational' _06_ ### Weather Eligibility _table_ Wind and visibility are screened together under a first hit policy, ordered from the worst combination down. A weather.windSpeed above 45 with weather.visibility under 10000 fails as 'Extreme wind and low visibility', wind above 45 alone fails because 'Winds exceed aircraft limitations', wind above 35 paired with visibility below 5000 fails as 'High winds with low visibility', and visibility below 1000 fails on its own. Only when no restrictive row matches does the catch-all set dispatch.weather.flag to true with 'Weather conditions acceptable'. Layered wind and visibility gates mirror how dispatchers apply operating minima: strong winds alone can exceed a type's demonstrated crosswind capability, while marginal winds only become disqualifying once visibility also degrades. A hard visibility floor reflects the takeoff-minima concept from instrument procedures, though the specific 45/35 and 10000/5000/1000 breakpoints here are conservative business choices rather than values from any particular regulation. WindSpeedweather.windSpeed Visibilityweather.visibility WeatherFlagdispatch.weather.flag WeatherReasondispatch.weather.reason \> 45 < 10000 false 'Extreme wind and low visibility' \> 45 \- false 'Winds exceed aircraft limitations' \> 35 < 5000 false 'High winds with low visibility' \- < 1000 false 'Visibility below minimum requirements' \- \- true 'Weather conditions acceptable' _07_ ### Dispatch Summary _expression_ The verdict is assembled by folding the four gates together: isDispatchable holds only when all(values(dispatch), #.flag) is true, dispatchReasons and failedCriteria collect the sections whose flag is false, and dispatchSummary renders either 'Flight is cleared for dispatch' or 'Flight dispatch denied'. Surfacing which criteria failed, not just a boolean, is what lets a dispatcher act on the result instead of re-checking every input by hand. _isDispatchable_`all(values(dispatch), #.flag)` _dispatchReasons_`filter(values(dispatch), #.flag == false)` _dispatchSummary_`$.isDispatchable ? 'Flight is cleared for dispatch' : 'Flight dispatch denied'` _failedCriteria_`filter(keys(dispatch), dispatch[#].flag == false)` ## Other Aviation templates [View all templates](/templates) [_Aviation_ ### Dynamic Airline Ticket Pricing Engine Automated fare optimization system that sets ticket prices based on time to departure, seat availability, market demand, and competitor pricing. ](/industries/aviation/templates/dynamic-ticket-pricing)[_Aviation_ ### Booking Personalization System Dynamic flight booking platform that tailors UI, discounts, and features based on customer loyalty status, device type, booking history, and traffic source. ](/industries/aviation/templates/booking-personalization-system)[_Aviation_ ### Flight Ancillary Recommendations Data-driven system that personalizes travel add-on recommendations based on customer profile, route details, and previous purchasing behavior. ](/industries/aviation/templates/flight-ancillary-recommendations) ## Make this template your own. Load Flight Dispatch Decision System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Flight Ancillary Recommendations - GoRules **URL:** https://gorules.io/industries/aviation/templates/flight-ancillary-recommendations **Description:** Data-driven system that personalizes travel add-on recommendations based on customer profile, route details, and previous purchasing behavior. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Flight Ancillary Recommendations Data-driven system that personalizes travel add-on recommendations based on customer profile, route details, and previous purchasing behavior. Download template Share ### Solution This intelligent recommendation engine helps airlines boost ancillary revenue by delivering personalized product suggestions that match each traveler's specific journey context. The system analyzes multiple factors including loyalty tier status, flight duration, travel purpose, and destination type to recommend the most relevant add-ons like lounge access, priority boarding, or extra baggage. For business travelers, it prioritizes productivity-enhancing services such as WiFi and fast-track security, especially for frequent flyers on medium to long routes. Leisure travelers receive suggestions focused on comfort and experience enhancement, while family groups see recommendations for practical needs like family seating and entertainment packages. The system also examines previous purchase history to avoid redundant recommendations, ensuring travelers only see relevant new offerings they haven't already bought. ### How it works The recommendation engine follows a structured evaluation process: 1. **Flight Classification**: Categorizes flights as short, medium, or long based on duration in minutes. 2. **Customer Analysis**: Evaluates loyalty status and examines previous purchase patterns to identify premium customers and product preferences. 3. **Base Recommendations**: Generates initial suggestions by matching travel purpose (business, leisure, family) with flight duration and customer attributes. 4. **Contextual Enhancement**: Adds specialized recommendations based on route characteristics (international, beach destinations) and airport facilities. 5. **Priority Assignment**: Ranks all recommendations by relevance score to highlight the most valuable suggestions first. 6. **Recommendation Consolidation**: Merges all suggestions into a unified, prioritized list for presentation to the customer. ### Where teams use it - Post-booking ancillary upsell campaigns - Real-time recommendations during web/mobile booking flow - Personalized preflight email marketing - Airport check-in kiosk offers - Airline mobile app targeted promotions - Call center agent suggestion tools ## Inside the decision model Flight Ancillary Recommendations ships as a JDM decision graph with 6 nodes, 3 decision tables and 17 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ categorize\_flight\_duration_expression_ calculate\_customer\_attributes_table_ base\_recommendations_table_ additional\_recommendations_expression_ join\_recommendations _01_ ### Request _input_ Four request blocks feed the engine: customerProfile with loyaltyTier and travelFrequency, route with flightDurationMinutes and destination, the travelPurpose flag, and a previousPurchases list used to suppress products the traveler already bought. **Sample request**_JSON_ { "customerProfile": { "id": "cust-12345", "loyaltyTier": "gold", "travelFrequency": "frequent", "preferredLanguage": "en", "preferredCurrency": "USD" }, "route": { "origin": "JFK", "destination": "international", "flightDurationMinutes": 480, "hasAirportLounge": true, "departureTime": "2025-04-15T08:30:00Z", "returnTime": "2025-04-22T15:45:00Z" }, "travelPurpose": "business", "tripDetails": { "passengers": 1, "cabinClass": "economy", "dateFlexibility": "fixed" }, "previousPurchases": \[ { "bookingId": "bkg-9876", "productType": "seat", "purchaseDate": "2024-12-10T14:22:00Z", "productDetails": { "seatType": "extra\_legroom", "amount": 35 } }, { "bookingId": "bkg-8765", "productType": "wifi", "purchaseDate": "2024-11-05T09:15:00Z", "productDetails": { "packageType": "full\_flight", "amount": 19.99 } } \] } _02_ ### Categorize Flight Duration _table_ Duration bucketing comes first: a route.flightDurationMinutes of 240 or more classifies the flight as 'long', 120 up to 240 as 'medium', and anything under 120 as 'short', resolved under a first hit policy. A four-hour break for long flights and a two-hour break for medium roughly tracks how airlines segment ancillary relevance: meal and entertainment products only sell on longer sectors, while short hops leave little worth offering beyond seats and bags. The exact minute thresholds are a merchandising choice, not an official haul classification. Flight Duration Minutesroute.flightDurationMinutes Duration CategoryflightDurationCategory \>= 240 'long' \>= 120 and < 240 'medium' < 120 'short' _03_ ### Calculate Customer Attributes _expression_ Purchase history gets condensed into flags before anything is recommended: isPremiumCustomer is true for a 'gold' or 'platinum' customerProfile.loyaltyTier, and hasBoughtBaggage, hasBoughtMeals, hasBoughtSeats, and hasBoughtLounge each scan previousPurchases for a matching productType. These booleans are what let later rules skip products the traveler already owns. _isPremiumCustomer_`customerProfile.loyaltyTier == 'gold' or customerProfile.loyaltyTier == 'platinum'` _hasBoughtBaggage_`some(previousPurchases ?? [], #.productType == 'baggage')` _hasBoughtMeals_`some(previousPurchases ?? [], #.productType == 'meal')` _hasBoughtSeats_`some(previousPurchases ?? [], #.productType == 'seat')` _hasBoughtLounge_`some(previousPurchases ?? [], #.productType == 'lounge')` _04_ ### Base Recommendations _table_ Every matching row fires here because the hit policy is collect, writing productType and priority pairs into recommendations.base. Business travelers on 'long' flights who satisfy isPremiumCustomer collect 'lounge' at priority 5, 'priority\_boarding' on 'medium' or 'long' sectors at 4, and 'wifi' at 3 regardless of duration; leisure rows push 'extra\_baggage', a 'meal' guarded by !hasBoughtMeals, and 'seat\_selection' guarded by !hasBoughtSeats; family rows add 'family\_seating', 'extra\_baggage', and an 'entertainment\_package' on long flights. Matching product to travel purpose is the standard ancillary merchandising play: productivity items for business, comfort and experience items for leisure, practical items for families. The negative guards on prior purchases prevent redundant offers, basic hygiene in upsell campaigns since pitching a product someone already owns depresses conversion. Travel PurposetravelPurpose Flight DurationflightDurationCategory Customer Attributes ProductproductType Prioritypriority 'business' 'long' isPremiumCustomer 'lounge' 5 'business' 'medium', 'long' \- 'priority\_boarding' 4 'business' \- \- 'wifi' 3 'leisure' 'long' \- 'extra\_baggage' 5 'leisure' 'medium', 'long' !hasBoughtMeals 'meal' 4 'leisure' \- !hasBoughtSeats 'seat\_selection' 3 +3 more rows in the downloadable template _05_ ### Additional Recommendations _table_ Context stacks on top of purpose in this second collect table, which appends route-driven offers into recommendations.additional. A lounge-equipped airport (route.hasAirportLounge and !hasBoughtLounge) plus premium status yields 'lounge' at priority 4, route.destination == 'international' adds 'travel\_insurance', a 'long' flight without prior meal purchases adds 'premium\_meal', frequent business flyers get 'fast\_track\_security', and 'beach' or 'resort' destinations paired with leisure travel add an 'excursion\_package'. Attaching insurance to international itineraries and excursions to resort destinations follows observable purchase propensity rather than any rule; travel insurance in particular converts far better on international trips where medical cover matters. Gating the lounge offer on the airport actually having one keeps the recommendation credible. Route Attributes Customer Context Additional ProductproductType Prioritypriority route.hasAirportLounge and !hasBoughtLounge isPremiumCustomer 'lounge' 4 route.destination == 'international' \- 'travel\_insurance' 3 flightDurationCategory == 'long' and !hasBoughtMeals \- 'premium\_meal' 2 customerProfile.travelFrequency == 'frequent' and travelPurpose == 'business' \- 'fast\_track\_security' 4 route.destination == 'beach' or route.destination == 'resort' travelPurpose == 'leisure' 'excursion\_package' 3 _06_ ### Join Recommendations _expression_ One flat list leaves the graph: flatten(values(recommendations)) merges the base and additional buckets into a single recommendations array, each entry keeping its productType and priority. Downstream channels can then sort by priority without caring which table produced a suggestion. _recommendations_`flatten(values(recommendations))` ## Other Aviation templates [View all templates](/templates) [_Aviation_ ### Flight Dispatch Decision System Rules-based aviation system that evaluates weather, aircraft, crew, and weight factors to ensure regulatory compliance and safe flight operations. ](/industries/aviation/templates/flight-dispatch-decision-system)[_Aviation_ ### Dynamic Airline Ticket Pricing Engine Automated fare optimization system that sets ticket prices based on time to departure, seat availability, market demand, and competitor pricing. ](/industries/aviation/templates/dynamic-ticket-pricing)[_Aviation_ ### Booking Personalization System Dynamic flight booking platform that tailors UI, discounts, and features based on customer loyalty status, device type, booking history, and traffic source. ](/industries/aviation/templates/booking-personalization-system) ## Make this template your own. Load Flight Ancillary Recommendations into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Dynamic Airline Ticket Pricing Engine - GoRules **URL:** https://gorules.io/industries/aviation/templates/dynamic-ticket-pricing **Description:** Automated fare optimization system that sets ticket prices based on time to departure, seat availability, market demand, and competitor pricing. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Dynamic Airline Ticket Pricing Engine Automated fare optimization system that sets ticket prices based on time to departure, seat availability, market demand, and competitor pricing. Download template Share ### Solution This intelligent pricing engine maximizes airline revenue by automatically setting optimal ticket prices based on multiple market factors. The system evaluates proximity to departure date, applying higher multipliers for last-minute bookings when travelers have fewer alternatives. It continuously monitors remaining seat inventory against total capacity to identify high-demand flights requiring premium pricing. The engine incorporates real-time demand forecasts to anticipate booking patterns and adjusts prices accordingly. It also performs competitive analysis by comparing base fares against market averages to ensure prices remain attractive while maximizing revenue. By combining these factors through weighted multipliers, the system determines the final ticket price and selects an appropriate pricing strategy, from premium rates for high-demand routes to discount pricing for flights needing to boost sales. ### How it works The decision graph processes pricing data through sequential evaluation steps: 1. **Time Urgency Assessment**: Analyzes days remaining until departure to apply appropriate urgency multipliers, with higher multipliers for imminent departures. 2. **Factor Calculation**: Computes key metrics including seat availability ratio, demand index, and competitive positioning. 3. **Inventory-Demand Analysis**: Evaluates remaining seat inventory against projected demand to determine scarcity value. 4. **Final Price Determination**: Combines urgency level, demand indicators, and competitive factors to calculate the optimal ticket price. 5. **Strategy Classification**: Assigns a pricing strategy label (premium, competitive\_high, match\_market, competitive\_low, or discount) to guide marketing and sales. ### Where teams use it - Commercial airlines optimizing revenue across routes - Charter flight services maximizing profitability - Low-cost carriers maintaining competitive pricing - Business class and premium cabin pricing - Holiday and peak season fare management - Route launch and new destination pricing ## Inside the decision model Dynamic Airline Ticket Pricing Engine ships as a JDM decision graph with 5 nodes, 3 decision tables and 15 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ time\_urgency_expression_ calculate\_factors_table_ inventory\_demand_table_ final\_pricing _01_ ### Request _input_ Pricing runs off a flat request: daysToDepature, basePrice, availableSeats, totalSeats, demandForecast, and avgCompetitorPrice are the fields every downstream multiplier is built from. **Sample request**_JSON_ { "flightId": "FL-123", "routeId": "JFK-LAX", "daysToDepature": 1, "basePrice": 250, "availableSeats": 5, "totalSeats": 180, "demandForecast": 95, "avgCompetitorPrice": 25 } _02_ ### Time Urgency _table_ Booking lead time maps to a multiplier under a first hit policy on daysToDepature: under 3 days yields 1.5 and 'high' urgency, 3 to 7 days yields 1.2 and 'medium', 8 to 14 days yields 1.1 and 'low', and beyond 14 days the multiplier stays at 1.0 with 'baseline'. Front-loading the steepest increase into the final 72 hours matches how airline revenue management prices close-in demand, where late bookers skew toward business travel with low price sensitivity. The 3, 7, and 14 day breakpoints follow conventional advance-purchase windows used in fare fencing, a common commercial choice rather than any mandated schedule. Days To DeparturedaysToDepature Urgency MultiplierurgencyMultiplier Urgency LevelurgencyLevel < 3 1.5 'high' \>= 3 and <= 7 1.2 'medium' \> 7 and <= 14 1.1 'low' \> 14 1.0 'baseline' _03_ ### Calculate Factors _expression_ Three normalized ratios come out of this step: availabilityRatio divides availableSeats by totalSeats, demandIndex scales demandForecast down by 100, and competitiveIndex divides avgCompetitorPrice by basePrice. Expressing everything as ratios lets the tables that follow use thresholds like 0.2 or 1.1 that hold for any aircraft size or fare level. _availabilityRatio_`availableSeats / totalSeats` _demandIndex_`demandForecast / 100` _competitiveIndex_`avgCompetitorPrice / basePrice` _04_ ### Inventory Demand _table_ Scarcity pricing kicks in when a low availabilityRatio meets a strong demandIndex, evaluated top down with first hit: under 0.2 of seats remaining with demand above 0.8 sets inventoryMultiplier to 1.3 and demandLevel to 'very\_high', progressively wider bands step down through 1.2 and 1.1, flights sitting at 0.6 to 0.8 availability drop to 0.95, and the fallback row discounts to 0.9 at 'very\_low'. Pricing below base when the cabin is still mostly empty is standard load-factor management: a seat flown empty earns nothing, so stimulating bookings beats holding fare. The mirrored premium on nearly full flights captures the scarcity value of the last remaining inventory, and the specific band edges are tuning choices rather than industry-fixed constants. Availability RatioavailabilityRatio Demand IndexdemandIndex Inventory MultiplierinventoryMultiplier Demand LeveldemandLevel < 0.2 \> 0.8 1.3 'very\_high' \>= 0.2 and < 0.4 \> 0.7 1.2 'high' \>= 0.4 and < 0.6 \>= 0.5 1.1 'medium' \>= 0.6 and < 0.8 \- 0.95 'low' \- \- 0.9 'very\_low' _05_ ### Final Pricing _table_ Everything converges here: combinations of urgencyLevel, demandLevel, and competitiveIndex select both a price formula and a priceStrategy label under first hit. 'high' urgency with 'very\_high' demand and an index under 0.9 multiplies basePrice \* urgencyMultiplier \* inventoryMultiplier by a further 1.1 for 'premium', the middle rows settle at 'match\_market' with no extra factor, weak demand with competitors above 1.2 or 1.3 times the base fare triggers 'competitive\_low' at 0.95 or 'discount' at 0.9, and a final catch-all row matches the market. Pricing on scarcity rather than the competitive set when urgency and demand peak reflects how revenue management treats the last seats on a near-sold-out departure; comparison shopping matters little to someone who must fly tomorrow. Undercutting even a higher-priced market when demand is 'low' or 'very\_low' is a volume play, a plain commercial choice since fares on most routes face no regulatory pricing constraint. Urgency LevelurgencyLevel Demand LeveldemandLevel Competitive IndexcompetitiveIndex Final PricefinalPrice Price StrategypriceStrategy 'high' 'very\_high' < 0.9 basePrice \* urgencyMultiplier \* inventoryMultiplier \* 1.1 'premium' 'high','medium' 'high' < 1.1 basePrice \* urgencyMultiplier \* inventoryMultiplier \* 1.05 'competitive\_high' 'medium','low' 'medium' <= 1.2 and >= 0.8 basePrice \* urgencyMultiplier \* inventoryMultiplier 'match\_market' 'low','baseline' 'low' \> 1.2 basePrice \* urgencyMultiplier \* inventoryMultiplier \* 0.95 'competitive\_low' 'baseline' 'very\_low' \> 1.3 basePrice \* urgencyMultiplier \* inventoryMultiplier \* 0.9 'discount' \- \- \- basePrice \* urgencyMultiplier \* inventoryMultiplier 'match\_market' ## Other Aviation templates [View all templates](/templates) [_Aviation_ ### Flight Dispatch Decision System Rules-based aviation system that evaluates weather, aircraft, crew, and weight factors to ensure regulatory compliance and safe flight operations. ](/industries/aviation/templates/flight-dispatch-decision-system)[_Aviation_ ### Booking Personalization System Dynamic flight booking platform that tailors UI, discounts, and features based on customer loyalty status, device type, booking history, and traffic source. ](/industries/aviation/templates/booking-personalization-system)[_Aviation_ ### Flight Ancillary Recommendations Data-driven system that personalizes travel add-on recommendations based on customer profile, route details, and previous purchasing behavior. ](/industries/aviation/templates/flight-ancillary-recommendations) ## Make this template your own. Load Dynamic Airline Ticket Pricing Engine into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Booking Personalization System - GoRules **URL:** https://gorules.io/industries/aviation/templates/booking-personalization-system **Description:** Dynamic flight booking platform that tailors UI, discounts, and features based on customer loyalty status, device type, booking history, and traffic source. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Booking Personalization System Dynamic flight booking platform that tailors UI, discounts, and features based on customer loyalty status, device type, booking history, and traffic source. Download template Share ### Solution This booking personalization system delivers tailored flight booking experiences by adapting to individual customer contexts. The platform automatically adjusts user interface elements based on device type, presenting mobile users with compact, touch-friendly layouts while desktop users receive expanded search options and detailed filters. Loyalty status recognition enables tiered benefits, with platinum members receiving exclusive deals, concierge service, and 15% discounts while new customers see standard options with loyalty program invitations. The system identifies traffic sources to present relevant promotions, offering social media visitors special deals with additional discounts, while direct visitors see standard pricing options. For returning customers, the platform activates features based on booking frequency, showing recently viewed items to frequent travelers and offering incremental discounts based on booking history. All these factors combine to calculate a personalization score that determines the overall booking flow template, ensuring each customer journey feels uniquely customized while optimizing conversion rates. ### How it works The personalization engine follows a sequential decision process: 1. **Device Detection**: Identifies whether the user is on mobile, tablet, or desktop and adjusts UI elements accordingly. 2. **Loyalty Analysis**: Evaluates membership tier to determine available features, priority level, and base discount percentage. 3. **Traffic Source Evaluation**: Analyzes how the visitor arrived at the booking platform to display relevant promotions and special offers. 4. **Booking History Assessment**: Reviews past travel patterns to determine customer classification and tailors recommendations. 5. **Personalization Scoring**: Combines factors including loyalty status, booking history, and traffic source to generate a numerical personalization score. 6. **Experience Compilation**: Calculates final discount percentages and selects the appropriate booking flow template based on the personalization score. ### Where teams use it - Airline ticket reservations - Hotel booking platforms - Car rental services - Vacation package providers - Cruise line bookings - Tour operator websites - Travel metasearch engines - Corporate travel portals ## Inside the decision model Booking Personalization System ships as a JDM decision graph with 7 nodes, 5 decision tables and 33 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ Device Type Personalization_table_ Loyalty Status Personalization_table_ Visit Source Personalization_table_ Booking History Personalization_table_ Calculate Personalization Score_expression_ Calculate Final Personalization _01_ ### Request _input_ Requests identify the trip by flightId and routeId, while the personalization tables read customer context fields such as customer.deviceType, customer.loyaltyStatus, customer.visitSource, and customer.bookingHistory; anything missing simply falls through to the default rows. **Sample request**_JSON_ { "flightId": "FL-123", "routeId": "JFK-LAX", "daysToDepature": 5, "basePrice": 250, "availableSeats": 35, "totalSeats": 180, "demandForecast": 75, "avgCompetitorPrice": 275 } _02_ ### Device Type Personalization _table_ Screen size drives the first branch: a customer.deviceType of 'mobile' returns 'compactSearch', 'simplifiedNavigation', and 'touchFriendlyControls' with a 'compact' layout that hides extras, 'tablet' and 'desktop' rows step up to 'medium' and 'full' layouts with 'detailedFilters' on desktop, and a blank catch-all serves a 'standard' layout under the first hit policy. Suppressing ancillary content on phones and reserving detailed filters for desktop follows conversion practice on airline booking sites, where small screens punish dense fare displays. These are UX conventions rather than regulatory requirements, so a carrier would tune the element lists against its own funnel data. Device Typecustomer.deviceType UI Elementspersonalization.uiElements Layout Configurationpersonalization.layoutConfig 'mobile' \['compactSearch', 'simplifiedNavigation', 'touchFriendlyControls'\] { 'type': 'compact', 'imageSize': 'small', 'showExtras': false } 'tablet' \['touchFriendlyControls', 'mediumSearch', 'fullNavigation'\] { 'type': 'medium', 'imageSize': 'medium', 'showExtras': true } 'desktop' \['expandedSearch', 'fullNavigation', 'detailedFilters'\] { 'type': 'full', 'imageSize': 'large', 'showExtras': true } \- \['standardSearch', 'standardNavigation'\] { 'type': 'standard', 'imageSize': 'medium', 'showExtras': true } _03_ ### Loyalty Status Personalization _table_ Tier recognition is a straight ladder on customer.loyaltyStatus with first hit: 'platinum' gets priority 1, a discountPercentage of 15, and features including 'conciergeService' and 'exclusiveDeals'; 'gold' and 'silver' step down to 10 and 5 with smaller feature sets; and both 'none' and the blank fallback land at priority 4 with 0 discount and a 'joinLoyaltyBanner'. A three-tier elite ladder with escalating soft benefits mirrors how most frequent-flyer programs are built, and showing enrollment prompts to non-members instead of discounts is standard acquisition practice. The 15/10/5 percentages are plausible loyalty economics but a commercial choice, not anything mandated. Loyalty Statuscustomer.loyaltyStatus Customer Prioritypersonalization.customerPriority Features to Showpersonalization.loyaltyFeatures Discount Percentagepersonalization.baseDiscountPercentage 'platinum' 1 \['priorityBooking', 'exclusiveDeals', 'conciergeService', 'upgradeOffers'\] 15 'gold' 2 \['priorityBooking', 'memberDeals', 'upgradeOffers'\] 10 'silver' 3 \['memberDeals', 'basicUpgrades'\] 5 'none' 4 \['joinLoyaltyBanner', 'standardOptions'\] 0 \- 4 \['joinLoyaltyBanner', 'standardOptions'\] 0 _04_ ### Visit Source Personalization _table_ Channel attribution decides which promotion surface appears: a customer.visitSource of 'partner\_site' carries the largest addDiscount at 5, 'social\_media' gets 3 with 'socialMediaDeals', 'email\_campaign' gets 2, 'search\_engine' shows 'searchSpecials' with 0 extra, 'direct' traffic sees no special offers at all, and a blank fallback serves 'standardOffers'. Giving the deepest incentives to partner and social traffic while direct visitors get none reflects plain channel economics: direct bookers already show intent and need no inducement, while paid and referred channels are where airlines spend to convert. The exact 5/3/2 spread is marketing calibration, not an industry rule. Visit Sourcecustomer.visitSource Show Special Offerspersonalization.showSpecialOffers Special Offers Typepersonalization.specialOffersType Additional Discountpersonalization.additionalDiscountPercentage 'email\_campaign' true 'emailPromotions' 2 'search\_engine' true 'searchSpecials' 0 'social\_media' true 'socialMediaDeals' 3 'partner\_site' true 'partnerOffers' 5 'direct' false 'none' 0 \- false 'standardOffers' 0 _05_ ### Booking History Personalization _table_ Past behavior is bucketed on two counters read together under first hit: totalBookings above 10 with recentBookings above 2 marks a 'frequentTraveler' with showRecentlyViewed switched on and a discount of 3, more than 5 bookings with recent activity is a 'regularCustomer' at 2, any history with recentBookings == 0 is a lapsed 'returningCustomer' at 1, and zero bookings makes a 'newCustomer' with nothing extra. Pairing a recent-bookings window with lifetime volume is the classic recency-frequency split airlines and travel platforms use to tell active frequent flyers from lapsed ones, and reserving the recently-viewed module for active customers avoids surfacing stale content. The cutoffs of 10 and 5 bookings are sensible segmentation choices rather than fixed industry standards. Total Bookingscustomer.bookingHistory.totalBookings Recent Bookings (Last 90 Days)customer.bookingHistory.recentBookings Recommendation Typepersonalization.recommendationType Show Recently Viewedpersonalization.showRecentlyViewed History Discountpersonalization.historyDiscountPercentage \> 10 \> 2 'frequentTraveler' true 3 \> 5 \> 1 'regularCustomer' true 2 \> 0 \== 0 'returningCustomer' false 1 \== 0 \== 0 'newCustomer' false 0 \- \- 'standard' false 0 _06_ ### Calculate Personalization Score _table_ Score assignment cross-tabulates three signals: whether customer.bookingHistory.totalBookings is above 0, the loyalty-derived customerPriority, and whether customer.visitSource is 'social\_media' or 'partner\_site'. Under first hit, a priority-1 member with history arriving from a promoted channel scores the maximum 65, the same member from other channels scores 50, each lower priority tier sheds roughly 10 to 15 points, first-time visitors with top status still earn 30, and the bare catch-all bottoms out at 5. Weighting booking history and elite tier ahead of arrival channel matches how personalization teams rank signal quality, since owned behavioral data is more predictive than referral context. The point values themselves are arbitrary rungs on an internal scale; what matters is that they line up with the 50/30/10 template thresholds applied in the next step. Has Previous Bookingscustomer.bookingHistory.totalBookings Loyalty Prioritypersonalization.customerPriority Visit Sourcecustomer.visitSource Personalization Scorepersonalization.personalizationScore \> 0 1 'social\_media', 'partner\_site' 65 \> 0 1 \- 50 \> 0 2 'social\_media', 'partner\_site' 55 \> 0 2 \- 40 \> 0 3 'social\_media', 'partner\_site' 45 \> 0 3 \- 30 +7 more rows in the downloadable template _07_ ### Calculate Final Personalization _expression_ Three closing values wrap the run: totalDiscountPercentage sums the base, additional, and history discount percentages, bookingFlowTemplate maps personalizationScore through breaks at 50, 30, and 10 into 'premium', 'enhanced', 'standard', or 'basic', and allFeatures flattens uiElements together with loyaltyFeatures into a single list. Summing the three discounts additively is what makes the earlier tables composable instead of mutually exclusive. _totalDiscountPercentage_`number(personalization.baseDiscountPercentage) + number(personalization.additionalDiscountPercentage) + number(personalization.historyDiscountPercentage)` _bookingFlowTemplate_`personalization.personalizationScore > 50 ? 'premium' : personalization.personalizationScore > 30 ? 'enhanced' : personalization.personalizationScore > 10 ? 'standard' : 'basic'` _allFeatures_`flatten([personalization.uiElements, personalization.loyaltyFeatures])` ## Other Aviation templates [View all templates](/templates) [_Aviation_ ### Flight Dispatch Decision System Rules-based aviation system that evaluates weather, aircraft, crew, and weight factors to ensure regulatory compliance and safe flight operations. ](/industries/aviation/templates/flight-dispatch-decision-system)[_Aviation_ ### Dynamic Airline Ticket Pricing Engine Automated fare optimization system that sets ticket prices based on time to departure, seat availability, market demand, and competitor pricing. ](/industries/aviation/templates/dynamic-ticket-pricing)[_Aviation_ ### Flight Ancillary Recommendations Data-driven system that personalizes travel add-on recommendations based on customer profile, route details, and previous purchasing behavior. ](/industries/aviation/templates/flight-ancillary-recommendations) ## Make this template your own. Load Booking Personalization System into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Booking Fraud Detection - GoRules **URL:** https://gorules.io/industries/aviation/templates/booking-fraud-detection **Description:** Advanced risk assessment that evaluates payment methods, booking patterns, and account behavior to prevent travel reservation fraud. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Booking Fraud Detection Advanced risk assessment that evaluates payment methods, booking patterns, and account behavior to prevent travel reservation fraud. Download template Share ### Solution This fraud detection safeguards airlines and travel agencies by analyzing multiple risk factors in booking transactions. It evaluates payment methods with specialized risk scoring for prepaid cards, gift cards, and cryptocurrency transactions. The system flags suspicious booking patterns by monitoring transaction frequency and detecting geographic mismatches between account country and IP location. For additional protection, it analyzes account history including account age and previous chargebacks. When suspicious activity is detected, the system automatically assigns risk levels (low, medium, high) based on cumulative risk scores from all factors. High-risk bookings trigger mandatory verification requirements and can be routed for manual review, while low-risk transactions proceed normally. This multi-layered approach prevents financial losses while maintaining a smooth booking experience for legitimate customers. ### How it works The decision graph processes booking data through multiple evaluation nodes: 1. **Payment Risk Analysis**: Evaluates transaction risk based on payment method and amount, assigning higher scores to prepaid cards with large amounts. 2. **Pattern Detection**: Identifies suspicious behavior patterns such as multiple rapid bookings or transactions from countries different than the account's registered location. 3. **Account History Verification**: Assesses risk based on account age and previous chargeback history, with new accounts receiving higher risk scores. 4. **Risk Aggregation**: Calculates a total risk score by combining individual risk factors and collects all risk reasons for review. 5. **Risk Level Classification**: Categorizes transactions as low, medium, or high risk based on the total risk score. 6. **Action Flags**: Sets verification requirements and manual review flags based on the assigned risk level. ### Where teams use it - Airline ticket reservation systems - Hotel booking platforms - Car rental services - Travel package websites - Airport lounge access systems - Frequent flyer program protection ## Inside the decision model Booking Fraud Detection ships as a JDM decision graph with 7 nodes, 4 decision tables and 20 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ payment\_risk_table_ pattern\_risk_table_ account\_risk_expression_ risk\_calculation_table_ risk\_level_expression_ flags _01_ ### Request _input_ Only two request objects are needed: booking carries payment\_method, amount, and ip\_country, while account carries country and bookings\_last\_24h; the three risk tables read them in parallel. **Sample request**_JSON_ { "booking": { "payment\_method": "prepaid\_card", "amount": 2500, "ip\_country": "US" }, "account": { "country": "US", "bookings\_last\_24h": 6 } } _02_ ### Payment Risk _table_ Payment instruments are ranked by abuse potential under first hit: a 'prepaid\_card' with booking.amount above 2000 scores 40 as a 'High-value prepaid card transaction', prepaid without the amount trigger scores 20, 'gift\_card' rows score 30 above 1000 or 15 otherwise, 'cryptocurrency' takes a flat 25, a 'credit\_card' only registers 15 above 3000, and the catch-all writes 0 for a 'Standard transaction'. Weighting prepaid and gift instruments hardest follows card-not-present fraud experience: both are favored cash-out tools because they detach the payment from a verifiable cardholder identity, and cryptocurrency removes chargeback recourse entirely. Credit cards score only at high amounts since issuer-side authentication already covers them; the 2000, 1000, and 3000 cutoffs are risk-team calibration, not any card-scheme mandate. Payment Methodbooking.payment\_method Transaction Amountbooking.amount Payment Risk Scorerisk.payment.score Payment Risk Reasonrisk.payment.reason 'prepaid\_card' \> 2000 40 'High-value prepaid card transaction' 'prepaid\_card' \- 20 'Prepaid card transaction' 'gift\_card' \> 1000 30 'High-value gift card transaction' 'gift\_card' \- 15 'Gift card transaction' 'cryptocurrency' \- 25 'Cryptocurrency transaction' 'credit\_card' \> 3000 15 'High-value credit card transaction' +1 more row in the downloadable template _03_ ### Pattern Risk _table_ Velocity and geography combine under first hit: account.bookings\_last\_24h above 5 together with account.country != booking.ip\_country scores the maximum 50 as 'Multiple bookings from different country', the same velocity alone scores 30, more than 3 bookings scores 35 with a mismatch or 20 without, a mismatch by itself scores 25, and the clean row returns 0 for a 'Normal booking pattern'. Stacking a country mismatch on top of velocity reflects how stolen-credential fraud actually presents: bursts of purchases routed through a foreign IP. More than five bookings in 24 hours would be extreme for a genuine consumer, so these thresholds are sensible business tuning; no regulation prescribes them. Recent Bookings 24haccount.bookings\_last\_24h Account Countryaccount.country Pattern Risk Scorerisk.pattern.score Pattern Risk Reasonrisk.pattern.reason \> 5 != booking.ip\_country 50 'Multiple bookings from different country' \> 5 \- 30 'Multiple rapid bookings' \> 3 != booking.ip\_country 35 'Several bookings from different country' \> 3 \- 20 'Several rapid bookings' \- != booking.ip\_country 25 'Booking from different country' \- \- 0 'Normal booking pattern' _04_ ### Account Risk _table_ Account maturity feeds the third score: account.age\_days under 30 scores 40 as a 'New account with significant transaction', under 90 scores 20 as 'Relatively new account', a further row on the same field scores 15 carrying the 'Previous chargeback history' reason, and the fallback returns 0 for 'Normal account history'. Young accounts scoring highest is standard fraud logic, since fraudsters register throwaway accounts shortly before attacking, which makes age one of the strongest cheap signals available. The 30 and 90 day breakpoints are conventional review windows in risk operations rather than mandated periods. Account Age (days)account.age\_days Account Risk Scorerisk.account.score Account Risk Reasonrisk.account.reason < 30 40 'New account with significant transaction' < 90 20 'Relatively new account' \> 1 15 'Previous chargeback history' \- 0 'Normal account history' _05_ ### Risk Calculation _expression_ Aggregation happens in two folds over the risk object: total\_risk\_score sums map(values(risk), #.score) across the payment, pattern, and account branches, and risk\_factors collects the reason text from every branch whose score is above 0. Keeping the human-readable reasons next to the number is what makes a later manual review actionable. _total\_risk\_score_`sum( map(values(risk), #.score) )` _risk\_factors_`map( filter(values(risk), #.score > 0), #.reason )` _06_ ### Risk Level _table_ Classification is a simple band on total\_risk\_score with first hit: 70 or more maps to "high", 30 or more to "medium", and anything below falls through to "low". Three bands are the practical minimum for a fraud queue - approve, challenge, review - and the 70/30 cut points are tuned against the upstream scores so a single strong signal lands in "medium" while it takes stacked signals to reach "high". They are operational calibration, not an industry scale. Total risk scoretotal\_risk\_score Risk levelrisk\_level \>= 70 "high" \>= 30 "medium" \- "low" _07_ ### Flags _expression_ Action bits come last: flags.requires\_verification is set when risk\_level lands in \["medium", "high"\], and flags.manual\_review only when risk\_level == "high". Splitting the two keeps friction proportionate, with step-up verification for the middle band and human review reserved for the worst cases. _flags.requires\_verification_`risk_level in ["medium", "high"]` _flags.manual\_review_`risk_level == "high"` ## Other Aviation templates [View all templates](/templates) [_Aviation_ ### Flight Dispatch Decision System Rules-based aviation system that evaluates weather, aircraft, crew, and weight factors to ensure regulatory compliance and safe flight operations. ](/industries/aviation/templates/flight-dispatch-decision-system)[_Aviation_ ### Dynamic Airline Ticket Pricing Engine Automated fare optimization system that sets ticket prices based on time to departure, seat availability, market demand, and competitor pricing. ](/industries/aviation/templates/dynamic-ticket-pricing)[_Aviation_ ### Booking Personalization System Dynamic flight booking platform that tailors UI, discounts, and features based on customer loyalty status, device type, booking history, and traffic source. ](/industries/aviation/templates/booking-personalization-system) ## Make this template your own. Load Booking Fraud Detection into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Airline Upgrade Eligibility - GoRules **URL:** https://gorules.io/industries/aviation/templates/airline-upgrade-eligibility **Description:** Advanced passenger upgrade decision engine that evaluates loyalty status, fare class, corporate agreements, and cabin availability to prioritize upgrades. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Airline Upgrade Eligibility Advanced passenger upgrade decision engine that evaluates loyalty status, fare class, corporate agreements, and cabin availability to prioritize upgrades. Download template Share ### Solution This airline upgrade system uses a point-based approach to fairly determine which passengers receive complimentary cabin upgrades. It first verifies basic eligibility by confirming ticket status, flight status, and completed check-in. For eligible passengers, the system assigns points based on three key factors: loyalty program status and accumulated miles, current fare class, and corporate agreement level. The scoring mechanism prioritizes high-value customers, with platinum and gold loyalty members receiving the highest consideration. Passengers in premium fare classes and those from companies with premier-level corporate agreements receive additional points. The system dynamically adjusts scores based on cabin availability, increasing upgrade chances when more seats are available and restricting them during high-demand flights. This balanced approach ensures upgrades are distributed to the most valuable customers while maximizing cabin utilization. ### How it works The decision flow processes passenger information through several sequential evaluation stages: 1. **Basic Eligibility Check**: Verifies ticket confirmation, active flight status, and completed check-in process. 2. **Loyalty Score Calculation**: Assigns points based on loyalty tier (platinum, gold, silver, member) with additional points for higher mileage thresholds. 3. **Fare Class Evaluation**: Allocates points based on the passenger's purchased fare class, with premium classes receiving more points. 4. **Corporate Agreement Assessment**: Adds points for passengers traveling under corporate agreements, with premier-level agreements receiving priority. 5. **Cabin Availability Adjustment**: Applies a multiplier to the total score based on available seats in the target cabin. 6. **Final Eligibility Determination**: Compares the final adjusted score against thresholds to determine upgrade eligibility and type (premium or standard). ### Where teams use it - Airlines with tiered loyalty programs - Business-focused carriers with corporate agreements - International long-haul flights with premium cabins - Airlines seeking to maximize premium cabin utilization - Carriers with sophisticated customer relationship management - Airlines looking to improve loyalty member satisfaction ## Inside the decision model Airline Upgrade Eligibility ships as a JDM decision graph with 7 nodes, 5 decision tables and 27 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ checkBasicEligibility_table_ calculateLoyaltyScore_table_ calculateFareScore_table_ checkCorporateAgreement_expression_ evaluateCabinAvailability_table_ determineUpgradeEligibility _01_ ### Request _input_ Three request blocks matter: passenger carries ticketStatus, loyaltyStatus, loyaltyMiles, and fareClass; flight contributes cabinAvailability; and corporate supplies agreementLevel and upgradeEligible. **Sample request**_JSON_ { "passenger": { "id": "P123456", "name": "Jane Smith", "ticketStatus": "confirmed", "flightStatus": "scheduled", "checkInStatus": "completed", "loyaltyStatus": "gold", "loyaltyMiles": 82500, "fareClass": "premium economy" }, "flight": { "flightNumber": "FL789", "departureDate": "2025-04-15", "route": "LHR-JFK", "cabinAvailability": 7 }, "corporate": { "agreementLevel": "premier", "upgradeEligible": true, "companyName": "Acme Corporation" } } _02_ ### Check Basic Eligibility _table_ Gatekeeping happens before any points are scored: with first hit ordering the table returns isEligible false as soon as passenger.ticketStatus deviates from 'confirmed', with dedicated rows mapping 'cancelled' to 'Flight cancelled' and non-'completed' states to 'Check-in not completed', and only the blank catch-all confirms 'Basic eligibility confirmed'. Running hard disqualifiers ahead of scoring mirrors how upgrade queues work in practice: a passenger without a confirmed ticket, on a cancelled flight, or not checked in cannot take a premium seat no matter their status, so filtering first keeps the scored pool clean. These are operational preconditions, not point tradeoffs, which is why they short-circuit instead of subtracting. Ticket statuspassenger.ticketStatus IsEligiblebasicEligibility.isEligible ReasonbasicEligibility.reason != 'confirmed' false 'Ticket not confirmed' 'cancelled' false 'Flight cancelled' != 'completed' false 'Check-in not completed' \- true 'Basic eligibility confirmed' _03_ ### Calculate Loyalty Score _table_ Points for status pair each tier with a mileage kicker under first hit: 'platinum' scores 50 with passenger.loyaltyMiles above 100000 or 40 otherwise, 'gold' scores 35 above 75000 or 30, 'silver' 25 above 50000 or 20, base 'member' 15 above 25000 or 10, and an unknown status scores 0. Letting tier dominate with miles as a tiebreaker matches how airlines sequence complimentary upgrade lists, where published elite level orders the queue and activity breaks ties within it. The 25000 through 100000 mileage rungs echo familiar qualification bands in frequent-flyer programs, though the point values themselves are internal weighting choices. Statuspassenger.loyaltyStatus Milespassenger.loyaltyMiles Scorescores.loyalty 'platinum' \> 100000 50 'platinum' \- 40 'gold' \> 75000 35 'gold' \- 30 'silver' \> 50000 25 'silver' \- 20 +3 more rows in the downloadable template _04_ ### Calculate Fare Score _table_ Fare paid earns its own points on passenger.fareClass: 'business' takes 30, 'premium economy' 20, 'economy flex' 15, 'economy standard' 10, 'economy basic' 5, and anything unrecognized 0, evaluated first hit down the list. Ranking upgrade priority by fare value follows standard revenue-based upgrade logic: the passenger who paid more, or bought a flexible fare, represents more yield and is rewarded first. Giving 'economy basic' a token 5 keeps the cheapest fares technically in the queue without letting them outrank flexible tickets. FareClasspassenger.fareClass Scorescores.fare 'business' 30 'premium economy' 20 'economy flex' 15 'economy standard' 10 'economy basic' 5 \- 0 _05_ ### Check Corporate Agreement _table_ Contracted business travel adds the final block: a corporate.agreementLevel of 'premier' with corporate.upgradeEligible true scores 25, 'standard' with the flag scores 15, any non-null agreement without the flag still collects 5, and no agreement scores 0. Corporate deals shaping upgrade priority is common on business-heavy routes, where perks like upgrade priority are negotiated into the account relationship. Requiring the upgradeEligible flag rather than just an agreement respects that only some contracts include upgrade clauses; the residual 5 acknowledges the account without granting the perk. Agreement Levelcorporate.agreementLevel Eligiblecorporate.upgradeEligible Scorescores.corporate 'premier' true 25 'standard' true 15 != null \- 5 \- \- 0 _06_ ### Evaluate Cabin Availability _expression_ Supply then reshapes demand: totalScore sums scores.loyalty, scores.fare, and scores.corporate, cabinMultiplier steps from 1.2 when flight.cabinAvailability exceeds 10 down through 1.0 and 0.8 to 0.5 at 2 seats or fewer, and finalScore multiplies the two. Scaling the whole queue by open seats loosens upgrades on empty premium cabins and throttles them while the inventory is still sellable. _totalScore_`scores.loyalty + scores.fare + scores.corporate` _cabinMultiplier_`flight.cabinAvailability > 10 ? 1.2 : flight.cabinAvailability > 5 ? 1.0 : flight.cabinAvailability > 2 ? 0.8 : 0.5` _finalScore_`$.totalScore * $.cabinMultiplier` _07_ ### Determine Upgrade Eligibility _table_ Four ordered conditions settle the outcome: basicEligibility.isEligible == false fails immediately and echoes the earlier reason with a score of 0, finalScore >= 75 returns 'Premium upgrade approved', finalScore >= 50 returns 'Standard upgrade approved', and the default row declines with 'Insufficient score for upgrade' while still reporting the finalScore. Two approval thresholds turn one scale into two grades of outcome, which lets a carrier distinguish a premium from a standard upgrade without running a second model. Returning the score even on refusal is a sensible transparency choice for agents auditing the queue; the 75 and 50 cut points are calibration against the upstream point values. Condition Eligibleresult.isEligible Reasonresult.reason Scoreresult.score basicEligibility.isEligible == false false basicEligibility.reason 0 finalScore >= 75 true 'Premium upgrade approved' finalScore finalScore >= 50 true 'Standard upgrade approved' finalScore \- false 'Insufficient score for upgrade' finalScore ## Other Aviation templates [View all templates](/templates) [_Aviation_ ### Flight Dispatch Decision System Rules-based aviation system that evaluates weather, aircraft, crew, and weight factors to ensure regulatory compliance and safe flight operations. ](/industries/aviation/templates/flight-dispatch-decision-system)[_Aviation_ ### Dynamic Airline Ticket Pricing Engine Automated fare optimization system that sets ticket prices based on time to departure, seat availability, market demand, and competitor pricing. ](/industries/aviation/templates/dynamic-ticket-pricing)[_Aviation_ ### Booking Personalization System Dynamic flight booking platform that tailors UI, discounts, and features based on customer loyalty status, device type, booking history, and traffic source. ](/industries/aviation/templates/booking-personalization-system) ## Make this template your own. Load Airline Upgrade Eligibility into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) --- ## Airline Loyalty Points Calculator - GoRules **URL:** https://gorules.io/industries/aviation/templates/airline-loyalty-points-calculations **Description:** Advanced system for calculating airline loyalty program points based on fare class, route type, distance, member status, and seasonal promotions. v2.0 GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here! Watch the launch videoWatch # Airline Loyalty Points Calculator Advanced system for calculating airline loyalty program points based on fare class, route type, distance, member status, and seasonal promotions. Download template Share ### Solution This loyalty points calculator automatically determines the exact number of points earned for each booking by evaluating multiple factors simultaneously. The system first applies a multiplier based on fare class, with premium cabins like First and Business receiving higher multipliers than Economy options. Route evaluation considers both flight type (Domestic vs International) and actual distance traveled, assigning appropriate base points accordingly. Member status levels (Platinum, Gold, Silver) significantly impact point earnings through status-specific multipliers that reward program loyalty. The system also accounts for seasonal promotions, automatically applying bonus multipliers during special periods. All factors are combined into a precise point calculation that's immediately available after booking confirmation, eliminating manual calculations and ensuring members receive accurate, consistent rewards regardless of booking channel or complexity. ### How it works The loyalty points calculator processes each booking through four sequential decision components: 1. **Fare Class Evaluation**: Analyzes the booking cabin class (First, Business, Premium Economy, etc.) and assigns the appropriate earning multiplier, ranging from 1.0 to 3.0. 2. **Route Assessment**: Determines base points by evaluating both route type (Domestic/International) and actual flight distance, with longer international routes earning substantially more points. 3. **Status Multiplier**: Applies member-specific multipliers based on loyalty tier status, with premium tiers receiving higher point multiples (up to 2x for Platinum). 4. **Promotion Handling**: Checks for seasonal promotion eligibility and applies a 50% bonus when applicable. 5. **Points Calculation**: Multiplies all factors together and rounds to the nearest whole number to determine the final point award. ### Where teams use it - Airline loyalty programs and frequent flyer schemes - Co-branded credit card point earning calculations - Partner airline mileage accrual - Corporate travel reward programs - Alliance-wide points standardization - Promotional campaign point bonuses ## Inside the decision model Airline Loyalty Points Calculator ships as a JDM decision graph with 5 nodes, 3 decision tables and 16 rules. Download it, load it into GoRules, and run it as-is on Zen Engine. _input_ request_table_ fareClassMultiplier_table_ routeBasePoints_table_ memberStatusMultiplier_expression_ calculateTotalPoints _01_ ### Request _input_ Accrual needs just two objects: booking with fareClass, routeType, distance, and isSeasonalPromotion, and member with the status tier; ids and enrollment details ride along without affecting the math. **Sample request**_JSON_ { "booking": { "fareClass": "Business", "routeType": "International", "distance": 3500, "isSeasonalPromotion": true }, "member": { "status": "Gold", "id": "MEM12345", "name": "John Smith", "enrollmentDate": "2020-05-15" } } _02_ ### Fare Class Multiplier _table_ Cabin sets the first factor on booking.fareClass with first hit: 'First' earns a fareMultiplier of 3, 'Business' 2, 'Premium Economy' 1.5, 'Economy Plus' 1.25, and any other fare defaults to 1. Scaling accrual with cabin is how revenue-based and hybrid loyalty programs keep earn roughly proportional to ticket yield, since a First fare can cost several times an Economy one. The 3x-to-1x ladder is a typical program design range, but the exact multipliers are commercial choices rather than an alliance or IATA standard. Fare Classbooking.fareClass Fare Multiplierpoints.fareMultiplier 'First' 3 'Business' 2 'Premium Economy' 1.5 'Economy Plus' 1.25 \- 1 _03_ ### Route Base Points _table_ Base points come from crossing booking.routeType with booking.distance: 'Domestic' sectors earn 250 under 500 miles, 500 in the \[500..1000\] band, and 750 beyond it, while 'International' earns 1000 under 2000 miles, 2000 in the \[2000..5000\] band, and 3000 past 5000, with a 500-point fallback when neither field matches. Banded awards instead of exact per-mile accrual make earnings easier for members to predict and simpler for partners to settle, a pattern many programs adopted when moving away from pure mileage earning. The international premium reflects the higher fares and strategic value of long-haul flying; the band edges themselves are program design, not regulation. Route Typebooking.routeType Distance (miles)booking.distance Base Pointspoints.basePoints 'Domestic' < 500 250 'Domestic' \[500..1000\] 500 'Domestic' \> 1000 750 'International' < 2000 1000 'International' \[2000..5000\] 2000 'International' \> 5000 3000 +1 more row in the downloadable template _04_ ### Member Status Multiplier _table_ Elite tier applies the third factor from member.status: 'Platinum' doubles earnings with a statusMultiplier of 2, 'Gold' takes 1.5, 'Silver' 1.25, and everyone else 1. Status bonuses in the 25% to 100% range mirror the elite earning boosts real frequent-flyer programs publish, and they are among the cheaper elite benefits to fund since points are a deferred liability. The specific 2, 1.5, and 1.25 steps are conventional but entirely discretionary. Member Statusmember.status Status Multiplierpoints.statusMultiplier 'Platinum' 2 'Gold' 1.5 'Silver' 1.25 \- 1 _05_ ### Calculate Total Points _expression_ Final math runs as one chain: seasonalPromotion resolves to 1.5 when booking.isSeasonalPromotion is true and 1 otherwise, then calculatedPoints takes floor(points.basePoints \* points.fareMultiplier \* points.statusMultiplier \* seasonalPromotion) and totalPoints exposes the result. Flooring matters because loyalty ledgers post whole points, and multiplying keeps every bonus proportional instead of stacking additively. _seasonalPromotion_`booking.isSeasonalPromotion == true ? 1.5 : 1` _calculatedPoints_`floor(points.basePoints * points.fareMultiplier * points.statusMultiplier * $.seasonalPromotion)` _totalPoints_`$.calculatedPoints` ## Other Aviation templates [View all templates](/templates) [_Aviation_ ### Flight Dispatch Decision System Rules-based aviation system that evaluates weather, aircraft, crew, and weight factors to ensure regulatory compliance and safe flight operations. ](/industries/aviation/templates/flight-dispatch-decision-system)[_Aviation_ ### Dynamic Airline Ticket Pricing Engine Automated fare optimization system that sets ticket prices based on time to departure, seat availability, market demand, and competitor pricing. ](/industries/aviation/templates/dynamic-ticket-pricing)[_Aviation_ ### Booking Personalization System Dynamic flight booking platform that tailors UI, discounts, and features based on customer loyalty status, device type, booking history, and traffic source. ](/industries/aviation/templates/booking-personalization-system) ## Make this template your own. Load Airline Loyalty Points Calculator into GoRules, adjust the rules to your policy, and ship it behind your own API. [Get started](https://us1.gorules.io) [Book a demo](/contact-us) ---