Objects of Affection Collection
Corrections issued against a published version of the Lacuna specification
A corrigendum corrects something in a published version of the specification that does not change what a conforming implementation has to do: a citation, a date, a figure, a quotation, a cross-reference, prose that misstated a requirement without changing the requirement, prior art credited in section 11, or an addition to section 13, which records what the specification has not specified and therefore obliges nobody.
A change that does alter what an implementation must do is not a corrigendum. It is a new version, and it is issued as one however small it is and however much it reads like a correction.
No corrigendum has been issued against any version of the Lacuna specification, as of 8 November 2026.
That sentence is written out rather than left as an empty list, because an empty list cannot be distinguished from a list nobody has maintained. It is a statement about this register on a date and not a claim that the specification contains no errors. Eleven are corrected in version 0.9 and declared in its own changelog, and they were corrected in the body of a new version rather than issued here, and this register was not yet in use.
Entries appear here in reverse order of issue, newest first, and are never removed. A corrigendum that is itself wrong is corrected by a further corrigendum that says so.
It does not edit the deposited version. Neither deposited file is changed, ever. The text you download under a version's DOI in five years is the text that was deposited under it, including any error a corrigendum here corrects.
And it is not merged into how the specification is served. The specification page renders the deposited text unchanged and links here. A page that quietly served the corrected text would mean two different documents answering to one identifier, which is a defect this institution has already published against itself: the version 0.8 deposit carried a markdown file and a rendered file that were not two renderings of one text, and a reader citing that version got a different document depending which file they opened.
This is the specification's own rule in section 14.1, applied to the specification: a correction is appended, never applied in place.
When a new version is issued, every outstanding corrigendum is applied in the body of that version and listed in its changelog. The entry stays here, closed, with a note naming the version that absorbed it. Nothing is lost and nothing is applied twice.
Versions are issued no less than thirty days apart, so a correction found the day after a release does not wait for the next one. It is issued here instead, on the day it is found. The single exception runs the other way: a requirement stated wrongly in a way that makes a conforming implementation wrong is not a corrigendum at all, and it is issued at once as a version that says so.
Versions 0.8, 0.9 and 0.10 of the specification were issued within ten days and only the first changed anything a conforming implementation had to do. A version number that moves because a citation was corrected tells a reader the document is unstable when it is not, and an implementer cannot tell from the number which changes oblige them.
So the number now moves when the reader's work does, and corrections come here. This is the release policy for the specification, adopted 8 November 2026, and it is stated in the specification itself from the version that adopts it.