One authorisation model, a dozen industries

The previous post introduced a small extension to the delegated-access model from earlier this year: person sits above the login, persona is the login itself, and business applies the same separation to companies. It's easy to claim a model like that is generic across industries. It's considerably more convincing to actually run it, unmodified, across a dozen different scenarios and watch the tests pass every time.

That's what the full repository does. The same fga/model.fga file - no per-vertical schema, no vertical-specific relation names - backs media, healthcare, financial services, telco, retail, and legal case management, plus a handful of scenarios I'll cover in later posts. In this post I will walk through what each of the first six verticals actually demonstrates, because the interesting part isn't that the model is reused - it's which primitive gets reused for what, and where a naive version of this model would have gotten it wrong.

Media: the same primitive for an hour and for months

Alex owns his family's streaming subscription. His teenager Jordan has his own login and can watch what's included, but can't manage the subscription - a standing, permanent viewer role. When Jordan wants to watch a pay-per-view event that isn't included in the plan, Alex approves it for one night only.

That one-night approval and Chris's months-long carer access in the healthcare vertical (below) use the exact same primitive: a delegate tuple with a not_expired condition, differing only in the valid_until timestamp. There's no separate "temporary purchase approval" relation - a one-off event is just its own account, and approving access to it for a night is the identical mechanism as approving access to a patient record for a recovery period. That's a useful thing to notice before building a bespoke feature for every kind of "temporary" your product needs.

Healthcare and financial services: not every shared account is a delegation

Jane is a patient. Chris is her carer during a period of recovery, with his own separate login - never Jane's credentials - and a time-bounded delegate tuple that only ever resolves into can_view, never can_manage. Whether Chris may also reschedule an appointment is a scope the application checks against its own delegation record; FGA's job here is narrower and more mechanical: does an active, time-bounded relationship exist, full stop.

Financial services is where the temptation to call everything a delegation gets strongest, and where resisting it matters most:

• Priya manages her son Noah's junior savings account. Noah can see his own balance but not manage the account - a permanent, limited role. Nobody is acting on his behalf; this relationship isn't temporary at all.
• Ravi and Sunita hold a joint account. Both are full owners - again a permanent role, because neither is subordinate to the other.
• Daniel holds power of attorney for his elderly mother Eleanor's account, under periodic review. This is the one that's actually a delegation - explicit, revocable, and bounded with not_expired.

Flattening all three into "shared access" would have either handed Noah more authority than intended or made Ravi and Sunita's joint account look like one of them is a temporary guest on the other's money. The distinction isn't academic - it's the difference between a role that ends when someone removes a tuple and a role that ends on its own regardless of whether anyone remembers.

Telco and retail: the same business, a different roster

Owen's family mobile plan and Brightco's corporate mobile fleet run on the same telco, and structurally they're the same shape: an owner for billing, an admin for day-to-day management, viewers for everyone else, and (in Owen's case) a friend with a time-bounded, view-only delegate while Owen travels. The only thing that changes between a family and a company is that Brightco's roles cascade from a business object's staff roster rather than being granted one login at a time - onboard or offboard an employee by changing the roster, not the account.

Retail runs the identical shape again for a household subscription versus a corporate benefits account, which is really the point: this isn't six different models wearing six different vertical costumes, it's one small set of primitives - owner, admin, viewer, delegate - composed slightly differently depending on who the parties actually are.

Case management: a named mandate versus a firm mandate

Harriet helps her elderly relative Grace by managing one specific complaint on her behalf. Grace has a second, unrelated case, and Harriet's delegation on the first case is invisible to a check against the second - there's no relation to traverse from Grace's person object at all, because person is never part of an access decision.

The sharper case is Priya, a legal practitioner. She represents a client under a permanent admin role (a legal engagement ends on explicit instruction, not by silent expiry, which is why it's a role and not a delegation), and separately has her own personal complaint as an ordinary customer, under a completely different login. Neither her professional mandate nor her personal login has any bearing on the other - the only place they connect is the individual relation back to the one verified person behind both, which no access check ever traverses.

Then there's the distinction between a mandate given to Priya by name and one given to her whole firm:

Client X engaged Priya personally. Client Y engaged her firm, Sterling Legal, instead - a grant to business:sterling-legal#staff rather than to Priya's login specifically. Either Priya or her colleague Leo, whoever is currently on staff, can act on Client Y's case; Leo has nothing at all on Client X's case, because that mandate was written directly against Priya's login. The client chooses the shape that fits: a named relationship with one solicitor, or cover from whoever the firm currently rosters.

Next Steps

Six verticals in, the model hasn't changed once - only the tuples. A follow-up post moves into government services, where the same primitives end up backing a company registry and a citizen-facing permit system, and where identity verification itself needs to become part of the model for the first time.