GoRules Version 2 is here

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 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.

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.

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.

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.

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.

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.

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.
• 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.
• 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 and self-hosted. Open your workspace, or talk to an engineer about what it changes for your team.