For decades, enterprise organizations have relied on rules engines such as Drools, DMN, IBM ODM and Corticon to separate business policy from application code. These technologies have proven themselves across banking, insurance, healthcare, government and manufacturing, letting business logic evolve independently of software releases.
So why would anyone invent another rules language?
The answer isn't that existing rules languages are inadequate. They solve the problem they were designed to solve extremely well. The problem is that the way enterprise policy is created is changing.
AI changes the starting point
Until recently, creating an executable policy meant assembling a team of analysts and developers who manually translated regulations, contracts, standards and business policies into executable rules. Today, large language models are remarkably capable of performing much of that translation automatically.
This naturally raises a question:
If AI can already generate Drools, DMN, Java or Python, why invent BDL?
It's an excellent question. The answer is that a policy compiler needs a different kind of target language than a human author.
The compiler is now part of the product
At Sertainly, the executable rules are not the beginning of the process — they are the end. The real pipeline is:
The source documents remain the system of record. The executable package is a compiled artifact. This subtle shift changes what matters. The objective is no longer simply to execute rules. The objective is to repeatedly transform evolving enterprise policy into deterministic software while preserving provenance, traceability, explainability and correctness. That is a very different optimization problem.
BDL is an intermediate representation
Traditional rules languages are primarily designed to express business logic. BDL is designed to express compiled enterprise policy. Those sound similar, but they lead to different design priorities. A compiler needs to answer questions such as:
- Which requirement did this rule originate from?
- Which paragraph of the source policy introduced that requirement?
- Which acceptance tests prove the requirement has been implemented?
- Which rules contributed to this outcome?
- If the source policy changes, which parts of the executable package must be regenerated?
Those questions are central to policy compilation. They are largely outside the scope of conventional rules languages.
It's not about syntax
A common misconception is that BDL exists because AI struggles to generate existing rules languages. That simply isn't true. Modern language models can generate Drools, DMN, Python and many other languages surprisingly well. The real question is different:
If you were designing a rules language today whose primary author was an AI policy compiler rather than a human developer, would you design it the same way?
Probably not.
Optimized for compilation
A compiler benefits enormously from predictable semantics. Every additional execution model, procedural construct or ambiguity increases the search space the compiler must navigate. BDL deliberately narrows that space. Its goal is not maximum expressiveness — its goal is reliable compilation of enterprise policy into deterministic behavior. That makes automated analysis, verification, regeneration and testing substantially easier.
Requirements are first-class
One of the defining characteristics of enterprise policy is that decisions rarely exist in isolation. They exist because specific requirements demand them. Rather than treating requirements as documentation attached to rules, BDL makes the relationship explicit. A compiled package knows not only what decision was reached, but why that decision exists and which requirement it satisfies.
That becomes invaluable when policies evolve. Instead of asking “which rules do we need to edit?” the compiler can ask “which requirements changed?” — and everything downstream can be regenerated. (That lifecycle is a hard problem in its own right; we go deep on it in When the Rules Change.)
Policy produces more than decisions
Enterprise policies rarely produce simple yes-or-no answers. A single evaluation may determine:
- eligibility
- classifications
- calculated values
- routing decisions
- evidence requirements
- reason codes
- derived facts
These are natural outputs of enterprise policy. BDL treats them as first-class concepts rather than forcing applications to reconstruct them from procedural logic.
Explainability is part of the model
Modern enterprises increasingly require every automated decision to be explainable — not just for regulators, but for developers, for auditors, for customers, and for AI governance. BDL packages naturally support deterministic traces showing:
- which rules fired;
- which requirements were satisfied;
- which facts were derived;
- which evidence was considered;
- and how the final outcome was produced.
Explainability is not an afterthought. It is part of the execution model. (That's a design choice, not a reporting feature — we make the case in Decisions That Explain Themselves.)
Recoverability matters more than expressiveness
Perhaps the biggest philosophical difference between BDL and traditional rules languages is the optimization target. Traditional rules languages optimize for expressing business logic. BDL optimizes for recovering executable policy from changing source material.
That distinction becomes important when regulations change every few weeks. When a contract is amended. When a compliance standard evolves. Or when a government publishes a new version of legislation. The question is no longer simply whether the software executes correctly. The question becomes:
Can the affected policy be identified, regenerated, tested and redeployed with confidence?
That lifecycle is what BDL was designed to support.
A different design center
None of this diminishes the value of established rules technologies. Drools, DMN, IBM ODM, Corticon and others remain excellent platforms for implementing business rules. BDL simply starts from a different assumption: that executable policy is increasingly produced by an automated policy compiler operating over source documents, with human review and deterministic runtime execution. That changes the role of the language. BDL is not trying to replace every rules language — it is trying to be the best possible compilation target for enterprise policy.
This is the same reason a compiled decision package isn't the same thing as AI-generated code that merely runs. Functional code and governed, auditable decision infrastructure are different artifacts with different guarantees — an argument we make in Why AI-Generated Code Is Not a Decision Platform.
Looking forward
As AI increasingly assists with software generation, we believe we'll see more languages designed around compilation pipelines rather than manual authoring. In that world, the most valuable languages won't necessarily be the most expressive. They'll be the ones that preserve intent, provenance, requirements, explainability and determinism from source document to runtime.
That's the design philosophy behind BDL. It wasn't created because existing rules languages are obsolete. It was created because enterprise policy compilation has become a new problem — and that problem deserves a language designed specifically to solve it.
The most valuable rules language of the AI era won't be the most expressive one. It'll be the one built to compile.