> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://tieback.io/docs/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server. # Lesson 4: Why a Published Record Should Not Change > Academy Foundations Module 4 Lesson 4: what snapshot immutability means in plain terms, and why corrections belong in a new version rather than a silent edit. **Module 4, Lesson 4 of 4. About 8 minutes.** ## Orientation A passport is trusted or it is worthless, and trust depends on a property that sounds almost too simple to teach: what a market surveillance authority read last year has to still be provable as what was published last year, even after this year's data has moved on. This lesson is about that property, and about why the natural instinct, to just fix a wrong value in place, quietly destroys it. Because the record must remain reachable and accurate for a defined period after the sale, and because events after sale, such as repairs, need to be added to it. Treating publication as the finish line leaves that whole obligation unbudgeted. ## Learning Objectives ## A Record of What Was True, Not What Is True Now A passport, at the moment it is published, states what was true about a product when it was placed on the market. That statement is read by other parties, and some of those parties act on it, keep their own copy of it, or rely on it later as evidence. If the underlying figures are silently altered after the fact, every one of those readers is left holding a version of the truth that no longer matches what the economic operator now says. Nobody can tell, from the outside, whether today's figure is a correction of an error or a change in what happened to be convenient to say. The alternative is straightforward once stated: when something needs to change, publish a new version rather than editing the old one in place. The earlier version stays intact, dated, and attributable to the moment it was published. The new version is dated too, and anyone comparing the two can see exactly what changed and when. This property, that a published snapshot is not overwritten but superseded, is what is meant by immutability in this context. It is a discipline about how corrections are made, not a claim that data never changes. **The common misreading** is to hear "immutable" and assume a passport can never be updated, which would contradict everything Lesson 3 established about repairs and lifecycle events needing to be added. The two ideas sit together without tension: new information is added, and existing published statements are superseded rather than rewritten. What must not happen is a wrong figure quietly becoming a different figure with no trace that a change occurred. The value this produces is an auditable history: a sequence of dated statements that can be laid out in order, so that a dispute about what was published on a given date can be settled by looking, not by trusting someone's memory of it. That history is also what protects the organisation itself. A manufacturer who genuinely made an honest correction has a defensible record of exactly that, instead of an erased trail that looks, to an outside investigator, indistinguishable from concealment. None of this depends on any particular platform or storage technology, and this lesson does not describe one. The requirement is conceptual: whatever system serves a passport, it has to preserve what was published, when, and let it be distinguished from what supersedes it. How any given vendor achieves that is an implementation detail well outside what a Foundations learner needs to evaluate, and outside the scope of this lesson. #### [How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work) Read how information changes through the lifecycle, then the data validation section, which explains why correcting a claim before publication is preferable to correcting it after, and what provenance is expected to record. #### Correcting the Aurelia S2's declared battery capacity Six months after launch, an internal audit finds that the published battery capacity for the S2 is slightly overstated, traced back to a supplier figure that was never independently checked. The wrong response is to log into the system serving the passport and change the number, so that the record now simply reads correctly with no trace that anything was ever different. Anyone who read the original figure, including a regulator who may have already queried it, has no way to know a change happened at all. The right response is to publish a new version of the record with the corrected figure, dated from the correction, while the original version remains retrievable and clearly marked as superseded. Anyone comparing the two can see what changed, when, and can trace the correction to the audit that found it. The product is not made retroactively different by the correction; the record is made honest about when the organisation knew what. #### Find your own silent-edit habit Think of one piece of product information your organisation currently corrects by simply overwriting it: a specification sheet, a web page, a spreadsheet. Ask whether anyone downstream who already read the old value would ever know it changed. If the honest answer is no, you have found a habit that a passport cannot inherit. ## Knowledge Check ## Takeaways * A published record states what was true when the product was placed on the market. * Corrections are made by publishing a new version, not by editing the old one silently. * Immutability describes how corrections are made, not a ban on adding new lifecycle information. * An auditable history distinguishes an honest correction from an unexplained, unverifiable change. **If you remember one thing:** if a fix cannot be told apart from a cover-up from the outside, it was made the wrong way. ## Sources [How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work), sections How Information Changes Through the Lifecycle and Stage 3: Data Validation. ## Related Docs * [Module 4 assessment](/docs/academy/foundations/module-4/assessment) * [Lesson 3: Life After the Sale](/docs/academy/foundations/module-4/lesson-3) * [Module 4 overview](/docs/academy/foundations/module-4) * [How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work)