A familiar noun can hide incompatible entity definitions
The company and the login may have different identifiers, lifecycles, and permissions. A business customer can remain active while one employee leaves, and several individuals may act for the same organization. Treating them as one entity makes migration errors likely and can blur access boundaries. The glossary should therefore describe each meaning within its document scope and record the relationship between them. It should not simply replace both words with a new preferred term. In a worked review, use one company with two users and a user associated with two companies. These cases test whether requirements concern organizational records, personal accounts, or their membership links. A later terminology decision should update affected interpretations through review; it should not silently merge existing records because the display labels have become similar.
Working through the example
Sales notes use customer for a company, while a portal specification uses customer for an individual login. A generated migration task treats both as one record type. Add scoped definitions and link each candidate to the meaning used by its source. Ask how company accounts and individual users relate instead of merging them.
A discriminating check
Test two requirements that use the same noun but expect different identifiers and permissions. A shared glossary reduces ambiguity only while its scope and revision remain visible to reviewers. The ambiguity research cited here motivates explicit terminology review. The project’s scoped glossary and unresolved qualifiers are design adaptations, not a claim to reproduce the studied tool.