# One Requirement Set: Duplicates and Conflicts Across Documents

> When several documents describe the same system, they overlap. The BRD says "Email is required", the meeting notes say "Customer email must be present", and the rules workbook lists it again as BR-007.

Source: https://totalshiftleft.ai/help-center/product-documentation/requirements-cross-document-duplicates-and-conflicts

> **Applies to:** All editions (requirements review is basic on Free; full on Professional and Enterprise) · Web app and Desktop app · A role that can edit the project

## Overview

When several documents describe the same system, they overlap. The BRD says "Email is required", the meeting notes say "Customer email must be present", and the rules workbook lists it again as `BR-007`. If each statement became its own requirement, you would review the rule three times and Studio would generate the same tests three times.

They also disagree. The BRD says an order can hold up to 100 items; the meeting notes say 50. A test can check only one of those numbers, and picking one silently would mean the other document's author finds out from a failing run.

Shift-Left Studio treats all the documents in a project as one requirement set. A rule stated in several documents is counted once. Where documents give different values for the same rule, nothing is generated for that rule until a person decides which value is right. You make those decisions on the **Gaps & conflicts** tab, in the **Across your documents** panel.

## Key concepts

| Term | What it means |
|---|---|
| Counted requirement | The one statement of a rule that Studio counts, reviews, and generates tests from. |
| Copy | Another document's statement of the same rule. It keeps its own row and source, is marked **Same rule as another document**, and generates no tests of its own. |
| Disagreement | Two or more documents give the same field and condition different values, for example a maximum of 100 in one and 50 in another. |
| Document rank | Your ranking of which document is most authoritative. It only **suggests** which value to use; it never decides for you. |
| Settled disagreement | A disagreement you have decided. It can be reopened at any time. |

## Before you begin

- At least two requirement documents in the project must have been extracted. See [Working with Many Requirement Documents](/help-center/product-documentation/requirements-multiple-documents).
- The panel appears only on the project-wide **Gaps & conflicts** view, not when you are looking at a single document.

## How duplicates are recognized

Studio groups two requirements from **different** documents as the same rule when any of these is true:

- They carry the same Studio requirement id.
- They state the same constraint on the same field, even in different words ("Email is required" and "Customer email must be present").
- For narrative requirements, they carry the same id from your documents, such as `BR-014`.
- You have told Studio they are the same rule.

Requirements that are merely similar in wording are never grouped automatically. They are offered to you under **Might be the same rule** so you can decide.

When a group forms, Studio picks which statement is counted. It prefers, in order: a statement a person has reviewed, the higher-ranked document, the statement that already has tests, and the more complete statement. Tests that were linked to a copy are also linked to the counted requirement, and a review decision on the counted requirement is carried to its copies.

> **Note:** Each document keeps all of its own rows. Grouping never deletes a requirement, so you can always find a rule by the document it came from.

## Step 1 — Open the cross-document view

1. Open your project's requirements and select the **Gaps & conflicts** tab.
2. At the top, find **Across your documents** — "A rule stated in several documents is counted once. Where they disagree, you decide which is right."
3. The panel contains up to five parts, each with a count. Click a heading to expand it.

| Section | What it lists |
|---|---|
| **Your documents disagree** | Open disagreements. Expanded by default. |
| **Disagreements you settled** | Decisions you have made, each with **Reopen**. |
| **Might be the same rule** | Pairs that look alike but were not grouped automatically. |
| **Stated in more than one document** | Groups: the counted requirement and the documents that also state it. |
| **Which document wins** | Your ranking of the documents. |

If the project's requirements were extracted before this feature existed, the panel brings them up to date the first time you open it.

## Step 2 — Rank your documents (optional)

Ranking tells Studio which value to suggest when documents disagree.

1. In **Which document wins**, use the **Rank** drop-down beside each document. Rank 1 is the most authoritative.
2. Optionally set the **Kind of document…** drop-down, for example **Business requirements (BRD)**, **Product requirements (PRD)**, **Functional specification**, **Business rules**, **Backlog / user stories**, **Data dictionary**, **Meeting notes**, or **Other**.
3. Changes are saved immediately and the panel is refreshed.

> **Important:** Ranking never settles a disagreement by itself. A rank set weeks ago should not silently decide a conflict nobody has looked at, so the higher-ranked value is only shown first and highlighted. A person still chooses.

## Step 3 — Settle a disagreement

Each card under **Your documents disagree** shows:

- The field and the values, for example "`order.items` is stated as **100** and **50**".
- Each document's statement: document name, where in it (section, sheet, line, page), the value, and the original sentence.
- A suggestion if your ranking gives one ("Suggested: 100 — …"), or "No test is generated for this rule until you decide."

Choose one of the following:

1. **Use <value>** — one button per value. The suggested value's button is highlighted. The chosen value becomes the rule, and the other statement is marked as replaced.
2. **Both are right…** — when each value applies in a different situation (for example, 100 for business accounts, 50 for consumers). Type when each value applies and click **Save**. A note is required.
3. **Another value…** — when neither document is right. Type the correct value and click **Save**.

Click **Cancel** to close the input without saving. After you decide, the card moves to **Disagreements you settled**, and tests can be generated for the rule again.

> **Note:** If a card says "possibly one number in two units", the documents may state the same limit in different units (for example, seconds and milliseconds). Check the sentences before choosing.

## Step 4 — Reopen a decision

1. Expand **Disagreements you settled**. Each row shows the chosen value and what the values were at the time ("was 100 vs 50"), or the note for a "both" decision.
2. Click **Reopen**. Every requirement involved returns to exactly the state and value it had before the decision.

A decision applies only while the disputed values stay the same. If a document is changed and now states a third value, the disagreement opens again so you can decide with all the values in front of you. Decisions survive re-extracting a document as long as the values have not changed.

## Step 5 — Decide look-alike pairs

1. Expand **Might be the same rule**. Each item shows two requirements with their ids, titles, and documents.
2. Click **Same rule** to group them, or **Different rules** to keep them apart permanently. A "different" decision also stops the pair from being grouped later.

## Understanding the results

Where you see the effect of the requirement set:

| Where | What you see |
|---|---|
| Document list | **N already in X** (rules restated from an earlier document) and **N disagree** (open disagreements involving this document). |
| Review list | **Same rule as another document** on a copy; **Also in …** on the counted requirement. |
| **Gaps & conflicts** list | A rule held back by a disagreement is listed under **Your documents disagree — settle it above**. |
| Coverage, traceability, and test generation | Each rule is counted once. A rule with an open disagreement is not used for generation. |

| State of a rule | Generates tests? |
|---|---|
| Counted requirement, approved | Yes |
| Copy | No — its counted requirement does |
| Open disagreement | No, until you decide |
| Settled with **Use**, **Both are right**, or **Another value** | Yes, from the decided value |

## Troubleshooting

| Symptom | Why it happens | What to do |
|---|---|---|
| The **Across your documents** panel does not appear | The project has fewer than two documents and nothing to compare, or you are viewing gaps for a single document. | Open the **Gaps & conflicts** tab from the project-wide view with at least two extracted documents. |
| Coverage shows fewer requirements than the documents contain | Duplicates are counted once. | Expand **Stated in more than one document** to see which rules were grouped. |
| A rule generates no tests | It has an open disagreement, or it is a copy. | Settle the disagreement, or look for its counted requirement (the row marked **Also in …**). |
| Two clearly different rules were grouped | They stated the same constraint on the same field. | If they genuinely differ, edit one so its field or condition is accurate; the grouping is recalculated. |
| A settled disagreement came back | A document now states a value that was not part of your decision. | Decide again with the new value in view. |
| "That could not be saved." | The disagreement changed or was settled elsewhere while the page was open. | Refresh the tab and decide again. |

## Best practices

- Rank documents as soon as you add them. Suggestions then appear with every disagreement.
- Settle disagreements before generating tests for a feature; until then, those rules generate nothing.
- Use **Both are right…** with a clear note when a value depends on the situation, rather than choosing one and losing the other case.
- Treat each disagreement as feedback for the document authors. Send the quoted sentences back to them so the source documents get corrected.
- Review the **Might be the same rule** list periodically; it keeps look-alikes from being tested twice.

## FAQ

**Does Studio ever resolve a disagreement automatically?**
No. The ranking suggests a value, but a person always decides, because a test can only assert one value and the wrong choice would hide a real problem.

**Can the Project Assistant settle a disagreement?**
The assistant can describe a disagreement and, once you tell it which value is right, offer to record your decision for you to accept. It never picks a side on its own.

**What happens if I delete the document a rule was counted from?**
If another document also states the rule, that document's statement becomes the counted requirement. The delete confirmation tells you how many rules are kept this way.

**Does grouping change my approved requirements?**
Only grouping information is added. The text, status, and values of a reviewed requirement are not changed by extracting another document.

## Related articles

- [Working with Many Requirement Documents](/help-center/product-documentation/requirements-multiple-documents)
- [Requirement Gaps and Use-Case Journeys](/help-center/product-documentation/requirements-gaps-and-use-case-journeys)
- [Requirement Document Versions](/help-center/product-documentation/requirements-document-versions)
- [Importing and Reviewing Requirements](/help-center/product-documentation/importing-and-reviewing-requirements)
- [Coverage and Extraction Fidelity](/help-center/product-documentation/coverage-and-fidelity)
- [Requirements Traceability Matrix](/help-center/product-documentation/requirements-traceability-matrix)

## For administrators (self-hosted installations)

| Setting | Default | What switching it does |
|---|---|---|
| `RIE_REQUIREMENT_SET_ENABLED` | `true` | `false` turns off cross-document grouping and conflict detection. The next refresh removes existing groups, so every statement is counted separately again. |