A quick and dirty definition of User Story:
"As a <role>, I want <goal/desire> so that <benefit>"
In this commonly accepted definition there is little space for defining business rules, constraints or user input.
Trivial example just to illustrate:
"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"
In this silly example, where would one define the fields needed when registering a book? Should it be written anywhere? Or should the required business rules be passed as word of mouth by the Product Owner?
Best Answer
The fields are part of the conversation that should be had. They may be written down if that is useful but that is a judgment call. Keeping the documentation up to date may be challenging whereas the working software could be seen as documentation to some extent.
User Story - A Promise to have a conversation would be a blog entry about this.
Your trivial example has a couple of points that I don't know how well you'd notice this. What does it mean to "register new books?" What is "Find their availability online?" Those are where the conversation begins and once the story is done there may be new stories as perhaps those registrations have to be kept on file or reports have to be generated periodically.