Two departments independently redefine the shared entity Citizen differently in local models. What lightweight governance practice should prevent semantic forks?
Select an answer to reveal the explanation.
Short Explanation
When two teams redefine Citizen on their own, you get two cities that do not match on the map. A lightweight model review board for shared entities keeps the enterprise meaning from forking. Local experiments can continue, but the shared term gets a checkpoint.
Full Explanation
Enterprise-shared entities such as Citizen should not fork silently across departmental models. A lightweight governance practice is to route enterprise-shared entity changes through a model review board before adoption so Parks, Health, and Finance do not redefine the same person concept incompatibly. Banning all data modeling to avoid conflict stops design rather than governing it. Allowing every team to publish conflicting Citizen definitions without review institutionalizes semantic debt. Replacing modeling with spreadsheet column renaming only pushes ambiguity into brittle extracts. Exam items reward lightweight review for shared entities, not absolutist bans. Caveat: local extensions can exist when scoped and mapped to the enterprise entity; the failure mode is unmanaged redefinition of the shared core. Operationally, require a model-review ticket for changes to Citizen attributes used across agencies, record the decision, update the governed model and glossary together, and block promotion of conflicting local models into enterprise integration paths. Track review-board throughput so shared-entity governance stays lightweight—slow boards push teams to fork Citizen definitions underground again.