The goal of @ValidateReference is to avoid repeating yourself.

Yes, I understand that goal. The question is is such annotation the best way to achieve that goal? That's the thing that needs to be investigated; I don't have the answer right now (it may well be that the suggested annotation is the way to go), but we should not limit ourselves to one solution before not carefully examining possible alternatives.

My concern with the suggested approach is that it is quite verbose, you'd have to annotate each and every member. So IMHO a more general concept is needed to apply all suitable constraints which e.g. is configured on the class-level as opposed to individual members.

A hidden value to @ValidateReference is the case when the Annotation Processor checks the class and method of the annotation to verify their existance.

Yes, agreed to that.

At this time it is my understanding that we are best off only using Annotation Constraints on our code instead of XML so our users will have better knowledge what to expect when interfacing our APIs

That I cannot really subscribe myself to. As pointed out before, the annotation-based approach creates a coupling between different models, which may be undesirable depending on your architecture. In your case, users would have to look at your internal model as well (because that's the source for @ValidateReference in your public API types IIUC) which seems not like a good idea. Admittedly each approach for copying constraints from another model will require knowledge of the source model, so for a public API it may be indeed best to copy constraints to make them very obvious.

Btw. I did not suggest to use XML (though it may be one alternative), but an API to apply that configuration programmatically.