I'm sure there a ton of ways to go about this that are very much dependent on what you have for a change process.
In our case we have something that's along these lines and it's been evolving for a while now.
Each WTPart has a default attribute we use for tier of release that is defined by level of rigor/risk (low, medium, high). This attribute determines the minimum list of approvers for each tier and in the change process there is a check for required approval roles based on that attribute.
We don't - however - separate WTPart and sort them into different routes but instead for a single ECN take the highest tier and that's what's used for required approvals.
If you're using tasks, you can do something similar and check whether a particular task is required (or not) based on what's coming into the ECN. Something like "if missing Manufacturing view, then require manufacturing task".
I noticed that the more "checks" and "rules" we added (things like "Check for missing tier attribute", "Verify BOM Maturity", "Resolve release targets", etc...) the more the process was perceived as slow and cumbersome by the users.
The other thing that very quickly became an administrative burden is shuffling people between the correct roles on a relatively frequent basis.
At the moment I'm reformatting some of the workflows to allow for checks based on required level of rigor (determined by WTPart subtype, program maturity, etc) AND engineer's desired level of rigor. So: at a certain tier, you have to have the checks you need. But for lower tiers, essentially I'm just checking whether any of the roles are populated with approvers (from correct groups) and - if yes - route to those approvers. If those are blank and the level of rigor allows it, a change can occur with minimal required sign offs.
I'd love to hear how you're doing it! I'm between two rocks on this: "we need all the rigor" and "we need to be REALLY fast". It's finding the appropriate intersection that everyone is satisfied with that's is a challenge.
