You're conflating a lot of things, and trying to convert the user story format into a new type of specification. It isn't one.
Instead, you should modify your process so that everyone shares a common knowledge base, and then break down user stories during Spring Planning into implementation tasks on the Sprint Backlog. You should also increase collaboration with stakeholders within the Sprint, and ensure that you hold framework ceremonies such as the Sprint Review to inspect the increment of work.
The power of agile practices is in leveraging an incremental inspect-and-adapt cycle, rather than in extensive upfront planning. Agility requires iterative processes, and your current way of defining work is not truly incremental or iterable.
Glossaries, User Stories, and Sprint Reviews
Define a Glossary
Even terms like "entities" are a ambiguous outside your particular business domain. On most agile projects, I've found it's extremely helpful to create a glossary as a project artifact, and then keep it updated with terms that we define within our organization or process. For example, you might have a couple of glossary items like:
A tag for a blog entry that can be used by administrators to organize content, or by users to find similar articles.
A blog entry whose Definition of Done includes having a:
This glossary must be kept updated, and is used as the canonical reference for terms in your user stories and tasks. You might even use markup (e.g. italics, quotes, underlining, or colors) to identify glossary terms in your backlog items, although I've rarely found this necessary in practice.
Use the Full User Story Format
When properly done, a user story contains:
- A value consumer.
- A value increment.
- A context to constrain or scope the increment.
Your current stories don't do those things, and so you lack sufficient information to understand the story's narrative or break it down into implementation tasks. For example:
As an article contributor,
I want to have a single-page interface for adding an article
so I can add a title, content, and one or more categories all at the same time.
This story provides a role with a point of view (the value consumer), what that person wants (leaving the implementation details to the development team), and some context that helps the development team understand the value proposition and acceptance criteria.
This type of story is much easier to break down into tasks for the Sprint Backlog. It also serves as a great focal point for conversations with the stakeholders throughout the Sprint as the team develops acceptance tests and fleshes out implementation details. A user story is a means of collaborating, not a way of tossing specifications over the wall!
Leverage Your Sprint Reviews
Scrum is all about inspect-and-adapt. Even in cases where you have low stakeholder engagement or can't actively collaborate throughout the Sprint, a short iteration ensures that if you build the wrong thing—or build the right one, and the stakeholders realize post-facto that it doesn't really serve their needs—then the process ensures that these issues are caught relatively quickly and can be iteratively changed or improved.
This means that even if you don't leverage user stories effectively, every week or two the stakeholders will see a potentially-shippable increment. They don't get to say "You did it wrong!", but they do get the chance to say "Well, I guess what we really wanted was..." and create new work which the Product Owner then prioritizes for a future Sprint.
Scrum (and agile processes in general) are about emergent design, incremental progress, and iterative improvement. So you don't have to deliver something perfect every iteration; you simply have to deliver something "good enough for now," or at least "good enough to solicit meaningful feedback." Either way, the Sprint Review is a useful process control when correctly implemented.