Composability Over Coupling: Evolving Authorization in Rails

Authorization feels simple in the early stages of a Rails application. You define a few roles. You write some policy methods. You add a handful of conditional checks. It works. In year one, that's usually enough. The tension appears later. Features expand. Roles multiply. Exceptions accumulate. A simple "admin vs user" distinction becomes a matrix of capabilities. What started as a few clean policy methods begins to encode assumptions about how permissions are stored and assigned. And that's where the real problem surfaces. Not complexity. Coupling. When your permission model changes, how much of your policy layer needs to change with it? If the answer is "a lot", then the system isn't just complex. It's entangled. In long-lived Rails applications, authorization strategies evolve. Direct permissions become group-based. Groups gain hierarchy. Multi-tenant boundaries appear. Auditing requirements emerge. The persistence model shifts to accommodate new realities. Your policies shouldn't n