Use Coding Rules to Structure Review

Organized and consistent coding is a primary goal during document review. On Everlaw, you can create coding rules to ensure consistency across documents and reviewers. There are two types of coding rules on Everlaw: conditional rules and auto-code rules.

Conditional rules require users to perform certain review actions when specific review 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 ensure that all documents in a context (i.e., duplicate families, attachment families, email threads, document versions) are automatically coded in the same way.

Use this article to understand how to create and administer both types of rules.

To read a reviewer-focused article about conditional and auto-code coding rules, please see this article. 

Requirements

Required permissions:  To create coding rules, you must be a Project Admin or have Code Admin permissions.

The Codes section of Project Settings must already contain the codes that you want to enforce with the rules you create.

Conditional rules

Conditional rules allow Project Administrators to link review actions together. For example, a project Administrator can require that, if a user rates a document Hot or Warm, they must also add a note to further specify why a document is important.

Understand conditional rules

Conditional rules comprise a requirement and a condition. There a two helpful ways to think about it. 

One way is to think of the requirement as the piece of review work that must be applied in order for the review work designated as the condition to be applied. For example, if the requirement is that the document has a note, and the condition is that the document is rated Hot, then you can think of the rule as "In order for a document to be rated hot, a reviewer must apply a note to the document."

Another way to think about a conditional rule is as an "If...then..." statement. When you create the rule, first you identify the requirement, which is the "then..." part of the statement. The condition is the "If..." part of the statement. In the previous example, where the note is the requirement and rating a document Hot is the condition, The statement is "If a document is rated hot, then it must have a note."

If a reviewer applies the review work from the condition to a document without applying the review work from the requirement, the receive a warning that their change violates conditional rules.

If they try to move on to the next document without adding the requirement, they receive a warning that "Any changes on documents with conditional rule violations will not be saved." 

Create a conditional rule

To set up a new conditional coding rule:

1. Access the Conditional Rules page: Go to Project Management > Project Settings > Codes > Conditional Rules.
2. From this page, select + New Conditional Rule at the top right of the conditional rules table.
   
   This opens the dialog to configure a new rule.
3. First, set your rule’s requirement by using the query builder to specify the review work that you are requiring. 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.”
   
4. Select Next to move on to the Condition step.
5. Set your rule’s condition. The condition criteria indicates which documents the conditional rule will apply to.
   
6. When you're done, select Submit.  You have now created your conditional rule. You can think of it as either of the two descriptions:
   • A document must be coded under Privilege before it can be rated Hot
   • If a document is rated Hot, then it must also be coded under Privilege

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 about conditional rule violations due to auto-code rules to learn more. 

Administer conditional rules

Once you have created a rule, it is listed in a table with information about the rule. From this table you can:

• Edit the requirement or condition: To do so, select the requirement/condition. This opens a dialog to edit it the relevant portion of the rule. When you're done, select Save.
• Allow Admin override: Select this box to allow 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.
• Access documents that violate the rule: The violations column displays the number of documents that are in violation of the conditional rule. Clicking on the number of violations takes you to a results table of all the documents that are in violation of a given 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
  • Admin users have toggled the admin override and coded documents in violation of the rule.
• To delete the rule, select the delete button

Auto-code rules

Auto-code rules propagate any coding decisions made within a category, rating, or freeform code to all documents in a given context. These rules are helpful for enforcing consistent coding across related documents. For example, you may want to enforce the rule that all documents in an attachment family should have the same Responsiveness coding. When you create an auto-code rule for the Responsiveness code and a reviewer codes an email as Responsive, the code is automatically applied to all the attachments to that email. 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:

1. Access the Auto-code Rules page: Go to Project Management > Project Settings > Codes > Auto-Code Rules.
2. Select + New Auto-Code Rule. This opens a wizard where you specify which category and context the rule should apply to.
3. Use the selector at the top to choose which code category, rating, or freeform code to propagate as part of the rule.
   
4. Select the document context you want the rule to apply to.

   Note

   Each coding option can only be associated with one document context (ie. if you create a rule that propagates rating decisions to duplicates, you cannot create another rule that also propagates rating decisions to attachments).

   Note

   The scope of the duplicates context depends 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 more about this setting, please see this article.

5. Select Save rule when you are finished.

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

From the table you can:

• Edit a rule's context: Select the auto-code rule's category or context. Then choose the new context and select Save rule.
• See and access documents coded according to the rule: Select the number in the Auto-coded documents column. This opens a results table of these documents.
• See and access existing violations: Select the number in the Violations column. This opens these documents in the results table, grouped by the relevant context.
  A document is counted as a violation if at least one document in its context differs by at least one code from the relevant category.
  Violations can occur 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 a way that now violates the rule.
• Delete a rule: Select the associated delete button. This means the rule will not be applied to any coding decisions moving forward. 
  Deleting an auto-code rule will not modify any existing coding 

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 notify you if the rule you are creating may lead to conditional rule violations. These scenarios 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 appears 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," because there is not an auto-code rule for the Redaction status category. The reviewer’s coding decision therefore creates 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 are 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 

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