The specific conditions that, once met, mean a feature is finished and accepted; written before building, not after.
Acceptance criteria are a short list answering the question: how do we know this feature is done? They are written as statements that can be checked with a yes or a no, such as 'a customer can cancel a booking up to two hours before the appointment' or 'an error appears if the phone number has fewer than ten digits'. They do not describe how to build it; they describe what the user must see.
Most disputes between a business owner and whoever builds for them come from 'done' meaning something different to each side. Written criteria settle that before work starts, and they become the basis for test cases directly. In Fanann, the Product Owner Noura asks the questions that settle scope, then writes the requirements document and the task list. Practical tip: write three to five criteria per feature, and make at least one of them about an error case. If you cannot phrase a criterion as a yes-or-no sentence, the feature itself is not clear yet.