@User Well from my understanding of your business domain, it seems like permissions granted to users via a project affect non-project specific resources - the zone. A zone is not "owned" by a project. Therefore with such model you need to disambiguate how permissions inherited from the various projects impact the authorization decision for a specific zone. The question here is "how is that decision made" in the application. It feels like the decision in your business domain is session specific. I imagine the user navigating via the website with an "active project", and this is the missing context you need to make an authorization decision. So if this information is purely session specific, there is no way around that other than using SpiceDB caveats, which is precisely implemented to support authorization decisions based on session specific information. An if it's not session specific, then there would be an equivalent concept in your business domain you should be able to translate to SpiceDB (i.e. as a definition) In the case of session specific, you could implement it as follows:

definition zone {
    relation granted: project with active_project

    permission edit = granted->edit
    permission write = granted->write
}

active active_project(active string, project_name string) {
  active == project_name
}

What's not ideal of this approach is that you are duplicating information already available in the tuple (the project resource ID) in the caveat context, but it should support your requirement. I think that could be a relatively straight forward to support injection of tuple specific information as context, I've seen it requested in the past already.