A browser-only tool is an architecture, not a slogan

This blog has already covered how a browser-only tool can still owe Part 11 a record, and what a device classification tool actually has to check to earn a user's trust in its answer. Neither essay stopped on a question worth asking on its own: what “browser-only” is actually promising in the first place. Almost every tool on the web renders in a browser. That's not the claim worth making. The claim worth making is about where the data goes once it's typed in — and that claim is either true in a way a visitor can check for themselves, or it isn't a real claim at all.

Rendering client-side and computing client-side aren't the same fact

A page built entirely in JavaScript still runs in the visitor's browser even when every answer they type gets sent to a server the moment they type it, scored there, and the result sent back to display. That's the common shape of a lead-generation tool: the questionnaire feels interactive and local, but the actual logic — the classification rule, the scoring model — lives on a server the visitor never sees, and the round trip is invisible unless someone goes looking for it. Calling that tool “browser-only” because the form fields render in a browser describes the UI, not where the thinking happens. The distinction that actually matters to a visitor is whether the logic and the data stay on their machine, not whether the buttons do.

What the constraint actually rules out

Built to the stricter version of that claim, a tool's decision logic — the branching questions a device-classification checklist walks through, the rule set a scoring tool applies — ships as code that runs entirely in the visitor's own browser, with no request fired to any server carrying the answers typed in. No email gate sits between a question answered and a result shown, because the result was never computed anywhere that needed to know who was asking first. That's a narrower promise than “free” or “no signup,” and it's the one that actually matters to a compliance officer weighing whether to type in a product description that hasn't been announced yet.

A static site makes the promise checkable, not just stated

This property ships as a static site with no backend beyond file hosting, which means the claim isn't something a visitor has to take on faith from a privacy policy. Opening a browser's own network panel while using an interactive tool here and watching what fires — or not — while a form gets filled in is a check anyone can run themselves, not a sentence they have to trust. That's a meaningfully different kind of promise than most privacy policies make, because most of them describe intent about data a vendor already collected, where a browser-only architecture is a claim about a request that was never sent in the first place, checkable directly rather than asserted.

Why the inputs here carry more weight than a typical web form

A device classification questionnaire or a risk-scoring worksheet asks for the kind of detail a regulatory or quality team has real reason to keep close: an indication for use months before a filing is public, a technology description for a product that hasn't been announced, an internal risk rating nobody outside the project has seen yet. A marketing tool that trades a classification answer for an email address has asked for more than the question needed, and routed the actual substance of the answer — not just a name and inbox — through a server built to capture leads, not to keep anything confidential. A tool built around this shelf's own beat has no reason to make that trade, because nothing about a correct classification answer requires knowing who asked.

Where this meets the file

The interactive tools previewed under the launch catalog's own tools section are built to this constraint on purpose: the logic runs client-side, nothing typed into a questionnaire is transmitted anywhere, and no result sits behind an email gate. That's a design rule this shelf holds itself to, not a claim asked to be taken on faith — and if a future tool here ever needs a server round trip for a real reason, that's a change worth disclosing plainly rather than assuming nobody will check. If you've found a gap between that promise and how a tool here actually behaves, the shelf takes that correction directly.