Switch from IBM ODM to GoRules.

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.