Upgradeable

The code behind the address can be replaced. Every other guarantee in these pages holds only as long as the upgrade authority allows it, which is exactly why the flag exists — it would be easy, and dishonest, to leave out.

The framework's own constraint

An upgrade must not change the extension set. Registration happens in the initialiser, which cannot run again, so a new implementation that quietly inherited another module would run that module's transfer phases while the discovery surface kept reporting the old set. That is undeclared behaviour, the one failure this framework exists to prevent. Removing a module is wrong the same way, from the other side.

Nothing on chain can enforce it. The proxy cannot inspect the module set of an implementation it has not yet delegated into, so there is no check to write. It is a governance obligation, and this flag is the warning that the obligation exists.

What to check

Who holds it

UPGRADER_ROLE is deliberately separate from the admin role, so a deployment can put upgrades behind different keys from configuration. Find out which keys.

Whether it is a timelock

A cached behaviour word is only as durable as this answer. A timelock turns an instant change into a change you can see coming.

Whether the set moved

The extension set is readable at any time. Compare it against what you cached; if it changed, the obligation was broken and every assumption downstream needs rechecking.

Storage is namespaced per module, derived from a string rather than assigned by declaration order, so a later implementation can add fields or add modules in any position without moving anything already written. That is what makes an upgrade survivable at all.