The upcoming "caveated relationship" functionality could support this, and it already shows up in

Watch

(this functionality is still WIP, but is already in

main

). The downside is that data would be injected at request time into the caveat evaluation engine, thus incurring unnecessary overhead (but only if a caveat is set in the relationship).

would that overhead be on every check/lookup regardless of whether there's a caveat provided in the request?

caveats are defined at the relationship level. In the request you'd provide the caveat context that is necessary to fulfil that caveat, but you also store it in the relationship. The should be rather low, and will only happen if the relationship is defined with a caveat. @Joey reminded me that this won't just work today as storing the caveat context will be discarded if no caveat name is referenced at relationship write time. The team would have to discuss what is a reasonable route forward to enable this, given that the foundation is in place, but we just need to clarify how are we going to allow writing "non-caveat related data". I suggest opening an issue in GitHub as Jake pointed out to continue the discussion there.