Auditing documentation at growing manufacturing / high-tech companies

I've done this now on a couple of companies. It comes down to one key question:

Does Engineering use Git? If not, what systems do they use?

After that, it becomes a process of integrating documentation onto the existing systems. If these don't exist, it's a process of moving documentation onto a Git-based platform. Through making documentation system and tool agnostic (plain-text, docs-as-code), we make it scalable, low-cost, and LLM ready.

I guess most of these types of companies have software teams using Git. The harder part then is moving the hardware team's documentation on these systems. So they already have the tools to shift their legacy MS Word content to docs-as-code, but have not yet taken the plunge to do this. Which brings us to another key question:

How much of an effort will it be to go back and convert the existing key documentation?

The effort to create documentation in a modern format is low -- it's mostly training and guidance (which improves everyone's core skills sets). With tools such as Pandoc and Python, the barrier to convert existing document is low.

The cost of inaction is far greater than the cost of action

"The Stern Review (2006)"

Some final and more general questions:

• Can I generate a list of all documents, their state (approved, draft etc), where they live, who owns it, and when it was last edited?
• Can I track a single change back to an Engineering Change Request or ticket?
• How many manual steps are their to go from draft --> approved --> published ?
• Is there a style guide and how automated is it to manage terminology and consistency?
• How many authors can work on a single document at the same time?
• Can I edit document metadata via an API?
• Can an engineer create a document on the company's workflow from day one?