A utility creates a new entity class for every team rename on the org chart. What taxonomy approach should the IRM architect prefer?

IRM architects should prefer a stable class taxonomy such as Organization, Application, Facility, and Vendor rather than creating a new entity class for every team rename on the org chart. Classes should name the durable kind of governable object, not transient squad titles that churn with HR reorganizations across a city government. Continuing one-off classes per team name makes taxonomy maintenance a permanent tax on the municipal program and breaks historical reporting whenever names change. Eliminating classes and sorting only by creator user ID destroys rollup and navigation value. Naming each class after the current manager's email couples GRC structure to individuals and fails when people leave or rotate. Exam caveat: stable taxonomy does not forbid organizational entity types—org units can be types under an Organization class without encoding every rename as a new class. Operational check: publish an approved class list through the IRM design authority, map existing types into it, refuse rename-driven class proliferation in change control, and review class count quarterly for taxonomy drift. Record civic examples (facility, vendor, application) in the architecture standard so bureau teams reuse shared classes, and verify executive dashboards still slice correctly after the next reorg without class churn.