Sorry but this seems to hit one of the age-old arguments of documentation: can you truly rely on everyone using your code downstream to read your docs?
This article makes a strong assumption "yes". Because it must, it relies on non-executable and non-verifiable documentation to implement a security gate. But for a very small performance overhead, you can likely do those checks in code, and never worry if your documentation becomes lost, outdated, or simply ignored, and more importantly, now that the requirements are embedded in executable code rather than dumb documentation, you can automated testing of the requirement.
Yeah, I prefer unit tests over docs. Rather than writing a document saying "Make sure X does Y" Just write a spec checking that X does Y and if it ever stops doing that there will be a descriptive error in the CI.
Docs and comments go out of date and people don't know they exist/where to find them. Unit tests are always checked and always maintained.
Can you provide proof that you can automate all tests of all code?
Can you provide proof that you can turn all human-understandable language into computer-understandable language?
We haven't even started the discussion yet of how much code you spend on writing tests for other people's code, versus how much code you spend writing your own code.
This article makes a strong assumption "yes". Because it must, it relies on non-executable and non-verifiable documentation to implement a security gate. But for a very small performance overhead, you can likely do those checks in code, and never worry if your documentation becomes lost, outdated, or simply ignored, and more importantly, now that the requirements are embedded in executable code rather than dumb documentation, you can automated testing of the requirement.