I suppose I should ask: * Why are you doing this? Ask your users. * If you don't have users, why are you bothering? * Who is going to maintain it after you'

I suppose I should ask: * Why are you doing this? Ask your users. * If you don't have users, why are you bothering? * Who is going to maintain it after you're gone? * How about "living off the land"? * What about document management? If it's just you, then delivery is probably more important than maintainability. Maybe it's more important to put the knowledge in a queryable data format if "what" is more important than "why". Delivery might look like PDF or HTML docs. Your users might prefer HTML or (urrrp) Word. Or (gerp) Confluence. You can try to influence that, of course. If it's code, e.g. Java or Python, there are built-in doc formats. Finally, how are you going to manage the evolution of that documentation: you need to at least give passing thought to versioning and who can edit. Swagger and Jupyter Notebook come to mind as creative approaches focused on particular problems. I've used Microsoft Access to document requirements and dependencies. I wrote HTML with Notepad 20+ years ago in a CMM 3 shop (served off of a file share), and that created a whole committee to decide what a "document" even was. I've used self-documenting / low code / no code approaches from time to time when crafting operational systems when I expect to immediately lose control to inveterate tinkerers.