The Workbench · The Shelf
A browser tool's output still has to leave the tab
This blog has already covered why a record that only lives in one browser's own storage fails the retrievable test 820.35 sets, and why remembering a visitor's in-progress answers between visits is a separate design choice from never sending them anywhere. Both essays treated the browser as the record's home, for better or worse. There's a third question neither one asked: once the worksheet is actually finished, does anything leave the tab at all?
A finished worksheet is still just on-screen state
A completed classification result, a filled risk matrix, a checklist with every row answered — all of it can sit correct, complete, and perfectly rendered on screen without ever becoming a file the visitor actually holds. Closing the tab at that point loses the result exactly as thoroughly as losing unsaved mid-session work does, just one step later in the process, and after the part most people assume is already safe.
A screenshot is a weaker artifact than it looks
When a tool offers no real export, a screenshot becomes the default way people capture a result, because it's the one option every browser already provides. A screenshot carries none of the structure a reviewer, a technical file, or a tracker actually needs from that result: no underlying values a script could re-import, no version stamp saying which edition of the tool produced it, nothing searchable, nothing that still works once it's been resized or cropped into a slide. It looks like a record. It behaves like a photograph of one.
Different handoffs want different files
Print exists for the binder and the wet signature. A generated PDF exists for the email attachment and the audit folder. A CSV or JSON export exists for the tracker the result actually has to land in next. A tool doesn't have to build all three; it has to decide which handoff its own output is actually headed toward, and build for that one deliberately — rather than leaving the rendered page as the only place the result exists and letting the visitor improvise a capture method on their own.
Technical documentation has to exist as a file, not a session
EU MDR Article 10(8) requires a manufacturer to keep its technical documentation available for competent authorities, and to provide that documentation, in whole or in summary, on request. Nothing in that duty contemplates a reviewer logging into someone's interactive tool to reproduce a session; it expects a document that already exists, ready to hand over. Output that only ever lived as live, on-screen state — something the manufacturer would have to recreate from scratch to produce — never clears that bar in the first place, whatever the tool calculated correctly while it was open.
Export can stay as honest as the tool that built it
The same architecture that keeps a browser-only tool from ever sending a visitor's answers to a server can generate that visitor's export client-side too — building the PDF or the CSV inside the browser itself and handing it straight to a download, with no round trip to undo the privacy promise the tool made at the outset. Print is the simplest version of this, and it costs a build nothing extra to ship on day one. A generated, self-describing file is the version worth building next.
Where this meets the build
The interactive tools previewed under the launch catalog's tools section are built to hand back a real exported file as their actual output, not a rendered page a visitor has to remember to capture before closing the tab. If one of them ever stops at on-screen state instead, the shelf takes that correction directly.
The Regulatory Toolkit launches soon — a free shelf of source-mapped templates, checklists and browser-only tools for regulatory teams. Get one email when it opens, or contribute a template.