Switch from Oracle OPA/Intelligent Advisor to GoRules.

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.