

The segmentation model breaks up a document into sections by looking for various signals for the start and end of a section. The model assigns a weight for each of these signals, decides on the coordinates of each section, then generates a new document for every section it finds. Each new document is then auto grouped with the root agreement itself and other sections found in the root agreement using a family identifier field called Document Parts.
At a high level, the segmentation model relies on the outline format of a contract. For example, the structure of the section headings. If the contract has some structure in the form of discernible section headings, the segmentation model will use this information.
The model will then take the beginning of a section heading, find all the text until the next section heading, and create a new section for the heading and body. The model recognizes that additional information at the end of a section such as page numbers, footers, and white space should not be included in the section.
Note: The model does not segment subsections, only the top-level section. For example, if Section 1 contains Section 1.1 and Section 1.1.A, Contracts will only segment Section 1 and not individually parse out any subsections within it.
Contracts is more accurate at some structure types than others. This is because of the publicly available contracts that Contracts has used as training data for building models to segment documents. You can assume that for high accuracy structure types, Contracts has a lot of training data and for low accuracy structure types, it has less. You can also assume that high accuracy structure types are more commonly used in practice. Though you may see low accuracy structure types on projects, they are far less common.
Once the model finds the last section in the main contract, it stops. This means that the model should not segment any sections after the signature block appears. For example, if there are addendums or exhibits in the document, the model will not segment sections within them. If it does, that means Contracts has incorrectly located the end of the main contract.
There are several scenarios where running segmentation would be appropriate. Following are examples of those scenarios.
Note: Segmentation can be a powerful tool, but it may not be required for your project. If you only need to extract certain data points to fields and you have quality regex that will yield the results you need, you may not need each document to be split up into sections.
Compare allows you to compare textual differences at the section-level by selecting section documents and using the compare mass action.
One common use case is when a company buys another and wants to uncover how certain key clauses in contracts they are acquiring differ from existing standard language.
Since every section is a document in Relativity, you can take advantage of the compare mass action to hone in on differences.
Once your population of documents is segmented and all sections are classified with a section type, you can use the Populate Section Text script. This script populates a yes/no field on each main document to indicate whether or not it contains a certain section. You can also populate a long text field with the text of that section on the document.
You could use this to determine which of your documents contain a Confidentiality section. A project requires extracting data points around obligations within Confidentiality sections.
To use the Populate Section Text script:
You can run segmentation to unlock the ability to filter a section using regex.
For example, if you are looking for a contract's Termination date, Contracts includes a Date regular expression that is great at finding dates in most formats. However, since you only care about the date in the Termination section, you have to figure out some way to refine your regex so that it only returns dates in the Termination section.
If you have all your documents segmented, including all Termination sections, you can create a saved search of all Termination sections, select it as a Regular Expression Filter, and see only hits in the Contracts Viewer for dates in the Termination section. This filtering power extends to field auto population as well.
When creating or editing an analysis profile, you can auto link references to sections. This setting will only work when a segmentation model is also selected in the analysis profile.
If checked, this will create links in the documents for all instances where the text references a section. For example, a reference like "as provided in Section 5" will appear in the Contracts Viewer as a link. Clicking that link will navigate you to Section 5, found during Segmentation Analysis. This setting will apply to all such references in the document.
If your document is fully segmented and you auto link references, more links will generate for self-references in the document.
Since Contracts lets reviewers code individual sections within the Contracts Viewer, you could implement a workflow where multiple reviewers are coding different sections on the same document at the same time.
You can create a section-level report that lists out the risks and obligations for each section you care about. To achieve this, you'd want reviewers coding sections.
For workflow efficiency, you can batch out all Assignment sections to your best assignment reviewers.
You can run segmentation with Contract's analysis profile or a custom profile.
To run segmentation with Contract's analysis profile:
The status of the analysis will appear under the Status section. Once complete, click the Refresh button to refresh the page and view results.
To create a custom analysis profile:
After you create a new analysis profile, run analysis with that profile:
The status of the analysis will appear under the Status section. Once complete, click the Refresh button to refresh the page and view results.
Following is a list of all fields that Contracts will auto-populate when you run segmentation.
Field | Field Type | Field Auto-population | ||
---|---|---|---|---|
Section Heading | Fixed-length text | Auto-populated with the verbatim section heading, extracted directly from text in the contract. | ||
Section Warnings | Fixed-length text | Auto-populated with One or more sections were missed if the model thinks it may have missed sections during segmentation. | ||
Section warning details | Long text |
Auto-populated with information on which sections the model thinks it may have missed during segmentation. For example, Missing section(s) 3, 4, 6. |
||
Contracts Section Start | Whole number |
Auto-populated with a number denoting coordinates for the start of a section. Note: Contracts uses this field to order section documents top-down as they appear in the root agreement in both the Sections pane of the Contracts Viewer and the Contracts Segmentation view on the document list in Relativity. |
||
Contracts Section End | Whole number |
Auto-populated with a number denoting coordinates for the end of a section. Note: Since Contracts knows the coordinates for the starts and ends of sections, you can navigate to sections within the Contracts Viewer precisely. |
||
Document Parts | Fixed-length text |
Auto-populated with a family identifier for grouping sections with their root agreements. Note: This is helpful for keeping sections visually grouped together with root agreements on your document lists and in the Sections pane of the Contracts Viewer. |
||
Document Type | Single choice | Auto-populated with Section on all section documents the model creates. | ||
Contracts Related Documents | Fixed-length text |
Auto-populated with a family identifier for grouping related documents, such as amendments, with their root agreements. All section documents within a root agreement will share the same ID. |
Note: If you run segmentation and later edit the values of these fields, running segmentation again will replace your manual edits.
If contracts segmentation is not performing well on your data set, you can segment documents based on your own custom regular expression:
To run analysis:
The status of the analysis will appear under the Status section. Once complete, click the Refresh button to refresh the page and view results.
The following parsing flags may appear when using segmentation:
Parsing flag | Description |
---|---|
Segment before match | A section should be created before the match and another section at the start of the next match. If your regular expression is matching on section headings, you should use the Segment before match parsing flag. |
Segment after match | Section should be created through the end of matched text and another section after the match. If your regular expression is matching on where sections end, you should use the Segment after match parsing flag. |
Segment except match | Sections should be created before & after the match, with the matched text not included in either section. If you want everything but your matches to be sections, you should use the Segment except match parsing flag. |
Segment only match | A section should be created for the match itself and only for the match itself. If your regular expression is finding key language that you want to be a section (but you don't want anything else to be a section), you should use the Segment only match parsing flag. |
When you need to improve segmentation results but don't have the time or inclination to do so manually, you can semi-automate this process:
Why was this not helpful?
Check one that applies.
Thank you for your feedback.
Want to tell us more?
Great!