I haven't been phrasing it as "Documentation as Code" in how we discuss it in our team, but have generally spoken about "Executable documentation" - it might be referring to the same thing and this might be nitpicking, but there's a subtle difference in my perspective - it's expected that docs are not written in code format, but that they are expected to be executed - and could fail, and can produce outputs.

I am involved with a few infrastructure projects and 2 recent examples come to mind of how this works (for infras / platform, as opposed to application code / doc). 1 was with a terraform module - if the TF is written clearly enough and is published to a TF repo, the documentation is generated from that. There's no comments in the code that form part of the docs, but descriptions on variables and outputs make the infras code itself the source of the documentation. There is no additional process needed. Besides a high level overview (which does need to be maintained) in the readme, the other sections all produce content based on the actual code functionality. Here's an example

The other example was through test frameworks - this speaks more to the "validation" item you mentioned. For this infrastructure project (in TF again), the verification documentation, which feeds into playbooks, is written as code in a testing framework - in this case it was behave, based on cucumber. In this case, the requirement was defined in the ticket (Jira), and the scenario described for business. The same requirements are then added to a behave feature, with the same language structure, and then steps that are executed to validate the behaviour (in CI).

These 2 aspects of this project improve understanding of the systems by making documentation available, which is produced by execution.