Redact project best practices

Duplicate markups can slow down your review workflow, inflate markup counts, and cause unexpected behavior during production. You can use the following tips to prevent duplicate markups and ensure that your Redact projects run smoothly.

Use the minimum number of projects

The fewer projects you have running against the same documents and markup set, the lower the risk of duplicates. Before creating a new project, ask whether you can instead update the rules on an existing project. In most cases it can.

Revert before experimenting with a new project

Creating and running too many projects is a common cause of duplicate markups. Instead of creating a new project that is potentially similar to others to try out a different rule configuration, revert the existing project. This clears the markups from the old project so that they do not accumulate alongside the results from the new one.

Update rules in an existing project rather than creating a new one

If you run a project and are not happy with the results, edit the rules, revert the project to clear any previously applied markups, and then rerun the project to test the edited rules. We recommend this workflow because it ensures that no markups from the initial project run are left on the documents and so you can see exactly how the edited rules work.

Creating a new project for every rule change and running it alongside the old projects accumulates markups from multiple projects on the same documents. Over time this leads to duplicate markups that are difficult to untangle.

Maintain one data source per project

To prevent duplicate markups, we recommend using one unique saved search per project and avoid using either the same or similar rules across projects, particularly with the same markup set. If documents appear in multiple projects with overlapping rules and the same markup set, duplicate markups are almost certain once you run the projects.

For example, the following setup is recommended because there are no shared documents, there is a low chance of duplicate markups:

• Project A - Saved Search A - Markup Set 1
• Project B - Saved Search B which has no documents shared with Saved Search A - Markup Set 1

The following setup is not recommended because the overlap between documents and rules in Project A and Project B in this example has a much higher chance of causing duplicate markups when both projects are run:

• Project A - Saved Search which includes documents 1-500 - Markup Set 1 - PII rules
• Project B - Saved Search which includes documents 400-800 - Markup Set 1 - same PII rules

Use separate markup sets if multiple projects must cover the same documents with the same rules

If your workflow requires multiple projects to process the same documents with similar or the same rules, we recommend assigning each one of these projects its own unique markup set. This makes it easy to track the markups that are applied by the different projects.

Other overlapping scenarios

You can run projects that use unique rules, even if they share documents and the same markup set because the markups will be applied to different content and in different locations within the documents.

If you have projects that use unique rules- for example, one project for PII and another for privilege terms - they can safely share both the same documents and the same markup set, since their markups will cover different content and locations.

For example, the following setup has different rules but the same markup set and because the rules are unique, there is little concern over duplicate markups:

• Project A - PII rules - All Redactions markup set
• Project B - Privileged terms rules - All Redactions markup set

The following setup is not recommended because it uses the same rules and the same documents which is likely to cause duplicate markups:

• Project A - PII rules - first batch documents - PII Redactions - Batch 1 markup set
• Project B - PII rules - second batch documents which contains the same ones as first batch - PII Redactions - Batch 2 markup set

Audit your projects before running

Before running a project that contains a lot of documents, verify that:

• No two active projects share the same documents, the same markup set, and the same or similar rules.
• Projects that were used for testing or earlier rule iterations have been archived or deactivated so that none of their markups persist.
• Any previously applied markups from deprecated projects have been removed.