Code Effects vs GoRules:
Embedded .NET Rules vs a Rust Decision Engine

Short answer: GoRules is a business rules platform built around ZEN, an open-source (MIT) decision engine written in Rust with bindings for Node.js, Python, Go, Rust, Java, Kotlin, C#, Swift and WebAssembly. Rules are JSON Decision Model (JDM) files - decision graphs of decision tables, switches, expressions and JavaScript/TypeScript function nodes - managed in the commercial GoRules BRMS, which runs in GoRules' cloud or as a self-hosted Docker service, with branches, change requests, releases to environments, GoRules AI and an MCP server. Code Effects is an embeddable decision management platform for .NET: a web-based Rule Editor in which people build rules as plain-language sentences from menus of your own data, and a stateless, thread-safe Rule Engine that compiles those rules and evaluates them against your own .NET objects, in-process. Code Effects 7 adds an optional Rule Repository with versions, approvals and testing, Audit for decision explainability, built-in AI tools that use the models your application registers, and an MCP server that lets AI agents write and test rules under human approval - all inside your own web application, on your own sign-in, with data in a database you own. GoRules is the stronger fit for polyglot stacks that want one free engine in many languages; Code Effects is the stronger fit for .NET teams that want rule authoring, rule management and production audit to become part of their own application.

One rule, one readable text - even in an AI conversation. A Code Effects rule, however complex - collections, calls to your own methods, IF / ELSE IF / ELSE branches with actions - is a single document that reads as plain language, so when the Rule Repository's AI writes or changes a rule, the whole rule appears in the conversation, checked against your source object, for a person to read before anyone saves it. In GoRules, logic of that size is a graph of tables, switches, expressions and functions; its natural-language display works rule by rule, and GoRules AI reports an action log rather than the decision as readable text. See Reviewing What the AI Wrote.

Code Effects vs GoRules at a Glance

Dimension	Code Effects	GoRules
Platform	.NET Standard 2.0 - .NET Framework 4.6.2+, .NET Core 2.0+, .NET 8+, C#, on Windows, Linux and macOS; the MCP server runs on .NET 8+; the entire platform is coming to Java in 2027	ZEN engine in Rust, with SDKs for Node.js, Python, Go, Rust, Java (JDK 22+), Kotlin, C#, Swift, Android and WebAssembly; the C# package (GoRules.ZenEngine) targets .NET 8 and calls the bundled native Rust library through P/Invoke
License & cost	Free for personal, community, development and research use; commercial use requires a perpetual Code Effects package (Standard for the Rule Engine and the Rule Editor; Business, Enterprise or Ultimate to add the Rule Repository, Audit and the MCP server) - see Code Effects Packages	ZEN engine and the JDM Editor component are free, open source, MIT; the BRMS is commercial - cloud plans (Free, Pro, Business, Enterprise) or a self-hosted license key validated against GoRules' License Portal
Rule model	Rules - evaluation and execution rules written as sentences, stored as Rule XML	Decision graphs (JDM) of decision tables, switches, expression nodes, function nodes and sub-decisions; GoRules 2.0 adds Policies, document-style typed rules
Rule authoring UI	Web-based, menu-driven, natural-language editor that offers only valid choices at every step, embeddable in any web page - React, Angular, Vue or plain pages - including public-facing pages for untrained external users	Graph canvas and spreadsheet-like decision tables in the BRMS; GoRules 2.0 can show rules as sentences, with editable value tokens and dictionary options, and free rewording converted back to expressions by GoRules AI; the open-source JDM Editor is a React component for embedding
Logic beyond conditions	Your own .NET methods as in-rule methods and actions, reusable and inline rules, collections, date shifts, durations	ZEN expressions (for example sum(map(items, #.price * #.qty))) and JavaScript/TypeScript function nodes with built-in dayjs, big.js, zod and http modules, a 5-second default timeout, and a JavaScript runtime overhead according to GoRules' docs
Data the rule works with	Your real .NET classes, Source XML or Adaptive Source - the source object	JSON in, JSON out; optional JSON Schema on input and output nodes, and typed data models and dictionaries for Policies
Rule execution architecture	Stateless, thread-safe .NET library, evaluated in-process, rules compiled to IL - currently running in hundreds of multi-threaded production environments worldwide	Embedded ZEN SDK in your process, or the GoRules Agent - a Rust service that serves decisions over REST and hot-reloads releases from object storage
Rule management	Rule Repository: a complete rule management application placed in one element of your own page, on your own sign-in, against SQL Server or PostgreSQL	GoRules BRMS: a separate web application (cloud, or one self-hosted Docker image on Linux x86_64 with PostgreSQL 12+) with its own users, groups, roles and SSO (OIDC on Enterprise cloud and self-hosted)
Decision workflow	Immutable rule versions, a decision workflow (request approval, approve or decline, Go Live, Take Offline) with typed confirmations and at most one live version per rule; your application decides who may take each step through 37 permissions	Git-like branches, merge requests into main, immutable semantically versioned releases, and environments (such as DEV, UAT, PROD) with None, Open Request, Single Approval or Group Approval deploy modes; authors can't approve their own requests; review enforcement depends on the plan
Testing before production	Exploration and expectation tests on your real classes, drafts tested without saving, saved tests, value templates, substitute test methods, tests from recorded production decisions, and batch runs of up to 350	Test files with named cases and expected outputs (subset matching), test events saved from simulations or traced requests, Quality Control with a run-all suite, PDF test reports and simple coverage, pre-flight checks on save and release, AI-generated test cases
Validation of saved logic	Every saved rule is structurally valid against its source object, checked in the editor and again on the server, including circular-reference checks - whoever or whatever wrote it	Static analysis of graphs and policies: type and name errors, conflicting writers, cycles, unreachable nodes, redundant table rows and missing default branches
Decision explainability & tracing	Visual Studio breakpoints and a production logger via TracerDelegate; Audit records each production evaluation of a live rule for step-by-step replay, explanation, statistics and new tests	Per-node trace (input, output, step-by-step) in the simulator and on request in the SDKs; the Agent emits structured JSON logs and supports OpenTelemetry; we found no built-in store of production evaluations in GoRules' docs
AI-assisted authoring	AI Rule Editor and AI Assistant in the Rule Repository, using the models your application registers (any model with tool calling; Claude and GPT tested), with your own API keys	GoRules AI builds and edits graphs, policies, tables and tests, simulates and explains, runs quality checks, and reads attached files; cloud usage is metered in credits, and self-hosted BRMS can use OpenAI, Anthropic, Amazon Bedrock, Azure OpenAI, Google Gemini or Vertex AI, or Ollama
Reviewing AI-written logic	The complete rule appears in the conversation as one plain-language text, with the server's verdict (Valid, Unfinished or Invalid) and each problem found, however complex the rule - collections, method calls, IF / ELSE IF / ELSE with actions	GoRules AI reports an action log (files changed, tests run, simulations) and its edits are reviewed in the draft workspace's Changes panel; natural-language display covers individual rules, and we found no way to show a whole graph as one text
AI agents and MCP	MCP server inside your own ASP.NET Core application, under your OAuth sign-in and permissions; every agent save waits for a person's approval, and agents can never approve, go live, take offline or delete	Remote MCP built into the BRMS (cloud or self-hosted, OAuth with admin-approved apps): browse projects, read and edit graphs and policies, run tests and evaluations, commit or open merge requests; a Local MCP bridge through the GoRules CLI for AI editors
Data filtering	The same Rule XML filters in-memory IEnumerable<T> collections (LINQ to Objects), usable as a self-service search or report control	Not found in GoRules' docs; the SDKs offer batch evaluation of many inputs, which is a different mechanism
Multilingual rule authoring	DisplayName/Description on every member and HelpXML for translating the entire editor UI; the Rule Repository takes its text from one translatable XML file	Display labels on dictionaries and data models; we found no documentation of translating the BRMS or JDM Editor interface
Deployment	Self-contained .NET assemblies and dependency-free npm packages, embedded in your own application; no external service required	Embedded SDK with rules bundled through CI/CD, or Agents pulling releases from S3, Azure Blob or GCS; the BRMS in GoRules' cloud or self-hosted (online license validation needs outbound HTTPS to portal.gorules.io; an offline mode is listed)
Time to production	Typically 3 to 4 days for one developer with the Rule Repository, plus 1 to 2 days of testing; see Code Effects Implementation	Depends on the deployment option: cloud sign-up is immediate; a self-hosted BRMS, Agents, object storage and environments take infrastructure work
Compliance certifications	Determined by your own hosting environment, since no Code Effects service is in the loop	SOC 2 Type II for GoRules' cloud, with the report available on Business and Enterprise plans
Source access	The Code Effects Source package (the entire platform)	ZEN engine and JDM Editor fully open source; we found no statement that the BRMS source is available

Two Architectures: A .NET Library vs a Rust Engine with Bindings

GoRules' central idea is one engine for every language. ZEN is written in Rust, and the same JDM file is meant to produce the same result from Node.js, Python, Go, Java, C# or a mobile app. That is a real strength for a polyglot organization. For a .NET team, though, it means the engine is native code: according to GoRules' C# documentation, the GoRules.ZenEngine package bundles native libraries for Windows (x64), macOS and Linux and calls them through UniFFI and P/Invoke, which GoRules itself notes adds some overhead, and the package on NuGet targets .NET 8. Evaluation returns a Task, and data crosses the boundary as JSON.

Code Effects is managed .NET from the ground up. The Rule Engine is a .NET Standard 2.0 library, so it runs on .NET Framework 4.6.2 as well as on .NET 8 and later, compiles each rule once into IL, and evaluates it against your own objects at the speed of compiled C#, on any number of threads. There's no native binary to ship per platform and no JSON mapping between your model and the rule. In Code Effects 7, the optional Rule Repository, Audit and MCP server follow the same model: they run inside your own web application, on your own sign-in, with their data in a database you own.

Rule Authoring: Sentences from Menus vs Graphs and Tables

GoRules rules are decision models. A JDM graph connects an input node to decision tables, switches, expression nodes, JavaScript or TypeScript function nodes and sub-decisions, and returns JSON from an output node. Decision tables are spreadsheet-like, with first and collect hit policies. GoRules 2.0 added two things worth acknowledging: Policies, document-style rules over typed data models and dictionaries, and a natural-language display mode in which a rule reads like a sentence ("employment is one of Employed, Self-employed"), with values and dictionary options editable in place. According to GoRules' docs, that sentence is a display of the stored expression, and rewording it in your own words goes through GoRules AI, which converts it back into an expression for review.

Code Effects starts from the other end. The Rule Editor builds every rule as a sentence - Check if Order Total is greater than 1000 and Customer Tier is not Gold - from menus that offer only the fields, operators, methods and values your source object allows at that point in the rule. There's no expression syntax to learn and no node graph to wire. Code Effects 7 extends that language with is in and is not in lists, inclusive is between, a Collections menu (exists, does not exist, all, first, last, count, count with), Concatenate, date shifts, date-only, time-only, offset-aware dates and durations, and inline rules that run another rule from THEN or ELSE. If your logic genuinely is a large grid of combinations, GoRules' decision tables are a natural format; if you want readable rules that business users can write without touching a model, see Decision Tables vs Code Effects.

Who Can Be Handed the Editor

GoRules' open-source JDM Editor is a React component that, according to GoRules' docs, lets you embed graph and decision table editing in your own product. It edits decision models, so the person using it still needs to think in nodes, tables and expressions. Code Effects' editor is web-based, framework-independent (React, Angular, Vue or plain pages, through the dependency-free @codeeffects/editor npm package) and built specifically to sit in any web page, including customer-facing ones. An untrained external visitor can be given rule-building capability directly, because the menus never offer anything invalid. For internal users, the Rule Repository puts the same editor inside a complete rule management application in one element of your page, in light or dark themes, following your own design.

Logic Beyond Conditions: .NET Methods vs Function Nodes

When a rule needs more than comparisons, GoRules offers function nodes: JavaScript or TypeScript handlers with built-in modules for dates, decimals, validation and HTTP calls, running inside the engine with a default 5-second timeout. GoRules' architecture notes say function nodes run slower than tables and expressions because of the JavaScript runtime overhead. In Code Effects, the extension point is your own .NET code: any public method can become an in-rule method or a rule action that business users pick from a menu, running in your application with your application's types, dependencies and security. Assembly whitelisting controls which code a rule may reach.

Governance: Releases and Environments vs a Decision Workflow

GoRules has invested heavily here, and its model is close to source control. Work happens on branches, changes reach main through merge requests that authors can't approve themselves, approval groups decide what's needed, releases are immutable semantic versions, and each environment (for example DEV, UAT and PROD) can require no approval, an open request, a single approval or one approval per group before a release goes live there. GitSync with GitHub and GitLab and release webhooks connect it to CI/CD. Review enforcement on the cloud plans depends on the tier, according to GoRules' pricing page.

The Code Effects Rule Repository governs rules individually rather than as project releases. Every saved change is an immutable version linked to the source version it was written against, versions can be compared and cloned, and rules can be moved to newer source versions with the elements that no longer resolve shown before the logic moves forward. An explicit decision workflow moves each version through request approval, approve or decline, Go Live and Take Offline, with a typed confirmation for every production change and at most one live version per rule. Rolling back is making an earlier version live again. Your application decides which of its users may take each step through 37 permissions, and your production code loads the live versions as a complete ruleset. The practical difference is where governance lives: in a separate BRMS with its own users and environments, or inside your own application, on your own users and your own database.

Testing and Simulation

Both platforms treat testing as part of shipping. GoRules keeps test files next to graphs, with named cases and expected outputs matched by subset, lets you save a simulation or a traced request as a test event, runs the whole suite from Quality Control, exports a PDF report for sign-off, flags untested graphs, runs pre-flight checks when changes are saved or released, and can generate test cases with AI.

The Code Effects Rule Repository lets business users test a new rule, or a proposed version, against values they enter before saving it, on your application's real classes, and keep exploring ideas as drafts that never create versions. Exploration tests answer what-if questions; expectation tests define the outcome a rule must produce and report whether it passes - effectively a simulation of a proposed change before it goes live. Each run shows the decision path, the conditions that held or failed, and the resulting values, and substitute test methods replace operations that shouldn't run during a test. Tests can be saved, built from value templates, and run in batches of up to 350. With Audit, any recorded production decision can become a test using its actual production data.

Validation: Static Analysis vs Rules That Can't Be Saved Invalid

GoRules continuously analyses graphs and policies for type and name errors, conflicting writers, cyclic dependencies, unreachable nodes, redundant table rows and missing default branches - a useful set of checks, and its typed data models catch misspelled values as you type. Code Effects takes a stricter line on structure: a rule is built only from the members of its source object, and the server checks it again before it becomes Rule XML, so an unfinished or structurally invalid rule is never stored as a rule, whether a person, a script or an AI agent wrote it. Circular references between rules are rejected on save. What neither platform can guarantee is that a rule says what the business meant: that is what tests and approvals are for.

Decision Explainability: Traces vs Recorded Production Decisions

GoRules returns a per-node trace - inputs, outputs and a step-by-step path - in the simulator and, on request, from the SDKs, and the Agent writes structured JSON logs (decision name and duration in GoRules' example) and supports OpenTelemetry. A traced request can be saved as a test. As far as we found, GoRules' BRMS audit logs record user and configuration actions, such as merges and deployments, rather than production evaluations, and we found no built-in store of production decisions to search later.

Code Effects covers this in two layers. The TracerDelegate used for Visual Studio debugging can also run in production as a self-hosted decision logger. Audit, new in Code Effects 7, records each production evaluation of a live rule - when it ran and for whom, the rule and source versions, the values the engine read (all or selected), the branch taken and what it set - and the Rule Repository turns those records into decision explainability: any recorded decision can be found, replayed step by step, explained, counted in production statistics, analyzed by business values, and turned into a test. Records go to a local journal first and a background worker moves them to the database, so recording never makes a decision wait, and the data stays in your own database.

AI-Assisted Authoring: GoRules AI vs the AI Rule Editor and AI Assistant

GoRules AI is capable and well integrated: according to GoRules' docs it creates graphs and policies, rewires nodes, edits decision table rows and expressions, writes and runs tests, simulates and explains results, runs the same checks as Quality Control and fixes what they find, and turns attachments such as CSV files, PDFs and Office documents into tables or dictionaries. Its changes land in the user's draft workspace for review, it reports an action log, and on releases and commits it is limited to reading and simulating. In GoRules' cloud, AI usage is metered in credits, with a faster model on the Free plan; a self-hosted BRMS is configured with OpenAI, Anthropic, Amazon Bedrock, Azure OpenAI, Google Gemini or Vertex AI, or local models through Ollama.

The Code Effects Rule Repository includes an AI Rule Editor and an AI Assistant that work under each user's permissions. The AI Rule Editor writes or changes a rule from instructions in any language, right next to the standard editor, and the result is checked against its source object immediately. The AI Assistant works across the entire rule database: it finds and explains rules, creates rules, versions, drafts and tests, runs tests, and queries rules, test history, recorded evaluations and activity to answer questions such as why a particular loan application was declined, or which versions were tested before they went live. Users can upload PDF policy documents and compare them with the current rules. The Assistant shows its steps, keeps conversation history and reports token usage and cost. Both tools use the models your application registers, with your own API keys, and neither requires the MCP server. Structural guardrails reject any AI-written rule that isn't valid against its source, every AI save requests approval, and AI can never delete, approve, go live or take a rule offline, even if the host grants those permissions by mistake.

Reviewing What the AI Wrote: The Whole Rule in the Conversation

In Code Effects, a rule is one document. However complex it gets - collections and existence checks, calls to your own .NET methods with their parameters, computed values, mixed AND/OR conditions, and IF / ELSE IF / ELSE branches that each carry their own actions - it is stored as one Rule XML document and reads as one plain-language text, the same text the Rule Editor shows. That is what lets the Rule Repository's AI show its work in full. Every rule the AI Rule Editor or the AI Assistant writes appears in the conversation as a card holding the complete rule as text, headed by the server's verdict - Valid, Unfinished or Invalid - and followed by each problem found against the source object. The person reviews the whole rule where they asked for it, in the words they would have used themselves, and what they read is what goes into the Rule Editor and, once they save it, into the repository.

GoRules has done more than most decision-table products to make rules readable, and it deserves credit for it. According to its documentation, a natural-language display mode shows a rule's stored expression as a sentence, with values editable in place, and Policies read like a document, mixing headings and paragraphs with dictionaries, data models, expressions, decision tables, matches and assertions. Both work rule by rule and block by block, though. Logic of the size described above is a decision graph in GoRules - an input, switches that route to different branches, decision tables, expression nodes, and JavaScript or TypeScript function nodes for whatever the expressions don't cover - and we found no documented way to show a whole graph, or a whole policy's logic, as one readable text. GoRules AI, according to its documentation, reports an action log - files changed, tests run, simulations - and its edits are reviewed in the Changes panel of the draft workspace, file by file and node by node.

This matters most exactly where AI is most useful: the long, multi-branch rules nobody wants to assemble by hand. The larger the logic, the more a reviewer depends on seeing all of it at once.

To be precise about the claim: a Code Effects rule that calls a reusable rule or runs an inline rule names it in its text, and that rule is a rule of its own - one more readable sentence, not a node. GoRules' own documentation is candid that its sentences go only so far: it expects developers to drop to code for complex expressions. A single function node can hold complex logic in one place too, as JavaScript or TypeScript - code for a developer, not a sentence for a business owner.

AI Agents and MCP

Both platforms now speak the Model Context Protocol. GoRules' Remote MCP, released in September 2026 according to its changelog, gives assistants such as Claude and ChatGPT access to a GoRules organization: they browse projects, read and edit graphs and policies, run tests and evaluations, and commit changes or open merge requests with the user's own permissions, with edits held in a private working copy until committed. Apps connect through OAuth and must be approved for the organization. A Local MCP bridge, run through the GoRules CLI, connects AI editors to the workspace open in the browser.

The Code Effects MCP server runs inside your own ASP.NET Core application and uses your application's own OAuth sign-in. Agents connected through it inspect sources, rules, tests and recorded evaluations, write and test rules, and investigate production decisions, within the permissions of the person they represent. Every rule an agent saves waits for a person's approval, tests that would call production code require that person's confirmation, and agents can never approve, put a rule into production, take it offline or delete. Evaluating live rules stays where it always was in Code Effects: in your own production code, in-process.

Licensing and Cost

GoRules' engine is free in the fullest sense: ZEN and the JDM Editor are MIT-licensed, and you can embed the engine in any product at no cost. The BRMS that manages rules is commercial - cloud plans from Free to Enterprise, with users, projects, environments, audit logs, review enforcement and SSO growing by tier, or a self-hosted BRMS that needs a license key from GoRules' License Portal. We found no published self-hosted plan details. The Code Effects Rule Engine and Rule Editor are free for personal, community, development and research use; commercial use requires a perpetual Code Effects package (Standard for the Rule Engine and the Rule Editor; Business, Enterprise or Ultimate to add the Rule Repository, Audit and the MCP server). All Code Effects licenses are perpetual, with no per-evaluation or usage fees, and source code is available through the Code Effects Source package. See Code Effects Packages.

Data Filtering and Dynamic Reporting

Code Effects can apply the same Rule XML used for a decision as a filter over in-memory IEnumerable<T> collections via Filter() - letting a business-authored rule double as a self-service search form or drill-down report for people unfamiliar with the underlying data. GoRules' SDKs evaluate batches of inputs, which is a different job: we found no equivalent of turning a decision model into a query predicate over a dataset in GoRules' documentation.

Where GoRules Genuinely Wins

GoRules gets a lot right. Its engine is free and open source under MIT, and one JDM file runs in Node.js, Python, Go, Rust, Java, Kotlin, C#, Swift and WebAssembly - a strong answer for polyglot organizations, mobile and edge use, and teams on the JVM today, where Code Effects is planned for Java in 2027. It offers a managed cloud with a free tier for teams that would rather not host anything, Git-style branching, merge requests, GitSync and multi-environment releases with group approvals, static analysis that flags conflicting and dead logic, spreadsheet-like decision tables for large grids of combinations, a broad list of supported LLM providers including local models, a hosted Remote MCP, and a SOC 2 Type II report for its cloud.

Where Code Effects Wins

Code Effects fits .NET teams that want rule authoring, rule management and evaluation to live inside their own application rather than beside it. Its engine is managed .NET Standard 2.0 - from .NET Framework 4.6.2 to .NET 8 and later - evaluating your own objects in-process with no native binary or JSON mapping in between, already proven across hundreds of production environments. Its editor builds rules as plain-language sentences from menus of your own data, so it can be handed to business users and even untrained public visitors, and every saved rule is structurally valid against its source, whoever wrote it. When the AI writes or changes a rule, the whole rule - however complex - is shown in the conversation as one readable text with its verdict, so people review the logic itself rather than an action log. With Code Effects 7, the Rule Repository brings versions, a decision workflow with typed confirmations, and tests on your real classes into your own application, on your own users and database, typically in days; Audit records production decisions so any one of them can be replayed, explained and turned into a test; and its AI and MCP server let people and agents write and test rules while only authorized people can approve or publish them. Licenses are perpetual, and the free license covers personal, community, development and research use.

FAQ

Does GoRules have a .NET SDK? Yes. GoRules publishes GoRules.ZenEngine on NuGet. According to GoRules' documentation, it bundles the native Rust engine for Windows (x64), macOS and Linux and calls it through P/Invoke, with async evaluation; the package targets .NET 8. Code Effects is a managed .NET Standard 2.0 library that also runs on .NET Framework 4.6.2 and later.

Is GoRules free and open source? The engine is. ZEN and the JDM Editor component are MIT-licensed. The GoRules BRMS that manages, tests and releases rules is commercial, in GoRules' cloud (including a Free plan) or self-hosted with a license key. Code Effects' Rule Engine and Rule Editor are free for personal, community, development and research use; commercial use requires a perpetual Code Effects package (Standard for the Rule Engine and the Rule Editor; Business, Enterprise or Ultimate to add the Rule Repository, Audit and the MCP server).

Can untrained or public users author rules with GoRules? We found no GoRules documentation aimed at that. The open-source JDM Editor can be embedded as a React component, but it edits decision graphs, tables and expressions. Code Effects' editor builds rules as sentences from menus that offer only valid choices, and it is built to be embedded in any web page, including public-facing ones.

Does Code Effects use decision tables like GoRules? No. Code Effects rules are written as readable sentences in the Rule Editor and stored as Rule XML, rather than as rows of a decision table. GoRules' decision tables suit large grids of combinations; Code Effects suits rules that business users read and write directly.

Do both platforms have approvals before a rule reaches production? Yes, in different shapes. GoRules uses branches, merge requests, immutable releases and environments that can require single or group approval, with enforcement depending on the plan. The Code Effects Rule Repository gives each rule immutable versions and a decision workflow - request approval, approve or decline, Go Live, Take Offline - with typed confirmations and at most one live version per rule, inside your own application and database.

Can AI agents work with rules in GoRules and Code Effects? Both offer MCP. According to GoRules' documentation, its Remote MCP lets assistants read and edit graphs and policies, run tests and evaluations, and commit or open merge requests under the user's permissions. The Code Effects MCP server lets agents find, explain, write and test rules and investigate recorded decisions under your own OAuth sign-in; every agent save waits for a person's approval, and agents can never approve, go live, take offline or delete.

Can Code Effects explain why a production decision came out the way it did? Yes, with Audit in Code Effects 7. It records each production evaluation of a live rule - when it ran and for whom, the rule and source versions, the values read, the branch taken and what it set - and the Rule Repository replays any recorded decision step by step, explains it, and can turn it into a test. GoRules provides per-evaluation traces and Agent logs; we found no built-in store of production decisions in its documentation.

Can the AI show the whole rule it wrote, right in the conversation? In Code Effects, yes. A rule of any complexity - collections, method calls, IF / ELSE IF / ELSE with actions - is one document that reads as plain language, so the Rule Repository's AI shows the complete rule in the conversation, with the server's verdict against the source object. According to GoRules' documentation, GoRules AI reports an action log and its edits are reviewed in the Changes panel; its natural-language display covers individual rules, and we found no way to render a whole decision graph as one readable text.

Is Code Effects available for Java, like GoRules? Not yet. GoRules already has Java and Kotlin bindings (JDK 22 or later for Java). The entire Code Effects platform is planned for the Java platform in 2027; today it runs on .NET.

Which engine is faster? Both publish their own figures. GoRules cites under 1 ms per evaluation and 10,000 to 100,000 requests per second per core for the embedded SDK. Code Effects' benchmark evaluates one million object instances against a simple rule in under 10 ms. Test both against your own rules and data.