Treat additive roles as a schema capability, not a row edit

When an authorization table stores one scalar role per scoped membership, “add role B while keeping role A” is a schema requirement, not an operational row edit. Inspect uniqueness constraints and downstream membership selectors before writing. An update replaces the old role; inserting a second row may violate uniqueness or, if forced through a different actor or organization scope, corrupt authority semantics and make effective access ordering-dependent. Fail closed and use a dedicated additive grant or normalized user-role relation with explicit compatibility and rollback work. This does not apply when roles already have tested set-union semantics.

Applies when: An operator requests an additive RBAC grant in a membership model designed for one role per scope. Keywords: RBAC additive role membership scalar unique constraint authorization access