Page History
...
Most of the time when you have “Not Applicable” as an option, you will use “mutually bound constraints” as in this case. Here, we want “Do Not Add a Hotel” to be bound with Type of Room as “Not Applicable” AND we want to have Type of Room of “Not Applicable” to be bound with “Do Not Add a Hotel” so we mark this one as a Mutually Bound Constraint.
Problem solved!
Summary
So what really just happened there?
...
Important note: you may argue that the statement at the bottom still looks correct in this direction, however you need to keep in mind how the word "must" is interpreted by the algorithm. Since the evaluation is done at the "pair of values" level, "must have Breed of Animal as Siamese" = "must NOT have Breed as Persian, Shiba Inu, Golden Retriever, Arabian" - of which "Persian" is incorrectly excluded, therefore this direction wouldn't work for this example. We could use such direction if we had multiple types that can be with only 1 breed.
Mutually Bound Pair
The underlying relationship type: one-to-one, represented by ALWAYS-ALWAYS statements in the left column.
With Mutually Bound Constraints, the values are exclusive to each other. In this example, there is only one horse breed in the second parameter. So, with 1 constraint, we can specify that "Horse" should not be paired with "Siamese, Persian, Shiba Inu, Golden Retriever" AND "Arabian" should not be paired with "Cat, Dog" - i.e. "Horse" and "Arabian" must only be tested together.
Summary
The final set of rules for this model (in the verbal form) would look like this:
In essence, Bound Constraints and Invalid Constraints perform similar tasks: they ensure that certain values only or never appear together - making all generated scenarios valid within the model scope. From a different point of view, Bound Constraints and Mutually Bound Constraints actually invalidate many values and Invalid Constraints bind many values, behind the scenes.