Using Coding Rules to Structure Review

Table of contents


Organized and consistent coding is crucial for an efficient review. On Everlaw, project administrators can configure coding rules to ensure consistency across documents. There are two types of coding rules on Everlaw: conditional rules and auto-code rules. Conditional coding rules require users to perform certain actions when specific criteria are met. For example, project admins may require that users code documents as “Reviewed” if they have applied an issue code to the document. Auto-code rules, on the other hand, allow project admins to dictate that all documents in a context (i.e., duplicate families, attachment families, email threads, document versions) be automatically coded in the same way. This article will discuss administering both types of rules. To read a reviewer-focused article about conditional and auto-code coding rules, please see this article

Return to table of contents

Conditional coding rules

Conditional coding rules allow project administrators to enforce certain review behaviors. For example, a project administrator can dictate that, if a user rates a document Hot or Warm, they must also add a code to further specify why a document is important.

Project administrators can configure conditional coding rules from the Conditional Rules tab on the Project Settings page under Codes. 



To set up a conditional rule, click + New Conditional Rule at the top right of the conditional rules table.


First, set your rule’s requirement. This is the action that you are requiring for documents that fit your condition.  In the example below, the requirement is that documents must be coded under the category “Privilege.” Requirement.PNG

Next, set your rule’s condition. The condition criteria indicate which documents the conditional rule will apply to. Phrased another way, by setting a conditional rule you are saying, “The document must have this requirement before it can fulfill condition.” In the example below, the condition for the rule is, “the document must have [a requirement] before it can be rated hot”  The requirement you establish will apply only to documents rated as hot.


You have now created your conditional rule, which is “A document must be coded under Privilege before it can be rated Hot.” When you create your new conditional rule, you may see a dialog notifying you of potential interactions with auto-code rules. Please see this section to learn more. 


The admin override toggle, if selected in the rules table, allows only project admins to save document changes that violate the designated rule. Non-admin users will never be able to violate the conditional rule by directly coding a document; if they try, their changes will not be saved. However, documents coded via auto-code can be coded in violation of a conditional rule by non-project admins. Please read the section on potential conditional rule violations below for more information. 

The violations column displays the number of documents that are in violation of the conditional rule. There could be violations for two reasons: the conditional rule was set up after users coded some documents and there exist documents in violation of the rule, or admin users have toggled the admin override and coded documents in violation of the rule. Clicking on the number of violations will bring up a results table of all the documents that are in violation of a given rule.

The trash can icon deletes the rule.

Return to table of contents

Auto-code rules

Auto-code rules can help you ensure that all documents in a given context (i.e., duplicates, attachment families, email threads, versions) are coded similarly.

Auto-code rules associate a coding category with a specific context, such that any time a code from the specified category is applied or removed to/from a document, all documents in the specified context are automatically modified in the same way. For example, a project admin may want to ensure that all documents in an attachment family are given the same code under the Responsiveness category. Instead of relying on people to remember to manually apply the same Responsiveness codes to each document in an attachment family, the project admin can configure an auto-code rule which specifies that anytime a document is coded under the Responsiveness category, the same code is automatically applied to all members of the document’s attachment family. By default, auto-code rules apply to all users, but groups with the Auto-Code Override permission can choose to turn off auto-code when coding documents. 

To configure an auto-code rule, navigate to the Codes tab of the Project Settings page, and then choose Auto-Code Rules. 


Next, click New Auto-Code Rule in the top right corner. This will open a wizard where you will specify which category and context the rule should apply to. The scope of the duplicates context will depend on whether email threading deduplication is turned on in your project. If email threading deduplication is on, the duplicates context will span both exact and email duplicates; if email threading deduplication is off, the duplicates context will only span exact duplicates. To learn about this setting, please see this article.


The first step is to choose the coding category that you want associated with the auto-code rule. Any code from this category that is applied to a document will be automatically applied to all documents in the specified context. Once you’ve chosen a category, you can specify which contextual documents the auto-code rule should automatically apply codes to. Please note that each coding category can only be associated with one context. This is to prevent the inadvertent modification of many documents at once.   

According to the auto-code rule shown below, if a code under the Responsiveness category is applied to a document, that same code will be applied to all documents in its attachment family. 


Once you’ve finished configuring your auto-code rule, click “Save rule.” Please note that creating an auto-code rule will not automatically modify codes on documents that were previously coded. Only documents that are coded after the rule has been saved will be affected by the auto-code rule. 

Once your auto-code rule has been created, it will be displayed in the Auto-Code Rules table.


Clicking on the auto-code rule’s category or its context will allow you to edit which context the rule applies to. The auto-coded documents column displays how many documents have been auto-coded by the rule. Clicking the number of auto-coded documents will open a results table of affected documents grouped by the specified context.

The Violations column displays how many documents are in violation of the auto-code rule. A document is counted in the Violations column if it differs from at least one document in the specified context by at least one code from the specified category. Clicking the number of violations will open these documents in the results table, grouped by the relevant context. An auto-code rule may be violated if someone with the Auto-Code Override permission chooses to override auto-code rules when coding a document, or if documents were coded prior to the creation of the auto-code rule in such a way that now violates the rule. 

Finally, clicking the trash can icon will delete the auto-code rule. Deleting an auto-code rule will not modify codes on any documents that were coded prior to deleting the rule; Everlaw will simply cease to automatically apply codes based on the rule in the future. 

Return to table of contents

Conditional Rule Violations Due to Auto-Code Rules

Upon saving a new conditional or auto-code rule, you may see a dialog about potential conditional rule violations.


Warning dialog when creating a new auto-code rule that interacts with an existing conditional rule. This dialog tells you that your new auto-code rule may automatically apply a code that will trigger an existing conditional rule.


Warning dialog when creating a new conditional rule that interacts with an existing auto-code rule. This dialog tells you that an existing auto-code rule may automatically apply a code that will trigger the conditional rule you are creating. 

These dialogs will notify you if the rule you are creating may lead to conditional rule violations. These two scenarios will occur if the category specified in an auto-code rule contains at least one code that satisfies the condition criteria of a conditional rule. If the conditional rule’s condition is later satisfied but its requirement is not, the document will be in violation of the conditional rule. It is important to note that conditional rule violations work differently for documents that are coded directly versus documents that are coded via auto-code. Documents that are coded directly cannot be coded in violation of a conditional coding rule (i.e., the coding change(s) that triggered the conditional rule will not be saved). By contrast, documents can be auto-coded in violation of a conditional coding rule. The violation will appear on the document, but the coding change that triggered the violation will be saved. 

If you see one of these warning dialogs, you can choose to create the rule anyway, or you can go back and change the rule’s configuration so that it will not create conditional rule violations. 

For a more detailed explanation of the interaction between conditional rules and auto-code rules, let’s look at an example: 

Let’s imagine that we are creating a new auto-code rule. In the example below, our new auto-code rule is configured to automatically apply codes under the Responsiveness category to all attachment family members.


When we save the rule, a warning tells us that there is an existing conditional rule that requires all documents that are coded “Responsive”--a code under the Responsiveness category--to also be coded under the Redaction Status category.


Let’s now imagine that someone on this project is reviewing Document A, which has an attachment called Attachment 1. 

  • The reviewer applies the code “Responsive” to Document A, and also applies the code “No redaction needed” (under Redaction Status) in order to satisfy the conditional rule. 
  • Due to the auto-code rule we set up earlier, which propagates any Responsiveness code applied to a document to all of the document’s attachment family members, both Document A and Attachment 1 will be coded “Responsive.” 
  • However, Attachment 1 will not be automatically coded with “No redaction needed” (assuming we have not set up an auto-code rule to propagate Redaction Status codes to attachment family members). The reviewer’s coding decision will therefore create a conditional rule violation on Attachment 1, as Attachment 1 will be coded “Responsive” without also being coded under Redaction Status. 

As mentioned previously, coding changes that violate conditional rules will be saved if the coding changes are made via auto-code, but coding changes that violate conditional rules will not be saved if the coding changes are made via direct coding. This means that if the reviewer had applied the “Responsive” code to Document A (via direct coding), but did not also apply a code under Redaction Status to Document A, neither Document A nor Attachment 1 would have been coded “Responsive.” This is because the reviewer made a direct coding change that violated conditional rules; such coding changes are not saved (unless the user is a project admin and Admin Override has been turned on for the conditional rule). 

As a project administrator, you can view and triage conditional rule violations from the Conditional Rules table.


Return to table of contents

Have more questions? Submit a request


Article is closed for comments.