14 — The user assessment
Summary
Specifies the workflow now live at /assess, where a visitor assembles their own installations as grant trees and mandates and sees what is reachable that they never intended. Two findings shaped every decision, and both cut against the obvious build. A completed assessment is, assembled, a plan for attacking the visitor — so the site stores their choices and never their answers, implemented as strictly as it can be: there is no free-text input anywhere on the page. And the objective is behaviour change, which has a measured failure mode: a strong threat with a weak answer produces denial rather than change, so every case ends on something the visitor can actually do — and the hosted case, which has zero efficacy by construction, ends on a request rather than a pretend remedy.
Key concepts
- Store the choices, not the answers — C20 — references into a public library, and nothing typed
- A conformance test for our own claim — browser storage makes the privacy claim architectural, and checkable in ten seconds
- Zero efficacy by construction — the hosted page is the one most likely to alarm and least able to do anything with the alarm
- The acceptor is a role, not a name — so this page cannot meet the pack's own named-acceptor standard — recorded, not hidden
Key ideas
- A general page may withhold the answer; a personalised one may not — the discriminator is whether the message is about the world or about the reader.
- Every excess path on a local tree bottoms out at the same node, so the page says it once: this is one problem rather than eleven.
- No score out of a hundred: a score gets optimised for how alarming it feels.
- The measure set is stated and the page cannot instrument any of it, because it deliberately has no backend.