# RiskMandate — the brief register Every document this site was built from, what it produced, and what it did not. Kept with a digest per file so nothing is worked twice and nothing is quietly dropped. Source: https://riskmandate.ai/briefs.html --- # Everything we were given, and what came of it. This site is built from briefs written elsewhere. Two things go wrong with that arrangement: the same document gets worked twice, and a document arrives and is never worked at all. Both failures are invisible unless somebody keeps a list — so here is the list, with the digest of every file as it was received and an honest status against each one. ## Two failures, one list. Neither of these is hypothetical. One of the documents below arrived twice, byte-identical, six hours apart — and three Lab entries had already been written from it. Without a digest to compare, the only thing standing between that and a wasted afternoon is somebody's memory of a filename. - **Nothing gets worked twice.** Every file is archived exactly as it arrived and its SHA-256 recorded. An identical file turning up again is recognisable _before_ anybody starts reading it, and the register lists every time it turned up rather than only the first. - **Nothing gets quietly dropped.** The agent producing these briefs can fetch [briefs-register.json](briefs-register.json), compare it against what it has sent, and name anything that is absent. That is a check somebody else can run against us, which is the only kind worth having. - **The status is the state of the work, not an intention.** Received means read and archived with nothing built, and Partly — the commonest honest answer — means some of it shipped and a named part did not. Neither is a promise that the rest will follow. - **And what was _not_ done is recorded beside what was.** A register that lists only outputs flatters the work. Every entry below carries both columns, and the right-hand one is usually longer. | | Status | What it means | | --- | --- | --- | | Processed | processed | Read in full, and something on this site exists because of it | | Partly | partly | Read in full; some of it is built and a named part is not | | Received | received | Archived and read, and nothing has been built from it yet | | Superseded | superseded | Later material replaced it. Kept, because the reasoning is still the record | ## Ten files, in the order they arrived. Each one is linked in full, as received, with nothing edited. Where a brief and this site disagree, the brief is what we were given and the site is what we concluded — and where we corrected a brief, the correction is on the page rather than in the file. ### The Grant Is User Shaped And Not Data Shaped: Start With The Connectors, And The Template Vault Is The Product **sha256** 1b2dfa45d228be6b0f6eb6a420090da160e979fe0b347048588565441a9f6e38 **This is the one that arrived twice.** Byte-identical both times, and the second arrival came in the same message as D3 and D4. It was not reprocessed — the three Lab entries below were already written from the first copy. This entry is the reason the register exists. - [Lab 01 — the grant is user-shaped, not data-shaped](lab-connector-grants.html), with four vendor quotes verbatim - [Lab 02 — what buying a behaviour policy would look like](lab-abp-flow.html), including the twelve-stage flow - [Lab 03 — requests against abp.sgit.ai](lab-abp-requests.html), including the proposed `material` property - **The five first policies themselves.** Lab 01 documents the grants; no policy document exists for any of the five shapes - **The template vault and the shape library** — named in the brief as the actual product, and not started - **The instrumentation table** timing the first five, which the brief calls the only pricing input anybody will have ### This Is The Tier One Application Nobody Could Find: The Connector List Alone Is Twenty Bits, So Compute Locally And Submit Banded **sha256** 11ff8f5f9eebb9200d30694381ff27c7e53a59417dd92f1a0461bbfe1b65ad89 **One correction to this brief is stated on the page it produced, and marked as ours.** The brief treats banding as the fix. Worked through, banding is the necessary first move and not the whole answer, because a banded submission still carries roughly the entropy of the fingerprint study the brief benchmarks against. The page shows the assumptions so somebody can check the arithmetic. - [Lab 04 — seven things to build, and one word we have not earned](lab-shape-collector.html) - **All seven items on Lab 04's own build list.** The page is the specification; none of it is built ### The Commit Author Is A Free Text Field: A Prompt Shifts The Odds, And Every Documented Fix Was Architectural **sha256** b54eddae92bc88d8133c1e544c339433972ef6cf8cf8656ac4771b7ffbce7ccd **The finding and the prompt are built; the experiment is not.** All six load-bearing quotations were fetched and checked against their sources rather than relayed — which produced two corrections to this brief, both stated on the page it became: the _partially verified_ state additionally requires the author to have **enabled vigilant mode**, and the claim that the attribution renders a profile picture and a profile link could not be found on the page cited. - [Lab 05 — your agent can commit as you, and no instruction stops it](lab-commit-author.html), with the eight-line prompt and its _enforced by_ column - The [free/paid line](pricing.html), which now sends a reader to Lab 05's four free settings before asking them for money - **The comparison experiment.** Lab 05 specifies it — three arms, twenty runs each, violations counted as repository queries — and no repository has been set up to run it against - **A signed-commits rule on our own repository.** Lab 05 says in as many words that the argument is demonstrated and not adopted until that is on - **Provider and connector pages** mapped onto the four layers, and the community incident repository behind them ### The Urgency Is Not A Deadline But A State: You Already Connected It, And A Distributed Skill Cannot Carry A Control **sha256** af73131b6a72bb5f6d8aad1563f124a016040833310df0fb8be717ec44bb0e56 **Both of its rulings are now on the site.** The entry product says it reduces accidents and does not stop an attacker, in those words, on the page carrying a price — and the behaviour policy is not sold as a skill, because the portable part of that format cannot carry a constraint. The word for the narrowing cover does not appear on the pricing page at all; the authorise question stands in its place. - The urgency section on [the front page](index.html) — three vendor sentences with dates and no adjective, then the two dated changes of this year - The [free/paid line](pricing.html), with the honest label and the authorise question - **The price experiment as redesigned** — charge one price and count, with a certainty question after. The page states the approach; no price is set and nothing is charged - **The generic prompt as an installable artefact.** The pricing page says it is free and published in the open; the file does not exist yet - **The early access group** — a dozen people running one of the five shapes, used for objections rather than numbers. No list exists ### Startup Summit 2026 — exhibitor booth guide **sha256** d13e3f08729fa8ffaab7f4e1d247535fb0782c5182df67e365ef61d52ca0cf3d **Third-party material, and it corrected three of our own planning assumptions** — the banner is not permitted, submissions go through the exhibitor portal rather than by email, and power has to be requested rather than assumed. Kept on a working page rather than a public one; whether it stays fetchable here at all is an open decision. - [The booth working page](summit-booth.html), with the guide embedded and the materials to hand over - Three corrections to [the Lisbon page](summit.html) and the messaging brief behind it - **Logo and name into the exhibitor portal.** The organisers' own deadline was 15 September - **The power request**, which goes through the portal and not by email ### Every Routable Address Is In The Grant: Do Not Attack Anyone Is The One Rule Everybody Signs, And It Is The One With No Barrier **sha256** b85fdbcb235b352150d5b806e58b4d525414a8c0a7ac11382a697f2f78127eb7 **Seven load-bearing quotations were fetched and checked rather than relayed**, including the reference container's firewall script. Two departures from the brief are stated on the page it became. It reports observing an agent's two egress paths _diverge_ in one session; in ours they did not — both reached every host tried — so the finding rests on the vendor's own sentences rather than on that observation. And we published a measurement of this machine's own egress instead, which found a raw outbound socket to an arbitrary public address and working name resolution, with no allow list standing in either path. - [Lab 06 — every routable address is in the grant](lab-network-reach.html), with the egress-path matrix and the four things the published reference firewall permits - **Two proposals to the model site** — the barrier's companion fields, and the six composition rules. Lab 06 states them; they are not yet on [the request list](lab-abp-requests.html) - **The provider comparison table**, which the brief says writes itself from the sources - **The reconciliation tool** between an agent's several destination lists — possibly the smallest useful thing we could ship on this capability - **The generic pasteable document** as an artefact rather than a table ### ABP Graph and Stakeholder Views — the policy is a graph, and every stakeholder gets a projection of it **sha256** d93b0fdc381a166dd0044b024031c9ee60a789533f7efc91ff3dafe4248afa90 **A voice memo, transcribed, and the transcriber wrote the acronym as `ADP` throughout.** It is the spoken ABP; the archived bytes are kept exactly as received, which is the rule, and the correction is here rather than in the file. The memo was worked into a brief on the day it was spoken and the file registered when it arrived, with D8. - [The direction brief — the policy is a graph, and every stakeholder gets a projection of it](https://github.com/Risk-Mandate/riskmandate.ai/blob/dev/docs/briefs/direction__abp-as-a-graph-and-stakeholder-views.md), with the vault structure it asks for and a build order - [The _by behaviour_ facet on the library](agent-behaviour-policy.html) — one click answers which policies can delete files, the graph's first visible edge - **One page per behaviour**, generated from the catalogue, listing every policy that has the edge with its barrier and its door - **Edges per path rather than per row** in every vault — the n8n lesson made structural - **Metrics and outward links on the 23 primitives** — speed, volume, blast; ATT&CK technique ids and GDPR articles, cited - **Views per audience** — CEO, CFO, CTO, investor, buyer, operator, engineer, project manager — with the prompt and the script shipped in the vault so the customer can regenerate the projection - **The two asks to the model site**, not yet on Lab 03 ### Use Case Driven ABP Policy Strategy — a policy per use case, and the £500 level is a prompt the customer runs **sha256** 8457a6637e212c0b91b2186efda1857836dc660deed3e328e796a267ab9e45ac **The four price points in the memo are the four levels the store put live the same day** (store.sgit.ai v0.1.7, 15 September): £5, £50, £500, £1,500. The memo's contribution is what the £500 level actually is — a prompt the customer runs in their own environment, whose output we turn into their policy — and the idea of a policy per use case, with our own Voice Debrief workflows as the first two. - [The direction brief — a policy per use case, and the £500 level is a prompt the customer runs](https://github.com/Risk-Mandate/riskmandate.ai/blob/dev/docs/briefs/direction__use-case-driven-policies-and-the-prompt-workflow.md), with the seven-step workflow written down - [Pricing](pricing.html), rebuilt around the four levels and linked to the store, with [the prompt step](pricing.html#prompt) spelled out - [The homepage](index.html) and every vault page point at viewing a policy and buying one - **The two Voice Debrief use-case vaults** — the web flow through a model-routing service, and the WhatsApp flow through n8n — written by the agent that knows those workflows and packaged here - **A page of its own for the £500 workflow**, once the store's side has a return address that is not a mailbox - **A use-case group on the library**, and the combination of several vaults' grants into one, which the generator does not do yet - **The per-shape header on the prompt**, naming the vocabulary and the order reference ### The offer is built and the button is not — each level is the level below plus one thing, and the post-sale page does not exist yet **sha256** 99e75be33f0989f6060b5acec058c34a13531b3d6bf54fc53e9cb5e65a23f3ff **The brief's finding is that the four levels are priced and described and nothing happens after the money moves.** Its rule for the ladder — each level is the level below plus one thing — was already true of the pricing page and is now said on it. The part this site owns is the page a customer lands on after paying, one per level; the payment links and the store's own product pages are the store's. - The four post-sale pages — [level 1](paid-t1.html), [level 2](paid-t2.html), [level 3](paid-t3.html), [level 4](paid-t4.html) — each saying what arrives and when, what this is not, what you do next, how the key reaches you, the definition of done, and who to write to. Unlisted and noindex: they are the success address for the payment link, not pages to find - [The £5 page is the download](paid-t1.html): the zip of the template vault for the shape bought, its size and sha256 stamped from the file by the build and checked in CI, and a hash check the page runs in the browser. Levels 2, 3 and 4 are a follow-up from a person within 24 hours - [Pricing](pricing.html#after), with the plus-one-thing rule stated and a definition of done per level - [The homepage](index.html#parts), with the four levels in the behaviour-policy section, and the £10 still on two pages corrected to £5 - **The payment links** and the success address on each (level 1 with `?shape=`) — the store's, not this site's - **The level-3 text on the store's product page**, and the opinion add-on page - **The A5 and the stand** ### Risk Mandate Website Repositioning Strategy **sha256** ab6f9486ecae99de444ff7bfe0aa4c7a95badcdd01fb12b795eec7ec852984eb **The first brief that asked for something to come off the home page rather than go onto it.** Its argument is a chain: our job is to make agents insurable; an agent is insurable when the organisation has authorised it in a way that survives examination, which is a licence to operate; a licence to operate needs a behaviour policy to be a licence for anything. So the ABP is sold first — it exists, it is the lowest touch and it can be delivered today — and the insurance thinking is kept in full rather than lost, on a page of its own. One departure while implementing it: the brief names three audiences, and a fourth, investors, is already written up on the Lisbon page, in the store and on the printed sheets. Three pages were built and the fourth is named as missing rather than quietly dropped. - [The home page](index.html), opening on who is arriving and what is actually sold - [Make agents insurable](insurance.html) — the whole insurance argument, kept in full on a page of its own - [Licence to Operate](licence-to-operate.html), adopting the organisation / instrument / licensee referent the vaults already use - [You run agents today](for-corporate.html), [You are a founder](for-founders.html) and [You are a startup](for-startups.html) - The menu rebuilt to seven top-level entries, with **Policies**, **Who it’s for** and **Insurance** as groups - **Multilingual delivery for levels 3 and 4.** The brief asks for the £500 correction and the £1,500 session to be deliverable in the buyer’s own language, since both have a person in the loop. Nothing is built, and nothing is claimed anywhere on the site - **An investor page**, the fourth audience - **A per-audience view inside a vault.** The home page gives that as the reason for audience pages; the vault app opens on one view for everybody ### The named professional, and the assignment of the individual who does the £1,500 review **sha256** d376355f1747cc88986a623b91592bee5a5ec3b73f3ac838c43687f7a8fb53eb **The first brief about a person rather than a document.** A consultant has agreed to take some of this work, so the top level needs two things written down: what the service actually is — the workflow, the timelines, the expectation on both sides — and who does it, as a page carrying the record, the experience and the declared interests, so that a buyer chooses the individual rather than a logo. The brief asks for the lead’s own page first and the second consultant mapped from it. Built as a generated family from one file per reviewer, because the store reads the same data for its chooser and two sites must not end up saying different things about the same person. The second reviewer is published as a labelled placeholder rather than a name, which is what was asked for: the shape can be read before anybody is asked to fill it in. - [The reviewed level](abp-reviewed.html) — eight steps in order, what you bring, what we never ask for, and every figure with the page and date it was read from - [Who runs your review](reviewers.html), and the rule that nothing on a reviewer’s page is written by us - [The first reviewer](reviewer-dinis-cruz.html), every line read off a published page with the date, and the interests declared on the page rather than in a footer - [The shape of the page](reviewer-ciso-xyz.html), labelled a placeholder everywhere it renders, so the next person can see what would be published about them before agreeing to any of it - [reviewers.json](reviewers.json) — the same data as a manifest, so the store’s chooser reads one source instead of keeping a second copy of a real person’s biography - **A second, named reviewer.** The brief names a consultant who has agreed; nothing about them is published until they have read their own page and said yes. The placeholder is what stands in the meantime - **The chooser at checkout.** Picking the reviewer while buying is the store’s workflow, not ours. The manifest is published for it and the arrangement is written up for them; nothing is agreed yet - **Comments and testimonials.** Asked for in the brief; none exist, and none will be written by us. The page says so instead of showing an invented one - **Availability.** No queue, no calendar and no throughput is published, because none can be honoured yet — the page carries a status and the date it was confirmed - **What the reviewer is paid.** Agreed in the brief and deliberately not published: a commercial term that belongs to the lead, recorded here so it is not mistaken for an oversight ### How it technically works: prompts first, then hope is not a control, then fit, integrate, graph, and the vault as provenance **sha256** dadd026e61c5653ea7789c5f8e852900cc4d1bef8f852ea9846719bd9ba91791 **Prompted by a peer asking, in a chat, “how does it technically work?”** The page called _How it works_ answered with an architecture that predates the Agent Behaviour Policy — twins, a RiskGraph, engines, board briefings, an API — none of which is what is sold, and one line of which, _twins instead of integrations_, said the opposite of the memo. The memo gives the order: start with a prompt because being surprised by the reach is the shift; notice that asking an agent to behave is hope rather than a control; fit the policy to whatever controls actually exist; integrate with whatever the customer runs, connectors built per engagement; connect it all as one graph to risks, standards and internal policies; and keep it in a vault because the vault is the provenance. Rebuilt in that order, with a status chip on each step. - [How it works](how-it-works.html), rebuilt: the technical insight kept, then six steps in the memo’s order, each marked running, per engagement or in design - The one-line answer to _what does this do_ at the top of the page, in the words the lead used in the chat - **Connectors to a customer’s own control planes.** Built per engagement, productised as they mature; none is a product, and the page says so rather than implying one - **The graph’s edges upward to risks and the board, and sideways to internal policies and documents.** Standards edges run in every vault today; these are marked in design - **Execution logs and evidence in the vault beside the policy.** The memo’s provenance store, marked as where this goes ### UK support, in the open: consolidate what the UK offers a startup at go-to-market, ask people what is missing, and let other founders use it **sha256** 0c528b8c5736930b4a4a87b5e816f38af0758a2cd42eb1ad9df6e0904eceeecc **The product is ready and the challenge is now users.** The memo asks for one public page, modelled on the partnership pages on sgit.ai, that consolidates the UK’s support for a London startup at this point: departments, programmes, events, and the kind of government-sponsored travel founders remember. It serves three readers: people the lead knows, asked whether anything is missing; other founders, who can use it; and RiskMandate, which records what happened at each door. - [UK support, in the open](uk-support.html): every entry read on its official page and dated, with the page’s own status, our status, and the closed programmes kept - [The register as data](uk-support.json), rendered into the page by a script that refuses a row without a source, and a closure without the words that close it - The finding the memo did not expect: the Sovereign AI procurement scheme’s third challenge, set with the NCSC, describes an Agent Behaviour Policy - **Applying to anything.** Every row says not started except Web Summit; which doors to try is the lead’s decision - **The government-sponsored travel.** The grant that paid for it was withdrawn in 2023; the page says what exists instead - **A matching page on sgit.ai.** That site is not in this repository; its partnerships section can link here ### Pilots do not stay in production: the business sees the gap between mandate and reach, at machine speed, and declines to sign for it **sha256** 762fd1ea85c2d701f304331d507374b7668ec41bae90788498c2221cd7ac6e53 **The real metric is not whether a pilot reached production but whether it stayed there.** The memo’s hypothesis: a pilot proves the agent can do the task in a curated world; production asks what else it can do, how many times, how fast, and on whose authority; and when the business models that, it declines to sign. It asks for the data behind it, for examples, and for the answer the site sells: limits in business units, set at design time. - [The pilot worked. Then somebody asked what else it could do.](article-pilots-do-not-stay-in-production.html) Fourteen surveys and forecasts with the causes each one names, three sources on staying in production, seven cases and two that do not fit, five variables beside the lethal trifecta, and a section on what the data does not show - **Data that tests the hypothesis.** No survey found asks whether the gap between reach and mandate stopped sign-off; the article says so and asks for cases - **A source for the credit approval at two in the morning.** None exists publicly; it is told as an anecdote and nothing more - **The operating limit from the insurance vault.** Not found in the published demo vaults; the article shows the shape with numbers labelled as invented ### Calendar edits cannot be undone: integrity risk, and why the edit permission is the dangerous one **sha256** 0349fc94e7df55c387bd3a2a1e8adb413c0bd742759ff671ad47d7ef7979df84 **A finding from drafting Calendar behaviour policies.** Google Calendar has a trash for deleted events but no way back from an edit, so an agent that edits many events leaves corruption that looks like a real calendar. The memo asks for the facts to be checked, including the trash period and who can restore; for the calendar-over-email point from early users; and for the conclusion: map each action by whether it can be undone, because an edit with no undo exposes more than a delete with one. - [A deleted meeting comes back. An edited one does not.](article-calendar-edits-cannot-be-undone.html) Every recovery fact quoted from Google’s own pages, for personal and Workspace accounts, three contradictions in those pages published unresolved, and the draft Calendar rows with recovery beside each - Two traps the memo did not have: deleting “this and following” events skips the trash, and an API patch to the guest list discards the previous list - **A qualification, not a contradiction.** The memo’s claim holds for personal accounts. Workspace editions with Vault keep earlier versions of primary-calendar events for an admin to export, though not to restore - **The Calendar behaviour policies.** In draft; the article quotes their rows and says so - **Evidence for calendar over email.** A handful of conversations, reported as that ### Business cases by risk reduced: the register without a security product and with it, from the operator to the board, starting with our own **sha256** 1dabf7f55b1cef3af6cacef62d5fcd0c46d0adb58ea96277cff8e7e79926dade **A section rather than an article, and win-win-win.** The business case for a security product is the risk register without it and with it, at every altitude from the operator to the board. Start with RiskMandate’s own product, including what a hope-level instruction to the agent is worth; research the categories of security product for agents; pick targets; publish the cases and use them to start conversations with the vendors. The memo asks whether earlier work already covers the risks and their owners: it does, in the RiskGraph Explorer vault, and the section runs on that model. - [Business cases, by the risk they change](business-cases.html): the method, the rules, and twelve categories of product computed against the typical deployment, each with what it adds - [The first case, our own](business-case-riskmandate-abp.html): two risks retired, one hidden risk named, and three expectations listed as reductions, never retirements - An engine that reproduces the Explorer’s rules, and a copy of its model with digests, so every register on these pages is computed rather than written - **The named cases, published.** Two are built as drafts, unlisted and marked noindex, until the lead decides to send them to the vendors - **A semantic graph per product.** A case is written as the answers a product changes among sixteen questions; what the questions do not ask about cannot yet be expressed - **The outreach.** The lead’s, after review ### OWASP and open source first: a semantic graph of OWASP, business cases for the open-source projects that reduce risk, and the companies built on open source **sha256** 3686c72fb430e18cf55612574ae81e302b61475c4f207bec62a2bbd780a42ca8 **Start the business cases with open source, and with OWASP in particular.** The lead is closely involved with OWASP and wants to bring RiskMandate’s ideas and standards there. The memo asks for a semantic graph of OWASP, which it says does not exist, zoomable from the foundation to one item because every document has its own ontology joined to a wider one; for cases for open-source projects that reduce risk, since free is never free and customising is the work; and for the companies built on open source, to connect with. - [OWASP, as a graph](owasp-graph.html): 52 projects and documents in four families, 110 items of eleven lists by title, 62 relationships OWASP states, and the Agentic Top 10 joined to the model and to the cases that change its answers. The data is published to be offered to OWASP - Eighteen [open-source cases](business-cases.html#cases), OWASP first, every change quoted from the project’s own documentation and checked, each with what adopting it takes - Eighteen [companies built on open source](business-cases.html#built-on-open-source), quoting only what was checked word for word - **Cases for OWASP’s documents.** The Top 10s, ASVS and SAMM change what a team knows, not what an agent can reach; they sit in the graph, and the bridge shows which cases change the answers each agentic item depends on - **Three agentic items the model cannot express.** Supply chain, memory and context, and agents talking to agents: the model has to grow - **The outreach.** To OWASP projects, maintainers and companies; the lead’s, after review ### A behaviour policy for everybody the lead talks to: a brief and a zip for a new agent, three vaults, and controls so nothing leaks across **sha256** db4b98aef049e05716c3789105ce4a56e4e96fd0939774fd912bea329c8b7624 **Users, one conversation at a time.** After talking to somebody, the lead gives a new agent a zip, a website and a sentence; the agent researches the organisation’s public pages and builds an Agent Behaviour Policy vault for them, to send as a demo they can correct and try. Three vaults: one for the keys, one for the UI, one per person, with controls so nothing leaks from one person to another, and each person’s vault written so it could be public one day. - [The brief](admin/briefs/workflow__abp-vaults-for-people-we-know/index.html): the existing app vault is the UI, a private keys vault holds every write key and the lead’s notes, one vault per person holds only public material; the workflow; what the feedback loop is meant to learn - The pack, kept in the repository at `packs/dist/` rather than on the site: instructions, templates, a scaffolder, a leak gate proved against six planted leaks, the site’s own builder with every catalogue deployment, and one fictional example built and checked - **The keys vault.** The first session creates it and gives its key to the lead, so the steps are exercised once with the lead watching - **Corrections from inside a vault.** Today a person replies to the lead; a form is a question for the app vault - **A real person’s vault.** The pack has been run end to end on a fictional organisation only ### An interview page, and a ChatGPT voice prompt to run it: a reusable pattern, and the first page, for a founder who knows UK events and marketing **sha256** c4734574a34364f4e5837a05197a207430ed8429e8fa17bf64332f73219910c4 **Expert feedback from people whose knowledge is in their heads.** Asking a busy founder to read a site and write feedback rarely works; asking them to talk for twenty minutes usually does. The brief asks for a page that carries a prompt the reader pastes into ChatGPT, which interviews them by voice and writes a structured summary they send back: a reusable pattern of six parts, and the first page on it, for a founder who is good at UK events, marketing and content. The prompt is to be used exactly, changed only where the site states a fact differently. - [The first interview page](interview-founder-marketing.html): the six parts in order, a copy button tested to copy the prompt exactly, nothing loaded and nothing sent - The pattern as a template, so the next page is one JSON file and one command - **A run in ChatGPT voice mode.** This agent has no ChatGPT account; the lead runs it once and checks the summary has all ten sections - **The prompt exactly as written.** Two phrases were corrected to what the site states: the home page names the CEO, CTO and CISO, not an insurer; and the behaviour policy is the licence’s instrument, not its evidence - **Sending the summary back into a vault.** The brief marks it as later ### Ask the ABP questions in the interview, and answer a LinkedIn role map as a stand-alone article: a generic framework, adjusted in every company, with accountability that holds on the way up **sha256** 2219d9a051791da925288f494be02fdbcf9a05709b12a70acc42ec4ff565d6ab **Two asks in one note.** First, the founder interview should also ask about the Agent Behaviour Policy itself: its name, whether it can be explained, what it adds, whether the market understands it, its value to the people who would use it, and whether it should sell. Second, an article of a kind the lead wants to write more of: take something strong seen on LinkedIn, here a map of who owns what in AI by role, and show our world on top of it. The map is a generic framework, as ours is, and every company adjusts it; what risk acceptance and the ABP add is the connection that keeps accountability intact on the way up. Written as a full document, so the details can be implemented. - [The interview’s first part](interview-founder-marketing.html): six questions on the ABP, a test of explaining it back after one hearing, thirty minutes, sixteen summary sections - [The article](article-who-owns-what-in-ai.html): the map’s rows quoted and credited; what each company sets and what stays fixed; one invented agent from eight ABP rows to the board; seven rules; six weeks; the model as nodes, edges and computations - **The post’s own link and date.** The article credits the infographic by title and author, and says when it reached us - **A run of the longer prompt in ChatGPT voice mode.** The lead’s, checking all sixteen sections come back - **The build.** Seven of the map’s roles are not in our model, authority is not yet data, and no engine runs the clocks; the article says so ### Graph visualisations for the role-ownership article: the blast radius as the employee connects and disconnects, the flows played out, the evidence, and the settings a mail scope cannot narrow **sha256** 524b59f30d4407f354272061f0e9c10e0ed45d5161d9ef19ad8007324a03bf5f **Show it, not only say it.** The article has the ontology and the taxonomy at the bottom, so draw them: a series of visualisations, animated in the page, that show the interconnection, the blast radius growing as an employee connects the assistant to their mail and shrinking when they disconnect it, the flows played out, and the evidence. Include the settings that cannot be prevented: a mail scope grants the whole mailbox, and what the behaviour policy adds is instructions and a mandate narrowed to one business process. - [Three figures](article-who-owns-what-in-ai.html), drawn by the page’s own script from the article’s data: the blast radius, which plays the six weeks or takes the reader’s own changes and recomputes the rows, the risks, their holders and the counts; the six weeks as a strip; and the ontology, every verb readable from both ends - The instruction switch: the mandate becomes precise about the business process, every row in the gap gains an expectation, and unbounded excess does not move. The mail scope fact is cited from the Gmail record - **Blast radius as a number.** The figure shows which roles a risk reaches and who holds it; it does not size the consequence, because the article scores nothing - **Real grants.** The figure runs on the invented agent; wiring it to a published ABP vault is the next step - **Evidence flowing downward.** A ceased risk cites its ABP version in text; the figure does not yet animate the evidence travelling back to the version ### Risks always flow upwards: the roles above carry the aggregate, click a role to see what it holds, list every risk that holds now, and show the level of risk the business already accepts against the gap outside it **sha256** 19de617c22e7226307413fbee045912c6af4fe56c453db8010d98209747c31a1 **A risk does not stop with its holder.** The first figure implied it did: connect the CRM and two risks sat with the CIO and Sales. They reach the CTO, the CEO and the board, and the people at the top get the aggregate; the CEO carries the calendar risk and the mail risk both. So: light the path upward, let each stakeholder be clicked to see the risks they carry, list every risk that holds at any moment, and show that reading the rep’s own mail is a risk the business already accepts, which is different from reading every mailbox the account can open. Drop the roles nothing reaches; keep Legal and the CFO. - [The blast radius rebuilt](article-who-owns-what-in-ai.html): every live risk lights the path from its holder to the board, every role above carries a count, a role’s panel lists what it holds, carries and is informed of, and a table lists every risk that holds now with the chain it reaches - The accepted level: row 1 is the rep’s own mail and establishes R0, accepted by the rep on connecting; row 9, the shared sales inbox, is outside the mandate and establishes R7. The tables, counts and six weeks follow: nine rows, five in the gap, unbounded excess five, then four, then three - Marketing, Product and HR leave the figure; Legal and the CFO are informed of every risk that touches a customer or their data; a compound risk is drawn larger by the facts it needs - **A quantity of impact or potential loss.** Each risk carries a consequence in words and an undo property, and no number: the article’s own rule is that kinds of consequence do the work of a score, and a loss figure is the lead’s decision - **Other scenarios.** One agent, as the lead asked for now ### Red travels up the path, and a control does not make a risk zero: it leaves a green one. Enough controls, including a proxy in the middle, to make every path green; risks for the CFO and Legal **sha256** d47dbfda7dd3e53314dc72b41922ae0a723cfd13202722bd468488be5ff2560a **Two details, and a scenario the figure could not yet show.** The rep’s path was green while the CEO’s and the board’s stayed green above a red risk; if a role carries a red, its path is red. And there was no way to make everything green: add enough controls, such as a proxy in the middle that carries out the actions, and the functionality should be all green, because the green risks are the functionality, accepted once the controls are in. As controls go on, the risks should be seen going down. Risks for the CFO and Legal were missing. Take the controls as working, for now. - [The colour travels up](article-who-owns-what-in-ai.html): while anything below a role is unaccepted, its path, halo and count are red. Four more controls, one an execution proxy that bounds every write row at once, two that end a risk by changing a fact: terms with the provider, the insurer’s written answer. Every control leaves a residual risk, green, inside its holder’s authority; with every control on, every path is green and nine green risks remain. A button does it in one click - RL with Legal and RC with the CFO, in the tables, the six weeks and the strip: nine risks on day 0, nine open and none unaccepted on day 42 - **The effectiveness of a control.** Every control is taken as working, as the lead said to for now; a control that is on and not working is what the ABP’s evidence tiers record, and it is not modelled here - **Residuals in the holder’s own words.** The figure draws them from a fixed list; a real record would have each holder write theirs when the control lands ## And the instructions that arrived as speech or a sentence. These have no digest to check, which makes them the ones most easily lost — a voice memo that changed the direction of the whole site leaves no artefact at all unless somebody writes it down. So they are recorded here in the same list, with the same two columns. **Put the Agent Behaviour Policy at the centre of the site.** The ABP is the fundamental primitive; the grant is calculated from reality via digital twins; RiskMandate drives the sale of ABPs, and those are the first batch of customers; the audiences are corporate users, investors and founders; and a security vendor whose controls reduce the delta has a business case we can make for them. - [The Agent Behaviour Policy page](abp.html) - The direction brief, in the repository under `docs/briefs/` - [Pricing](pricing.html), rebuilt around the store's four levels and linked to it - The homepage's second panel, which should become _the grant you did not enumerate_ and still does not **The Startup Summit exhibitor pack and the event site**, for a strategy document and the materials we need to submit. - [The Lisbon 2026 page](summit.html) - The messaging and strategy briefs, in the repository under `docs/briefs/` - Nothing, other than what D5 corrected. **Hire a freelancer who also works through agents.** Give them a page and a first prompt focused on making sales online and at Lisbon, and make their first task being a power user and tester of behaviour policies. - [Working with us](work.html) - [Brief B1 — power user and tester of Agent Behaviour Policies](work-abp-power-user.html) - Rate, hours, start date, escalation route, publication rules and repository access — deliberately absent because that page is public, and listed on it as owed **Preserve the Lab's thinking as it changes**, and publish it as files that can be sent through a chat app — because by the time a reader follows a link, the page has moved on. - Dated PDF editions of every [Lab](lab.html) entry, and the whole Lab as one file - [The edition register](lab-editions.json), with a digest per file - Nothing. **Answer the questions people actually ask in public**, with the standing rule that the site never names who asked. Two public comments were supplied as the first two questions, and answers that outgrow a section get their own page. - [Questions](questions.html) — real questions, answered with a date and no name attached, and both current answers containing a _no_ - A convention for screenshots. Our own demos are fine; anybody else's product runs into the no-probing and no-verdicts rules, so the Lab's drawn mockups remain the pattern until that is decided **Build a specific vault for Claude chat connected to a Gmail inbox, capture the connection screens with the address obscured, and map the whole customer workflow** — the vault, its home page, the settings, the permissions, the prompts given to Claude — as the purchase workflow. Do not use the agent's name. - The template vault `claude-gmail-connector`, built and checked: six rows, **four measured** on the deployer's own account, the eight screens transcribed in `evidence/` with the address redacted — pushed as vault `oc433z3m` and read live on [its own page](abp-vault-claude-gmail-connector.html), unpushed, and on [the next-policy page](agent-behaviour-policy-next.html) as built and awaiting a push - The customer's draft instance, anonymised, with a question on every mandate line, under `vaults-instances/` — pushed as a private vault (`xjir6m0c`); its key went to the lead in the session and is on no page - The purchase workflow, run once — the brief in the repository under `docs/briefs/`, a page on [the console](admin/briefs/workflow__buying-a-policy-for-claude-on-gmail/) - The twelve screenshots as redacted image files: they arrived inline and could not be edited from the session, so the transcriptions stand in for them - The customer's correction of the mandate, and the signed licence **Where is the new Claude + Gmail section; publish the vault; give the Gmail workflow brief a page in the admin section, in a way that takes many briefs; and rebuild the admin section** to the structure, layout and capabilities of `store.sgit.ai/admin/` and the newsroom console at `pt.newsroom.sgit.ai/newsroom/`. - The Gmail-connector vault pushed from the session with the shared token (`oc433z3m`), its public read key in the catalogue, [its page](abp-vault-claude-gmail-connector.html) reading the vault live and its tile in [the library](agent-behaviour-policy.html) - [The admin console](admin/): a rail with counts, what needs the lead as the only filled rank, [the board](admin/work/) read off the state file, [the memo queue](admin/memos/) read off this register, [every document under `docs/` as a page](admin/briefs/), the vaults with measured rows and open questions, the records and the tooling — written by `build-admin.mjs`, checked in CI, never edited by hand - [The Gmail workflow brief](admin/briefs/workflow__buying-a-policy-for-claude-on-gmail/) as the first of those pages - Nothing from this instruction. What the console shows as owed is on the console itself, under _needs the lead_. **Make the Gmail-connector vault the first MVP vault**, with a solid end-to-end experience and the design template every other vault reuses; global changes to the code vault are fine. Start from the store's V3 marketplace mock-up — the vault panel with its left navigation, the positioning of the vault — and the store's table of what each level gets you, including the dual licence. - [The direction brief](admin/briefs/direction__mvp-vault-and-the-reading-app/): what the mock-up says about the vault, the feature list read off the store's table, the dual licence as a file and a data block, the reading app redrawn with a left navigation, what changes globally, four decisions for the lead, the plan - The build: the licence block and `LICENCE.md`, the v3 reading app, a new app vault, `oc433z3m` rebuilt and re-pushed, the vault page repositioned — after the lead's answers to the four decisions **The material to add to the Gmail-connector vault.** Go back to first principles on the grant and map its side effects: a grant is the union of capabilities, and the reader needs the consequences — each explicit, each tied to the asset that makes it real (secrets in mail, reset links, mail from others). Count the routes out. Authorisation to read is not authorisation to forward. Harvesting, mass send, what makes a platform suspend an account, mass change to the inbox's filing. Realistic scenarios on the mandate; standards as mini-graphs in the vault; the vault navigated as a website with materials per audience. - [The direction brief](admin/briefs/direction__consequences-assets-and-the-vault-as-a-website/): the memo in its own order, where the vault already is, the consequence layer — assets, consequences, standards mini-graphs, the capability × asset → consequence triple — eleven first consequences for `oc433z3m`, what it settles for the MVP brief, the build order, what needs the lead - Task briefs [T11](admin/work/T11/) (consequences and assets) and [T12](admin/work/T12/) (standards mini-graphs); [T04](admin/work/T04/) amended with _Who are you?_ - The data itself: `assets.json` and `consequences.json` in the vault, `CONSEQUENCES.md` derived, the _What follows_ view, two more scenarios - The research list documented from Google's pages — sending limits, suspension, the modify tools, Claude's web tools as a second leg — never provoked - The standards mini-graphs, and _Who are you?_ in the app with the MVP build ## Check us, rather than trusting us. The whole point of a digest is that somebody else can compute it. If you produce these documents, you do not have to take this page's word for what arrived — hash what you sent and compare. **Every document is recorded by the SHA-256 of the file exactly as we received it.** Hash your copy, look for the digest in the register, and anything that is not there did not reach us — or reached us and was not archived, which is our bug and worth telling us about. ``` # what did we actually receive? curl -s https://riskmandate.ai/briefs-register.json \ | jq -r '.documents[] | "\(.sha256) \(.status) \(.title)"' # is the brief I just sent in there? sha256sum my-brief.md ``` A register that only lists what was done is a press release. Every entry above carries what it asked for and did not get, and on most of the twenty-three that column is the longer one. It is kept that way deliberately: the value of this page is that it can embarrass us, and a version that could not would not be worth fetching. - **The file is the record, not this page.** [briefs-register.json](briefs-register.json) is what a program should read; this page renders it for people. If the two ever disagree, the file is right and the page is stale. - **Every archived document is byte-identical to what arrived.** Nothing is edited, reformatted or trimmed — including the parts we think are wrong. Where we disagree with a brief, the disagreement is published on the page it produced and marked as ours. - **Statuses go stale in one direction only.** An item marked _received_ can become _processed_. Nothing moves the other way, and nothing is deleted from the list once it is on it. - **If something is missing, that is the most useful thing you could tell us.** Use the contact control in the header and name the digest. Register maintained by hand alongside the work, and checked in CI: every document listed must exist at the path given and match its recorded digest, and every file in `assets/briefs/` must appear in the register. Last reconciled 16 September 2026. ## Twenty-three items. None untouched, and none finished. Every item now names something it produced and something it did not. Twenty of the twenty-three are marked _partly_, which is the honest state of almost all real work and the status this register expects to use most. The column that matters is the right-hand one.