It is the hypothesis of project hri07e that every time an engineering project is carried out a good portion of the methods and jargon are in fact re-used from previous projects and that in most commercial project - very little has not been done before. In fact - if the method IS brand new - the owner of the project probably hasn't been told that his project is in fact an experiment to see if this new method is valid or not. (And that if the new method is not - he may find himself with a brand new white elephant.)
Much of the effort of hri07e is spent in capturing the knowledge of past projects in a way that it can be re-used in future projects without compromising the Intellectual Property of the original work.
As this may require almost as much work as doing the project work - it is proposed that the project team only be asked to identify and make available the procedures and jargon that they have used, and that a special knowledge management team be tasked with creating the generic version.
At some point the need for new products will level off and at that point each project may be asked to draft their own new standards if in fact they really, really must create a new standard. (And again - the project owner should be told "this has never been done this way before - are you comfortable with that?" - and see what answer they get.)
hri07e extends the DoD concept to not only standard deliverables (called DID's by DoD - CDID's in hri07e) - but also to standard jargon to be defined in the Data Dictionary for the appropriate domain of expertise for the subject matter. In this case - all of the important data items contained in a CDID should be have associated key codes which are defined in an hri07e Data Dictionary - or in the project Data Dictionary if the project is so secret that no-one outside the project is allowed to know how the engineering was done. (Which also means that no-one outside the project can comment on whether it's correct or not.)
Standardized Documents in hri07e are not called Data Item Descriptions (DID's) - but rather Contract Deliverable Requirement Descriptions (CDID's) and have a somewhat broader application in that "everything" that is not an engineered object or system is a CDID. Engineered objects do however have "data sheets" which collect the design data using "key codes" - and these data sheets are in fact defined by CDID's - again - unlike their DoD counterparts.
One hard to fathom result of this method is the recursive nature of these fundamental documents describing CDID's and SIG's and key codes. There IS a CDID for writing CDID's for example - as there is for creating SIG's and Key Codes. Since it refs to its own structure it is rather confusing to read compared to the engineering CDID's and so it is suggested that it not be your starting point for understanding the topic. The only comfort in that is that DoD also has a "DID DID" but they call it MIL-STD-963B.