Newsletter
Join the Community
Subscribe to our newsletter for the latest news and updates
Welcome to this GoRules review 😊!
Business rules often begin as a few if statements, then spread across services, spreadsheets, policy documents, and tribal knowledge. The hard part is no longer writing one condition—it is letting business teams change policy without breaking production, while keeping every decision testable and explainable.
GoRules tackles that problem as a business rules management system (BRMS). It combines readable rules, decision tables, visual flows, AI-assisted authoring, Git-style change control, managed or self-hosted deployment, and the open-source ZEN execution engine.
I reviewed the current GoRules V2 public product experience, feature pages, version-control workflow, open-source runtime, and both cloud and self-hosted pricing. I did not create an organization or deploy a production decision model, so this review does not claim to benchmark private dashboard usability, support quality, or real-world latency. Let's dive in! 🚀
GoRules makes its operating model unusually clear before signup. Business logic is authored and reviewed inside the BRMS, packaged as a versioned release, then evaluated through the hosted Agent, an embedded SDK, or a batch pipeline. The public walkthrough uses lending rules, but the same pattern fits pricing, eligibility, underwriting, fraud checks, routing, and promotions.
GoRules presents version history, approval flows, and environment promotion as parts of one BRMS workflow.
The interface shown publicly is clean and concrete rather than abstract enterprise software. Version history looks familiar to developers, while visual diffs and approval cards are understandable to analysts and compliance teams. The product's strongest first impression is not any single editor—it is that authoring, testing, review, and release all live in the same lifecycle.
GoRules is also listed in the Turbo0 product directory, alongside more tools in management software and platforms.
The authoring layer is designed to reduce the translation gap between a policy owner and an engineer. Conditions can be displayed like business sentences, while the developer representation remains available behind a toggle. Decision tables, expressions, functions, and switches can be combined on a visual graph.
GoRules displays a lending rule as a sentence and connects it to a broader decision canvas.
This is the heart of the product. A readable editor alone can become another document that drifts from code; GoRules is more convincing because the same model is executable and testable. The caveat is that teams still need disciplined schemas, ownership, and review rules—visual tooling does not remove policy complexity 💡.
GoRules AI can ingest policy PDFs, spreadsheets, or plain-language requirements and turn them into tables and decision graphs. Users can then refine thresholds conversationally, ask why a decision occurred, and generate scenario tests for edge cases.
GoRules AI turns policy documents into reviewable decision models while keeping release control with people.
The governance boundary is well chosen: AI drafts, edits, explains, and tests, but it does not silently deploy. A human reviewer approves the change, and a human-controlled release moves it toward production. GoRules also advertises an MCP server so tools such as Claude, Cursor, Codex, or another MCP client can edit rules, run tests, and explain decisions through governed drafts.
That makes AI useful without treating generated policy as trusted by default. I especially like the emphasis on reviewable diffs and generated tests. The remaining question is practical accuracy: policy documents are full of exceptions, cross-references, and ambiguous language, so teams should treat import as a strong starting point—not an automatic migration 🤖.
Most rules engines can evaluate conditions; fewer make change management understandable outside engineering. GoRules brings branches, commits, visual diffs, merge reviews, release tags, history, and rollback into the business-rule workflow.
GoRules shows policy history and a cell-level decision-table diff without requiring analysts to use Git.
A change can be isolated on a branch, tested, reviewed as a visual diff, merged, and promoted through development, staging, and production. Releases remain immutable between environments, which reduces the chance that “the same” policy behaves differently after a manual rebuild. Approval flows and audit logs record who changed, reviewed, and released the logic.
This is where GoRules looks most enterprise-ready. Financial services, insurance, healthcare, and other regulated teams need more than a rule editor—they need evidence of who changed what, when, and why. GoRules claims SOC 2 Type II compliance, while higher plans add audit logs, enforced reviews, SSO, and stronger release controls. Buyers should still validate those controls against their own compliance requirements rather than treating a feature list as certification coverage.
The execution layer is not locked inside the hosted product. The ZEN engine is MIT licensed, written in Rust, and available through native bindings for TypeScript/JavaScript, Python, Go, Rust, Java, Kotlin, C#, and Swift.
GoRules offers the Rust-based ZEN engine as an MIT-licensed, in-process decision runtime.
ZEN can run inside an application process, serverless function, device, or service without a network call to GoRules. The same decision model can also run through GoRules Agent or over large datasets in Spark and batch jobs. This separation is valuable: the BRMS manages lifecycle and governance, while the engine evaluates decisions wherever the workload lives.
The open core lowers vendor-lock-in risk and gives developers a credible path to experiment before adopting the full platform. It does not make the complete BRMS free or open source; collaboration, managed environments, approvals, audit features, AI allowances, and enterprise support depend on the selected commercial plan. That boundary is reasonable, but teams should map exactly which governance features they need before designing around the free engine.
GoRules publishes separate pricing for managed Cloud and self-hosted deployments. The screenshot below shows annual Cloud billing; monthly billing and self-hosted plans use different prices.
GoRules Cloud annual pricing includes a free BRMS tier, paid deployment environments, AI credits, and enterprise governance options.
Managed Cloud, billed annually:
Self-hosted: Free runs on your infrastructure; Team is €50/month; Business is €500/month; Enterprise is custom. The self-hosted AI route uses your own model and provider key, so GoRules does not charge AI credits there.
The free tiers are useful for evaluating the model, but production governance becomes a meaningful software budget. That is defensible for high-value decisions, yet smaller teams should compare the cost of GoRules with the engineering and audit burden it replaces—not only with another SaaS seat price.
GoRules V2 positions readable rules, testing, governed releases, and open execution as one decision layer.
That's the end of this GoRules review!
GoRules has a coherent architecture: write policy in a form business teams can read, test the actual executable model, review every change, and run the same decision logic wherever the application needs it. The combination of a governed BRMS and an MIT-licensed runtime is more compelling than either piece would be alone.
What I loved:
Points to consider:
If changing business policy safely is becoming harder than evaluating the policy itself, GoRules is worth a serious pilot. Start with one decision that already causes friction, model its edge cases, and verify the full path from draft to production before expanding 🚀.
