A location-discovery platform needs to represent two fundamentally different things: the people using the system and the real-world places or events they interact with.
These entities may be closely connected, but they should not share the same identity model. A person can create a listing, request ownership of a business profile, contribute a photo, or check in at an event. None of those actions makes the person and the listing the same entity.
The LeeX ecosystem reference explicitly distinguishes the User ID from the Listing ID, placing user identity and listing identity in separate parts of the wider system.
Why User Identity and Listing Identity Must Be Separate
A User ID represents an account. A Listing ID identifies a particular real-world entity represented in LeeX, such as a business, event, or infrastructure feature.
Consider a business owner who creates an account and requests control of a restaurant listing. The account represents the person using LeeX. The listing represents the restaurant itself.
If the owner changes their account details, the restaurant's identity should not change automatically. Likewise, if the restaurant changes its display name or ownership, the owner's User ID should remain independent of the listing.
This separation supports clearer permissions, more reliable records, and better continuity over time.
What Belongs in a User Profile?
The LeeX reference describes Profile as the place for user identity, account controls, privacy, and user-owned activity.
A coherent profile experience could organize:
- Account information and settings.
- Privacy controls.
- Saved listings and Moments.
- Content created by the user.
- Relevant account and contribution actions.
These are conceptual responsibilities described by the ecosystem reference, not a claim that every item is already implemented in the current product.
The important architectural principle is that a profile should represent the user without becoming the authoritative record for every place or event that person interacts with.
What Happens When a User Manages a Listing?
A user may have a relationship with one or more listings. For example, a business owner may request to claim a business, while a community contributor may submit a correction or create a Moment associated with a public place.
These relationships should be represented explicitly.
A claim request is not automatically proof of ownership. Similarly, a user who creates a listing does not necessarily own or control the real-world entity represented by it.
The system therefore needs to distinguish account identity, listing identity, ownership or management relationships, and verification status. The exact permissions and review workflow should be defined by the product's approved rules rather than inferred from the presence of a profile or listing.
Why Stable IDs Matter
Display names and other descriptive fields can change. A business may rebrand, a listing may receive a corrected address, or the person managing it may change.
If the system relies only on names or copied text, these changes can cause broken references and inconsistent records.
The LeeX reference describes the Listing ID as a stable identifier assigned when a listing is created. It also states that User ID, Listing ID, Moment ID, Event ID, and Report ID represent different object types.
This distinction matters when connecting:
- User-created Moments to the relevant listing.
- Check-ins to the appropriate entity.
- Saved collections to current listing records.
- Reports to the exact listing or content being reviewed.
- Notifications to the underlying records that require attention.
A notification or feed card should point to the relevant record rather than become the system's source of truth.
Ownership Changes Should Not Erase Entity Identity
Imagine a restaurant listing that remains relevant after its manager changes. The platform should be able to update the authorized ownership relationship without treating the restaurant as an entirely new entity by default.
The LeeX reference describes an ownership-transfer journey in which authority and consent are checked, the owner relationship changes through an authorized process, and the Listing ID remains stable.
This model helps preserve continuity for existing references and records. It also makes it possible to review owner-specific verification separately when management changes.
The precise transfer process, eligibility rules, and audit requirements still need to be defined in the applicable implementation specifications.
Common Design Mistakes to Avoid
Several mistakes can undermine this separation:
Using a username as a permanent entity identifier. Usernames and display names may change; they should not replace stable internal IDs.
Treating listing creation as proof of ownership. Creating a record and having authority over the real-world entity are different things.
Conflating ownership with verification. A claim establishes a request or relationship that may require review; verification should communicate a defined level of evidence.
Deleting relationships when a record changes. Saved items, Moments, reports, and other references need deliberate handling when listings are updated, transferred, merged, or retired.
Giving every role the same permissions. Ordinary users, listing owners, and administrators have different responsibilities. High-impact actions should be permissioned and auditable.
These are not merely database concerns. They affect trust, privacy, moderation, and the consistency of the public experience.
About the Founder
Oscar Awowari is the Founder and CEO of LeeX. The platform's wider ecosystem concept connects user identity with a structured system of real-world listings, community contributions, discovery, and administrative oversight.
The practical strength of that model will depend on how clearly the distinction between people, places, and their relationships is reflected in the product's actual data model and workflows.
Conclusion
Separating User IDs from Listing IDs provides a foundation for a more consistent city-discovery ecosystem. People can contribute to, manage, or interact with real-world entities without becoming those entities themselves.
For LeeX, this distinction supports stable listing identity, clearer ownership relationships, accountable administration, and reliable connections among saved items, Moments, Check-ins, and reports.
The broader lesson for software architecture is straightforward: model people, entities, and relationships separately. Doing so makes it easier to manage change without losing the identity and history that give a system meaning.
Top comments (0)