Appreciate your input. Perhaps it is seen as a waterfall way of doing a things. Personally I would write it alongside building the system, then continue to evolve it as the architecture matures. It does not need to be a case of writing everything down first before building things. Although it might be cheaper to change the words in the document compared to destroying Infra and rebuilding it!

This can then be used to show customers or auditors that we have been diligent and designed the system carefully, even if they find some flaws.

I'm a huge fan of specifications (despite the downvotes to my comment above).

They can be slightly tricky to maintain and to get right. But not nearly as ticky as maintaining software for which there's at best only a partial sense of a coherent shared mental model available to the stakeholders (not to mention the developers) as to what this piece of software is supposed to do. Other than a slew of JIRA tickets written by a cast of thousands, and assigned to a zillion different developers over the years.