for future use

Controlling the scope of application of conditions will be important for rulesheet authors when drafting policy that can be reliably applied to many message/document circumstances, including unforeseen circumstances. This provides a level of flexibility and robustness to a rulesheet, allowing it to govern disclosure of documents that were undefined or unanticipated when the rulesheet was defined.

For example, a rulesheet may have a rule dictating redaction and denial by default (this is only for completeness; this default rule does not remain under consideration in this discussion). It may have another rule stating that all currency data type nodes shall be redacted and admitted when the users are Accountant role members. It may have a third rule stating that all nodes semantically defined as "monetary transfer amounts in excess of ten thousand Euros" be disclosed when the users are Accountant role members.

In our illustration here, let's consider that an Accountant role member is indeed the user context, and there is a node in the present document that is a transfer of (Euro 12500). According to our hypothetical rulesheet, there are two outcomes to be applied: "redact and admit" and "disclose". If one were to simply follow CDCL's cascade, the reconciled outcome to be enforced would be "redact and admit". One might argue that the disclosure rule appears to be more specific in its intent than the redaction rule, but that is the crux of the entire matter here. The CDCL engine should never attempt to assume the intent of the rulesheet author. It very well may be that the redaction rule was added subsequent to the disclosure rule - perhaps due to some change in policy, and the rulesheet author did not consider the discrepancy between these two rules.

With a feature in Booliette and in CDCL Fundamental Form that permits a rulesheet author to define the scope of control over these two conditions... ...the engine could honor the explicit intent of the rulesheet author. For example, the rulesheet author might say:
  1. <MOST LOCALLY SCOPED or MOST NARROWLY SCOPED> when node is of "currency" data type and when the users are Accountant role members
  2. <LEAST LOCALLY SCOPED or LEAST NARROWLY SCOPED> when node is of "monetary transfer amounts in excess of ten thousand Euros" semantic and when the users are Accountant role members

This way, the transfer of Euro 12,500 would be redacted and admitted. Better yet, compelling the rulesheet author to define explicit scope of control for conditions ought to aid the author in identifying errors and discrepancies that should be corrected in the rulesheet.

Condition scope of control could be implemented in CDCL Fundamental Form either as an ordering of nodes (nodes that are rules) or as properties of nodes (nodes that are rules). Utilizing ordering of nodes may be more useful for this purpose than utilizing properties because the use of properties would require logic to keep the properties synchronized across the rulesheet. This raises an important point, and that is the condition scope of control has a maximum scope of a rulesheet. These condition scopes of control do not cross rulesheet boundaries; they are used to signify the one outcome from a single rulesheet in a deck prior to any overlay that may be performed.