Relationship Guidance

Last updated: October 26, 2026

Relationship Guidance lets Repository Admins provide context about their contracts to help Ivo form relationships between documents more accurately. This is especially useful for workspaces with unconventional contract naming conventions, unusual referencing styles, or non-standard contract hierarchies.

Who can use this

Viewing and editing Relationship Guidance requires the Intelligence Admin Role.

When to use it

Relationship Guidance is most valuable when configured before ingesting contracts into your repository. Adding context ahead of time helps Ivo apply it from the start rather than having to re-process existing documents.

Examples of when Relationship Guidance is useful:

  • Your contracts use unconventional naming or referencing conventions that Ivo may not recognize automatically.

  • Certain contract families follow unusual hierarchies, such as a non-standard parent-child structure between agreements.

How to configure it

  1. Navigate to Settings → Repository.

  2. Open the Relationship Guidance section.

  3. Add your context or guidance for how Ivo should interpret relationships between contracts in your workspace.

  4. Save your changes.

Example of Relationship Guidance

The Relationship Guidance depends on the contracts you ingest into Intelligence and on how your business names and structures its agreements. Below is an example:

AGREEMENT STRUCTURE
Each customer relationship is normally governed by one top-level agreement, supplemented by schedules, addendums and amendments.
- Current structure: the top-level agreement is the Customer Agreement, typically with a Product Schedule for each product the customer buys. A missing schedule suggests non-standard treatment; it does not mean the product is unaddressed.
- Legacy structure: the top-level agreement was the Subscription Agreement, which covered the core software directly. Services were added either by a separate Professional Services Agreement or by a Services Addendum to the Subscription Agreement. Some customers instead have a Professional Services Agreement supplemented by a Software Addendum.
- Because accounts mix the two structures, a top-level agreement referred to by a legacy name, such as the Subscription Agreement or the Professional Services Agreement, may now go by the current name, Customer Agreement.
- Current-form schedules and addendums are deliberately used with legacy and bespoke top-level agreements, so mixed accounts are normal. Bespoke top-level agreements may have non-standard titles; a non-template title does not mean there is no governing agreement.

IDENTIFYING THE TOP-LEVEL AGREEMENT
Our schedule, addendum and amendment templates usually refer to the top-level agreement generically rather than by title and date, for example "the Subscription Agreement, Customer Agreement or other governing agreement between the parties." By convention, a generic reference like this points to whichever top-level agreement with that customer was in force on the referencing document's effective date. 
A generic reference is not evidence that no top-level agreement exists.

AMENDMENTS
Amendments are identified by effective date, not by title or number. Numbering is unreliable, many distinct amendments share the title "Amendment to Customer Agreement", and some are titled by subject matter.

FOOTERS
Footers in signed agreements identify the template name and version only (for example "Form CA-04"). They do not identify a governing agreement or document hierarchy.

Notes

  • Editing Relationship Guidance does not automatically re-run relationship detection on contracts that have already been uploaded. If you need relationships recalculated on existing contracts after updating your guidance, contact your Ivo contact or support team.

  • Relationship Guidance works on document content and naming conventions. It does not use contract metadata to form relationships.