Errata and Version History

Errata are part of the scholarly record, not an embarrassment to be hidden. A correction should repair the current page while preserving enough information to tell a reader what changed, why it changed, how the correction was checked, and whether earlier conclusions were affected.

This chapter is the canonical home for public correction records. It does not replace repository history: commits show every textual edit, whereas an erratum explains a substantive defect in terms useful to readers. Nor does a correction erase the fact that an earlier version may have been read, cited, or used in a calculation.

Current ledgers

Different records require different checks. The ledgers below separate them without weakening the common reporting standard.

Ledger	Scope	Typical verification
Site Errata	Conceptual, expository, navigational, and accessibility defects	Subject review and rendered-page inspection
Formula Corrections	Signs, factors, indices, domains, assumptions, and equation labels	Independent derivation and limiting-case checks
Table Corrections	Incorrect entries, headings, units, conventions, or generated values	Source comparison or regeneration
Notebook Reproducibility Issues	Broken environments, stale outputs, missing data, and nondeterministic results	Clean-environment execution
Citation Corrections	Wrong attribution, metadata, quotation, scope, or source linkage	Primary-source inspection
Redirects and Deprecations	Moved canonical homes, obsolete pages, and compatibility URLs	Route and inbound-link checks
Changelog	Material releases and editorial milestones	Release-level review

An issue can appear in more than one ledger when its consequences cross boundaries. One record remains primary; related entries cross-link to it rather than copying the full account.

What counts as an erratum?

An erratum records a defect that could cause a reasonable reader to learn, calculate, cite, implement, or navigate something incorrectly. Examples include:

• a sign or normalization error in a displayed equation;
• a statement whose hypotheses are too weak for the stated conclusion;
• a table entry in the wrong convention or unit system;
• a citation that attributes a result to the wrong source;
• a notebook that cannot reproduce a published figure from its declared environment;
• a broken canonical link that strands readers or points to obsolete content;
• wording that materially reverses or obscures the physical interpretation.

Routine improvements do not normally require an erratum. Copyediting that does not change meaning, smoother transitions, added examples, refreshed styling, and new cross-links belong in repository history or the changelog. When reasonable readers could disagree about whether meaning changed, record the correction. Transparency costs less than ambiguity.

Record schema

Every confirmed public record should expose the following fields. A field may be marked not applicable, but it should not silently disappear.

Field	Requirement
ID	Stable identifier of the form QM-ERR-YYYY-NNNN
Status	Current point in the correction lifecycle
Impact	Consequence for readers: critical, high, medium, or low
Category	Nature of the defect, such as sign_error
Affected page	Canonical URL and, when useful, section or equation
Incorrect content	Concise description of what the prior version said or implied
Corrected content	Concise description of the repaired statement
First published	Earliest known date of the affected version
Reported	Date the issue entered the tracker
Corrected	Date the public correction was deployed
Reporter	Person or process that identified the issue, subject to privacy preferences
Reviewer	Person who independently verified the diagnosis and repair
Evidence	Derivation, source, test, regenerated artifact, or reproduction log
Repository link	Issue or pull request carrying the technical discussion
Downstream impact	Other pages, tables, figures, notebooks, or conclusions audited

For example, an issue tracker may begin with this machine-readable record:

id: 'QM-ERR-2026-0001'
status: 'reported'
impact: 'high'
category: 'sign_error'
affected_page: '/example/canonical-page/'
reported: '2026-08-19'
first_published: null
corrected: null
reporter: 'pending consent'
reviewer: null
repository_link: null

This is a schema example, not an active erratum. Public ledgers must never use invented examples in a way that could be mistaken for real corrections.

Status lifecycle

Status reports what has happened, not how confident an individual contributor feels.

Status	Meaning	Reader-facing action
reported	A specific, reproducible concern has been received	Preserve the report and acknowledge receipt
triaged	Scope, category, impact, and owners have been assigned	Add an interim warning if reader harm is plausible
confirmed	Evidence establishes that published content is defective	Display a warning on the affected page until fixed
fix_in_progress	A correction and downstream audit are under review	Keep the warning visible
fixed	The corrected page is deployed and verification has passed	Link the page to its permanent erratum
closed_no_change	Review found no defect or no warranted content change	Publish the reason when the original concern was public
superseded	A later record subsumes this issue	Link both records and retain the earlier identifier

A report should not jump directly from reported to fixed merely because the textual edit is small. Diagnosis, independent verification, and downstream review are distinct actions.

Impact levels

Use the four impact levels below. Category describes what went wrong; impact describes what the error could do.

Impact	Criterion	Examples
Critical	Could create an immediate safety, security, or severe research-integrity risk	Malicious download, dangerous experimental instruction, fabricated source, or systematic corruption of many results
High	Changes a central conclusion, derivation, spectrum, theorem, or computational result	Wrong sign in a Hamiltonian, false theorem, missing degeneracy, or incorrect algorithm
Medium	Misleads locally but leaves the main conclusions recoverable	Omitted hypothesis, inconsistent convention, wrong table unit, or misleading interpretation
Low	Causes limited confusion without changing substantive conclusions	Local notation ambiguity, mislabeled link, minor metadata defect, or isolated typo in prose

Impact may rise during investigation. A low-seeming sign typo becomes high impact if it propagated into a spectrum, figure, notebook, or later derivation. Conversely, a conspicuous typo can remain low impact if the surrounding derivation and result are unambiguous.

Error categories

Use one primary category and as many cross-references as necessary.

Category	Use when
minor_typo	A textual defect does not change technical meaning
notation_clarity	Symbols, indices, domains, or conventions are ambiguous or inconsistent
citation_issue	Attribution, bibliographic metadata, quotation, or source scope is wrong
formula_error	A mathematical expression is wrong and no narrower category dominates
sign_error	One or more signs are incorrect
factor_error	A numerical, dimensional, Fourier, or normalization factor is missing or wrong
conceptual_error	The physical or mathematical claim is false, materially incomplete, or overgeneralized
numerical_error	A computed value, fit, plot, or numerical conclusion is wrong
broken_notebook	Declared code, data, or environment does not reproduce the published output
stale_reference	A source or status claim is no longer current enough for its stated purpose
broken_link	A required route, anchor, download, or external source is unavailable or incorrect
accessibility_issue	Content is materially inaccessible through supported reading or input modes

Do not use minor_typo as a default for errors found in equations. A typo in mathematics can be high impact even when it is only one character long.

Correction workflow

1. Capture the report. Preserve the reporter’s exact page, location, observed problem, and supporting evidence.
2. Stabilize the page. For plausible critical or high-impact issues, add a visible warning or temporarily withdraw the affected artifact.
3. Reproduce the issue. Confirm the published state from the deployed page, generated artifact, or tagged source revision.
4. Classify it. Assign a primary category, provisional impact, affected content types, and an owner.
5. Diagnose the cause. Distinguish source-text defects from rendering, generation, dependency, environment, data, and routing failures.
6. Construct the correction. Repair the canonical home and avoid creating a parallel derivation solely to work around it.
7. Verify independently. A reviewer other than the author checks the corrected claim with an appropriate method.
8. Audit propagation. Search dependent formulas, examples, figures, tables, notebooks, translations, and cross-links.
9. Publish atomically. Deploy the corrected content, permanent ledger record, and necessary redirects or warnings together.
10. Close with evidence. Record dates, reviewer, checks, repository links, and any residual uncertainty.

If a full repair takes time, publish the diagnosis and interim warning first. Silence is not a neutral state once a consequential error has been confirmed.

Verification by error type

Build success is necessary for most corrections, but it is rarely sufficient.

Error type	Minimum technical check	Independent check
Formula, sign, or factor	Re-derive from stated assumptions; check dimensions and limits	Separate derivation or trusted primary/reference source
Conceptual claim	Identify precise hypotheses and counterexamples	Subject-matter review
Numerical result	Rerun from source data and fixed environment	Independent implementation, benchmark, or analytic limit
Table entry	Regenerate or trace to authoritative source	Spot-check neighboring entries and conventions
Notebook	Execute from a clean environment with pinned inputs	Compare hashes, tolerances, and rendered outputs
Citation	Inspect the cited work itself	Confirm metadata and that the source supports the exact claim
Redirect	Test old URL, final URL, anchors, and canonical metadata	Crawl inbound internal links
Accessibility	Inspect semantic structure and keyboard/screen-reader behavior	Test representative rendered pages

For equations, useful checks include:

• physical dimensions and units;
• Hermiticity, symmetry, and covariance properties;
• limiting cases and known special solutions;
• normalization and completeness;
• basis and Fourier-transform conventions;
• boundary terms, domains, and regularity assumptions;
• numerical evaluation at a nontrivial test point.

Agreement with a familiar-looking formula is not enough when conventions differ. The correction record must state which convention was used.

Immediate-action issues

Some reports warrant action before ordinary triage is complete:

• instructions that could damage equipment or endanger a person;
• malicious or compromised downloads;
• fabricated data, sources, quotations, or authorship;
• a central formula known to contaminate many downstream pages;
• accidental disclosure of private reporter information;
• a notebook or artifact that silently produces materially false results.

For these cases, preserve evidence, restrict or warn the affected content, and notify the responsible maintainers. The eventual public record should explain the correction without exposing private data or publishing an exploit recipe.

Version policy by content type

The site’s frontmatter review date is not a semantic version number. It says when a page was last reviewed against its current scope. More specific artifacts need more specific provenance.

Content type	Version when	Provenance to preserve
Formula or derivation	A substantive correction changes a sign, factor, hypothesis, domain, or result	Prior expression, corrected expression, derivation check, and downstream audit
Table	Entries, conventions, units, or generation inputs change	Generator/source version, generation date, and changed rows
Notebook	Code, data, environment, or expected outputs change	Repository commit, dependency lock, data identifiers, random seeds, and tolerance policy
Figure	Data, code, labels, normalization, or physical interpretation changes	Source asset, generator revision, and regenerated output
Glossary	A definition or scope changes substantively	Previous wording and affected cross-references; do not version copyedits
Bibliography	Attribution, metadata, or a material annotation changes	Source inspected, corrected metadata, and reason the annotation changed
Redirect	A canonical URL moves	Old URL, destination, deployment date, and permanence
Deprecated page	Content is superseded or unsafe to maintain as canonical	Visible warning, replacement page, and permanent redirect when possible

Formula and table corrections should carry durable identifiers even if the current page only displays the repaired form. A reader comparing a printout or saved notebook with the live site needs a stable way to reconcile them.

Erratum, changelog, or repository history?

These records answer different questions.

Record	Question answered	Typical audience
Erratum	What published claim or artifact was wrong, and what is correct now?	Readers relying on technical content
Changelog	What material capabilities, chapters, or policies changed in a release?	Returning readers and maintainers
Repository history	What exact source lines changed, by whom, and in which commit?	Contributors and auditors

A major correction usually belongs in all three, with each record linking to the others. A prose copyedit usually belongs only in repository history. A new chapter belongs in the changelog and repository history but is not an erratum.

Reporting guidance

The error-reporting guidance in About explains how to submit a correction. A useful report includes:

• the canonical page URL and nearest section heading;
• the exact equation, sentence, table row, figure, or notebook cell;
• the observed defect and the reporter’s proposed interpretation;
• a derivation, counterexample, source, screenshot, log, or minimal reproduction when available;
• the browser, operating system, dependency environment, or assistive technology when rendering or reproducibility is involved;
• whether the issue appears to affect downstream results.

Reporters need not know the final impact or category. Those are triage decisions. A short, precise counterexample is more useful than a confident severity label.

Privacy preferences should be respected. Public credit is opt-in; anonymous or private reports receive the same technical review. Corrections should never be delayed because attribution details are unresolved.

Current public state

No confirmed erratum is listed directly on this overview at the present review date. Active and historical records belong in the specialized ledgers above. This statement does not claim that every draft page has completed expert review or that no unknown errors remain. Page-level status labels communicate the review state separately.

Common mistakes

Silently fixing the current page

Readers with cached pages, notes, citations, or downloaded notebooks cannot tell whether the discrepancy is theirs. Substantive corrections need a stable record.

Treating every edit as an erratum

Flooding the ledger with ordinary copyedits obscures changes that affect technical trust. Preserve all edits in version control; reserve errata for reader-relevant defects.

Classifying by effort

A one-character sign correction can be high impact. A large rewrite can merely improve exposition. Classify by consequence, not patch size.

Checking only the reported line

Definitions and conventions propagate. Search citations, backlinks, generated artifacts, related examples, and notebooks before closing the issue.

Citing authority instead of verifying conventions

Two correct references may use opposite metric signatures, Fourier normalizations, phase conventions, or unit systems. State and translate the convention.

Using the review date as proof of correctness

A review date records a process event. It does not guarantee that an unknown error is absent, and it does not replace an erratum after an error is found.

Exercises

Exercise 1: a missing Fourier factor

A page defines

$$\widetilde{\psi}(p) = \frac{1}{\sqrt{2\pi\hbar}} \int_{-\infty}^{\infty} e^{-ipx/\hbar}\psi(x)\,dx,$$

but later writes the inverse transform without the factor $1/\sqrt{2\pi\hbar}$. The final Gaussian wave packet is then incorrectly normalized. Propose the primary category, impact, minimum verification, and downstream audit.

Solution

The primary category is factor_error. A secondary formula_error label may aid discovery, but it is less specific. The impact is at least high because the missing factor changes the final normalization and therefore any probability computed from it. It could become critical only if the page were tied to a safety-sensitive or severe research-integrity consequence.

Verification should derive the inverse transform from the declared symmetric Fourier convention and check both Parseval normalization and a test Gaussian. The audit should search the canonical Fourier-transform reference, every page that reuses this convention, momentum-space examples, tables of transforms, figures, and executable notebooks. The corrected page and permanent formula ledger entry should deploy together.

Exercise 2: a source that became stale

A literature guide accurately stated in 2024 that no experimental result had tested a particular parameter regime. A reliable 2026 paper now reports such a test. Is the old statement an erratum, a routine update, or both?

Solution

First inspect the wording and date context. If the page explicitly said “as of 2024” and cited a review that supported the statement, the historical claim was not false when published. Updating the guide is normal maintenance, with a changelog entry if the annotation materially changes.

If the page presented the absence of tests as a timeless fact, or if its last_reviewed metadata implied a 2026 review after the new result was available, classify the problem as stale_reference. A public citation-correction record is warranted when readers could reasonably rely on the outdated claim. The correction should cite the new primary paper, narrow the historical statement, and audit any page that inferred theoretical or phenomenological conclusions from the claimed absence.

Canonical links

• Report an error explains how readers should submit a correction.
• Review freshness explains what a review date records.
• Page status labels describe editorial maturity separately from knowledge status.
• Scientific standards state the expectations for reasoning, checks, and supporting sources.
• Corrections explains how material errors should be addressed.
• Tables, Formula Compendium, and Bibliography are the canonical homes audited by their corresponding correction ledgers.

References

1. Committee on Publication Ethics, Core Practices, especially the guidance on post-publication corrections and integrity of the scholarly record.
2. The Turing Way Community, The Turing Way, a handbook for reproducible, ethical, and collaborative data science.
3. National Academies of Sciences, Engineering, and Medicine, Fostering Integrity in Research, National Academies Press (2017).