Toolkit

Govern

What the toolkit stores, and where.

A plain note for security teams and practitioners. It does not overclaim.

AI Demand Toolkit security and data handling note

Status: draft v0.1, GOVBRM original, not yet validated.. A plain description of how the toolkit, workbook, courses and certificates handle data, written for the security or information governance team of an organisation deciding whether staff may use them.. No penetration test, code audit or independent review has been carried out.

What this note covers

The AI Demand Toolkit, the Value Orchestration Workbook, the three free micro-courses, the AI Demand Framework pages, the certificate generator and the credential verification page at govbrm.com. All of them are pages of one static website. This note describes how they behave as built on 14 September 2026, what that means for the information you type into them, and what a security team should check before approving their use. It does not overclaim: a static page with no server is simple to reason about, but simplicity is not the same as security, and several risks sit with the device and the person, not the site.

The model in one paragraph

The site is a set of files served by GitHub Pages. There is no application server, no database, no user account and no login. The toolkit and the workbook are forms that save what you type into your browser's local storage on your device. Nothing you type is transmitted to GOVBRM or to any other party. Paid content (the framework, the toolkit and the courses) is published in encrypted form and decrypted in your browser with an access code that members receive by email. Certificates are drawn in your browser and downloaded from it. The only outbound requests the site's own code makes are to its own origin, for its pages, its manifest files and its registry file.

Local storage

What is stored: toolkit answers and the chosen lane; workbook answers; the access code; course progress and knowledge-check answers; the name, date and ID of the last certificate generated; a flag that the pre-launch curtain has been passed.

Where it is stored: in the browser's local storage for the origin govbrm.com, on the device. Local storage is per browser and per browser profile. Work saved in one browser is not visible in another, on another device, or in a private window after it closes.

What it is not: it is not encrypted at rest by the site. Local storage is protected only by the operating system's user account and by the browser's own protections. Anyone who can open that browser profile can open the toolkit and read the saved answers, and anyone with file-system access to the profile can read the storage files directly.

What GOVBRM can do with it: nothing. GOVBRM has no way to read, back up, restore or delete local storage on your device.

Export and import

Export writes a plain JSON file containing every saved answer, with a timestamp, to a location you choose. The file is not encrypted and not signed. Treat it as you would treat a document containing the same answers: it may contain names of proposed AI uses, suppliers, risks, costs and stakeholders. Store it where documents of that classification belong.

Import reads a JSON file you choose and writes its answers into local storage, replacing answers with the same keys. The importer parses JSON only and fills form fields; it does not execute anything from the file. A malformed file is rejected with a message. Importing a file from someone else replaces your answers with theirs; there is no merge.

Persistence and deletion

Answers persist until they are deleted. The toolkit offers a clear control per canvas. The workbook offers a clear-all control. Each course offers a control to forget the access code; there is no control to clear course progress or the last certificate other than the browser's own settings. Clearing site data for govbrm.com in the browser removes everything at once. Browser features such as sync may copy local storage to other devices signed into the same browser account; whether that happens depends on the browser and its settings, not on the site.

Deleted data cannot be recovered by GOVBRM because GOVBRM never held it.

Accidental exposure

The ways the contents of the toolkit can leave the device are all ordinary ones: an exported file sent by email or saved to a shared drive; a printed page; a screenshot; a shared screen during a call; browser sync to a personal device; a browser extension with permission to read page content. None of these involve the site sending data, and none can be prevented by the site.

Shared computers and browser profiles

On a shared computer, anyone using the same browser profile sees the saved answers, the access code and the last certificate. Use a separate operating-system account or browser profile, or export and clear before leaving. A private or incognito window keeps nothing after it closes, which is safer for a one-off session and loses the work.

The access code is stored in local storage in plain text so that members are not asked for it on every visit. On a shared profile the code is readable by the next user. The code opens published content only; it does not open any account, payment method or personal data.

Device compromise

If the device is compromised, everything in the browser profile should be assumed readable, including toolkit answers, workbook answers and the access code. The site cannot mitigate this and does not claim to. The exposure is bounded by what was typed: the site holds no credentials, tokens, payment data or personal data beyond a certificate name that the learner chose to type.

Third-party scripts

None. Every page carries a Content Security Policy that restricts scripts to the site's own origin and blocks embedded objects and form submission. The site loads no analytics, advertising, font, tag manager, chat widget or social embed. This can be verified from the page source and from the browser's network panel: there should be no request to any host other than govbrm.com while using the toolkit.

Two features open third-party sites in a new tab when clicked: the Add to LinkedIn profile button, which passes the credential name, organisation, date and ID in the link; and, in the courses, links that open a third-party AI assistant with a prepared question about the unit in the link. Neither runs any third-party code on govbrm.com, and neither passes toolkit or workbook content. A security team that restricts the use of external AI assistants should tell staff not to use the continuation links; the courses work without them.

Dependencies

Access codes and encryption

Paid content is published as encrypted files. In the browser, the access code is run through a key derivation function with a published salt and iteration count, and the resulting key decrypts the content. The code itself is never sent to a server and there is no server to check it against.

What this achieves: readers without the code cannot read the published files by opening them.

What it does not achieve: the code is shared by all members, so the scheme protects against casual access, not against a member sharing the code. A member could also decrypt the content and republish it. This is a licensing control, not a security control, and should be described as such. The scheme protects GOVBRM's content; it does nothing to protect your data, which is never encrypted by the site.

Certificate generation

Certificates are drawn on the device from a template on the site, with the name the learner types and the date. The credential ID is a short checksum computed on the device from the credential code, the normalised name and the date. The verification page recomputes it from a name and date entered by whoever is checking. This means:

  • GOVBRM has no record of who has generated a free certificate and cannot confirm or deny one on request
  • anyone who has passed the knowledge check, or who can reach the generator, can generate a certificate in any name; the terms of use call this misuse but the site cannot prevent it
  • the ID proves only that the name and date match the ID; it does not prove that the named person passed
  • free micro-course certificates should be treated by employers as evidence of self-directed learning, not as verified credentials

Practitioner and master credentials are different: they are issued after a live assessment and listed in a published registry file that the verification page reads. The registry is currently empty.

Hosting

GitHub Pages serves the site over HTTPS. GitHub's infrastructure logs the usual request data (IP address, user agent, pages requested) under GitHub's own terms; GOVBRM does not receive those logs. The site's source repository is private. Availability depends on GitHub; there is no service-level commitment, and the terms of use say so. If the site is unavailable, saved local storage is still on the device but cannot be opened until the pages load again, so export a copy of anything that matters.

The site is behind a pre-launch password curtain at the time of writing. The curtain is a presentation control, checked in the browser against a published hash. It is not an access control and should not be described as one.

What GOVBRM can and cannot see

Can see: newsletter subscriptions and membership tiers, via Substack; bookings for paid seats, via Stripe; messages sent to the LinkedIn page; the registry file it publishes.

Cannot see: anything typed into the toolkit, the workbook or a course; whether a member has used the access code or which pages they have opened; who has generated a free certificate; who has visited the site, which pages, or from where.

This is a design choice and also a limitation: GOVBRM cannot help recover lost work, cannot confirm a free certificate, and cannot tell an organisation which of its staff use the toolkit.

What a security team should check before approving use

  1. Read the page source and confirm the Content Security Policy is present and restricts scripts to the site's own origin
  2. Watch the browser's network panel while filling a canvas, exporting and importing; confirm no request leaves govbrm.com
  3. Decide what classification of information staff may type into the toolkit, given that it is held unencrypted in the browser profile and in exported files; for sensitive proposals, use the printed canvases or an internal copy on approved systems
  4. Decide whether staff may use managed devices only, and whether browser sync to personal devices is a concern under your policy
  5. Decide whether the AI continuation links in the courses are acceptable under your policy on external AI assistants
  6. Confirm the vendored PDF library's version and licence against your third-party component policy, or block the certificate page and accept the PNG download instead
  7. Treat free micro-course certificates as self-generated learning evidence in any competency or vetting process
  8. Record that GOVBRM offers no security attestation, audit report, penetration test result or contractual security commitment, and decide whether that matters for the intended use
  9. If the method is to be adopted formally rather than tried by individuals, consider the licensing model and whether an internal copy of the canvases on approved systems is the better route

What this note does not claim

Dates come to members first

Courses and certifications are announced in the GOVBRM Newsletter before anywhere else.

Join free for the essays behind the framework, the access code for the free micro-courses, and first word of every cohort. Paid membership adds the toolkit, the framework and a seat at the masterclasses.