it's maybe not exactly analogous but at my old company we had a notion of "users" and "personas," where a user could have many personas and the persona became the thing that the check was authorized against. it was mostly to support sales and CS users who would have different personas for different demos/tasks that should have access to different things. we started out with personas being a special case of users, but we eventually split them out into a separate definition. I don't remember the reasoning at this point though. our experience of personas was mostly that the bookkeeping gets to be a pain, but that was a concern that mostly lay outside of SpiceDB. I suppose you'd have a similar issue with service users, in the sense that you'd have to know whether a given piece of code should be issuing a check for a service user vs a normal user. If the codepaths for service and normal users are well-segregated, that sounds like it wouldn't be too much of a problem, but if they're related or overlapping then it makes the calling code more complicated.