Is there any recommendation on how to handle "cases that should always/never happen". I'm thinking things like: - you have

organization

and

group

that both have a

member

relation and the

group

has an

org

relation that references the

organization

it's in, and to be a member of a

group

you need to be a member of the parent

organization

. It is tempting to write things like

permission is_member = member & org->member

, but if I enforce the above rule at write time, then this runtime check becomes redundant and would theoretically add latency for no benefit - if we try to adapt the https://authzed.com/blog/user-defined-roles example in such a way that some of the "capabilities" are inherited from others (e.g. I might have both

update_comment

and

delete_comment

and if I have

delete_comment

I automatically get

update_comment

as well). Again it would be tempting to set it up as

permission can_update_comment = role->update_comment + role->delete_comment

(or even define a

permission

on the

role

itself that would compute the union of both the

update_comment

and

delete_comment

relations so that I can just refer to it everywhere without having to redefine the union), but if my system is set up in such a way that the inheritance is guaranteed at write time (for legacy reasons lets say), that extra check might be redundant Any suggestions on how to handle those types of scenarios? They might not be the best examples but hopefully they convey the general idea 😅