Compliance
Errata and change bars: the document's memory
A living document accumulates a dated ledger of its own corrections, and reading it is how a reader learns the text changed under them.
What a change bar marks
A change bar is the thin vertical line in the margin of a revised document that says this paragraph is not the paragraph you read last time. Errata are the published list of what a document or a device got wrong. Together they are the memory of a specification, and reading them is how a reader finds out that the text changed under them.
Every living document accumulates them. A specification published, implemented and revised develops two parallel texts: the normative body and the record of its own corrections. The change bar marks where the current text diverges from the previous edition; the errata sheet lists where the text itself was wrong. A reader who reads only the clean text is reading the specification as it now claims to be, not as it was when the hardware on the bench was designed.
The habit of keeping a dated ledger of what changed and when is shared by every discipline that depends on provenance. The discography desk that keeps a session-by-session ledger for a small jazz label does the same work on recordings: which take shipped, which credit was corrected, which date was wrong in the first pressing. A specification's errata are its sessionography, the dated admission of what the first release contained.
How does a specification admit a mistake?
Through a correction that is itself a document. The mechanism has several names: errata for errors in the published text, engineering change notices for normative changes folded into the next revision, change bars marking where the folded changes landed. The important property is that the correction is dated and attributed: a spec that cannot say when a sentence changed cannot be read against the hardware built before the change.
This desk keeps a worked example in the document 300312-001 page: an Intel datasheet address that served for years and then stopped resolving, whose successor content had to be reconstructed from what cited it. That is errata work from the outside: when the publisher's own ledger is unreachable, the reader rebuilds the history from the documents that pointed at it.
Why do the corrections matter more than the text?
Because the text you hold is the answer after the corrections. A figure that moved between revisions carries its history only in the change record; the clean page shows the destination, not the path. For the reader implementing against a document, the path is the information: a moved figure means old silicon was qualified to the old number, a clarified sentence means implementations disagreed about the old one, and a deleted requirement means someone shipped the thing the requirement forbade.
| Record | What it marks | What it answers |
|---|---|---|
| Change bar | Where this edition differs from the last | What to re-read |
| Errata sheet | Known errors in the published text | What not to implement as written |
| ECN or change notice | Normative change between editions | What the next edition will say |
| Revision history | The dated list of admitted changes | When each change entered the text |
What does a missing record mean?
Not that nothing changed. A document without a visible revision history may still have been reissued silently, and the only proof is the diff between two dated copies. The datasheet reader's habit, described on the page about reading an old datasheet, applies at the specification scale too: hold two versions, compare them paragraph by paragraph, and treat every unexplained difference as a change the publisher chose not to annotate.
The engineering process that generates these records is summarized in the engineering change order article, read on September 6, 2026. Behind every erratum is a found defect, a disposition decision and a release; the errata sheet is the only part of that chain the reader ever sees.
Checks for reading corrections
- Read the revision history before the body: it tells you which text is new.
- Look for errata under the document number and under the product, separately.
- Diff two dated copies when no change record exists; silence is not stability.
- Map each change to the hardware qualified under the old text before assuming compliance.
Common mistakes
- Implementing from a document without checking its errata sheet.
- Reading a change bar as trivia rather than as the diff the publisher admits to.
- Assuming a silent reissue means no change; prove it with a diff.
- Quoting a superseded figure because the document that carried it still resolves.
The clean text is the claim and the corrections are the record, and a reader who holds only the claim holds half the document. The margin marks and the dated admissions are where the specification confesses, and confession is the part worth reading first.
Errata and change bars mark where a specification text moved between revisions, and they are read against the revision notes that date each edit. A compliance run is a different kind of record: it captures what a specific device did at a specific time, on a specific link, under a specific test suite. The two are often confused when a failure is traced back to a clause that changed. For readers who need to follow that trail further, the newer page on the evidence a run leaves sets out how a run is logged, what the log retains, and how it is read alongside the errata that prompted the test.
The page behind these facts
The change-order machinery behind errata and revisions is described in the engineering change order article linked above, read on September 6, 2026. The desk's worked example of reconstructing a vanished document is the page on document 300312-001, and the related reading of dated datasheet revisions is on the page about old datasheets, both linked inline.