@theconductor Many thanks - the downside of this approach is that at the point you undertake the permission check you need to somehow know which project you are asking about - which if you are in a piece of "software" that doesn't know about projects makes this almost impossible - and if you are simply trying to start a piece of software you also need to possibly try starting via ALL projects - again not great. I was attempting to avoid putting the concept of project into the [subject resource permission] tuple (since needing the project info is only really about the internals of the permission check). I do think that this example argues for sometimes allowing the object and subject to automatically be a part of the context. If this were the case I would NOT need the validate caveat ... and I could actually change the definition of project to both allow

user

and

user with software/deny

so that only users that needed to be denied some software would put that in the relation.

definition project {
    relation admin: user
    relation member: user | user with software/deny
    permission allow = member
}