I am open to correction on this, but it's my understanding that:
1.) When you create a rule at a lower level, such as in the correlation engine, that the status and settings of that rule will propagate "upwards" to the root (default) of the policy. In other words, when you create a correlation rule and enable it that it's enabled all the way up to the default policy. The same goes for the settings such as aggregation.
2.) I was also told that rules/policies that exist at a lower level, such as correlation rules, should never be enabled at the default policy. That is, they should be enabled in the correlation policy, but not at levels above it. It was said that this causes additional processing for the rule that's not necessary at the default policy level.
Again, I was told this by a VAR at a very early stage in my exposure to the SIEM, so I could be wrong/misinformed. If that's the case I would like to know.
To follow up on penoffd's post...
When we create new correlation rules, the first thing we do after creating them, even before rolling them out, is to disable them at the default policy level, then drill down to the policy where we actually want them applied, and set them to block inheritance. This is also where you'd turn off aggregation if that's what you want/need. This insures that the rule is only running on the data sources or devices you've selected which will help with the overall load.
I should have elaborated, but this is what we do as well. Thanks for pointing out the details.