Composable Roles

The Principle

Build access from small, reusable, well-understood blocks. Roles are modular building blocks that can be combined, extended, and scoped. A person's effective access is the composition of their assigned roles. Each role is defined once and reused across many assignments.

The Problem With Monoliths

Most organizations end up in one of two failure modes. Either they create hundreds of nearly-identical roles (“Backend Engineer,” “Backend Engineer (Production),” “Backend Engineer (Payments),” “Backend Engineer (Payments, Contractor)”), and drown in maintenance. Or they create a handful of overly-broad roles: “Engineering,” “Admin”, and grant far more access than anyone needs because creating a precise role is too much work.

Composition Over Proliferation

Composable roles solve both problems. A base role defines common access. Team-scoped roles add system-specific permissions. Seniority modifiers adjust the scope. Temporary overlays add time-bound escalations. The result is precise access built from a small number of well-understood components.

The engineer who joins the payments team gets the engineering base role, the payments team scope, and their seniority modifier. If they go on call, a temporary overlay adds the permissions they need for incident response. If they move to a different team, the team scope changes and nothing else does. Each building block is tested, reviewed, and understood in isolation.

The Exception Tail

Not every access need fits neatly into a composable role. The executive assistant who needs ad-hoc access to a board portal. The security researcher who needs a one-off sandbox. The legal hold that requires preserving, not revoking, a departed employee's data. These cases exist and will continue to exist. The framework must accommodate them rather than deny them.

The practical approach: exceptions are declared in the same configuration, tagged distinctly, and subject to the same reconciliation and audit. They expire automatically unless explicitly renewed. An exception that persists long enough becomes a role: this is a signal, not a problem. The model does not need to pretend exceptions don't exist; it needs to ensure they are visible, time-bounded, and reviewed.

Antipatterns

• Hundreds of nearly-identical roles that differ by one or two permissions.
• A handful of overly-broad roles that grant far more access than anyone needs.
• Creating a new role for every new hire or team variation.
• Long-lived exceptions that never expire and never get reviewed.