Why four models for "business rules"?
They’re not interchangeable. Each solves a different problem about how rules are written, who reads them, how they chain, and how they travel between systems. The lab walks through all four on the same decision.
- The business owner needs to see and edit the rule. Not in code. In a table they can read in a meeting, change without an engineer, and sign off. That’s what DMN gives you — a decision table where each row is a case and each column is a condition. "If consent status is ACTIVE and scope contains balances:read, then ALLOW." A product manager can edit that.
- The lawyer or compliance officer needs to read the rule. In English. With clear modal verbs — must, may, must not. That’s SBVR. "It is necessary that a Third-Party Provider does not access account data without an active consent that explicitly authorises the requested scope." A solicitor signs off on that prose; an engineer compiles it to machine logic.
- The rule has to chain through relationships. "Can BudgetEye read Marcus’s account?" depends on Marcus holding the account, his consent granting access to BudgetEye, the consent covering the scope, the consent still being active. That’s five linked facts, not a flat lookup. Datalog is for this — declarative logic that walks the graph and chains rule on rule.
- The rule has to travel between engines. The bank’s internal platform uses Drools. The cloud security team uses OPA. The regulator runs IBM ODM. All three need the same rule, expressed in their native syntax, kept in sync. RuleML is the interchange format — write once, emit to all three, never let them drift.
- The four models are not competitors. They’re collaborators. DMN handles the auditable table, SBVR handles the legal-readable prose, Datalog handles the chaining logic, RuleML handles portability. A mature rules platform uses all four, each at the layer where it’s strongest.
| Tab | Model | Year | The audience | What it does best |
|---|---|---|---|---|
| 01 | DMN | 2015 | Business owner · product manager | Decision tables; visual; auditable; editable without an engineer |
| 02 | SBVR | 2008 | Compliance · legal · regulator | Structured English with modal verbs; bridges legal prose to machine logic |
| 03 | Datalog | 1977+ | Engineers building chained authorisation | Recursive, declarative; walks graphs; handles "eligibility depends on eligibility" |
| 04 | RuleML | 2000s | Platform architect | Rule interchange across engines; write once, port to many |
The decision table
A product manager can read a table. A product manager cannot read Java. DMN puts the decision in a form the business actually owns — and the bank’s rules engine reads exactly the same table.
- The table is the rule. Each column is an input the rule cares about — TPP status, consent status, scope, expiry. Each row is a case — "if the TPP is regulated AND consent is ACTIVE AND scope includes balances:read AND expiry is in the future, then ALLOW." Reading the table top to bottom is reading the rule.
-
The hit policy is the meta-rule. When more than one row could match, what wins?
UNIQUEsays exactly one row should match (and the table is broken if zero or two do).FIRSTsays first match wins.COLLECTsays return every matching row.PRIORITYranks them. Choosing the hit policy is itself a design decision the business owner makes. -
The cells use a tiny expression language called FEEL. Not full code. Just expressions like
> 1000,in ["DE", "FR", "IT"],not("REVOKED"),between 0 and 100. The product manager can read and edit these without an engineer. - The engine treats the table as compiled code. When the agent asks "can BudgetEye read Marcus’s balance?" the engine packages the inputs, scans the rows in the order the hit policy dictates, finds the matching row, and returns the output. No Java, no Python — just the table the business owner approved.
- The auditable trail. When a regulator asks "why did you let BudgetEye through?" the bank shows the DMN table, points at the firing row, and says "because of this row in this version of the table, approved by this product owner on this date." That’s exactly what BCBS 239 and FCA expect — and it’s impossible if the rule is buried in a switch-statement somewhere in middleware.
DMN (Decision Model and Notation; OMG 2015, current version 1.4 from 2023) is the OMG standard for business decision modelling. It separates decisions from their supporting logic via two complementary diagrams: the DRD (Decision Requirements Diagram) shows how decisions relate to inputs, knowledge sources, and authorities; the decision table provides the executable logic at each decision node.
FEEL — Friendly Enough Expression Language. A side-effect-free expression language with conventional arithmetic, comparison operators, time/date arithmetic (date("2026-08-15") - today()), and collection operations (some s in ["accounts:read"] satisfies s = "accounts:read"). FEEL guarantees termination and determinism — properties required for the rules engine’s formal verification properties.
Hit policies. Single-output: U (unique), A (any — all matching rows must agree), P (priority), F (first). Multi-output: C (collect — return all matches), C+ (sum), C< / C> (min / max), C# (count). The hit policy is part of the table’s public interface; changing it is a versioned change.
Execution. Compliant engines (Camunda, Drools, KIE, Trisotech, Signavio) compile DMN tables to one of: a decision tree, a series of if-then-else statements, or a SQL CASE expression — depending on the hit policy and the target runtime. Performance for tables of typical size (≤ 50 rows × ≤ 10 inputs) is sub-millisecond.
Versioning & governance. Each DMN file is a versioned artefact with a namespace URI, model ID, and version. The OMG conformance levels (1 → 3) define exactly what an engine must support; level 3 is full FEEL plus boxed expressions. Bank deployments typically pin to level 3 with a fixed FEEL subset.
Structured English
A compliance officer needs to read the rule. In English. Before the engineer compiles it to anything. SBVR is the bridge — controlled natural language with modal verbs that a lawyer signs off and software still parses.
- Define the vocabulary first. Before any rule is written, SBVR demands you list the nouns and verbs in scope. "Third-Party Provider", "Consent", "Account", "Scope" as nouns. "holds", "authorises", "grants access to", "covers" as verbs. Each noun has a definition; each verb has a sentence pattern. The vocabulary is the dictionary of the contract.
- Then write rules with explicit modal verbs. "It is necessary that..." means must-always-be-true. "It is obligatory that..." means must-do. "It is permitted that..." means may-do. "It is prohibited that..." means must-not-do. The modal verb is doing real work — it tells you whether the rule is a constraint, an obligation, a permission, or a prohibition. Each maps to a different enforcement action.
- Underlined nouns and italicised verbs are the cue. Visually, SBVR documents underline the defined nouns and italicise the defined verbs. It is necessary that each Consent is granted to exactly one Third-Party Provider. The vocabulary is right there in the sentence — no ambiguity about what term means what.
- The rule compiles, but the prose is the source of truth. SBVR is designed so that tools can mechanically translate the structured English to OCL, SWRL, or first-order logic — but the document the regulator reviews and the compliance officer signs is the prose, not the compiled form. If they ever disagree, the prose wins.
- Why the bank wants this layer. When the FCA publishes new guidance, the bank’s compliance team needs a place to write the new rules in the language regulators speak — not Java, not DMN. SBVR is that place. The translation to DMN or Datalog or Drools happens afterwards, controlled by engineering, but the source-of-truth artefact stays in the regulator’s language.
SBVR (Semantics of Business Vocabulary and Rules; OMG 2008, current 1.5 from 2019) is the OMG standard for expressing business vocabulary and rules in a form that is both human-readable and machine-translatable. It has two surface notations: SBVR Structured English (SBVR-SE), the controlled-prose form that humans read; and SBVR Logical Formulation, the formal-logic form that machines consume.
Vocabulary. SBVR distinguishes noun concepts (Customer, Account, Consent), fact types (Customer holds Account; Consent authorises access), characteristics (Account is dormant), and individual concepts (the specific entity Marcus Aldridge). Each is defined with synonyms, source authority, and signifier — providing the lexicon for all subsequent rules.
Modal logic foundation. SBVR rules attach a deontic modality to each statement: alethic (it is necessary / it is impossible) for structural truths; deontic (it is obligatory / it is prohibited / it is permitted) for behavioural rules. The modality determines the enforcement action — a violation of an alethic rule is a model error; a violation of a deontic rule is a policy breach. SBVR’s formal semantics is based on classical modal logic, specifically the K, T, S4, and S5 systems.
Translation targets. SBVR-SE compiles mechanically to: OCL (Object Constraint Language) for UML model invariants; SWRL (Semantic Web Rule Language) for OWL ontology rules; first-order logic for theorem provers; SQL CHECK constraints and triggers for relational databases; and DMN decision tables when the rule has the table-shape.
Tooling. Open-source tools include Visual Paradigm SBVR, OMG’s SBVRwiki, and the academic SBeaVeR plugin. Commercial tools include IBM RTC SBVR and Trisotech Business Glossary.
Recursive logic
Some rules walk graphs. "Can BudgetEye read Marcus’s balance?" isn’t one lookup — it’s a chain across five linked facts. Datalog was designed in 1977 for exactly this kind of declarative chaining, and it’s the language modern policy engines (Rego, Cedar) descend from.
-
Facts are sentences with no variables.
holds(marcus, wm_acct_001).granted_to(cn_ma_04, budgeteye).has_scope(cn_ma_04, "balances:read").status(cn_ma_04, ACTIVE). Each fact is one piece of the world. The database is a pile of these. -
Rules are sentences with variables.
can_read(TPP, Account) :- holds(Cust, Account), authorised_by(C, Cust), granted_to(C, TPP), in_scope(C, "balances:read"), active(C).The colon-dash reads as "if" — left of it is what gets derived, right of it is what must already be true. Variables (capitalised) get matched against the facts. -
The engine chains forward. Asked "can_read(budgeteye, wm_acct_001)?" the engine searches for a way to satisfy every clause on the right of the rule. It finds
holds(marcus, wm_acct_001)— bind Cust=marcus. It searches forauthorised_by(?, marcus)— finds CN-MA-04. It checksgranted_to(CN-MA-04, budgeteye)— yes. Checks scope — yes. Checks active — yes. All five clauses satisfied. Answer: yes. -
Recursion is where Datalog earns its keep.
can_supervise(X, Y) :- direct_report(X, Y).can_supervise(X, Y) :- direct_report(X, Z), can_supervise(Z, Y).Now "can the regional head supervise an analyst three levels down?" chains automatically. SQL can’t do this elegantly; Datalog was built for it. Bank examples: org-chart authority, ultimate beneficial owner trails, transitive consent delegation. - Why this matters for open banking. Modern authorisation systems — Google Zanzibar, OPA Rego, AWS Cedar — are essentially Datalog dialects with better syntax. The reason isn’t fashion: it’s that open-banking permission isn’t a flat table; it’s a graph of customers, consents, scopes, TPPs, and time windows. The graph needs a query language that recurses. Datalog has been that language for 47 years.
Datalog (originating in the late 1970s, formalised in the 1980s) is a declarative logic-programming language consisting of function-free Horn clauses. It is a strict subset of Prolog (no function symbols, no cut, no negation as failure in the pure form) chosen precisely so that every Datalog program terminates and every query has a finite, well-defined answer.
Syntax. A Datalog program is a finite set of rules H :- B_1, B_2, ..., B_n. where H (the head) and each B_i (a body atom) are of the form predicate(t_1, ..., t_k) with terms t_i being either variables or constants. No functions, no nested terms.
Semantics. Three equivalent semantics: model-theoretic (the minimal Herbrand model of the program), fixed-point (least fixed point of the immediate-consequence operator T_P), and proof-theoretic (SLD resolution on Horn clauses). For pure Datalog, all three agree; the fixed point is reached in polynomial time in the size of the database.
Stratified negation. Pure Datalog has no negation, which limits expressiveness. Stratified Datalog admits negation only when the program can be partitioned into strata such that a predicate’s definition references negated predicates only from lower strata. This preserves the existence of a unique minimal model and is sufficient for nearly all banking-rule use cases (denial reasons, exception lists, blacklists).
Modern descendants. Datalog underpins: Soufflé and DDlog (program analysis); OPA / Rego (cloud policy enforcement); AWS Cedar (resource authorisation); Google Zanzibar (relationship-based access at planet scale); Datomic and LogicBlox (database query); Yedalog (Google data analysis). Banks adopting OPA or Cedar are using Datalog whether they call it that or not.
Complexity. Pure Datalog query answering is PTIME-complete in data complexity (the database is the input, the program is fixed). With stratified negation, EXPTIME in combined complexity. Modern engines (LogicBlox, Soufflé) achieve performance competitive with hand-written SQL on graph-shaped queries.
Rule interchange
The bank’s internal platform uses Drools. The cloud security team uses OPA. The regulator runs IBM ODM. All three need the same rule. RuleML is the lingua franca that lets one rule live in many engines without drifting.
- The portability problem is real. A typical bank runs DMN tables in Camunda for product decisions, Drools for fraud rules, OPA for cloud-resource policies, and AWS Cedar for application authorisation. Same rule about "active consent required" gets written four times, in four syntaxes, by four teams. Drift is inevitable.
- RuleML is a neutral XML/JSON representation. The rule "if consent is active and scope contains balances:read, then allow" is expressed once in RuleML — a syntax neither Drools nor OPA nor Cedar nor anyone uses natively, but all of them can import. Like a translation hub.
- The translation goes both ways. RuleML compilers exist for Drools, ODM, Jess, Prova, OPA, and Cedar. You write the rule in RuleML, the compiler emits each native dialect. When a regulator audits, you show the RuleML — the single source of truth — and demonstrate which engines run derived copies.
- There are layered variants for different rule kinds. Reaction RuleML for event-condition-action rules (fraud triggers). Deliberation RuleML for derivation rules (eligibility, classification). Consumer RuleML for simple production rules. Each layer is a subset of the next, so a tool that handles deliberation rules can read consumer rules too. The bank picks the layer matching the rule’s flavour.
- The honest limitation. RuleML adoption has lost some ground to engine-specific tooling — OPA in particular has become the cloud-native default and many teams write Rego directly. But for the bank that needs to demonstrate one rule, many engines, no drift, RuleML is still the standard answer. It’s the format you reach for when "we run the same rule in five places" is the actual problem.
RuleML (the Rule Markup Language; emerged early 2000s, current 1.02 from 2019) is a family of XML- and JSON-based markup languages developed by the international RuleML Initiative to enable rule interchange across heterogeneous rule engines, decision platforms, and inference systems.
Layered architecture. RuleML defines a hierarchy of sub-languages, each subset of the next: Datalog RuleML (function-free Horn clauses), Hornlog RuleML (full Horn logic with functions), Naf Hornlog (with negation as failure), FOL RuleML (first-order logic), and Reaction RuleML (production and ECA rules with side effects). A tool consuming a higher layer can consume all lower layers.
Interchange ecosystem. Translators exist between RuleML and: Drools DRL (JBoss), Jess CLP, Prova, RIF (the W3C’s competing Rule Interchange Format, with which RuleML now interoperates via a shared XML serialisation), OWL 2 RL, SWRL, and several research engines. RuleML serves as the pivot in many regulatory and inter-organisational rule-sharing scenarios.
Relationship to other standards. RuleML is broader than RIF — it includes reactive and ECA rules — but the two have converged via shared XML schemas. RuleML predates and influenced LegalRuleML (legal reasoning), API4KB (knowledge-base APIs), and the OASIS LegalRuleML TC standards.
Honest market position in 2026. RuleML’s adoption has been concentrated in regulated industries (insurance, banking, healthcare) where multi-engine rule deployment is a real operational concern. In the cloud-native space, OPA + Rego has emerged as a de facto standard, and engine-specific tooling (Drools workbench, AWS Cedar Analyzer) often substitutes for full RuleML pipelines. RuleML remains the canonical answer when explicit cross-engine portability and regulator-readable source-of-truth artefacts are required.