Business rules engine software has been around for quite awhile. The primary function of a business rules engine (BRE) is to enable the rules for a business process to be expressed in a manner that enables an application or process to automatically execute the business process pursuant to the rules. Mysteriously, law schools are continuing to fail to teach their students about the mere existence of BRE tools and their utility and value to enabling legal compliance.
At their most basic, rules composed with BREs are semantic expressions describing what actions are to be performed with respect to an information object. Like any semantic system, BREs require a vocabulary from which the rules are to be composed and, for each word, a meaning is required. But one of the key features of the resulting applications is that the application can evaluate the surrounding context to determine if a particular rule is appropriate to be executed.
That context is, itself, expressed in information that describes the state of things at a particular moment. The specific functionality employed is called an inference engine. The inference engine evaluates the available information and, based on the controlling rules, determines which business rules are to then be executed with respect to the related information object. Driverless cars are really mobile inference engines through which the vehicle sensors are constantly evaluating the context and calculating the appropriate action (applied to the vehicle itself rather than a specific information object).
Of course, BREs face two significant hurdles within the full dimension of cyberspace. First, BREs must be scaled to function across larger, interdependent devices, systems, and ecosystems. Like the challenges of Babel, that requires developing uniform vocabularies, with meanings and semantic structures that are shared and adopted across the grid. To the astonishment of entire legal communities, the technologists have progressed enormously in that direction. Not only do major software companies, such as Oracle and Microsoft, have their own BRE languages and tool kits, but standards initiatives have progressed, creating open standards in which vocabularies, syntax, and full libraries of rules can be expressed.
Second, BREs (and the standards, languages, and vocabularies that enable their potential to be optimized) do not tolerate ambiguity. The rules generated by BREs are no different than any other line of code in any software–they require precision. This creates a chasm in using BREs to automate processes subject to legal rules. Why? Because the legal rules are inherently authored with vocabulary words that are intentionally ambiguous.
This hurdle is harder to overcome. But companies that figure out how to build bridges across that chasm achieve high levels of consistency, compliance, and require substantially lower expenditures in training, management oversight, reporting, and remedial and corrective actions. In my book, you can find the Rules for Composing Rules, a set of 8 principles that enable that chasm to be crossed. I look forward to your success in using those rules.