Joe, Assuming 9.1?
Your requirements are not unique. Keep in mind you can soft type containers and folders and parts / documents to drive ACL creation. You do not soft type solely to add attributes.
Add additional more specific roles to the team. Don't say desinger, say designer type x.
Also do not forget ad hoc acl creation. When the change process is going you can iterate through affected data and grant temporary modify or read access etc.
I'm suggesting for our system to implement create permission, but deny modify to everything, unless there is a pending ECN or work authorization to change it.
There is also security labels, role profiles, and actions that can be disabled per container. And more can be added via roleaccessprefs.xml.
The more time you think this through upfront, the easier production support will be.
You can also use multiple organizations where MFG users are placed using principal administrator into a separate MFG organization. Enable search and sharing of users on that 2nd org as well disable ability to have separate containers in that org. When users of a different organization are members of a role of a container of a different organization, they ONLY have read and download access. Even if they are team members of the container. You have to explicity grant additional ACL's. Multiple is a lot less riskier in 9.x! Use them where they make sense to make system administration EASIER!
In general, you want to avoid patching with ACL's as much as possible.
E-mail me if you have any questions.
Hope that helps,
David DeMay
Sent from my Verizon Wireless BlackBerry