Quick answer: ask AI for evidence-linked criteria, not approval

Give the assistant a user outcome, approved business rules, allowed starting states and explicit unknowns. Ask for a candidate criterion with a concrete trigger, an observable result, a counterexample and a source-rule ID. Product, engineering and QA then resolve disagreements before connecting the approved criterion to a test and recording its actual result.

Separate three statuses: drafted, approved for implementation, and verified against the implemented system. Neither a well-written Given–When–Then sentence nor an AI-generated test script advances a requirement through all three. The twenty examples below cover related stories within one feature; they are not twenty mandatory conditions to paste into every user story.

Start with the editable refinement worksheet. The complete fictional source and evidence packet supplies the policies, data and twelve illustrative test records used later, so you can challenge the conclusions rather than trust a summary.

Distinguish a story, a criterion, a test and the Definition of Done

A story describes a useful outcome for someone. A criterion defines a condition the solution must satisfy. A test specifies how to observe that condition using particular data and a particular environment. A test result records what happened. Keeping these artifacts separate makes it possible to change the implementation without silently changing the business promise.

Artifact Invitation example What it cannot establish by itself
User story An owner invites a teammate into a workspace Which roles, limits or expiration rules apply
Acceptance criterion A pending invitation reserves one available seat without creating an active member That the implemented reservation works
Test case Start with nine occupied seats, invite a new recipient, inspect authorized invitation and membership views The result before execution
Test evidence Build, environment, inputs, timestamp, observed output and linked criterion Coverage of untested branches
Shared Definition of Done Agreed product quality requirements applicable to the increment Every feature-specific business decision

This distinction is older than generative AI. Agile Alliance dates Ron Jeffries' Card, Conversation, Confirmation model to 2001. Its relevance here is practical: generating a card does not replace the conversation or its confirmation. Agile Alliance: Three Cs.

In Scrum, the Definition of Done describes the increment's required quality state. A passing invitation example does not waive those shared requirements. Equally, completing a technical checklist cannot resolve an undefined invitation policy. Scrum Guide: Definition of Done.

Use Given–When–Then when a state transition needs explanation. Cucumber separates starting context, event and observable outcome; executable scenarios also need step definitions. The snippets in this article are specification examples, not an installed Cucumber test suite. Cucumber Gherkin reference.

Assemble the invitation rules before writing examples

Our fictional workspace W7 has a capacity of ten seats. Eight active members and one unexpired pending invitation occupy nine. An owner wants to invite mina@example.test as a Member. The address is a synthetic test fixture; no message should be sent to it. A pending invitation is not an active membership.

The case uses four linked stories: INV-01 creates an invitation, INV-02 reports delivery state, INV-03 handles expiration and revocation, and INV-04 makes the flow usable across supported interaction modes and languages. This split prevents a large feature checklist from masquerading as one small, estimable story.

Rule Fictional decision Owner to identify in a real project
P1 Authorization Current workspace owner only; recheck permission and tenant at mutation Product and security owners
P2 Input Email required; use approved format fixtures; Member or Viewer role; note optional Product and design
P3 Capacity Active members plus unexpired pending reservations must not exceed ten; no duplicate pending recipient Product and engineering
P4 Creation and replay Creation yields Pending, not membership; scoped unchanged request may replay inside 24 hours Engineering and product
P5 Lifecycle Invitation expires after 48 hours, with a strict before-expiry validity check; revoke releases its reservation once Product and engineering
P6 Delivery Invitation persistence and notification delivery are different states; three attempts, then manual handling Operations and engineering
P7 Experience Approved EN, simplified Chinese and Japanese copy; keyboard/error behavior and time display are reviewed Design, QA and localization

These are author-created decisions, not security standards, email specifications or recommended service-level agreements. In a real packet, add each policy's version, approver and effective date. Conflicting notes should remain visibly conflicting until the responsible people decide which rule applies.

For example, “invite anyone” in a sales note does not override P1. Nor does a capacity value of ten define a commercial OpenMax plan. If the actual owner has not chosen whether pending invitations reserve seats, ask that question before generating a capacity criterion. A plausible assumption is still an assumption.

Twenty acceptance criteria with observable counterexamples

Read these as a feature-level coverage menu. Each example gives a behavior and a reason a superficial check could miss a defect. Where a criterion contains related effects, record separate assertions rather than awarding a vague partial pass.

1. Successful creation leaves the recipient pending

Given W7 has nine occupied seats and a currently authorized owner, when that owner submits the valid new recipient as Member, then the authorized invitation view shows I77 as Pending and occupied seats become ten. The membership view still shows eight active members. P1–P4; INV-01. A success toast alone is insufficient: it could hide a missing invitation or premature membership. Capture both user-observable views using authorized test access.

2. A missing required email preserves the other inputs

Given the email is empty but Member and a note are selected, when the owner submits, then an email-required error appears and no invitation is created. The role and note remain available for correction. P2; INV-01. Include the empty-string and spaces-only fixtures approved for this form. Do not infer that an AI placeholder such as “recipient email here” is valid input.

3. An optional note stays optional

Given all required fields are valid and the note is unset, when an invitation is created, then it remains without a note. P2; INV-01. There is no generated greeting, inferred relationship or invented justification. Compare the invitation detail against an explicit unset value. If a later policy makes a note mandatory for a special role, that is a new conditional rule, not a silent edit to this example.

4. Invalid format does not become a delivery test

Given the approved invalid fixture mina.example.test, when submitted, then the form reports the format problem and no invitation or notification job is created. P2; INV-01. The valid fixture mina@example.test demonstrates only acceptance by this product's input rule. It does not prove mailbox existence, ownership or deliverability. Use the team's actual email-validation specification; do not ask AI to invent an all-purpose regular expression.

5. Invitation roles do not grant owner privileges

Given the creation flow allows Member and Viewer, when a request attempts to assign Owner, then it is rejected without a new invitation. P2; INV-01. Test an altered request as well as the visible options. Restricting a dropdown is a user-interface choice, not evidence that a server enforces the allowed role set. Owner transfer belongs to a separately authorized story.

6. The last seat has an inclusive boundary

Given nine occupied seats, one new invitation may bring the total to ten. Given ten, another new recipient must be refused with a capacity explanation and no extra reservation. P3; INV-01. Both examples matter: checking only the full workspace can miss a system that incorrectly refuses the final available seat. Record active members and pending reservations separately so the denominator remains explainable.

7. A new request key does not bypass recipient uniqueness

Given I77 is still pending for the same recipient in W7, when the owner repeats the invitation with a different logical request key, then the system exposes the existing invitation rather than reserving another seat. P3–P4; INV-01. Define recipient identity and normalization with the actual identity owner. The synthetic fixture uses an identical address; it does not establish how aliases or case variants should be treated globally.

8. An existing member is not invited again

Given the recipient is already an active member of W7, when the owner requests an invitation, then the authorized view explains that membership already exists and neither invitation count nor occupied seats increases. P3; INV-01. This differs from a pending invitation and needs its own fixture. Do not return another tenant's membership details while trying to be helpful.

9. A viewer cannot create an invitation through a direct request

Given the actor is a Viewer in W7, when the actor sends the creation request directly, then access is denied and invitation state is unchanged. P1; INV-01. The fictional response is 403. A hidden Invite button is not the evidence being tested. Real authorization and information-disclosure behavior require the security team's review, including the agreed response exposed to the caller.

10. Permission is rechecked after the form opens

Given the actor opened the form as Owner but became Viewer before submission, when submission reaches the mutation boundary, then it is denied without a reservation. P1; INV-01. This catches a stale-permission assumption. The setup needs a controlled role change and an observable result; “the user was authorized earlier” is not an acceptable substitute for the policy's current-permission requirement.

11. Workspace scope cannot be changed by editing an identifier

Given the actor owns W7 but has no authority in W8, when a request targets W8, then it is rejected without revealing W8's members, invitations or capacity. P1; INV-01. Test the unauthorized target explicitly. The response details must follow the real security policy, which may deliberately avoid distinguishing a nonexistent workspace from a forbidden one.

12. Replaying an unchanged request returns the original result

Given I77 was created with K77, when the same currently authorized actor repeats the same payload in W7 within the 24-hour replay window, then the result still identifies I77 and adds no reservation. P4; INV-01. Scope includes workspace, actor, key and payload. Record fast double-click and lost-response scenarios separately. A retry is not a new business invitation just because the browser sent another request.

13. The same key with a different payload is a conflict

Given K77 created a Member invitation, when a request reuses K77 but changes the role to Viewer, then it conflicts and leaves I77 unchanged. P4; INV-01. Our fictional response is 409. Returning “success” for the changed payload would conceal that the requested change never happened. Editing an existing invitation, if allowed, needs its own contract and permissions.

14. Concurrent requests cannot both consume the last seat

Given a fresh W7 fixture has nine occupied seats, when two distinct new-recipient requests compete for the last seat, then exactly one invitation is created and the other receives the capacity outcome; the total is ten, not eleven. P3; INV-01. Two sequential manual clicks cannot establish this concurrency behavior. Engineering must supply a controlled concurrent test and record both responses and the final authorized capacity view.

15. A lost response is an unknown outcome, not a confirmed failure

Given the server created I77 but its response was lost, when the client reconciles using the unchanged K77 request inside the replay window, then it receives the existing invitation without another reservation. P4; INV-01. Until reconciliation, the interface must not confidently state that creation failed. After the 24-hour window, inspect existing pending state using the agreed recovery path instead of assuming indefinite replay protection.

16. Delivery failure does not undo a committed invitation

Given I77 is Pending and its notification encounters a temporary delivery failure, when the three fictional attempts are exhausted, then delivery is marked for manual handling while I77 and its single reservation remain identifiable. P6; INV-02. Do not label queued mail as delivered. A stable event identifier can support deduplication, but this example does not promise exactly one message will reach an external inbox under every failure mode.

17. Expiration has an exact instant

Given I77 was created at 2026-01-05T10:00:00Z, its expiration is 2026-01-07T10:00:00Z. An acceptance attempt immediately before that instant may proceed if all other conditions hold; at that instant it must not. P5; INV-03. Use a controlled clock. Expiration releases the reservation once, and the expired status remains explainable. Define success behavior in the separate acceptance story rather than assuming an invitation link grants membership automatically.

18. Repeated revocation does not release two seats

Given an authorized owner revokes a pending invitation, when revocation is repeated, then the invitation remains Revoked and its reservation is released only once. P1, P5; INV-03. Starting from ten occupied seats, the first release produces nine and the repeated action leaves nine. If acceptance and revocation race, add an explicit conflict rule; neither this sequential example nor AI prose resolves that separate decision.

19. A keyboard user can identify and correct the email error

Given a supported keyboard and screen-reader setup, when the email-required error occurs, then the user can identify the field and error, reach the correction control without a pointer and resubmit without losing other inputs. P7; INV-04. Record browser, assistive technology, focus behavior and announcement evidence. A keyboard tab-through alone is not a complete accessibility assessment or a WCAG conformance claim.

20. Localized expiration displays the same deadline

Given I77's UTC expiration, when displayed for Tokyo, Shanghai and UTC contexts, then the corresponding times are January 7 at 19:00, 18:00 and 10:00, with approved language and an unambiguous timezone. P7; INV-04. The stored deadline and invitation identifier do not change. Check real narrow-screen rendering and missing-translation fallback; translating a string without exercising its layout is not localization verification.

Refine AI drafts in five steps

  1. Freeze the smallest useful packet. Include the story, P1–P7 or their real equivalents, approved fixtures, exclusions and unresolved questions. Remove live invitation tokens and personal addresses. If the assistant cannot access a source, report that absence rather than claiming it reviewed the policy.
  2. Ask for candidates and objections together. Require a rule ID, starting state, trigger, result, prohibited side effect and a counterexample for each candidate. Ask which decisions are missing. A rule without an approved source remains a proposal, even when its wording sounds conventional.
  3. Review examples with product, engineering and QA. Use concrete disagreement: does a pending invitation reserve capacity, or not? Example Mapping separates rules, examples and unanswered questions; those questions should remain visible until resolved. Cucumber Example Mapping.
  4. Approve scope before attaching tests. Split creation, delivery and lifecycle work when they cannot fit a coherent story. Assign stable criterion IDs and a version. Record who decides business behavior and who judges technical feasibility. A generated test implementation still needs independent review of its assertions.
  5. Collect results without rewriting expectations to pass. Save the build, environment and evidence against the approved version. Failed, blocked and unrun checks remain distinguishable. When a policy changes, keep the previous result and re-evaluate affected tests; do not silently edit an expected value after seeing the outcome.

For upstream planning, the AI project risk register template helps track unresolved release risks. Use the sprint retrospective analysis guide after delivery to examine process problems; a retrospective is not a substitute for acceptance evidence.

Work through bad candidates and incomplete test evidence

The following are author-written examples of weak AI-style output, not transcripts from a tested model. Their value is that each mistake has a specific correction.

Weak candidate Why it fails Corrected decision
Successful invitation creates a member Conflates Pending with active membership P4: create Pending and reserve one seat
Check permission when opening the form Ignores a subsequent role change P1: check at mutation, including replay authorization
On timeout, use a new key and try again Treats an uncertain outcome as a new business action P4: reconcile the unchanged request first
The request key prevents duplicates forever Invents retention and ignores recipient state P4: 24-hour scope; after that reconcile pending state
The invitation email is delivered immediately once Confuses commit, queue, provider acceptance and inbox delivery P6: separate delivery state and manual escalation
Eight of ten passed, so everything is accepted Excludes unrun checks and ignores failures Report all planned states; resolve blocking defects

The downloadable packet contains twelve illustrative test records: T01–T04 pass, T05 fails permission enforcement, T06 passes, T07 concurrency is not run, T08–T10 pass, T11 keyboard/error handling fails, and T12 Japanese rendering is not run. That is eight passed, two failed and two unrun. Ten of twelve planned checks were executed; eight of those ten passed. Eight of twelve planned checks have passing evidence.

These are different denominators, not interchangeable “quality scores.” The twelve selected checks also do not cover all twenty criteria. The permission failure blocks acceptance of the affected behavior regardless of the attractive 80% pass rate among executed checks. An unrun concurrency check has no passing evidence. The appropriate decision is to fix, execute the missing checks and review the remaining coverage—not to declare the feature finished.

This is a fictional evidence-reading exercise. No invitation backend, email provider or OpenMax workflow was executed to produce those records. You can verify the arithmetic from the packet, but that verification proves only the interpretation of these twelve teaching rows.

Choose the simplest refinement method that fits the uncertainty

For a small story with available decision-makers, a short manual discussion and a shared document may be enough. It has little setup cost and makes disagreements visible, but decisions can be lost if nobody records them. Add a versioned worksheet before adding more automation.

A native backlog template improves repeatability: every story asks for source rules, examples and evidence. Its limitation is semantic. A required text box can contain an invented rule just as easily as an approved one. Automated syntax checks help catch missing IDs or malformed examples, not whether the policy is correct.

Executable tests become valuable once behavior is agreed and the system can be exercised. They provide repeatable observations but can faithfully implement the wrong expectation. Review the business rule and the assertion independently. Use AI-assisted drafting when context is long or recurring; its benefit is candidate organization, while its additional risk is plausible unsupported detail. Scale only after a narrow reviewed trial, with version control and clear write permissions.

Where OpenMax fits—and where it does not

OpenMax's official AI product manager material includes a PRD-generation prompt asking for user stories, acceptance criteria, out-of-scope behavior and unresolved questions. That supports a drafting use case, not proof of a ready-made invitation engine or a working connection to your test system. OpenMax AI product manager use cases.

The useful handoff is a sanitized requirements packet that the assistant turns into candidate criteria for review. Keep your approved backlog and test evidence as the systems of record. Before enabling any writes or integrations, verify the available connector, permitted scope, review mechanism and recovery behavior in your own environment. This article has not tested those capabilities.

Use this original prompt as a starting point:

Draft acceptance-criterion candidates for INV-01 using only the attached approved rules. For each, return rule ID, actor, starting state, trigger, observable result, prohibited side effect, counterexample and unresolved question. Keep Pending separate from membership and delivery. Do not invent policies, performance targets or test results. Label every unsupported decision as a question. Do not modify the backlog or send invitations.

If the central policy is still disputed, OpenMax cannot supply the missing business authority. Resolve that with the owner first. Then review OpenMax's product information and try one non-production story with the worksheet. Expand only when reviewers can explain which candidates they kept, changed or rejected and why.

Limits: these examples do not certify the whole feature

Security and privacy behavior needs qualified review using your actual architecture and obligations. The fictional tenant and role rules are not an authorization design or legal advice. Never paste production tokens, customer addresses or sensitive requirement attachments into an unapproved tool.

Performance, recovery and accessibility need their own evidence. “Fast” requires an operation, workload, environment, percentile method, sample window and error rule. Do not copy an arbitrary 800 ms target from a template. “Recoverable” requires an agreed recovery point, time and data-consistency check, not merely a previous deployment version. One accessible form path does not establish whole-site conformance.

If the feature itself uses an AI model, add a separate evaluation contract: dataset version, rubric, reviewer process, unacceptable outcomes and fallback. Criteria generated with AI and criteria for an AI system are different problems. A deterministic invitation test cannot prove model quality, and a good average model score cannot excuse a forbidden permission change.

Before closing the story, ask the smallest decisive question: which observation would make us reject this implementation? If nobody can answer, improve the rule or example before asking AI for more text. Start by correcting the permission and keyboard defects in the sample, not by making its pass-rate headline more flattering.

Frequently asked questions

Are AI-generated acceptance criteria ready to use?

They are candidates until the responsible team checks their source rules, scope and testability. Approval of the wording is separate from verification against an implemented system.

Does every user story need all twenty examples?

No. Select relevant risks and split unrelated behavior into separate stories. The twenty examples span creation, delivery, lifecycle and user experience within one invitation feature.

Is Given–When–Then enough to make a criterion testable?

No. The starting state, business rule, observable result and concrete boundary must be defined. Executable automation additionally requires implemented steps, a suitable environment and actual results.

Can an 80% test pass rate justify acceptance?

Not by itself. In the fictional packet, eight of ten executed checks pass, but two fail and two more were not run. A permission failure remains blocking, and the sample does not cover every criterion.

Can OpenMax automatically approve the story?

This guide verifies only an official requirements-drafting use case. It does not verify automated approval, backlog integration or test execution. Keep acceptance decisions with the people authorized by your team.

Sources and editorial method

OpenMax content team; revised September 4, 2026. This is OpenMax-owned educational product content, not an independent product review. The invitation rules, examples, prompt, worksheets and result records were created for this guide. They are not a customer case study, a benchmark or first-hand product test. Specialist approval of your real security, privacy and accessibility requirements remains necessary.