DMN Engine
A DMN engine evaluates business decisions modeled in DMN: decision tables, FEEL expressions, and the dependency graph connecting them. You send it an input context, it runs the decision graph, and it returns the result - deterministically, with no side effects, and fast enough to sit in a request path.
QuantumBPM is a DMN 1.5 decision engine at Conformance Level 3, written in Go, with a 99.32% pass rate against the official DMN TCK. It runs standalone if all you need is decisions, and shares a project, identity, and audit trail with the BPMN engine if you need both.
Conformance is the thing to compare
Every DMN tool claims DMN support. The DMN Technology Compatibility Kit is the OMG's own test suite, and it is the only way to compare that claim across vendors without taking marketing at its word.
| Engine | TCK pass rate | Spec level |
|---|---|---|
| QuantumBPM | 99.32% (3367/3390) | DMN 1.5, Level 3 |
| Camunda (DMN-Scala 1.9) | 84.07% | Partial DMN 1.3 |
The 23 tests we do not pass are deliberate omissions, not gaps we are working around: direct
invocation of Java code, regex backreferences, and unreal dates like 9999999-01-01. We would
rather state that plainly than round up.
Why it matters in practice: conformance is what decides whether a decision table you wrote against the spec behaves the way the spec says, or the way one vendor's interpreter happens to behave. The second kind is the one that breaks when you migrate.
Full boxed expression coverage
DMN is more than decision tables. Level 3 conformance means the whole boxed expression family is implemented, and QuantumBPM implements all of it:
| Expression | What it is for |
|---|---|
| Decision table | Rules as rows, with hit policies (Unique, First, Collect, Priority, Any, Rule order, Output order) |
| Literal | A single FEEL expression, for formulas and calculations |
| Context | Key-value entries that break a decision into named intermediate steps |
| Invocation | Calling a business knowledge model with bound parameters |
| Function definition | Reusable FEEL functions with parameters |
| List and Relation | Collections and embedded reference tables |
| Conditional, filter, quantified, for | The DMN 1.5 additions for control flow over collections |
Plus the full graph model: decisions, input data, business knowledge models, knowledge sources, and decision services - which Camunda 8 does not offer at all.
A FEEL editor that behaves like an IDE
FEEL is the expression language DMN is built on, and most tools give you a text box and wish you luck. QuantumBPM ships a FEEL language server, so the editor gives you autocomplete over the variables actually in scope, hover documentation, function signatures, and inline errors before you save.
The same FEEL implementation powers the BPMN side, so gateway conditions, I/O mappings and decision logic are one language with one set of semantics rather than two dialects that drift.
You can try the exact engine that runs in production, in the browser, on the FEEL playground - no account needed.
Evaluate over HTTP, from any language
Decisions are a synchronous API call. Post an input context, get the per-decision results back.
const result = await client.dmn.evaluate(
'loan-eligibility',
new Vars().set('requestedAmt', 1000).set('creditScore', 720),
);
First-party SDKs cover Go, TypeScript/Node, Python and Java, and the platform is a single OpenAPI spec so any other language is a generated client away. Details in the evaluation docs and the SDK reference.
Versioning and audit come with it
Two things teams usually build themselves, and here do not have to:
- Every save is a version. Definitions are immutable versions under one stable identity, and a freshly saved version is callable immediately - there is no separate deploy step. You can pin to a specific version or always resolve the latest. See definitions and versioning.
- Every evaluation is recorded. Inputs, outputs and per-decision results are stored, so answering "why did this application get rejected in March" is a query, not a logging project.
That audit trail is native. Camunda, Drools and jDMN either push you to an external history store or leave it to you entirely.
When a standalone DMN engine is the right call
Use a DMN engine when the rules change more often than the code, when the people who own the rules are not the people who deploy, or when you need to show an auditor exactly which rule version produced a decision.
Do not bother when the logic is three stable if statements owned by one team. A decision
engine is overhead you do not need yet.
Consider the BPMN side too when the decision is one step inside a longer process with waiting, retries and human approval. That is what the BPMN engine is for, and both surfaces share the same project, identity and FEEL semantics.
Frequently asked questions
What is a DMN engine?
A DMN engine evaluates decisions modeled in DMN (Decision Model and Notation), the OMG standard for business decision logic. You supply an input context, the engine walks the decision requirements graph, evaluates the decision tables and FEEL expressions in dependency order, and returns the results. Evaluation is synchronous, deterministic and side-effect free, so a decision engine can sit directly in a request path.
What is the DMN TCK and why does the pass rate matter?
The DMN Technology Compatibility Kit is the OMG's official conformance test suite. It is the only vendor-neutral way to check that an engine interprets the specification correctly. QuantumBPM passes 99.32% (3367 of 3390 tests) at Conformance Level 3. A low pass rate means decision tables behave the way one vendor's interpreter happens to behave rather than the way the spec defines, which is what breaks when you migrate between tools.
How does QuantumBPM compare to Drools and Camunda DMN?
On conformance, QuantumBPM passes 99.32% of the TCK at DMN 1.5 Level 3, against 84.07% for Camunda's DMN-Scala on partial DMN 1.3. Drools and jDMN are also Level 3 but are JVM libraries rather than products, so execution history, a modeler and a FEEL language server are things you assemble yourself. The full breakdown is on the comparison page.
Can I use the DMN engine without the BPMN engine?
Yes. If you only need decisions, use the decision surface on its own - deploy a model, call the evaluate API, read the history. The BPMN process engine is there when a decision needs to sit inside a longer-running process, and the two share a project, identity and audit infrastructure when you use both.
Is DMN faster than calling a rules service?
QuantumBPM evaluates decisions in sub-millisecond time with a native Go runtime and no JVM warm-up, so the engine itself is rarely the bottleneck - network round-trip usually dominates. The more useful comparison is against hand-written rules in application code: DMN trades a small, predictable evaluation cost for versioning, audit and the ability to change rules without a deploy.
Is QuantumBPM open source?
No, and we would rather say why plainly. Our aim is a ready-to-use product at a fair price, funded well enough to sustain ongoing development, maintenance and support. Drools and jDMN are genuinely open source, and if what you want is a JVM library to embed in your own application they are reasonable choices. QuantumBPM is a product rather than a library: the modeler, the FEEL language server, execution history and versioning are exactly the parts you would otherwise assemble and maintain yourself. We would rather charge fairly for the complete thing than publish a hollow core and sell the rest back. You can still run it entirely in your own infrastructure with the Enterprise Helm chart, or evaluate it locally with the Docker dev server without talking to sales.
Are my DMN models portable to other engines?
Yes. DMN is a vendor-neutral OMG XML standard and FEEL is part of that standard, so models and decision logic move between conformant engines. High TCK conformance is precisely what makes that portability real rather than theoretical.