Is it a common pattern to do something like a fallback lookup for permissions? (there's probably a better name for that). For example, imagine that i have a

folder

type and a

file

type (which belongs to a

folder

). a

folder#owner

automatically gets

read

permission on the

file

instances within. Alternatively, files can be shared with users directly, without granting

folder

access (basically, I'm describing Google Drive). In my application, if I have few folders (~100) and many files (millions), I'm tempted to skip modeling every

file

and its relationship with the

folder

unless the

file

is directly shared. So, when I lookup if a user can read a file, I would both check if the user has a direct relationship to the

file

and check if the user has ownership of the

folder

(I can trivially determine the folder ID from the file ID). This way, I only need to write the direct

file

to

user

relationships to Zanzibar, not storing relationships between

folder

and

user

(far more common) As I write this out, this smells a bit like an anti-pattern in that I'm encoding my permissions heirarchy in the application client rather than solely in SpiceDB. However, the upside is that I'm encoding way less information into SpiceDB, adding performance and making adding SpiceDB to already existing applciation databases much easier. Are there times when this makes sense, or is this purely premature optimization/anti-pattern thinking?