I'm ready for advice, now that I better understand my problem.
So, here's my current workflow. And by "my current workflow", I mean how things are structured right now on projects. And I have the power to influence this whole workflow if things are broken in it. Let's assume a greenfield development project at first.
I'm handed a set of requirements that describe what the software system must do and are allocated to sub-systems: things on the hardware, things in the air, things on the ground, test and support tools, etc. I go through and understand these requirements and likely derive other requirements from stakeholders to put a nice box around what I'm building. My requirements get approved and I start designing.
Designing has a few forms: myself at my computer/IDE, myself and one or perhaps two coworkers at a computer/IDE, myself with pen and paper or whiteboard, or myself with coworkers at a whiteboard/conference room. It can be assumed that everything valuable gets digitized - photographed or scanned and stored electronically in a defined location. Source code in version control.
At some point, for each software product, my work needs to be reviewed. There needs to be an initial design review (think PDR) and a detail design review (think CDR). These are technical/engineering reviews, though. Not programmatic/managerial. Those are at a much higher level than just software, unless only software is being delivered to a customer.
At the initial reviews, the question is "will this solution meet the given requirements in the intended environment?" At the detail review, the question is "is everything done to implement the solution?" Effectively, at the end of the final review, anyone should be able to go to a build server, produce the executable software, and load it onto the target hardware for a final and complete integration and acceptance testing process.
Along the way, there's this very poorly defined "design data" component. Clearly, one component is the source code. But that's likely to be insufficient. It doesn't capture design decisions made along the way very well - what does the software look like and why were certain decisions made.
To capture a description of a design, the IEEE has a standard. It's nicely called "IEEE Standard for Information Technology - Systems Design - Software Design Descriptions". It doesn't say much about the content of what a software design description (SDD) looks like physically or electronically, but it does provide guidance for what types of things to consider capturing.
Effectively, it says things like "document the context that your system lives in - the hardware environment, the users, other software - and treat your thing as a black box" or "write about the information that your software system needs to function or produces as output" or "write about your interfaces - hardware, software, protocols, user interfaces, etc". Pretty generic stuff, really. And standard.