Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

Documentation as Source Code for AI


options: type: guide version: “1.0.1” birth: “2026-02-16” token_size: 1123

Documentation as Source Code for AI

The Problem

In the era of AI-backed development, AI systems — RAG pipelines, coding agents, AI assistants — consume documentation as their primary input. They don’t read your codebase first; they read your docs. Traditional documentation practices fail in this context:

Poor documentation is no longer just an inconvenience for humans. It is a bug in the AI system.

The Principle

All content in this repository is treated as production source code — versioned, tested, lifecycle-managed, and machine-readable — because it is the primary input for AI systems.

This is not a metaphor. The same engineering rigor applied to production code — diffing, testing, code review, CI/CD, garbage collection of dead code — applies to every document, ADR, and notebook in this repository.

Sean Grove (OpenAI, “The New Code”) articulates the underlying insight: “code is a lossy projection from the specification” — discarding specifications while keeping generated code is like shredding the source and version-controlling the binary. In an AI-consumed repository, documentation IS the source that AI systems compile into outputs.

How This Repository Implements the Principle

Each aspect of the Documentation-as-Code paradigm is governed by a concrete ADR:

PrincipleWhat it meansGoverning ADR
Docs = source codeJupytext pairing makes docs diffable, mergeable, testableADR-26014
Metadata = API contractMyST-native frontmatter makes every document machine-queryableADR-26023, ADR-26016
Lifecycle = garbage collectionSuperseded articles are deleted to prevent RAG noise; ADRs are preserved as negative knowledgeADR-26021
Structure = architectureRepository layout is deliberate design, not accumulation; restructuring = refactoringADR-26020, ADR-26026
ADRs = development backboneEvery major decision is an ADR; proposed ADRs serve as living RFCsADR-26025
CI/CD = deploymentSync-guard validates documentation integrity before deploymentADR-26015
Hub = authoritative specsHub holds conventions and specifications; spokes hold implementation. The hub is the “POSIX standard” — it defines what conforming implementations must do. Implementations (vadocs, mentor_generator) are replaceable; standards outlive them. The replacement test: if the implementing tool were replaced, would this decision still apply? Yes → hub. No → implementation repoADR-26020

The Structural Analogy

In source code, architecture determines where modules live, how they reference each other, and what contracts they expose. The same applies to documentation:

This stands in direct opposition to pre-AI knowledge bases — collections of articles with no enforced structure, no traceability between documents, and no automated verification. Those collections were adequate when only humans consumed them. They are inadequate when AI systems depend on them.

Role of This Document

This manifesto is not an ADR. ADRs are decisions — reversible, with alternatives considered, subject to promotion gates. This document is a declaration of principles — the unchanging foundation that individual ADRs implement. It answers “why does this repository exist?” while ADRs answer “how do we build it?”

References