Holacracy Community of Practice Archive, 2015-2019 Community Holacracy Web Site

> Example: "Any role who wants to make changes to training slides, must first ask approval from Training Design role"

To me this reads like the very definition of a domain, only packaged as a policy.

In general, domains should be used with caution (and only created based on concrete tensions /examples), but in this case, "Training Slides" as a domain on the Training Design role would make more sense to me than this policy. Clearer this way, in my opinion. ( A domain also clarifies, that the domain owner needs to specify a reason why the access to a domain was denied after the request. The policy above does not specify this duty on the Training Design role, thereby inviting an abuse of power.)

With a domain in place you don't need an accountability for "approving or declining requests to impact domain X" on that role then.

That would be a problematic accountability anyway, since such an accountability doesn't limit any other role's behavior (which was the intended effect of it) - even if your job is to "approve", I am not limited by you "not approving". Ok, fine, you did not approve - doesn't mean your role can tell my role what not to do. Accountabilities can't do that - only domains and policies can set boundaries and force prior synchronization with centralized points of control (domains).

Either way, you should consider testing the proposal for the policy to find out, whether there is a real tension / example behind creating the policy/ domain in the first place. Otherwise, you create a lot of red tape without the need for it.