Identify Contradictions in a Product Requirements Brief with ChatGPT

A product brief may contain requirements that look reasonable individually but cannot all be satisfied under the same conditions. One passage can require a control to remain disabled while another requires it to be available in that state. Finding those pairs early helps the team clarify behavior before implementation depends on an inconsistent specification.

This guide produces an original requirement conflict log with ChatGPT. Its examples are fictional, and current documentation was checked on October 6, 2026. The model proposes candidate conflicts; the product owner confirms the intended behavior and approves any specification change.

Establish the specification boundary

Identify the brief version, product edition, supported environment, and approved supporting documents. Separate current requirements from older examples and proposals. A difference between versions is not automatically a contradiction in the active specification.

Give every requirement a stable ID and preserve the original wording. Split compound statements when they specify several independently reviewable behaviors. Retain their relationship to the original passage so the extraction does not change the author's intent.

Record the meaning of terms such as must, should, optional, enabled, available, and complete if the team has approved definitions. If their meaning is unclear, mark that ambiguity instead of treating all statements as equally binding.

Extract behavior, condition, and scope

For each requirement, identify the subject, condition, expected behavior, exceptions, and relevant timeframe. A comparison becomes useful when it checks these components rather than simply searching for opposing words.

“The submit control is disabled before validation” and “the control is enabled after validation” are compatible because their conditions differ. Two requirements prescribing different behavior in the same validation state may be a conflict, but the owner should still check intended exceptions.

The current OpenAI prompting guide covers expressing context and boundaries. Here the boundary is that supplied requirements govern the analysis. A generated interpretation should remain labeled as an interpretation until the owner confirms it.

Classify differences before calling them contradictions

Separate duplicate requirements, complementary requirements, ambiguous terms, version differences, and candidate contradictions. A duplicate may be redundant but still consistent. An ambiguous phrase can make a conflict possible without establishing it.

Look for conflicts in values, timing, conditions, permissions, and interface states. Preserve units and thresholds for numerical constraints. A limit measured per session differs from one measured per account, so compare the denominator before proposing a contradiction.

Avoid resolving a pair by assuming an undocumented exception. If one requirement says “always” and another appears to limit the behavior, record the question that would establish the exception. Do not silently narrow the first requirement to make the log look clean.

Build the requirement conflict log

Use one row per candidate pair or clearly related group. The log should show why the statements may be incompatible and what decision would resolve that issue.

Keep source locations beside the requirement IDs. A reviewer should not have to search the whole brief to reconstruct the comparison. Retain the original wording even when the log uses a shorter normalized description.

Ask ChatGPT for evidence-linked candidates

Supply the brief, approved definitions, source authority, and log schema. Request extraction before comparison so you can check that each requirement has been represented accurately.

Extract requirements from the supplied product brief with stable IDs.
Preserve original wording, conditions, exceptions, units, scope, and version.
Compare requirements that apply to the same subject and overlapping conditions.
Separate duplicates, ambiguity, version differences, and candidate contradictions.
For each candidate cite the requirement pair and explain the shared context.
Do not resolve conflicts by inventing exceptions or rewriting approved behavior.
Return the conflict log, decision questions, and requirements not assessable from the packet.

Review both the extracted statements and the candidate pairs. A mistaken extraction can create a contradiction that never existed in the source. Correct the extraction first rather than merely deleting the resulting conflict row.

Review a fictional interface conflict

Suppose R-12 states that a fictional form's submit control must remain disabled while required fields are incomplete. R-27 states that the same control must always be enabled for that form, including incomplete states. The shared condition is an incomplete form, and the expected control states differ.

The log can ask whether submission should be prevented by disabling the control or by allowing a click and presenting validation feedback. That question describes the decision without choosing the product's behavior on the owner's behalf.

If R-27 actually refers to a different form or an accessibility-specific interaction, the apparent conflict may disappear or become an exception requiring clearer wording. Preserve that clarification and the source supporting it. Do not continue calling the pair contradictory after its scope is resolved.

Check implied dependencies and terminology

Some requirements depend on conditions described elsewhere. A success message may require a completed server response, while a separate timing rule may demand immediate confirmation before that response exists. Compare the documented meaning of confirmation and the actual timing scope before drawing a conclusion.

Distinguish a desired user experience from a verified technical constraint. The model should not invent system limitations to declare a requirement impossible. If feasibility evidence is absent, mark a feasibility question for the responsible specialist.

Use the brief gap analysis guide for broader missing information. The conflict log has a narrower purpose: showing how specific requirements interact under an overlapping condition.

Resolve and propagate approved changes

The owner should decide the intended behavior, exceptions, and effective specification version. Record the approved replacement text and the reason for the change. Keep deferred conflicts visible with the information needed for resolution.

Identify related requirements, acceptance criteria, examples, and supporting documents that may need the same update. Changing one sentence can leave another contradictory example in place. The log should connect the decision to those affected references.

Recheck the revised requirement set after a material resolution. Confirm that the replacement removes the original conflict without introducing another one. Preserve the prior log and specification version so implementation teams can understand which behavior was approved and when.

Frequently asked questions