* feat: implement slots instead of natural language Replace the natural-language projection (`nl`) with engine-owned slot completion: for a cursor position the engine classifies the slot being edited (operand, operator, literal, member access, ...) and returns typed options, literal facts and the expected type, for policies and graphs. - zen-expression: new `slot` module (classification, literals, operators) and a lenient lexer mode for incomplete input; `nl` removed - Intellisense: typed diagnostic codes with arguments, richer inspect for hover, dedicated parser error variants (messages unchanged) - Engine: `Workspace::cursor_scope`, `slot`, `facts`; `rename_from` and `references_from`; editor spans in UTF-16 units; renames reach imported policies, `$nodes` reads, child graphs and output column heads; no `$root` completion in policies - Node bindings: `slot`, `facts`, `cursorScope`, `slotBatch` replace `nl`, `nlTokenize`, `nlEncodeString`, `nlTokenizeBatch` No change to expression evaluation: the VM, compiler, functions and the default lexer path are untouched, and parser error messages keep their text. * fix: harden slot classification, scopes and graph expectations - restore master execution order; slot scopes hide writes of the edited block and its dependents instead of relying on block ranking - token-start editing gated by slot state; operator, list and operand spans no longer splice into neighbouring tokens - interval-aware bracket pairing for half-open and reversed intervals - lenient lexer recovers from unknown characters (slots only) - graph expected type follows switch and pass-through nodes and merges compatible output schemas - sibling inference caps distinct values and analyses lazily - deterministic overload return type display * fix: order policy blocks by entity reads through closures and relationships - record reads for `#.field` in closures so entity fields read through lists become dependencies - link reads through derived lists (filter/map results) to the entity fields they carry and order the list after those fields - evaluate entity blocks on single relationships, and demand entity paths for plain reads through relationships - slot scopes keep the top-level variable when hiding written fields
Rust Rules Engine
Business logic humans can read and machines can run. One copy of your rules: the owner reads it, every system runs it.
ZEN Engine is a cross-platform, open-source Business Rules Engine (BRE) written in Rust. This crate is the core: the same engine that powers the Node.js, Python, Go, Java, Kotlin and .NET bindings, available with zero FFI overhead. Decisions evaluate in microseconds and are stored as portable JSON. Loading the JSON is up to you: file system, database or service call.
Try it in the free Online Editor with a built-in simulator, or embed the open-source React JDM Editor in your own product. Learn more about the Rust rules engine on the GoRules website.
Rules that read like sentences
Conditions are written the way the business says them, in the ZEN Expression Language. The developer view is one toggle away, and the two can never drift apart: there is only one source of truth, and this engine runs it.
Rules as graphs, or as documents
Model a decision on a visual canvas of decision tables, switches, expressions, functions and reusable sub-decisions. Or write it as a policy document with prose, typed data models and tables. Both compile to the same engine and return the same answers.
To go deeper, see the Rust SDK documentation, the decision graph guide and the ZEN Expression Language reference.
Installation
[dependencies]
zen-engine = "2"
Upgrading from 0.x?
arbitrary_precisionis no longer a default feature. If you rely on arbitrary-precision number handling, enable it explicitly:zen-engine = { version = "2", features = ["arbitrary_precision"] }. Language bindings are unaffected.
Quickstart
use zen_engine::DecisionEngine;
use zen_engine::model::DecisionContent;
use serde_json::json;
#[tokio::main]
async fn main() {
let decision_content: DecisionContent =
serde_json::from_str(include_str!("./pricing-rules.json")).unwrap();
let engine = DecisionEngine::default();
let decision = engine.create_decision(decision_content.into()).unwrap();
let response = decision.evaluate(json!({
"customer": { "tier": "gold", "yearsActive": 3 },
"order": { "subtotal": 150, "items": 5 }
}).into()).await.unwrap();
println!("{}", response.result);
// => {"discount":0.15,"freeShipping":true}
}
Loaders
Attach a loader to serve decisions by key. Build one declaratively from LoaderConfig (Static, Filesystem, Zip), or construct the loader structs in zen_engine::loader directly. With a configuration, decisions are pre-loaded and pre-compiled for faster evaluations.
use zen_engine::DecisionEngine;
use zen_engine::loader::LoaderConfig;
use serde_json::json;
#[tokio::main]
async fn main() {
let loader = LoaderConfig::Filesystem { path: "./rules".to_string() }
.into_loader()
.unwrap();
let engine = DecisionEngine::default().with_loader(loader);
let response = engine.evaluate("pricing.json", json!({ "amount": 100 }).into()).await.unwrap();
println!("{}", response.result);
}
Custom backends (REST API, S3, database) implement the DecisionLoader trait. Full guides, including all loader variants and expression evaluation, are in the Rust SDK documentation.
Other platforms
- Node.js - GitHub | Documentation | npm
- Python - GitHub | Documentation | PyPI
- Go - GitHub | Documentation
- Java / Kotlin - GitHub | Documentation | Maven Central
- .NET - GitHub | Documentation | NuGet
- Swift (iOS) - GitHub | Documentation
The GoRules platform
The engine is open at the core; GoRules is the platform around it. Managed cloud, self-hosted, or embedded with no network hop. SOC 2 Type II.
Contribution
The JDM standard is growing and we need to keep tight control over its development and roadmap, as a number of companies use GoRules ZEN Engine and GoRules BRMS. For this reason we can't accept code contributions at this moment, apart from help with documentation and additional tests.