A policy per use case, and the £500 level is a prompt the customer runs

Date: 2026-09-15 · Author: @website-agent
Trigger: project lead's voice memo of 15 September, "Use Case Driven ABP Policy Strategy" (Otter transcript, about two minutes), received 15 September as a file and registered as D8
Reads against: direction__abp-as-a-graph-and-stakeholder-views.md (the memo it follows on from); store.sgit.ai v0.1.7 as read on 15 September (the four levels, /offers/, /d/t3/, /how-it-works/); the fifteen vaults; MAP-A-GRANT.md as shipped in every vault since v1.15.0

1. What the memo says, in its own order

1. Another primitive: the use case. Alongside a policy per target application and a policy

   per business function, a policy per workflow: "use case driven … we can then start combining several policies." The combination is the customer's; the examples are ours.

2. Voice Debrief as the worked case study, because its workflows are specific and already

   built, and because describing them advertises the product. Two are named:

   • The web flow. Upload audio on the website; transcribe; generate an infographic; the

     audio and the text go to "open router, multiple models", and the results come back. The lead's own reading of it: "the grant is that the data can go up anywhere. The mandate would be: I don't want anybody else apart from this transaction to see the data. But we don't know where the data is stored … we have no governance at this stage." A good example of governance precisely because the grant is unbounded and the mandate is narrow.

   • The WhatsApp flow through n8n, *"the one that has all those examples from the thing we

     created"*: the shape the n8n vault already measured, now as a use case.

3. Let the agent that knows the system write the policy. *"Let's create the prompt for the

   agent that I have that knows how voice debrief works and knows how the n8n workflow works to actually be the one that creates the policy, the grant, and the mandate that can then send to us and we can package it up."*

4. That is the third level of the store. *"We give the user a prompt for them to calculate

   what's happening in that environment, and then we'll take that prompt and we'll create the policy for you."* Four price points: the pack (£5), the vault (£50), the custom policy (£500, "the workflow is we give them a prompt, they run the prompt in the environment, they send us the result, and then we send them back the [policy]"), and two live sessions (£1,500).

5. Show what the £500 buys, in practice, and *"we need a page, and we need to map this

   app, and we need to map the server."* The store.sgit.ai agent is working on the store side; synchronise once it finishes.

2. Where we already are

• The prompt exists. MAP-A-GRANT.md travels in every vault since v1.15.0: it is the

  prompt for an agent that holds a credential to measure its own grant, draft the mandate from the deployer's words, and produce the two JSON files the generator turns into everything else. Its seven rules of measurement came from the n8n write-up, which was itself produced this way. The memo's workflow is that prompt with a return address.

• The n8n shape is measured. n8n-owner-api-key stands at seven of eight rows measured on

  a live sandbox. The WhatsApp-through-n8n use case is that grant with a different mandate: exactly what data/scenarios.json already models (six mandates per vault, the grant never changing). A use case is a scenario promoted to its own vault, with its own workflow description and, where the workflow spans several applications, the union of their grants.

• The store has the four levels live (v0.1.7, 15 September): £5 the pack by email, £50 a

  working vault, £500 corrected for your situation (agents with review), £1,500 two sessions and a professional signs. Its own ledger says levels 1 and 2 exist and run and levels 3 and 4 are specified, never run; its level-3 page says "you tell us the industry, the use case and the details" and "nobody interviews you at this level: you send the details and the work is done from them". The memo makes that concrete: the details you send are the output of a prompt you ran.

• The site now links to the store (v1.19.0): the homepage's view a policy / buy a policy,

  the pricing page rebuilt around the four levels, and a buy this policy link on every vault page to the store's page for the same slug (the store uses our slugs).

3. The £500 workflow, written down

What the customer does, what we do, and what arrives, so the level-3 page on both sites can say the same thing.

Two things the workflow depends on that do not exist yet: a return address for step 4 that is not a mailbox (a write-only vault link is on the store's not for sale yet list as a sharing primitive; until it exists, the order reference in an email is the honest answer), and a per-shape header for the prompt so the customer's agent knows which vault's vocabulary and reach names to use.

4. Voice Debrief as the first use-case vaults

Two vaults, both use-case in vault.json, both documented from the workflows as built rather than from a vendor page, because the workflows are ours to describe:

The memo's instruction is that the agent that knows the workflows writes these, using the prompt, and sends the files here to be packaged. That is the workflow in §3 run on ourselves first, which is the right order: the £500 level has never been sold once, and the first run should not be a customer's.

5. What this asks for, in order

1. A page for the £500 workflow on this site (how-the-corrected-level-works.html or a

   section of pricing.html): the seven steps, the prompt linked, what arrives, what does not. Done as a section of the pricing page in v1.19.0; a page of its own when the store's side has the return address.

2. The prompt with a header: a generated MAP-A-GRANT.md per vault that names the shape,

   the vocabulary version and the order reference placeholder. Small change to the generator.

3. The two Voice Debrief vaults, produced by the agent that knows the product, packaged

   here. A use-case status in vault.json and a Use cases group on the library page.

4. Combination: a vault whose grant is the union of two vaults' grants, with the source

   vault named on every row. The generator does not do this yet; it is the mechanism every real deployment needs and the third axis of the library.

5. Synchronise with the store agent on the level-3 page wording once its side lands: the

   same seven steps, the same prompt, the same what does not arrive.

6. What this does not settle

• Whether a use-case vault is a new status, a new group, or a scenario that has grown up.

  This brief says a vault with its own workflow description; the library's third axis.

• The return address for step 4. A mailbox works today and is the wrong long-term answer.
• Who reviews at level 3: agents with review is the store's phrase; the reviewer is a person

  and the note is what they sign off, but nothing here names them.

• The Voice Debrief grants themselves. They are documented from our own workflows, which is

  allowed; the model calls through a routing service reach providers whose retention we cannot read, which is a research_needed row, not a guess.