Extracted from Rules: Shaping Behavior and Knowledge, by Ronald G. Ross, 2023, 274 pp, https://www.brsolutions.com/rules-shaping-behavior-and-knowledge-book.html

None of the following are appropriate in expressing rules:

• Instructions
• Commands (conditional or otherwise)
• Processes, procedures, and actions

What's left then as proper form for expressing rules? Facts, or more precisely, factual expressions.

When I say 'facts' it might or might not occur to you to think 'data'. But you should. They're intimately connected. A great many problems involving both ambiguity and data quality arise from lack of awareness about this connection.

About Facts

When I say 'fact' you should think of a sentence taken to be true. Suppose I state:

The Eiffel Tower is located in Paris.

That's a fact. I've personally verified it to be true. I have seen the Eiffel Tower with my own eyes, touched it, and ridden the elevator to the top. Facts are a basic element of knowledge.

Aside: Actually, rather than 'sentence' I should say 'proposition' because the same proposition can be expressed in many ways and in different natural languages.

Obviously not every sentence is true. Suppose I said, "Mt. Fuji is in New Zealand." That's verifiably not true.

So generally, to be a fact a sentence needs to be stipulated as such.

• In law, facts are included in fact patterns decided by a judge or jury.


• In journalism, facts are established by corroboration.


• In IT business systems, facts are generally indicated by the presence of data in databases.


• For business knowledge, facts are structured using a concept model.[1]

Rules vs. Facts

Rules go a step farther than facts. A rule prescribes something about some factual expression always or never being true. A rule is not an actual fact about the world per se but rather about the world as a group or community of people would have it be.

Suppose you say in your business "Our customers have names." Or you might say "Some customers have names." You might even say, "As of this moment, every one of our customers has a name." Let's assume each statement is true — that is, all are facts.

Still, tomorrow a customer might come along that doesn't have a name. What you have not yet said explicitly is that you want to avoid any nameless customers. For that you need to express a rule, perhaps:

Rule: Every customer has a name.

For some factual expression to express a rule, you must communicate your special intent about that expression always or never being true. In other words, you must somehow explicitly indicate the intended 'ruleness' of the expression.

There are many ways to indicate this 'ruleness'. In the example above, the text is literally prefixed by 'Rule'. That was no accident. Or, you might have used a keyword such as 'must' in a context where it is clear you are writing rules.[2]

Every customer must have a name.

No matter what method is used, to represent a rule a factual expression must somehow be 'stamped' as such if that is what is intended. Left implicit, you can never be sure.

Inserting factual expressions into decision tables also 'stamps' them as rules. Unfortunately, a significant majority of rules don't fit into decision tables. So, other forms of 'stamping' ruleness is required. Bad ways to 'stamp' ruleness include:

• Depending on IF-THEN syntax.[3]
• Using a proprietary language or interface, which risks platform lock-in.

Let's take another example. Suppose I assert the following is true:

A customer is charged a fee for a bank wire.

Fact or rule? As the text stands, it's impossible to tell. Since a rule is different than everyday facts, assuming 'fact' is probably safest. To indicate 'rule', you need something extra. You must 'stamp' the text as a rule. For example, you can do one or both of the following:

• 'Stamp' the sentence internally using a keyword such as 'must'.

A customer must be charged a fee for a bank wire.

• 'Stamp' the sentence externally using a suitable prefix or other device.

Rule: A customer is charged a fee for a bank wire.

Aside: Formally, indicating a factual expression as definitively expressing a rule (or other form of guidance) requires an indication of modality (generally speaking, behavioral rule vs. definitional rule). This indication can also be achieved by keyword (e.g., 'must' for obligation) or an appropriate context of authoring.

Most rules are more complex with regard to facts. Example:

Agent Rule: A customer must be assigned to an agent if the customer has placed an order.

This rule uses a two-part factual expression:

Part 1: a customer is assigned to an agent

Part 2: the customer has placed an order

Rules, Facts, and Concepts

A more complex rule can involve a significant number of parts or conditions, sometimes a dozen or more. But each rule isn't based on its own unique set of concepts; the same underlying concepts are used over and over again in different rules. (In other words, the relationship between rules and the concepts underlying them is many-to-many.)

So, a blueprint for expressing the rules is quite helpful. Here is a partial concept model diagram supporting the rule above.

Figure 1. Partial Concept Model Diagram Supporting the Agent Rule

A concept model diagram does not show actual facts or rules; instead, it shows the concepts needed to express those facts and rules consistently, specifically:

• noun concepts, as indicated using boxes labeled by terms.


• verb concepts, as indicated using worded lines and arrows.

Not incidentally, each term in a concept model diagram requires a solid business definition. A box on a diagram — even a labeled box — means nothing without adequate definitional criteria (business definition and/or definitional rules).

Expressing Rules

In a given natural language, there is no single correct way to express the same rule. There are good ways and bad ways, of course, but even following all dictates of grammar and of ruleness, it's still possible to have alternative versions. For example, both the following rules mean the same:

Rule 1: The sum total of an order must not exceed $10,000.

Rule 2: The total amount of an order must not be greater than $10,000.

If that happens, pick the version that best communicates the meaning, or keep both as synonymous forms.

One more important point: A rule and the rule statement(s) that express it are not actually the same thing. The easiest way to understand why is to think about multi-language support. In Switzerland, for example, you might have four statements of the same rule, one each in French, German, Italian, and Romansh. The rule is actually the meaning, not the statement. (The same is true for facts vs. statements of facts.)

References

[1] Refer to: Business Knowledge Blueprints: Enabling Your Data to Speak the Language of the Business (2^nd ed), by Ronald G. Ross, 2020.

[2] Refer to www.RuleSpeak.com, currently available in seven languages, for guidelines to write rules in structured natural language. In RuleSpeak^® for English, the keywords for 'stamping' sentences as behavioral rules are must and only. RuleSpeak was one of three reference languages used by OMG specification SBVR (Semantics of Business Vocabulary and Business Rules), which does not standardize any particular language for rules.

[3] Refer to Ronald G. Ross, "What's Wrong with If-Then Syntax For Expressing Business Rules — One Size Doesn't Fit All," Business Rules Journal, Vol. 8, No. 7 (July 2007), URL: http://www.BRCommunity.com/a2007/b353.html

# # #