This is a dynamic role issue. so instead of modelling it as two
different person type classes, which have the well know limitation of a
person only being able to have one role/function, you should rather have
a person class with a "has-a" relationship to some role objects. This
allows you to combine persons/roles as you desire dynamically.

These role objects could then contain the specifics of that persons
role. This would support dynamic/run-time changes in a persons role. In
contrast to the static class model you originally proposed, which would
require changes to the code every time a new person/role relationship is
invented.

For a policy you would follow the same principle with regard to people
involved in the policy, e.g. say you needed to create a new policy where
 there was a third participant in the policy, e.g. "PolicyGuardian".
With the dynamic version you only need to add the PolicyGuardian class
and a couple of methods to deal with that participant, and you are ready
to go.

tom