AI generates acceptance criteria that cover the happy path and the most common failure modes reliably. It misses domain-specific edge cases that require business context the AI doesn't have — regulatory constraints, specific integrations, institutional quirks. This guide shows 10 AI-generated criteria across five feature types, with the specific PM edits that made each one testable by a QA engineer without clarification.
How AI generates acceptance criteria
Scriptonia generates acceptance criteria from user stories in the PRD. For each story, it applies a structured reasoning process: identify the success state, identify the common failure states, identify the validation path, and write each as a Given/When/Then statement. The generation is thorough on structure and coverage; it is weaker on domain-specific constraints that require knowledge outside the input.
10 real examples with PM edits
Feature type 1: Authentication — password reset
User story: As a user who forgot their password, I want to reset it from the login screen so that I can access my account without contacting support.
AI generated:
Given a user submits a valid email on the reset page, when they submit the form, then they receive a reset email within 60 seconds.
PM edit (added specificity):
Given a user submits a valid email on the reset page, when they submit the form, then they receive a reset email within 60 seconds and the email contains a single-use link that expires after 15 minutes.
Why the edit mattered: The AI omitted the expiry and single-use requirements — both security decisions that engineering needs to know before building.
Feature type 1: Authentication — second example
AI generated:
Given a user enters an email not in the system, when they submit the reset form, then they see an error message indicating the email was not found.
PM edit (changed the behavior):
Given a user enters an email not in the system, when they submit the reset form, then they see the same generic confirmation message as a valid email — "If this email is registered, you'll receive a reset link" — with no indication that the email was not found (prevents account enumeration).
Why the edit mattered: The AI's default behavior exposed a security vulnerability. The correct behavior (same message for valid and invalid emails) is a security best practice the AI didn't apply by default.
Feature type 2: E-commerce checkout
AI generated:
Given a user completes checkout, when payment is processed successfully, then they are shown an order confirmation page with their order details.
PM edit (added specifics):
Given a user completes checkout, when payment is processed successfully, then they are shown an order confirmation page containing: order number, list of items with quantities and prices, delivery estimate date, shipping address, and a button to track their order. A confirmation email is sent to their registered email within 60 seconds.
Why the edit mattered: The AI generated a testable criterion but at too low a resolution. QA needs to know exactly what "order details" means to write a test.
Feature type 3: Real-time collaboration
AI generated:
Given two users are editing the same document simultaneously, when one user makes a change, then the other user sees the change in real time.
No PM edit needed — this criterion is specific and testable as written.
AI generated (second criterion for same story):
Given a user's connection is lost during editing, when they reconnect, then their changes are preserved.
PM edit (added conflict resolution):
Given a user's connection is lost during editing and another user edits the same section, when the disconnected user reconnects, then a conflict resolution dialog appears showing both versions and the user can choose which to keep. No changes are silently overwritten.
Feature type 4: Notification system
AI generated:
Given a user has unread notifications, when they view the notification center, then all notifications are displayed with unread notifications visually distinguished from read ones.
No PM edit needed.
AI generated:
Given a user marks all notifications as read, when they refresh the page, then all notifications remain marked as read.
PM edit (added server-side persistence requirement):
Given a user marks all notifications as read, when they close and reopen the app, then all notifications remain marked as read. Read state is persisted server-side, not only in local storage.
Feature type 5: AI feature (PRD generation)
AI generated:
Given a user pastes a Slack thread, when they click Generate, then a PRD is produced.
PM edit (added all specifics):
Given a user pastes a Slack thread of 50–5,000 words, when they click Generate, then a PRD with all 10 required sections is produced in under 35 seconds. The generated PRD contains no placeholder text (e.g., "[insert metric here]") and at least 3 edge cases in the Edge Cases section.
The pattern: what AI gets right vs. what PMs must add
| What AI generates well | What PMs must add |
|---|---|
| Happy path criteria | Security implications (e.g., account enumeration) |
| Common error states | Specific timing requirements (60 seconds, 15 minutes) |
| Basic persistence testing | Server-side vs. client-side persistence distinction |
| UI state requirements | Conflict resolution and multi-user edge cases |
| Format requirements | Exact field names and content requirements |