ACCEPTANCE CRITERIA — ORIGINAL FICTIONAL EXAMPLES
Checked 2026-10-27. Proposed criteria and checks, not executed tests.
https://showmeyoursaas.com/articles/acceptance-criteria/
General references:
https://www.atlassian.com/work-management/project-management/acceptance-criteria
https://cucumber.io/docs/gherkin/reference/

INVITATION POLICY
Expiry is evaluated at the application's defined clock instant.
At or after expiresAt, the invitation cannot create membership.
Only an authorized administrator can replace an eligible expired invitation.
A replacement does not revive the old token.
A replay of an already accepted request creates no additional membership.

AC-I1
Given an invitation expires at 12:00:00 UTC
When acceptance occurs at 12:00:00 UTC
Then no membership is created and the agreed expiry explanation appears.
Also test immediately before and after the defined instant.

AC-I2
Given an authenticated non-administrator without replacement authority
When they directly request replacement for another workspace
Then the operation is denied, membership and invitation state remain unchanged,
and protected workspace information is not disclosed.

AC-I3
Given an authorized request has accepted an invitation
When the same request is replayed
Then no additional membership is created.
Decision still needed in a real API: exact replay response and idempotency contract.

SEAT POLICY
Ten active memberships are permitted; pending invitations do not count.
Define deactivation behavior in the real contract before implementation.

AC-S1
Given nine active memberships and one eligible activation
When an authorized activation commits
Then the active membership count is ten.

AC-S2
Given ten active memberships
When another activation is requested
Then it is rejected with the agreed capacity response and the count remains ten.

AC-S3
Given nine active memberships and two competing eligible activations
When the activation requests run concurrently
Then committed state never exceeds ten active memberships.
Verification must exercise the race and inspect persisted state, not only a disabled button.

BACKGROUND JOB POLICY
States: queued, processing, completed, failed.
Only the authorized workspace may retrieve output.
Retries must not duplicate a charge or completion notification.

AC-J1
Given a permitted report request
When the job is marked completed
Then the authorized requester can retrieve its intended result.

AC-J2
Given the worker retries the same job
When processing finishes
Then no second charge or duplicate completion notification is created.

AC-J3
Given a job has failed
When the requester views status
Then the agreed support reference appears without private input disclosure.

AC-J4
Given a user from another workspace
When they request the report output directly
Then access is denied without exposing the result.

BLANK DRAFTING FORM
Change / criterion ID:
Actor and authority:
Starting state:
Action:
Observable result:
Boundary / permission / retry / failure case:
Proposed verification method:
Environment and synthetic fixture:
Actual result and evidence (leave pending until checked):
Open policy question:
Review owner / date:

REVIEW QUESTIONS
Could two reviewers interpret the same phrase differently?
Is the clock, count, permission, or state boundary explicit?
Could the proposed check disprove the criterion?
Does a screenshot prove only interface state while the criterion concerns server behavior?
Which usability claims require observation with relevant participants?
What belongs in the team-wide Definition of Done instead?