OK here's the tricky bit of information I'm looking for. If you lock a document in our system (let's say we change status from 'available' to 'locked'), I would need to push that status into SpiceDB and then use the document field into a static resolver somewhere? https://authzed.com/docs/reference/caveats Am I on the right track?

Unless

lock

status is of dynamic nature (e.g. in that it's not persisted in your applications database and it's determined at request time), I wouldn't model this with caveats. You can certainly do it, it' just not the right tool for the job. I'm missing a bit of context of what you are trying to achieve, but assuming you want to unauthorize access to a locked resource, you can always do something like this

definition document {
  relation viewer: user
  relation locked: user:*
  
  permission view = viewer - locked
}

What you achieve here is that by using the wildcard you can deny access to everybody by writing the to

locked

.

lock status would be persisted in our MySQL DB yes. "you want to unauthorize access to a locked resource" Yes but not only do we want to do that, we want granular permission. We used to have only 'view' and 'edit' actions and we want to go granular now. edit:name, edit:status, and so on. So instead of reinventing the wheel or scaling our current source code adding more complexity and missing key features like scalability/caching, we're looking into switching to the best open source framework to deliver that part of our tech stack.

correct

@_thommas yeah you want to model everything as part of the graph (i.e. as relations) whenever possible. If you add caveats, you'll be caching permutations of the result of a subproblem, rather than just the subproblem. SpiceDB takes your schema and decomposes in smaller cacheable subproblems so they can be reused for subsequent requests, for the duration of a specific max staleness window.