Versioning and Review Policy

Review dates and status labels are promises about maintenance, not decoration. A page that builds may still be incomplete, under-cited, conventionally inconsistent, or scientifically stale.

Every mature page should carry frontmatter fields that identify its page status, knowledge status, canonical home, and last review date. The label meanings are defined in Page Status Labels.

Review Triggers

Review a page when:

• a formula, sign, normalization, or convention changes;
• a canonical page is moved or renamed;
• a new page duplicates part of an existing derivation;
• an external standard, software library, or dataset changes;
• a reader reports an error;
• a frontier topic becomes settled or a claimed result is challenged;
• a build error, broken link, broken figure, or KaTeX failure is found;
• a page is promoted from draft to usable, reviewed, or canonical.

Promotion Criteria

A page may move from draft to usable when it has a clear purpose, valid frontmatter, readable structure, working math, references, and no known broken links.

A page may move to reviewed only after checking:

• mathematical claims,
• assumptions and domains of validity,
• references,
• convention consistency,
• canonical-home placement,
• internal links,
• figures and alt text when present,
• exercises and solutions when present,
• local build output.

A page should be marked canonical only when it is mature enough for other pages to rely on as the primary home for the topic.

Stale Content

If a page is useful but known to be stale, mark it needs_update and state the reason near the top. Do not silently leave stale material with a reassuring status label.

If a page has been superseded, mark it deprecated, point to the replacement, and avoid preserving duplicate derivations unless needed for historical context.

Changelog Policy

The Changelog records notable editorial and structural changes. It is not a replacement for version-control history. Use it for reader-facing milestones such as new volumes, convention changes, major page reorganizations, and corrected errors that could affect interpretation or calculation.

References

• Committee on Publication Ethics, Core Practices, for publication-integrity principles.
• The Turing Way Community, The Turing Way: A Handbook for Reproducible, Ethical and Collaborative Data Science, for open maintenance and reproducibility practices.
• M. A. Nielsen, Reinventing Discovery, Princeton University Press, 2011.

Exercises

1. A page builds but has no references and duplicates a derivation from another canonical page. Should it be promoted to reviewed?

Solution

No. Build success is necessary but not sufficient. The page needs references and must respect the one-canonical-home rule before review promotion.

2. A software page depends on behavior that changed in a new library release. What should happen?

Solution

Review the page, update the version-sensitive claim, cite the relevant documentation or release note, and mark the page needs_update until the correction is complete.