What Gets Documented
In one line: Review the effect of a change, not its label or size.
| Category | Readers | Trigger |
|---|---|---|
| Business intent and terminology | Domain owners, analysts, developers | Changed meaning, rule, definition or acceptance example |
| Architecture and ADRs | Technical owners and maintainers | Changed boundary, significant decision or constraint |
| API/integration reference | Providers and consumers | Changed schema, behavior, authorization or failure semantics |
| Operations and recovery | Operators and support | Changed deployment, configuration, support or recovery behavior |
| Privacy/compliance mapping | Accountable qualified owners | Changed intended use, data processing or applicable obligations |
| User journeys and features | Users and business reviewers | Changed observable behavior or supported capability |
| Project state | Returning contributors | Updated maintained work records, optional repository snapshots and separate runtime evidence |
A one-line flag change can alter business behavior. A “bugfix” can change API compatibility. Neither is exempt merely because it is small. When a change has no documentation impact, record the review rationale rather than requiring cosmetic edits.