# The User Section Is A Conformance Test For The Site's Own Claim: Store The Choices Rather Than The Answers Because The Pack Is A Map Of The Visitor's Own Weaknesses, And A High Threat With No Efficacy Produces Denial Rather Than Change

**version** v0.33.61
**date** 20 August 2026
**from** Human (project lead)
**to** The pki.sgit.ai site agent, Engineering, Product, Ambassador

**type** Dev brief

*Thirteenth of 20 August. The behaviour-change objective is grounded in a meta-analysis rather than in intuition, and that grounding contradicts an editorial decision made earlier today for a different page, which is recorded here rather than resolved silently because both decisions are right for their own document. The browser storage properties are stated as they are, and the local-folder case is the one already established in this corpus as broken. Limitation: no page exists yet, so this specifies rather than reviews, and the efficacy actions proposed for the hosted case are the ones this corpus named today rather than a surveyed set.*

---

## What This Is

The user area the memo asks for, the one thing that must not be stored in it, and the documented reason its stated objective can backfire: **the memo wants a section on the registry site where a visitor chooses their agents, their environment, their evidence and their mandate, assembles an evidence pack, and has risks derived from it, held in browser storage now and in a vault later, with the explicit purpose of making people aware that the agents they run hold far more privilege than they realise and moving them to safer practice; the first thing to notice is what the visitor is being asked to assemble, because a completed pack is a description of which agents run where, holding which credentials, with which containment, on that person's own estate, which is in aggregate a serviceable plan for attacking them, so the design rule is that the site stores the visitor's choices rather than their answers, meaning references into a public library of pre-computed trees rather than any free text or scan output describing their machine, which preserves the entire demonstration and leaves nothing worth stealing behind; browser storage is then not a compromise forced by not having built the vault yet but a demonstration of the site's own thesis, because a visitor can open the network panel and observe that nothing leaves, which makes the privacy claim architectural rather than operational in exactly the sense this corpus distinguished on 6 August, and the later migration to a vault preserves that property since the vault is encrypted client-side, changing durability and adding an unrecoverable key rather than changing who can read it; the objective, however, is behaviour change, and behaviour change through threat has a documented failure mode, since the standing meta-analysis finds that strong fear appeals combined with low-efficacy messages produce the greatest defensive responses, meaning denial, avoidance and reactance, while strong threat combined with an equally strong efficacy message produces the greatest behaviour change, so a page that shows somebody a frightening picture of their own estate and offers nothing that works will underperform a page that says nothing at all; that finding contradicts an editorial decision taken earlier today for the concept explainer, where every remedy was deliberately removed, and both decisions are correct because they apply to different documents, since a general explainer is a low-threat message where withholding the answer creates appetite while a personalised assessment is a high-threat message where withholding it creates denial; and the hardest case is the hosted one, because the honest answer there is that nothing the visitor can do will change the containment, which is zero efficacy by construction, so that page needs an action that is not a remedy but a request, and this corpus named the specific one today, being a vendor endpoint that signs an existing audit record for a named relying party.** It is the thirteenth document of 20 August (cross-ref: the v0.33.61 end-to-end flow brief, the v0.33.61 register interface brief, the v0.33.61 analogies brief, the v0.33.59 publishing matrix brief, and the v0.33.56 token gateway brief). New contributions: **the pack identified as an attack plan and the choices-not-answers rule that follows, browser storage reframed as a conformance test, the migration's effect isolated to durability, the fear-appeal finding applied and its contradiction with today's explainer decision recorded, the hosted case identified as structurally zero-efficacy, and a measurement set that is not alarm.**

## What The Visitor Is Actually Building, In Today's Vocabulary

The memo lists four things to choose. The project lead: **"the grant, the evidence, the environment, the mandate, and basically answer those questions."**

Each already has a definition from earlier today, which means the interface has a specification rather than needing one:

| The memo's word | Settled today as | Where it comes from |
|---|---|---|
| **Environment** | The surface: your own machine, or a vendor's | The two populations, which have different shapes rather than different contents |
| **Grant** | A tree of subgrants, each node labelled boundary, setting or expectation, each dated | Pre-computed per agent and surface, from the library |
| **Evidence** | The label on each node, and its date | Tested, documented, or asserted |
| **Mandate** | An allow-list, stored, and presented as prohibitions | The person accepts the prohibitions; the system keeps the allow-list |

And the output is not a report. **It is a set of risks, each of which can carry a named acceptor and an interval**, which is the test settled on 28 July and the thing the risk product consumes. A pack that produces prose has produced nothing.

## Store The Choices, Not The Answers

The finding that should decide the storage design, and it is not obvious because the danger arrives from the direction of helpfulness.

**A completed pack describes which agents the visitor runs, on which machine, holding which credentials, with which containment, and which of those containments is only a setting.** Individually those are unremarkable facts. Assembled, dated and ranked, they are a serviceable plan for attacking that person, and the site asked them to write it down.

Browser storage makes that worse in one specific way: **anything stored is readable by any script running on that origin.** This site assembles its pages client-side from vault content, which is the working hypothesis for why it is hard to index, and client-side assembly is a script-execution surface. So the threat model is not exotic.

The rule that removes the problem without removing the product:

> **Store references, never descriptions.** The visitor picks entries from a public library of pre-computed trees. What is kept is a list of identifiers and a mandate selection. Nothing stored says anything about that person's machine that the library did not already say publicly about everybody's.

| Stored | Not stored |
|---|---|
| Library entry identifiers for the agents chosen | Any path, hostname, account name or project name |
| The surface chosen, from a fixed set | Free text describing the setup |
| Mandate selections, from the prohibition list | Anything typed by the visitor |
| Acceptance decisions, with an interval | **Any output of a scan of the visitor's own machine** |

The last row is the one to hold the line on, because a scan is the obvious next feature and it is the point at which the stored pack stops being a set of pointers and becomes an inventory. **If a scan is ever added, its output belongs in the visitor's own vault and never in browser storage**, and that is a reason to build the vault path before the scan rather than after.

There is a pleasant consequence. Because the stored artefact is only references into public material, **losing it costs the visitor almost nothing**, which is exactly the property the memo wants for a demonstration and which no amount of warning copy could otherwise deliver.

## Browser Storage Is A Demonstration Of The Thesis, Not A Compromise On It

The memo frames local storage as the starting point before the real thing. The project lead: **"this needs to be sort of stored for now on a kind of local storage kind of environment."**

**It is better than that.** On 6 August this corpus distinguished a privacy claim that is architectural, meaning we cannot see it because it never comes to us, from one that is operational, meaning we do not retain it. The first is a property, the second is a promise.

A user section that keeps everything in the browser on a statically hosted site makes the claim architectural, **and it makes it checkable by the visitor in about ten seconds**: open the network panel, complete the assessment, observe that nothing is sent. There is no backend to send it to.

That is the same move as the static vault deployment of 16 August, which was built as a conformance test for the claim that the server reads nothing. **The user section is a conformance test for the claim that the site does not collect**, and the site should say so on the page rather than leaving it to be discovered, because a claim the reader can verify in ten seconds is worth more than any assurance and this site's whole positioning is built on that difference.

The properties to state plainly, in the honest-limitations register the site already uses:

| Property | Consequence for the visitor |
|---|---|
| Per browser, per device, per origin | It does not follow you to your phone |
| Cleared by clearing site data | And by a private window ending |
| No recovery of any kind | Say this, rather than implying durability |
| Readable by scripts on this origin | Which is why only references are stored |

**And one that must be tested rather than assumed.** The publishing work of 16 August established that a page opened from a local folder gets an opaque origin, which is why local browsing needs a served origin. Browser storage is keyed by origin, so **the user section will not work from a local folder copy of the site**, and if the site is ever distributed as a downloadable bundle, this feature is the one that breaks. That belongs in the test matrix rather than in a support conversation.

## The Migration To A Vault Changes Durability, Not Privacy

Worth isolating because the instinct is that moving to a vault is the moment the data becomes ours, and it is not.

| | Browser storage | The visitor's vault |
|---|---|---|
| Who can read it | The visitor, on that device | The visitor, anywhere |
| Can we read it | **No** | **No.** Encrypted client-side |
| Survives clearing site data | No | Yes |
| Follows the visitor to another device | No | Yes |
| Failure mode | Silent loss, costing little | **A key with no reset** |

So the privacy property survives the migration unchanged, which is unusual and worth saying, and what changes is that the visitor acquires something durable enough to lose badly. The corpus rule applies: a vault whose write key is lost is frozen rather than broken, and escrow is a precondition rather than a nicety. **For a demonstration artefact that is a poor trade**, which argues for keeping browser storage as the default even after the vault path exists, and offering the vault to people who have decided the pack is worth keeping.

## The Objective Is Behaviour Change, And It Has A Documented Failure Mode

The memo states the real goal twice and it is not awareness for its own sake. The project lead: **"we should be making users aware that their cruel agents, the use, have far too much privilege, have far too much access. It's far too much dangerous. So how do we drive that message so that they move to a more secure and safe use of agentic workflows?"**

**That is a fear appeal, and fear appeals have a measured failure mode rather than a suspected one.**

The standing meta-analysis on the subject finds that people respond to a threatening message along one of two paths. **Danger control** is the useful one: attitudes, intentions and behaviour move in line with the recommendation. **Fear control** is the other: defensive avoidance, denial and reactance, aimed at removing the fear rather than the danger. The determinant is efficacy, and the finding is blunt:

> **Strong fear appeals combined with low-efficacy messages produce the greatest levels of defensive response.** Strong fear appeals combined with high-efficacy messages produce the greatest behaviour change. The practical instruction is that a high-threat message must be accompanied by an equally high or greater efficacy message, or it backfires.

The defensive responses are negatively correlated with the useful ones, so this is not a case of a weaker effect. **A frightening page with no credible answer performs worse than a page that says nothing**, because it actively produces the counter-argument.

Two components of efficacy have to be present, and the second is the one this domain fails:

| Component | The question the visitor asks | The risk here |
|---|---|---|
| Response efficacy | Would the recommended action actually reduce this? | Answerable: the excess shrinks, and you can show it |
| **Self-efficacy** | **Could I actually do it?** | **This is where it fails, because the interface often does not offer the narrow option** |

That second row is a finding this corpus made from the other direction earlier today: the broad grant is usually the only grant the tool knows how to issue. **So the tool must not recommend actions the visitor cannot perform**, because a recommendation that fails on arrival is worse than none: it confirms that nothing can be done, which is the definition of low efficacy.

## Which Contradicts A Decision Made Earlier Today, And Both Are Right

Recorded rather than smoothed, because the two documents will sit on the same site.

The concept explainer written earlier today has **every remedy deliberately removed**, at the project lead's direction, so that the page states the problem and the rest of the site carries the answer. That instruction is in its editorial note, with a warning to future editors not to helpfully add a solutions paragraph.

**Applying the same rule to the user section would produce the worst combination in the meta-analysis.** So the rule does not generalise, and the reason it does not is precise rather than a matter of taste:

| | The concept explainer | The user assessment |
|---|---|---|
| Threat level | **Low.** General, about agents in the abstract | **High.** Personal, about this visitor's own machine |
| Effect of withholding the answer | Creates appetite. The reader goes looking | **Creates denial.** The reader has nowhere to put the feeling |
| Correct ending | The problem, stated cleanly | **The problem, and something that works and that they can do** |

So both stand, and the discriminator is whether the message is about the world or about the reader. **A general page may withhold; a personalised one may not.** That is worth writing into whatever guides the site's authors, because the two pages will otherwise look inconsistent to anybody who reads them in sequence and somebody will helpfully align them.

## The Hosted Scenario Is The One Most Likely To Backfire

The consequence nobody would predict, and it falls out of the two findings above.

For an agent running on the visitor's own machine, efficacy is available. The containment is theirs, they can inspect it, and there are real actions: a separate account, a container, an egress policy, removing a permission-skipping flag from a shell file. Response efficacy is demonstrable because the tree visibly shrinks, and self-efficacy is plausible because they own the machine.

**For a hosted agent there is nothing.** The containment belongs to the vendor, cannot be inspected, cannot be changed, and this corpus tested today that it cannot be attested either. Every honest recommendation reduces to use it less or use something else.

**That is zero efficacy by construction**, and it is precisely the condition the meta-analysis says produces maximal denial. So the page most likely to alarm a visitor is the page least able to do anything with the alarm.

The exit for that page is not a remedy, and it should not pretend to be one:

> **Convert the helpless position into a request.** The visitor cannot change the containment, and they can ask for the one thing that would make it verifiable. This corpus named it today: a vendor endpoint that signs an existing audit record for a named relying party, with the surface field in it.

That gives the hosted page an action that passes both efficacy tests. It is something the visitor can genuinely do, in five minutes, and it is aimed at the only party who can actually close the gap. It also serves the research site's dated tripwire, because every visitor who asks is a data point in whether any vendor answers.

## What To Measure Instead Of Alarm

The previous brief established that counting acceptances inverts under pressure, because the number is maximised by making risks easy to accept. **The equivalent trap here is measuring shock.** A tool optimised on how alarming the result feels converges on a number nobody believes, and the meta-analysis says what happens next.

| Measure | Why it is the honest one |
|---|---|
| Assessments completed rather than abandoned | An abandoned assessment is fear control happening in real time |
| **Visitors who take a named action afterwards** | The only measure of danger control, and the one to instrument first |
| Risks stated with an acceptor and an interval | The primary measure from the previous brief, unchanged |
| Risks declined or sent back | A hundred percent acceptance means the assessment is not saying anything |
| **Visitors who report the result as wrong** | The gap, and the most valuable input the library will get |

The last row is worth building for rather than tolerating. The trees are pre-computed claims about other people's products, dated and re-runnable, and a visitor saying that is not what my setup looks like is the cheapest correction the library will ever receive.

## Build Order

1. **The library of pre-computed trees**, published, dated, with a re-run method, before any user section exists. The interface is worthless without it and the participant rules apply from the first entry.
2. **The choices-only storage schema**, written down before any code, with a stated rule that nothing describing the visitor's machine may enter it.
3. **The selection flow and the rendered tree**, ending on excess authority shown as a picture rather than scored as a number.
4. **The efficacy exit, one per surface**: real actions for the local case, the vendor request for the hosted case.
5. **The risk objects**, each with acceptor and interval fields, which is what the risk product consumes.
6. **The vault path**, offered rather than defaulted, with escrow addressed before it ships.

The acceptance test, in the discipline used repeatedly today:

> A visitor completes the assessment in under five minutes, can state in their own words what their agent could reach that nobody intended, can name one thing they will do about it, and can verify by opening the network panel that nothing they entered left the browser.

The third clause is the one that fails if the efficacy exit is missing, and the fourth is the one that makes the site's own argument.

## What This Does Not Try To Be

- **Not a scanner.** Nothing that inspects the visitor's machine belongs in browser storage, and the vault path should exist before that feature does.
- **Not a durable record.** Browser storage has no recovery, and the page should say so rather than imply otherwise.
- **Not an alarm.** High threat without efficacy is the documented worst case, not the strong version of the message.
- **Not a contradiction of the explainer's no-remedies rule.** That rule is right for a general page and wrong for a personal one.
- **Not a place where our storage choice is a compromise.** It is the site's own claim, made checkable.

## Honest Tensions

| Tension | Note |
|---------|------|
| References rather than descriptions | It leaves nothing worth stealing and it caps how specific the assessment can ever be, which is exactly what a visitor will ask for next |
| Browser storage as a feature | It makes the privacy claim checkable and it guarantees the visitor loses their work, which reads as unfinished rather than principled unless the page explains it |
| Efficacy required alongside threat | It is what makes the message work and it obliges the site to recommend actions, which the explainer page was deliberately built to avoid |
| The hosted exit as a request | It is honest and it asks the visitor to do something with no guarantee anybody answers |
| Measuring action rather than completion | It is the real measure and it happens off the site, where it is hardest to see |
| A participant assessing other people's products | The library is the whole interface and it is a dated judgement about competitors, maintained indefinitely |

## Open Questions

| Question | Notes |
|----------|-------|
| What happens when a visitor wants specificity? | The choices-only rule caps the assessment, and the vault path is the answer, which means building it sooner |
| Who maintains the library? | Every node is dated and a vendor default change invalidates rows silently |
| Is the local-folder case supported at all? | Browser storage is origin-keyed and a local folder has an opaque origin, so this feature breaks in a distributed bundle |
| What is the efficacy list for each surface? | Proposed here from this corpus's own findings rather than from a survey of what actually works |
| Does the assessment record which version of the library it used? | Otherwise a visitor returning in a month cannot tell whether their result changed or the library did |
| Where does escrow sit for the vault path? | Carried since 14 August and it becomes a visitor's problem rather than ours the moment this ships |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 20 Aug | `v0.33.61__arch-brief__end-to-end-flow-is-the-august-worked-example-with-an-agent-as-the-twin-grant-tree-needs-control-labels.md` | The four objects the visitor selects, the library of pre-computed trees, and the acceptance metric this extends |
| 20 Aug | `v0.33.61__reference__grant-and-mandate-explainer-what-you-gave-it-and-what-you-asked-for.md` | The no-remedies editorial rule, which this brief establishes does not generalise to a personalised assessment |
| 20 Aug | `v0.33.61__dev-brief__register-ui-every-edge-carries-a-verification-badge-policy-is-a-query-that-must-return-empty.md` | The vendor request that gives the hosted page an action, and the badge the tree's nodes carry |
| 16 Aug | `v0.33.59__dev-brief__publishing-matrix-five-invariants-fourteen-tests-local-folder-needs-a-server.md` | The opaque origin of a local folder, which breaks origin-keyed storage, and conformance testing as a design purpose |
| 6 Aug | `v0.33.56__arch-brief__sg-send-token-gateway-resale-prohibited-in-line-forced-append-and-settle.md` | Architectural against operational privacy claims, which is what browser storage buys here |
| 14 Aug | `v0.33.58__strategy-brief__sgit-topic-sections-catalogue-read-keys-yes-write-keys-never-frozen-vaults.md` | Escrow as a precondition, which the vault path inherits and hands to the visitor |

---

## Key Claims

| # | Claim |
|---|-------|
| 1 | A completed pack describes the visitor's own estate and is in aggregate a plan for attacking them |
| 2 | Browser storage is readable by any script on the origin, and this site assembles pages client-side |
| 3 | So the site stores references into a public library and never descriptions of the visitor's machine |
| 4 | That also makes losing the stored pack nearly costless, which is what a demonstration wants |
| 5 | Browser storage makes the privacy claim architectural and checkable in the network panel in seconds |
| 6 | The user section is therefore a conformance test for the site's own claim, as the static deployment was |
| 7 | Migrating to a vault changes durability and adds an unrecoverable key, and does not change who can read it |
| 8 | Strong fear appeals with low efficacy produce the greatest defensive responses, and defensive responses correlate negatively with the useful ones |
| 9 | So a frightening result with no credible action performs worse than saying nothing |
| 10 | The explainer's no-remedies rule is right for a general page and wrong for a personalised assessment |
| 11 | The hosted scenario has zero efficacy by construction, which makes it the page most likely to backfire |
| 12 | Its exit is a request rather than a remedy, namely the vendor endpoint that signs an audit record for a relying party |

---

## Sources

- The standing meta-analysis of fear appeals, distinguishing danger control responses of attitude, intention and behaviour change from fear control responses of defensive avoidance, reactance and denial, finding that strong fear appeals with low-efficacy messages produce the greatest defensive responses while strong fear appeals with high-efficacy messages produce the greatest behaviour change, reporting a negative correlation between defensive and danger control responses, and instructing that a high-threat message must be accompanied by an equally high or greater efficacy message: https://regulatorwatch.com/wp-content/uploads/2020/06/Witte-and-Allen-2000-A-Meta-Analysis-of-Fear-Appeals-Implications-for-.pdf
- The revised theory of fear appeals separating response efficacy, meaning whether the recommended action works, from self-efficacy, meaning whether the person believes they can perform it: https://www.sciencedirect.com/science/article/abs/pii/S0167811615000142

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).