Documentation & Training exit conditions
Candidate exit conditions for the Documentation & Training type. See the catalog overview for how to adopt these.
README & project overview
| Exit condition | What it checks |
|---|---|
|
A README file is present at the repository root. |
|
The README opens with a project title and a one-paragraph description of what the project does. |
|
Status badges (build, coverage, version) resolve to live endpoints and are not broken. |
|
The README contains an installation or setup section with runnable commands. |
|
The README includes at least one minimal usage example showing the primary workflow. |
|
Required runtimes, versions, and system dependencies are listed before install steps. |
|
The README states the license and links to the LICENSE file. |
|
The README points to support channels, issue tracker, or community forums. |
|
The README declares maturity or lifecycle status (alpha, beta, stable, deprecated). |
|
A table of contents is present when the README exceeds a configured length threshold. |
Quickstart & getting started
| Exit condition | What it checks |
|---|---|
|
A dedicated quickstart or getting-started guide exists. |
|
The quickstart reaches a working "hello world" result in a stated, bounded number of steps. |
|
Every quickstart command block is copy-paste runnable without manual editing. |
|
The quickstart states its prerequisites and assumed starting state. |
|
Each quickstart step shows the expected output so users can self-verify. |
|
The quickstart provides teardown or cleanup instructions for created resources. |
|
No quickstart step references removed commands, flags, or endpoints. |
|
The quickstart covers each officially supported operating system or platform. |
|
The quickstart ends with links to deeper documentation or next tutorials. |
API reference
| Exit condition | What it checks |
|---|---|
|
An OpenAPI or gRPC/protobuf specification file exists for every public service. |
|
The API specification passes a schema validator without errors. |
|
The published API specification matches the routes and handlers implemented in code. |
|
Every endpoint or RPC method carries a human-readable description. |
|
Every request parameter, field, and header documents its type and meaning. |
|
Each endpoint documents its success and error response codes with schemas. |
|
Each endpoint provides example request and response payloads. |
|
Authentication and authorization requirements are documented per endpoint. |
|
Deprecated endpoints and fields are flagged with removal timelines. |
|
A catalog of error codes maps each code to a cause and remediation. |
|
Rate limits, quotas, and pagination behavior are documented where they apply. |
Architecture documentation & diagrams
| Exit condition | What it checks |
|---|---|
|
A system architecture overview document exists describing major components. |
|
At least one architecture diagram depicts components and their interactions. |
|
Architecture diagrams are stored as editable source, not only as exported images. |
|
Data-flow or sequence diagrams document the primary request and event paths. |
|
Each documented component identifies its owning team or maintainer. |
|
External and internal service dependencies are enumerated in the architecture docs. |
|
Architecture components link back to their originating requirements in the knowledge graph. |
|
Architecture diagrams reference only components that still exist in the codebase. |
|
Trust boundaries and network zones are marked in the architecture documentation. |
Architecture Decision Records
| Exit condition | What it checks |
|---|---|
|
A dedicated ADR directory or log exists in the repository. |
|
Each ADR follows the agreed template with context, decision, and consequences. |
|
Every ADR records a status such as proposed, accepted, or superseded. |
|
ADRs are numbered sequentially without gaps or duplicate identifiers. |
|
Superseded ADRs link to the decisions that replace them. |
|
Each ADR records the date the decision was made. |
|
Architecturally significant changes in the diff are accompanied by a new or updated ADR. |
|
Each ADR documents the alternatives considered and why they were rejected. |
|
ADRs link to the components or modules they govern in the traceability graph. |
Operational docs, runbooks & troubleshooting
| Exit condition | What it checks |
|---|---|
|
A runbook exists for each production-critical service or workflow. |
|
Every alert links to a runbook section describing its response procedure. |
|
Runbooks contain concrete, ordered steps an on-call engineer can execute. |
|
Deployment and rollback procedures are documented with exact commands. |
|
Runbooks specify escalation contacts and severity thresholds. |
|
A troubleshooting guide maps common failure symptoms to diagnoses. |
|
A FAQ addresses recurring user and operator questions. |
|
Backup, restore, and disaster-recovery procedures are documented and dated. |
|
Runbooks list upstream and downstream dependencies impacted during incidents. |
|
Each runbook records a last-verified date within the configured freshness window. |
Changelog, release notes & versioned docs
| Exit condition | What it checks |
|---|---|
|
A changelog file is present and maintained. |
|
The changelog contains an entry for the current release or unreleased section. |
|
Changelog entries follow a consistent, parseable format such as Keep a Changelog. |
|
Version numbers in the changelog conform to the project’s versioning scheme. |
|
Release notes call out breaking changes and required migration steps. |
|
Each released version records a release date. |
|
Documentation is versioned so users can view docs matching a specific release. |
|
Published docs expose a version selector covering supported releases. |
|
A migration guide accompanies each major version bump. |
|
Deprecations are announced in release notes ahead of removal. |
Code comments, docstrings & configuration reference
| Exit condition | What it checks |
|---|---|
|
Every exported function, class, and method carries a docstring or doc comment. |
|
Public API docstrings document parameters, return values, and raised errors. |
|
Docstrings describe the current signature with no parameters that no longer exist. |
|
Public API documentation coverage meets a configured minimum threshold. |
|
A configuration reference documents every supported setting and environment variable. |
|
The configuration reference states the default value for each setting. |
|
Required configuration keys are distinguished from optional ones. |
|
Every documented configuration key is actually read by the code, and vice versa. |
|
Auto-generated API documentation builds without warnings or errors. |
|
A glossary defines domain terms and acronyms used across the documentation. |
Onboarding, training & doc health
| Exit condition | What it checks |
|---|---|
|
An onboarding guide walks a new contributor from clone to first successful build. |
|
The onboarding guide documents local environment setup end to end. |
|
A CONTRIBUTING guide describes branching, review, and submission workflow. |
|
A code of conduct is present and linked from the contribution guide. |
|
Training material or tutorials exist for the primary user and operator personas. |
|
Training material includes hands-on exercises with verifiable outcomes. |
|
Every code example in the documentation compiles and runs in continuous integration. |
|
Internal and external documentation links pass an automated link check. |
|
No documentation page is older than its configured staleness threshold without review. |
|
Every documentation page is reachable from navigation with no orphaned files. |
|
Every shipped feature has at least one linked doc in the knowledge-graph traceability layer. |
|
A deterministic traceability check reports no drift between docs, code, and requirements. |