Defaults, Exceptions and Applicability

Laws are typically drafted in a style where the rules that apply most generally are stated first, and more specific variations are stated later. Blawx calls this style "defaults and exceptions." Laws are also frequently written in a style where one section of a rule "turns off" the effect of another section of the rule. Blawx calls this "applicability."

Blawx gives you some powerful tools to be able to represent defaults, exceptions, and applicability in your code in a way that closely matches the way they are used in legislation, making your code easier to write, and easier to maintain.

Defaults and Exceptions in Blawx

The basic system of dealing with defaults and exceptions in Blawx can be described by these steps:

  • Indicate which sections of the law led to what conclusions, and whether those conclusions are subject to exceptions.
  • Indicate which conclusions overrule which other conclusions.
  • Write rules that check to see what rule reached what conclusion.

The first part is done using the "attributed rule" block, and the second part is done using the "overrules" block.

Sometimes, a rule depends on whether another specific rule came to a certain conclusion (as opposed to whether ANY part of the rule came to that conclusion). In that case, you can use the "holds" block to check to see what conclusions were true, by virtue of what sections of the rule, taking into account all the possible exceptions to those rules.

Take a rule that reads as follows:

Pet Act

1. A person with a pet is eligible.
2. Despite section 1, a person with a moustache is not eligible.
3. If a person is eligible under section 1, they are eligible under this section.

Attributed Rules

We will start by encoding section 1 using the "attributed rule" block. We will create the category "person", with the attributes "eligible", "has a cat" and "has a moustache."

We can say that a person with a pet is eligible, but that this conclusion can be overruled by other conclusions elsewhere, by creating an attributed rule that looks like this:

Person With Pet Eligible

Likewise, we can create another rule in section 2 that says that a person with a moustache is not eligible, which will look like this.

Person With Moustache Not Eligible

Note that we don't need this rule to be subject to other exceptions, so we have not checked off the "subject to exceptions" checkbox.


Now that we have two different rules that come to competing conclusions, we can say what the relationship is between them using the "overrules" block. Here, we need to say that the conclusion in section 2 that the person is not eligible overrules the conclusion in section 1 that they are. This is how we encode the words "Despite section 1", and so the encoding goes into section 2 of the rules, where those words appear.

The overrules block allows you to put these defeating relationships exactly where they are stated in your law (if they are stated explicitly at all).

In this case, our overrules statement would look like this:

Eligibility Overruled


Now, in section 3, we can state that section 3 concludes that someone is eligible if section 1 reaches the same conclusion, by using the "holds" block in the condition of the rule, like this:

Holds Rule

Now section 3 will "hold" only if section 1 holds, regardless of what any other section of your rules might conclude.

Defeated Defeaters

Note that using this system it is possible to have rules that might be defeated by other rules, which in turn might be defeated by other rules. That will work, as long as none of the defeating relationships are cyclical. That is to say, if rule A defeats rule B, rule B defeats rule C, and rule C defeats rule A, then none of the three rules will ever conclude anything at all, and your code will return "no models" when those rules are involved.

Advanced Defaults and Exceptions

Most of what you will want to do will be possible using the "attributed rule", "overrule" and "holds" block as described above. However, if you need to troubleshoot your defaults and exceptions, or if you want to build your defeasibility rules yourself, that can be done with the unattributed rule block and the other exception blocks: overrules, according to, defeated, and holds.

All categories and attributes result in the creation of a rule that if something (or its logical negation) is held by any section, that conclusion also is true generally. This means that you do not need to use the 'holds' block to see if something is true, you can just ask if it is true.

When you create an attributed rule, it generates two rules. The first determines whether the conclusion is tentatively reached by that section, which can be tested using the "according to" block. The second determines whether that conclusion is undefeated, which can be tested using the "defeated" block wrapped in a negation as failure ("there is no evidence that") block. If it is undefeated, the second rule concludes that the answer "holds" (and is therefore true generally).

Overrule blocks create a rule that if the conclusion in the overruling rule holds, then the conclusion in the overruled rule is "defeated."

You can therefore use the defeated, according to, holds, and overrule explicitly to test these properties of your code.


In addition to situations where two sections of a rule come to incompatible conclusions, and one conclusion needs to win out over the other, there are also frequently situations in which one section of a rule will simply cause another section of the law to conclude nothing. Take for example, a rule like this:

1. Birds can't talk.
2. Section 1 does not apply to Big Bird.

Here you can see that section 2 doesn't reach any conclusion of its own, it just prevents section 1 from reaching a conclusion about Big Bird specifically. This rule will not conclude that Big Bird can talk. It will just not conclude that Big Bird cannot.

Blawx allows you to encode this sort of inapplicability using the attributed rule block and the "applies" block. The process is this:

  • Indicate which rules can be made inapplicable by selecting "subject to applicability" on the attributed rule block.
  • Use the applies block (optionally with a logical negation block) to indicate what rules apply to what objects.

Does Not Apply

In this case, you would encode section 1 as follows. Note that the "subject to applicability" checkbox has been marked on the attributed rule block.

Birds Can't Talk Rule

If you make a rule subject to applicability, you need a way to derive applicability for all the objects to which the rule should apply. One of the ways to do this is to create what is called a "presumption." In this case, we will say that if there is no evidence that the section does not apply to something, and that something is a bird, then the section applies to that bird. This will cause Blawx to presume that the section applies to birds unless it has explicit information that it doesn't.

When making applicability presumptions, you can presume either applicability, or inapplicability, and then make the other explicit. The choice will usually have to do with which formulation best matches the text of the rule you are encoding.

Applicability Assumption

In this case, section 2 of our rule would be encoded like this:

Big Bird Inapplicability

This will be enough for Blawx to know that section 1 does not apply to big bird. But you may want Blawx to be able to explain exactly why section 1 does not apply to big bird, in which case we need to create a fact that is attributed to a section. Unlike attributed rules, attributed facts can be created using the "holds" block, like this:

Big Bird Attributed Inapplicability

In this case, section 1 concludes a logical negative, and we want to know why that logical negative does not apply to big bird, so in a test you might ask "why is there no evidence that it is not true that big bird can talk?", like this:

Big Bird Question

The answer will be that there is no evidence section 1 concludes that big bird cannot talk, because section 2 held that section 1 does not apply to big bird.