Table of contents

• Introduction
• Conditional coding rules
• Auto-code rules
• Conditional Rule Violations Due to Auto-Code Rules

Introduction

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.”

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 propagate any coding decisions made within a category, rating, or freeform code to all documents in a given context, such as duplicates, attachment families, and email and chat conversations. 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. 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. Navigate to the Codes tab of the Project Settings page, and select Auto-Code Rules
   • 
2. Click 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 that 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).
   • 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.
   • 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.

From the table you can:

• Edit a rule's context by clicking on the auto-code rule's category or context
• See and access documents coded according to the rule by clicking the number in the Auto-coded documents column
• See and access existing violations by clicking the number in the Violations column. This will open 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 by clicking the associated trashcan icon. 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 

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 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