Join for free

Audit product requirements for ambiguity and missing decisions

Author: AILesson9 min setupTested with:ChatGPTReviewed: 2026-08-28

Quick answer

Find language that permits incompatible implementations and expose the owner and evidence needed to decide. Provide: Requirement document, Product and system context, Review scope and governance. Expected result: A requirement audit with ambiguity locators, decision gaps, conflicts, risk, clarification questions, and readiness status.

1

Add your context

Your text stays in this browser. AILesson Prompts does not send it to a model or server.

2

Your prompt

Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt

Audit the exact product requirements for ambiguity, conflict, and missing decisions.

PRD, stories, criteria, diagrams, terms, links, versions, comments, and decision log:
[requirements]

Users, workflows, current behavior, platforms, states, roles, data, integrations, constraints, risks, and policies:
[context]

Release, teams, owners, reviews, severity, readiness, environments, and rewrite scope:
[review]

Preserve exact excerpts and locators. Flag subjective adjectives and adverbs, undefined nouns and actors, vague quantifiers, hidden defaults, passive voice hiding responsibility, pronouns with multiple referents, terms used inconsistently, solution statements without need, examples mistaken for exhaustive rules, and words such as easy, fast, intuitive, seamless, flexible, secure, support, real time, normally, appropriate, and etc. For each issue list at least two materially different implementations the wording permits, user or system consequence, severity, affected requirement, decision owner if supplied, evidence needed, and one neutral clarification question. Also audit scope boundaries, preconditions, triggers, states and transitions, permissions, data source and lifecycle, empty/error/loading/offline/retry behavior, concurrency and idempotency, localization, accessibility, privacy, security, analytics, performance, compatibility, migration, rollback, dependencies, and acceptance criteria. Identify contradictions across artifacts and decisions absent from the log. Do not invent answers or rewrite unresolved choices as facts. End with blocked versus non-blocking gaps, a decision queue ordered by dependency and risk, and implementation/test readiness status.
Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.

From input to outcome

A worked example

See how concrete context turns this recipe into a usable result

Actual input

Requirement document
PRD v0.7 section 2: 'Make acceptance ownership easy to see for all users. Requesters should be able to quickly assign the right person. The system should notify them appropriately and update in real time. Support unassigned cases and etc.' Story AC-4: 'Given a Ready handoff, when the owner selects an accepter, then the change is saved.' Diagram D2 shows requester selecting accepter; comment C18 says coordinator may edit. Decision log: web prototype only; no notifications this release; active workspace members only; exact copy pending. Another story says status becomes Assigned when accepter exists, but current state model contains Draft, Active, Ready, Accepted only.
Product and system context
Roles: requester creates; owner does work; accepter authorizes acceptance; coordinator administers workspace. Approved: requester or coordinator may set optional accepter; owner may view only. Audit log records actor, old/new value, time. Existing member IDs; no retention change. Web only. Accessibility requires keyboard, programmatic label, non-color status. Privacy review complete. Analytics names and performance target unresolved.
Review scope and governance
Prototype usability-test release. Product owns workflow decisions, Design owns copy, Engineering owns state and error behavior, Accessibility reviews interaction, Research owns test script. Blocker severity: B prevents implementation/test; M permits build but risks inconsistent behavior; L editorial. Ready requires no B gaps, testable criteria, reviewed design, working prototype, unit and accessibility checks. Diagnose only; do not rewrite final requirements.

Example output

Readiness: not ready; six blocking decisions and several medium gaps remain.

B1 — actor conflict. AC-4 says “owner selects,” D2 says requester, C18 says coordinator, while approved context allows requester or coordinator and makes owner view-only. These permit incompatible authorization and security tests. Product owner must confirm the approved rule in every artifact; evidence is the decision log/context.

B2 — state conflict. One story creates Assigned, but the approved state model has no Assigned state. Implementations could add a new workflow transition or keep Ready with a field indicator, affecting persistence, analytics, migration, and tests. Product owns: does accepter assignment change workflow state or only field presentation?

B3 — notification contradiction. “Notify appropriately” permits email, push, in-app, or no notification; the decision log says no notification this release. It also leaves recipient, trigger, repeat behavior, and opt-out undefined. Product must remove or explicitly exclude notification for this boundary; no one should invent behavior.

B4 — eligibility and invalid data. “Right person” could mean any user, active member, role-qualified member, or suggested person. Approved boundary is active workspace member, but AC does not cover inactive/non-member submission or concurrent deactivation. Product/Engineering must define observable rejection and recovery; Design owns later copy.

B5 — unassigned behavior. “Support unassigned cases and etc.” does not define whether empty is allowed on create, clear is allowed later, who may clear, how it appears, or whether Ready can continue. Product owns these decisions; “etc.” is not testable.

B6 — save/error/concurrency. “Saved” could mean optimistic local display or confirmed server persistence. Missing: loading, failure, retry, repeated submission, two editors, stale view, audit behavior, and rollback. Engineering proposes options; Product approves user-visible rule.

Medium gaps: “easy,” “quickly,” and “real time” lack measures; exact copy and analytics names are explicitly pending; keyboard order, programmatic label, focus after error, and non-color indicator need criteria. “All users” conflicts with role-specific edit permissions and should distinguish view from edit.

Decision order: actor/state/notification → unassigned and eligibility → save/concurrency/error → accessible interaction/copy → analytics/performance. Test readiness follows only after B items become observable criteria.

Why this works

  1. 1

    Competing implementation examples make abstract ambiguity concrete for decision owners.

  2. 2

    Dependency-ordered gaps prevent teams from polishing criteria around an undecided core behavior.

Check the result

  • Does every ambiguity include exact text and two materially different interpretations?

  • Are missing decisions assigned only to known owners and never silently resolved?

  • Does readiness cover states, permissions, data, failures, accessibility, privacy, testing, and rollback?

Use it with confidence

Frequently asked questions

Practical answers about when to use this recipe, what to provide, and where human review still matters

What should I prepare before using “Audit product requirements for ambiguity and missing decisions”?

For “Audit product requirements for ambiguity and missing decisions,” prepare Requirement document, Product and system context, and Review scope and governance. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.

When is the “Audit product requirements for ambiguity and missing decisions” result not ready to use?

The result is not ready if it does not yet deliver the stated outcome—A requirement audit with ambiguity locators, decision gaps, conflicts, risk, clarification questions, and readiness status—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.

Which AI tools have recorded tests for “Audit product requirements for ambiguity and missing decisions”?

The published test record for “Audit product requirements for ambiguity and missing decisions” lists ChatGPT as of 2026-08-28. This confirms recorded runs, not guaranteed compatibility or identical results in later product versions. For another tool or version, keep every constraint visible and repeat the result checks before use.

More ways to explore

Where this recipe fits

Text promptsFeedback & reviewProduct & user researchProduct managementFor managersFrom evidence to decision

Keep the work moving