Concepts

Background that makes the rest of the documentation easier to follow: how a document becomes a delegate, exactly how values compare, and what the engine caches and shares.

How RuleWright worksThe packages, the load-compile-evaluate pipeline, the two execution paths and the cache. Values, numbers and textHow JSON values become .NET values, and how numbers, strings and dates compare. Performance, caching and threadsMeasured costs, the content-hash cache, and what is safe to share.

Why rules are data

Other .NET rule engines put C# in rule files, as lambda-expression strings compiled at run time, or write rules as C# classes. RuleWright's rules are JSON with a closed vocabulary. That trade gives up arbitrary expressiveness and gets back three things:

• Safety. A rule can't run code. Letting analysts or a UI author rules doesn't hand them your server.
• Tooling. A closed vocabulary can be validated with exact error locations, enumerated for an editor, diffed in a pull request, and hashed by meaning.
• Speed. A finite set of operators compiles to tight expression trees, with no general-purpose expression language in the way.

When a test really needs code, a custom function brings it in, written and registered by you.

RuleWright evaluates one fact against a set of rules and returns. It doesn't chain rules or keep a working memory, so it is not an inference engine. If you need forward chaining over facts that change, a Rete engine such as NRules is the right tool.