Documentation Standards & Docs-as-Code
We treat documentation with the exact same rigor as executable software. All architectural decisions, API contracts, deployment instructions, and compliance evidence are written in Markdown, stored in version control alongside code, and tested during CI/CD pipelines. This eliminates stale wiki documentation and creates an auditable single source of truth.
The Docs-as-Code Philosophy
Documentation stored in external proprietary wikis quickly drifts out of sync with production code. Under Docs-as-Code:
- Version Controlled: Documentation changes travel in the same Git pull requests as the code they describe.
- Peer Reviewed: Technical leads review doc changes during code review gates.
- Automated Link Checking: CI/CD linters verify all markdown links, anchors, and image paths before merge.
Markdown & MDX Authoring Rules
Plain-Language On-Ramp
Every document must begin with a 1–3 sentence plain-language summary before complex code or specifications appear.
Heading Hierarchy
Use a single # H1 for page title, followed strictly by ## H2 for major sections and ### H3 for subsections. Never skip heading levels.
Diagrams as Code
Use Mermaid.js or Section 508 accessible SVG components. Avoid raster PNGs without descriptive text descriptions.
Inline Code Documentation (JSDoc / Docstrings)
Public interfaces, exported services, and regulated clinical calculation functions must include structured docstrings documenting parameters, return types, and possible thrown exceptions:
Copy this prompt to generate thorough API and component documentation.
Community Discussion & Feedback
Attributed peer feedback and official Netspective architecture notes.