Saved in the browser is not the same as retrievable

Retrievable is the word the rule uses

FDA's Quality Management System Regulation, now in force, replaced the old recordkeeping text at 21 CFR 820.180 with a new provision, 820.35, that folds in ISO 13485:2016's own Clause 4.2.5 by reference rather than restating it. The duty that clause sets for a controlled record is specific: it has to stay legible, readily identifiable, and retrievable. That third word is doing real work. A record that exists, and that the right person could technically find eventually, hasn't cleared the bar — retrievable means the record comes back on demand, not after a search.

Persistence during use is a different promise

Keeping a visitor's half-finished answers in the browser between visits, the way this blog's own earlier post on the subject describes, solves a real problem: nobody should have to redo a twenty-field classification worksheet because they closed the tab. But that promise is scoped to one browser, on one device, under one profile. It says nothing about whether the finished record — the worksheet once it's actually complete — can be handed to an auditor, filed into a document-control system, or opened by a colleague who never touched the tool. Those are retrieval questions, and local storage was never built to answer them.

A record tied to one browser profile isn't retrievable

Clear a browser's site data, switch devices, or hand the laptop back to IT, and anything living only in that profile's storage is gone with it — not archived, not backed up, just gone. A record in that state fails “retrievable” the moment the one copy stops being reachable, and it fails it quietly, because nothing about the tool ever announced that the browser itself was the only place the record lived. A tool that wants its output to count as a QMS record has to get that output out of the browser's own storage and into something the user actually holds.

What export has to produce, and what it doesn't have to be

Neither 820.35 nor ISO 13485 names a required file format for a retrievable record. What they name are the properties the output has to keep once it leaves: legible on its own, without the tool's interface around it; identifiable as the specific record it is, not an anonymous download; and retrievable by whoever's own system takes custody of it next. A plain exported file the user names, dates, and files themselves clears that bar. A session that only ever existed as on-screen state, with no equivalent artifact the user can point to later, doesn't — no matter how faithfully it remembered the user's answers while the tab stayed open.

Identifiable means the record has to say what it is

An exported file sitting in a downloads folder named export.pdf or untitled.json has cleared “retrievable” and still failed “readily identifiable” — nothing in the file itself says which device it's about, which version of the worksheet produced it, or when. A tool's export has an easy fix available that a paper form never did: carry the device name, the date, and the tool's own version into the file's visible content, not just its filename, so the record still identifies itself after the filename gets changed or the file gets moved.

Where this meets the build

The interactive tools previewed under the launch catalog's tools section are built to produce a real exported artifact as their actual output, not a screen a visitor has to remember to screenshot before closing the tab. If one of them ever stops at on-screen state instead of a file you can keep, the shelf takes that correction directly.