In general you specify behavior across team level. You can add behavior at iterations.  It can also be hierarchical in iterations and can be at a level nested into planned for iterations. For example you can split a release iteration into smaller chunks e.g. To make a process more strict towards the end of an iteration. It can also tied to iteration types.

Thanks. I did read that article and posted question after reading, it did not help with the team vs iteration rule precedence.

 It is not clear wither iteration rule is added to or overrides team rule (for the same role)

also not clear rule composition/precedence when it comes to concrete iteration (instance) vs iteration type (e.g. 'shutdown') - is is additive or does concrete interation override type imposed rule ? (all for same role, to make things simple)

It grabs the first role of the user in the team are that owns the object to manipulate/ act on. Then it starts with the deepest nested iteration, looks at the type, if no type at the iteration and looks for operational behavior. It looks fo the first operational behavior definition it can find for the role. If it finds a definition for an operation that is involved, for the role, that is picked, and only that. If it doesn't it looks at the team area, does the same. And up the team area hierarchy. It does this for all roles until it finds the first operational behavior. It only executes the first it finds. 

Oh, I see, so it executes the first found, looking team area-wise locally first - 1) current iteration, 2) iteration type, 2) team area, and going up the team hierarchy making the same rounds at each level, until it finds a definition for the given role. Did I get it right ?