Had some suggestions, also in retrospect, feels like hack that the filter returns a Policy with one policy from the selector, not sure if its better to add a policy.FilterCheck. I would maybe suggest Filter only returns the last policy level i.e policy/subpolicy/subsubpolicy/check so it will return subsubpolicy and then in the execute u will do subsubPolicy.GetCheck(lastPart) ? maybe less hacky but must pass check to execute.

With that way of doing it, how do you tell if the last part is a check or a policy?

You give me a path lets say Px is a policy and C is a check. So by passsing p//p1/p2/p3/C or p//p1/p2/p3 the function always returns p3 + C in the latter case it will return p3 + "". The Execute function gets P3 + C if C != "" it runs C in P3 if it exists, otherwise runs all P3 checks.

You give me a path lets say Px is a policy and C is a check. So by passsing p//p1/p2/p3/C or p//p1/p2/p3 the function always returns p3 + C in the latter case it will return p3 + "". The Execute function gets P3 + C if C != "" it runs C in P3 if it exists, otherwise runs all P3 checks.

While I see that your suggestion works in our current codebase but I am wary about tying policy filtering execution together. I implemented it this way so that any function that needs to interact with a policy never needs any more information than the policy that is passed to it. This fully decouples filtering from execution/evaluation/anything other action we implement. I don't think that actions should have to know any information about the selector or any other processing that might go on.

You give me a path lets say Px is a policy and C is a check. So by passsing p//p1/p2/p3/C or p//p1/p2/p3 the function always returns p3 + C in the latter case it will return p3 + "". The Execute function gets P3 + C if C != "" it runs C in P3 if it exists, otherwise runs all P3 checks.

While I see that your suggestion works in our current codebase but I am wary about tying policy filtering execution together. I implemented it this way so that any function that needs to interact with a policy never needs any more information than the policy that is passed to it. This fully decouples filtering from execution/evaluation/anything other action we implement. I don't think that actions should have to know any information about the selector or any other processing that might go on.

Yes that makes sense, maybe what bugs me is the fact that if you ask for a control you get a copy of that policy only with that control. But I can see that the my initial suggestion remove the decoupling.