This is not really correct. Use and maintenance of a tool, vehicle, or other system are detailed in Technical Orders (TO) and (for the Navy) Technical Manuals ™ are written and maintained by the respective services. Hardware vendors and contractors provide inputs to the TO/TM but may have little insight or control over how a system is used. There is, of course, no need to have a specific technical order for a simple tool like a wrench or a hammer. What the contractor does have to provide or maintain records to comply with procurement specificiations (MIL-STD, MIL-DTL, and the various industry standards such as MS and NAS fasteners, AWS/ASM certified welds, ASTM/ASM/AISI, et cetera are certifications, manufacturing specifications, quality inspection records, and for complex products, and process and inspection documentation such as travellers, work package instructions, acceptance/lot acceptance test records, discrepency reports, et cetera. The reason for this is that in the case of a failure or defect it allows the procurement authority or failure investigation team to go back through the chain of production and determine if there was a latent defect or change in materials or processes that resulted in the observed problem, which is often critical in cases such as the loss of an aircraft, launch vehicle, or ordnance device where there is little or no direct physical evidence to review. It also certifies that a material or component was procured from a certified vendor and a lesser strength or quality of component (“counterfeit”) was not substituted. This data is often required to be collected and provided through the entire production chain back to material and individual component or lot procurement, so for a complex system such as an aircraft it may be many layers deep, e.g. the avoinics box on an aircraft will have certs from the box manufacturer, the PCB and component manufacturers, material and fasteners specs, et cetera, which results in many volumes of documentation. This is in addition to the engineering documentation such as design analysis reports (DAR) and qualification test reports (QTR) which are required to verify that the basic design meets the specified design requirements laid out in the procurement specifications.
Is such information really necessary or valuable? It clearly isn’t really necessary to have a large binder of documentation for a simple tool like a handle or a wrench; what is really needed is just a basic certification that shows that the tool was built to a certain standard (e.g. materials, tempering and hardening processes, et cetera) and was tested or verified at some level to meet the basic loads and conditions it is intended to operate in. For most consumer products you just get the manufacturer’s say so based upon the perception of brand quality and warranty service. In mission critical applications, however, where failure of a component may culimate in failure of a critical objective or loss of lives, more confidence is often desired, and the tendency for procurement agents (who are often not knowledgeable or experienced in the specifics of the product requirements) to simply accept the lowest bid for a part or system needs to be tempered by the assurance that the product will, in fact, meet functional requirements and is not counterfeit. That this system of procurement has become bureaucratic, officious, and unwieldy is a result of the complexity of military systems and the inflexibility in applying the same procurement standards across the board to hammers and aircraft alike.
However, it should be noted that in the effort to address the egregious cost growth of military procurment, the DoD (and NASA as well) abolished many MIL-STD and MIL-DTL requirements in the early 'Nineties and moved toward a commercial-off-the-shelf (COTS) procurement strategy (often referred to in the aerospace world as “Crap Off The Shelf”). This was largely a disaster and it is questionable that it saved any money, because while it eliminated the costs associated with traceability documentation, parts and systems still had to be verified at an operating level to meet functional requirements, and when a commercial component fails in acceptance testing, or starts failing in the field after acceptance because a manufacturer made some arbitrary change in materials or process that wasn’t documented in any provided data, it may be difficult or impossible to accurately diagnose the problem, and the vendor has little responsibility to come to root cause or otherwise resolve the issue unless a defect is uncovered. By the late 'Nineties and early 'Oughts the DoD started reviving and reinstituting such standards because of all of the problems with defective and counterfeit COTS parts. And even with this, we’re still dealing with issues today because of the shift of manufactuing to foreign companies where there is often little insight or accurate documentation into production. This has been a particular problem with components such as capacitors, fasteners, and batteries, where even getting certifications doesn’t verify that the certs aren’t fraudulent, and has led to the creation of a government wide tracking system for “sibling alerts” where a suspected or known defect in a component is propagated across procurement agencies with a warning against other products which use similar components from the same vendor.
This is obviously very expensive, and because hardcopy documentation is required, results in a lot of paper that has to be manually handled and stored. The commercial automotive industry, which went through similar issues with globalization of component production, has largely developed an alternate system where vendors show compliance by independently verified lot testing and digital certifications which can be automatically reviewed and don’t take up any physical space. This technology didn’t exist back in the pre-Internet 'Eighties, and government procurement standards today have not kept up with modern methods of digital records and verifications, but it is feasible to achieve the same degree of verification and confidence without the cost of maintaining hardcopy documentation though verification of foreign-sourced components is and will likely remain challenging.
Stranger