Technical Proposal
also called Design Doc, RFC
A written argument for a course of action, circulated for review before the work starts, structured so that disagreement surfaces early and cheaply.
The value is not the document, it is that writing forces the thinking. A proposal that cannot articulate the problem, the options and the trade-offs is a proposal whose author has not finished deciding.
A structure that works: problem (what is broken, with evidence), constraints (budget, deadline, skills, regulation), options considered with the trade-off of each, recommendation with rationale, consequences accepted, risks and unknowns, and what happens next.
Two habits that determine whether it works as a process. Circulate it for comment before the decision feels made, or the review is theatre and reviewers know it. And keep it short — two to four pages read by ten people beats twenty pages read by two.
The consequences and unknowns sections are what reviewers should spend their time on. A proposal with no stated downsides has not been reviewed, it has been announced.