Introduction

What is the PyRulesEngine

While building any application, the core part of it is always the business logic or policies. And as with any application, there always comes a time when rules or policies change. With that change comes a lot of rework like changing design, rewriting logic components, regression testing, etc. The rework amounts to a lot of unnecessary engineering overhead.

In this py_rules_engine library, we have abstracted the evaluation of rules so the core logic is maintained in explicit YAML or JSON JSON Decision Models (JDM) while the application stays clean. The inputs to the system are purely dynamic (Python dictionaries/objects), and the engine handles parsing securely.

These features make this library highly configurable and secure, as shown in Getting Started.

How it works

Here, there are multiple actors/components involved natively in the Python ecosystem:

Rules Engine

This component is the core engine (RulesEngine), completely divorced from unsafe eval() or vulnerable AST loops. It leverages Google's Common Expression Language (CEL) constrained by strict cyclic depth limiters and a mandatory syntax validation gate.

Storage Manager

As shown in our schema formats, we need rules in a particular format. While the structure is rigid, the data itself is abstracted via the StorageManager. It can read from FileStorageProvider (JSON/YAML), or be extended for databases, Redis, or object stores. It features latest version resolution.

Input

The inputs for the system are arbitrary dynamic Python dicts injected natively.

Wrapper / Endpoints

This library sits as an attachable core that can be bound to FastAPI (as a REST backend) or integrated directly into standard Python scripts using asyncio execute_all_rules_async. The wrapper passes the inputs and workflow names to the Engine, and parses the generated RuleResultTree returned by the core AST evaluation loop.