Technical Documentation
API docs, architecture records, user guides, and runbooks with structured review.
Overview
API documentation, architecture decision records, user guides, and runbooks all benefit from a structured creation and review process. Datarim ensures that documentation is accurate, complete, and tested against real systems. The pipeline prevents the common failure mode where docs are written once and never verified — every endpoint is checked, every example is tested, and every link is validated.
Example: API Documentation for a Payment Service
A team needs to create comprehensive API documentation for a payment processing service with 12 endpoints. The docs must serve third-party integrators and include working code examples in three programming languages.
Pipeline Walkthrough
| Stage | What happens |
|---|---|
| /dr-init | Scope: 12 endpoints, request/response schemas, error codes, auth flow (L2) |
| /dr-prd | Audience: third-party integrators. Requirements: OpenAPI 3.1, code examples in 3 languages, sandbox URLs |
| /dr-plan | Priority: auth flow first, then payment lifecycle (create → capture → refund), then webhooks |
| /dr-do | Write docs. Cross-reference with actual API code for accuracy |
| /dr-qa | Verify: every endpoint documented, examples tested, error codes complete, links valid |
| /dr-archive (Step 0.5) | Note: generating examples from actual API responses was faster than writing them manually |
Key Benefits
- Accuracy by cross-reference — docs are verified against actual API code, not assumptions about behavior
- Audience-first design — the PRD stage defines who reads the docs and what they need, preventing developer-centric blind spots
- Tested examples — QA ensures every code example actually works, in every listed language
- Living documentation — the pipeline can be re-run when the API changes, with QA catching stale sections
Relevant Agents
Which agents are most active in this use case:
- Writer — drafts documentation with clear structure and examples
- Editor — consistency, terminology, and formatting review
- Developer — verifies code examples and cross-references with source code
- Reviewer — completeness checks and link validation
Complexity Routing
How complexity levels apply to technical documentation:
- L1 — Update a single endpoint's description or fix a broken code example
- L2 — Document a new API with 10-15 endpoints, including schemas and examples
- L3 — Create a complete developer portal with guides, tutorials, and reference documentation
- L4 — Multi-product documentation suite with versioning, migration guides, and SDK references