NovA unit needs a stable identity even when its display name changes
Display labels, translations and sales names can change, but a property should keep the same underlying identity so saved state and history do not split or merge incorrectly.
This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.
Renaming a unit should be a content change, not an existential event. A sales sheet may call it “A1203,” a later public page may present “Tower A · 12-03,” and the English edition may use a different formatting convention again. None of those changes necessarily means the apartment itself has changed.
A property platform becomes fragile when it cannot tell the difference between a label and an identity. If the display string is treated as the thing itself, a harmless rename can create a new record, disconnect saved state, duplicate analytics or detach previous enquiries from the unit the buyer was actually considering.
A display name answers a different question from an identity
The display name exists to help a person recognise the unit. It can be edited for clarity, language, typography or a revised naming convention. The underlying identity exists so the system can maintain continuity.
Those responsibilities should not be forced into one field. A technical identifier does not need to be elegant or even visible. Its job is to remain stable while the public representation changes around it.
This distinction becomes especially important on a bilingual site. Russian and English labels may legitimately differ. If a platform uses the label as the key, two languages can accidentally create two technical objects. The same risk appears when an editor fixes transliteration or when a developer changes the public format of unit numbers.
A stable identity gives the interface room to improve without threatening the data relationships behind it.
The saved-property trail should survive a rename
Consider a hypothetical buyer who saves a unit when it is labelled “B-807.” They add a note about the bedroom orientation and later send a question about the payment schedule. The project team then adopts a clearer public naming convention and the unit becomes “Tower B · 08-07.”
The buyer should still see the same saved property. Their note should remain attached. The earlier enquiry should still make sense. Any documents or images that belong to that unit should continue to belong to it.
If the platform creates a new entity because the label changed, the buyer loses continuity even though nothing material happened to the apartment. Worse, both versions may remain visible and look like two available units.
The reverse error is equally serious. Two different units can have similar labels, particularly across phases or buildings. A stable identity rule must not merge them merely because the text looks alike. Continuity is useful only when it follows the actual entity.
Facts can change without creating a new unit
Price, availability, furnishing, floor-plan notes and image sets may all change over time. Those are changing attributes of the same unit unless the underlying offer genuinely becomes a different entity.
This matters because the platform needs to express change. If every new price creates a new technical record, there is no coherent way to say “the same apartment now has a different price.” The system only sees unrelated snapshots.
A stable identity makes version-aware behaviour possible. A buyer can return to a saved unit and learn that one condition has changed. The product can preserve the earlier context while showing the current state.
That does not mean history should be silently overwritten. Stable identity and transparent change work together. The first tells us what remained the same; the second tells us what changed.
Identity should survive translations and editorial improvements
A bilingual property product has a practical reason to keep labels flexible. Word order, punctuation, transliteration and explanatory text can differ between languages. An internal shorthand that made sense to the team may later be replaced by a clearer public description.
I want editors to be able to make those improvements without fearing that a saved shortlist will break. That requires the public label to be an attribute of the unit, not the foundation of its existence.
Internal migrations create a similar challenge. A legacy code may be replaced, or records may move between systems. The migration still needs a controlled mapping to the same real-world unit. String similarity is not enough. The team needs a deliberate reason to say these records are the same entity.
There is also a boundary with later topics such as page addresses. A unit’s identity should not depend on the URL either, but the deeper point here is about the property record itself. The unit must remain recognisable to the system before any particular page representation is considered.
Buyers notice continuity, not identifiers
No buyer needs to admire the internal key. The benefit appears indirectly. A saved unit does not disappear after a naming correction. A comparison does not suddenly show duplicates. A previous question stays attached to the right property. Russian and English pages continue to describe one entity. A changed price looks like a changed fact, not a mysterious replacement apartment.
That is the outcome I care about. Stable identity is not database tidiness for its own sake. It protects the buyer’s trail through a changing product.
The discipline works in both directions: preserve continuity when the real unit is the same, and preserve separation when the units are genuinely different. A platform that can do both is much less likely to turn an editorial rename into a commercial misunderstanding.