The CDCL system is a solution for disclosure control, and as such, it implicitly knows of only one action a subject always intends to take on a resource (i.e. data). That action is “read”.

Disclosure control's purpose is not to change data in a document; it is essentially to redact or disclose it while preserving any disclosed data's meaning. Redaction in CDCL can be declared in one of two ways: intention to outright remove data from the document (in CDCL, an outcome called redact-and-deny or simply redact) or intention to mask it (called redact-and-admit or mask). Therefore, CDCL has very limited ability to define or assign data within the work products in a disclosure control transaction. A case in point is its limited ability to dynamically format an email alert/bulletin. Also honoring disclosure control's purpose – yet more importantly, to grant to rulesheet authors a high degree of confidence and trust – is CDCL's inherent, single, outcome-combining algorithm called the “cascade”. When multiple, contentious outcomes have been decided for a piece of data based on evaluated policies, CDCL's cascade defers to the most restrictive outcome.

As aforementioned, CDCL can support more than one word to be substituted for a given purpose; a case in point is how both redact-and-admit and mask are two words, either of which may be used by a policy author to declare a certain and unique outcome for a rule. CDCL uses two mechanisms in order to offer this flexibility to authors. One is a “thesaurus of synonyms”, and the other is “alias”. The manner in which these two mechanisms work is significantly different, but their objectives are quite similar. In this paper, let it be sufficient to state that these two mechanisms will permit an evolution in and improvement of the verbiage and syntax of the CDCL authoring form language. Most examples herein illustrate state of the art only at this time of writing. It should also be noted that WIJIS does not believe the expressions of policy rules in these examples are in an ultimate form with optimal clarity or comprehensibility and without any room for improvement. Instead, WIJIS promotes CDCL as a system of integrated tools and as a framework with the important proviso that the tools have mechanisms for adaptation. This meets our objective for a solution, either as is or through eventual adaptation, that may be read and understood by non-programmers.

In CDCL, preservation of meaning may be declared by a policy author through use of a specific, conditional-disclosure outcome called don't-quote-out-of-context (formally disclose-and-don't-quote-out-of-context). The piece of data to which policy-evaluation decided this outcome applies is considered the “root” level of the context within which no data may be redacted on a piecemeal basis. Any decided redaction outcome found on a piece of data within the context will result in the wholesale redaction of the context's root and everything it contains. This is akin to a prohibition on a line-item redaction, which if allowed, carries significant risk of changing the meaning of the remnant data that would be disclosed.

Disclosure control policy in CDCL is organized into rules, and rules are organized into rulesheets. A rulesheet may be managed like a file of information – saved as a draft, published for production use, retired from use, updated to a new version, etc. Intended for human eyes, CDLC Authoring Form language is the means of expression for rulesheets. This language's syntax and grammar cover the highest constructs in a rulesheet, constraining the structure of policy information as a set of rules and of other information pertaining to how the rulesheet shall be handled. This language incorporates another language called Booliette in order to express the conditions or circumstances that must be evaluated to determine the applicability of any given rule. So, Authoring Form contains Booliette, but the opposite is not true. Booliette has its own syntax and grammar, and it covers a rulesheet's lower level constructs, which constrain the structure of each rule's policy logic.

Rulesheets are identified and distinguished from each other in two manners: by URI and by a composite key. The URI is defined by the rulesheet repository in which the rulesheet is persisted. The composite key depends on a description of the disclosure control problem. As the disclosure control problem varies, policy may vary, and so, one rulesheet may apply to a certain disclosure control problem while another may apply to a different disclosure control problem. The disclosure control problem is described by two pieces of information: the “problem space”, which may be akin to the document's type or schema, and the “primary custodian” of the document, which is the entity ultimately responsible for the document's data and is typically defined by (not necessarily defined as) the party acting as a client in requesting disclosure control services. The rulesheet's composite key is established by the rulesheet author and is composed of:

If both the problem space and primary custodian in the rulesheet's composite key are null, the rulesheet is considered to be the stakeholder's generic policy. The stakeholder may have exceptional policies by having any of its rulesheet authors define a rulesheet with either or both of the problem space and primary custodian in the key as non-null.

Hence, one may realize that a stakeholder is free to define exceptional policies and is free to define a generic policy. For example, Acme Accountants might define a separate rulesheet for each of three different policies: one which pertains to any documents whose primary custodian is Acme Accountants' subsidiary Big Branch Bookkeeping, one which pertains to the specific, exceptional case of Big Branch Bookkeeping's documents of problem space “parent company's ledger” (this policy takes precedence over the former), and one generic policy pertaining to all other circumstances.

Within the CDCL system, the identified primary custodian of a document is treated differently from any other identified entities holding stake in the disclosure of that document. The primary custodian must have its policy discovered and included by the operating CDCL Gatepoint, whereas the other stakeholders' policies may or may not be discovered and included. Failure to include the primary custodian's policy is an error condition.

Another feature of CDCL Authoring Form is its permissiveness in allowing a rulesheet author to express policy using a minimal quantity of rules in any given rulesheet. Depending on policy, succinctness can foster clarity. During decision-making, a CDCL Gatepoint ensures complete coverage of disclosure control for all data within a document by first applying decisions to applicable pieces of data according to policy, thereafter followed by inheritance of the decided outcomes to any children data elements (in a hierarchically structured document) that have no outcomes, and concluded by the application of the rulesheet's default rule to any data still lacking outcomes.

One may realize that a valid rulesheet, therefore, contains one and only one default rule and may contain zero to many other rules. All data within a document will have decided outcome(s) when a CDCL Gatepoint finds and includes at least the primary custodian's valid rulesheet.

Familiarity with a document's format or schema would allow a rulesheet author to intentionally leverage the feature of outcome inheritance. Lacking such familiarity, one should be prudent and draft explicit rules for every semantic that is pertinent in one's policy.