...
The basic premise is as follows: any part created starts as a WIP file, editable by any PDM user, they then have the option to move it to concepting to show that a file should not be referenced by other projects, or does not show design intent. If a file is going to be worked into a usable state it should stay in WIP. Files in WIP with the goal of being approved should follow proper design standard and be designed showing design intent, with labeled folders and tree items to allow others to access them easily. The file stays in WIP until it is ready to be reviewed by the head of the system, or the chief. At that point the user initiates a status change to submit for review. In that state the head will not be able to edit the part, and it will be locked unless it it pushed back to WIP for more revisions. The head has two options depending on the quailty quality of the file, either push back to WIP or push through to a REV state. REV states are also locked, preventing changes to be made in that state, and should be considered ready for production. If a head or lead or member spots a problem, the lead will have permissions to pull it back into a WIP state, thus unlocking the file. At this point, the file must be put back through the same process in order to be ready for production, and subsequent submit for review creates a REV B file.
An Alternative to this is to require that a part be in level REV B to allow it to be put into production. In this alternate method, the file can be edited during REV A and referenced by other projects during that time, this would mean that WIP files can be ignored by all other system leads and that the only referenceable files are REV A and above files. This would mean that a minimum level of REV B would be locked, and that REV A files can be referenced, but not put into production.
...