Conflict Detection & Resolution
How SpecGraph's AI detects conflicts between department requirements, and how teams work through resolution.
Conflict Detection & Resolution
When requirements come from multiple departments independently, conflicts are inevitable. One team wants a feature that contradicts another team's constraint. Two departments need the same resource but in incompatible ways. A security requirement rules out an engineering shortcut. SpecGraph's conflict detection surfaces all of these issues explicitly, before they cause problems in development.
What Counts as a Conflict?
The AI looks for several types of incompatibility between wishes:
Direct Contradictions Two wishes that are mutually exclusive: Engineering wants to build a stateless API while the mobile team requires server-side sessions.
Scope Conflicts One wish greatly expands the scope in a way that makes another wish impractical: a wish for real-time collaboration conflicts with an offline-first requirement.
Resource Conflicts Two wishes compete for limited budget, timeline, or effort in a zero-sum way: both wishes are marked Critical and Extra Large but together they exceed the project's capacity.
Technical Incompatibilities Two wishes that are incompatible at the implementation level: a wish for a NoSQL database conflicts with a wish for complex relational queries across multiple entities.
Priority Mismatch A low-priority wish from one department directly undermines a Critical wish from another: a "nice to have" simplification from one team would remove functionality that another team considers non-negotiable.
Reading a Conflict Card
Each conflict on the Conflicts page is presented as a card with the following structure:
Header: Conflict title, severity badge (Critical / High / Medium / Low), and current status (Open / Resolved).
Conflicting Wishes Panel: The two (or more) wishes in conflict, shown side by side with full details including department, type, priority, and description.
AI Explanation: A plain-language description of why these wishes conflict and what the core tension is.
Impact Analysis: A breakdown showing how each PRD section would be affected if Wish A is prioritized vs. Wish B. This helps the team understand the downstream consequences before deciding.
Resolution Options: AI-suggested paths forward, each with a brief rationale and trade-off summary.
Discussion Thread: A comment thread where any team member can add context, push back, or propose alternatives.
Vote Panel: Team members can vote on which resolution option they prefer. Votes are visible in real time.
Working Through a Conflict
Step 1: Understand the Conflict
Read the AI explanation and the impact analysis carefully. Make sure you understand not just what the conflict is, but why it matters — which PRD sections are at risk and what the downstream consequences of each resolution path would be.
Step 2: Discuss
Use the discussion thread to bring in context that the AI might not have had. This could be:
- Budget or timeline constraints that make one path unfeasible.
- Regulatory requirements that override a preference.
- Technical facts that rule out an option.
- Stakeholder priorities that haven't been formally captured.
Tag team members in comments to bring them into the discussion.
Step 3: Vote
Once the options are understood, team members vote on their preferred resolution. Votes help surface consensus (or lack of it) quickly.
Step 4: Resolve
When discussion has converged — or when the project lead is ready to make the call — click Mark as Resolved and select the chosen resolution path. Add a brief resolution note explaining the rationale if it's not obvious from the discussion.
The resolution is recorded, timestamped, and attributed to the resolver. Resolved conflicts remain visible in the project history.
Conflict Severity and Blocking Rules
| Severity | Description | Blocks Unification? |
|---|---|---|
| Critical | Fundamentally incompatible; project cannot proceed without resolution | Yes |
| High | Significant impact; strong recommendation to resolve | Yes |
| Medium | Notable tension; resolution recommended but not required | No |
| Low | Minor friction; can be noted and deferred | No |
All Critical and High conflicts must be in the Resolved state before the Generate Unified PRD button becomes available.
Conflict Statistics
The top of the Conflicts page shows a summary panel:
- Total conflicts detected.
- Breakdown by severity (Critical / High / Medium / Low).
- Resolved count vs. open count.
- Estimated time to completion based on resolution velocity.
Use this panel to track progress and identify which severity tiers still need attention.
Re-Running Conflict Detection
If a department amends their survey after conflict detection has been run, or if wishes are manually added or edited, you can re-run conflict detection to catch any new conflicts introduced by the changes. Click Re-detect Conflicts from the Conflicts page.
Re-running conflict detection does not remove previously resolved conflicts — it only adds new ones. Previously resolved conflicts stay in the resolved state.