Everything this store says, and how it knows

52 claims. Every chip on a page links to one of these rows.

The state of each thing on the offer list

• exists and runs — Fifteen Agent Behaviour Policy template shapes are published, free and public, with published read keys, at riskmandate.ai. The pack for any of them is what the £10 level sends: built, and it runs today. The templates being free is not a problem for this store — what is priced is the template with the mandate corrected, a name on the licence and no public key. (how we know: data/abp-catalogue.json, promoted from riskmandate.ai/abp-vaults.html with its content hash) abp-templates-exist
• exists and runs — A template shape is built into a vault by one command. The £50 level is that build, licensed to you, with the public key off it — a vault you hold the keys to, with its own app, its own history and a read key you can hand to anybody who asks how you govern the agent. Built, and it runs today. (how we know: riskmandate.ai/abp-vaults.html: every tile is a shape built into a vault by one command) abp-vault-build-exists
• delivered by a person — The £500 level is a named security professional's work, and that work has been done many times. The generator and the correction exist, the vaults are built from them, and six vaults of exactly this are published with read keys anybody can open. What is bought at this level is that person's time turned on your situation rather than a template's — which is why its delivery estimate is one to three days from your reply and depends on a calendar rather than on a queue. (how we know: data/offers.yml, t3) abp-correction-by-a-person
• delivered by a person — The £1,500 level is two sessions with a named security professional, who reviews the work and signs it off. That is not the company issuing a signed opinion as a formal instrument — that wording does not exist on this site — and the delivery page keeps the two apart, because the difference is the whole of what a buyer is and is not getting. (how we know: data/offers.yml, t4, read against the signed-opinion add-on) abp-sessions-by-a-person
• exists and runs — The catalogue on this site is promoted from riskmandate.ai at build time, with the source URL, the retrieval time and a sha256 of the page it was read from, because no page here that sells anything opens a network connection. A shape added upstream appears at the next build; one that arrives without a product code stops the build rather than rendering a tile whose buttons produce a code nobody can fill. (how we know: tools/promote_abp.py and data/abp-catalogue.json) abp-catalogue-promoted
• does not exist yet — The multi-format add-on's generator exists. The check that every variant renders the same fact set — the diff that must be empty — does not exist, and hard rule 6 forbids printing the guarantee before the check is built. So the guarantee is not printed. (how we know: 02__THE-HARD-RULES.md, rule 6) fact-diff-absent
• does not exist yet — The signed-opinion add-on's wording does not exist, and it must before a first signature. The offer is listed and cannot be bought: there is no code behind it. (how we know: 01__WHAT-TO-BUILD.md, the add-on rows) opinion-wording-absent
• read, not run — The corrected vault is estimated at one to three days from the buyer's reply — from the reply rather than from the payment, because until the details arrive there is nothing to correct against. It is an estimate rather than a measurement and is labelled as one; the constraint behind it is one person's calendar. The 24 hours is riskmandate.ai's commitment to follow up and is theirs to keep. The gap this closes was found by walking the store as a founder with six weeks to a term sheet, who left without buying and named the missing date as the reason. (how we know: data/offers.yml t3, and the synthetic-user run 2026-09-15-startups-01) t3-delivery-time-estimated

The offer line replaced on 15 September 2026

• built, not located — The application that would compute tier 1's delta was built in August and has not been located. Until it is, tier 1 is a questions page, and this site says so on the offer, on the delivery page and here. (how we know: 01__WHAT-TO-BUILD.md, the tier table) t1-app-not-located
• specified, not built — Tier 2 was specified on 28 July. The graph it selects from exists at 1,523 nodes with amendments applied. The pipeline that turns a situation into a vault does not exist. (how we know: 01__WHAT-TO-BUILD.md, the tier table) t2-pipeline-absent
• a booking, not a download — Tier 3 is a booking, and it overlaps the signed-opinion add-on. The overlap is recorded and unresolved, so the two are sold separately and neither page implies the other. (how we know: 01__WHAT-TO-BUILD.md, the tier table) t3-collision-open
• a booking, not a download — Tier 4 is a booking with a deposit: two sessions with a named security professional, whose time the deposit reserves. The seven-role team described in the pack is a specification rather than something staffed — what is delivered is one person's work, and the page says which before the conversation rather than after it. (how we know: 01__WHAT-TO-BUILD.md, the tier table) t4-is-a-booking-with-a-person
• projected — Tier 4's deposit is £500, and it is payable by link. The fee argument that put tier 4 on the invoice rail was always about the £10,000 and never about the deposit: at £10,000 a card costs up to about £250, and on the same rate £500 costs about £12. So the deposit is a payment link and the balance is not — two amounts, two rails, one offer. Arithmetic, not an invoice. (how we know: 01__WHAT-TO-BUILD.md, the price paragraph, applied to the deposit the same document already describes) t4-deposit-below-threshold
• does not exist yet — What happens to a deposit against an engagement that cannot be scheduled is not written down. Until it is, the deposit follows the conversation and a written scope and is never taken before one — which is a change to the flow rather than a promise on a page, because a promise about somebody's money that nobody has agreed is worse than an admission that the wording does not exist. (how we know: data/offers.yml, the t4 deposit record, and the same rule that holds the signed-opinion add-on off sale) t4-deposit-terms-absent

Who each offer was built for

• read, not run — For a team assessing an agent they already run, the market anchors between eight and one hundred and fifty thousand dollars, and nothing sits underneath it. The choice today is a five-figure engagement or nothing, and that gap is what tiers 1 and 2 are pointed at. (how we know: The audiences brief, in the pack at /dev-packs/store/) agent-market-gap
• read, not run — No productised, affordable, signed investor review exists at any price, and every component of one is already written. It is the emptiest quadrant on this site, and tiers 3 and 4 are what point at it — but the signature itself is a separate add-on whose wording does not exist. (how we know: The audiences brief, in the pack at /dev-packs/store/) investor-review-absent
• read, not run — For a founder, two funded incumbents and a free tier beneath them already publish the answer. Selling a startup a posture document is selling into a commoditised tier, so no offer here does. The unoccupied direction is the reverse one: what diligence will find, before it runs. (how we know: The audiences brief, in the pack at /dev-packs/store/) founder-tier-commoditised
• does not exist yet — Nothing on the offer list was built pointing at a startup. The startup group is assembled entirely from tiers built for somebody else, run in the opposite direction — it is a framing of tiers 3, 4 and 2, not a seventh thing on the price list. The reverse-direction offer does not exist as a separate purchase and is not sold as one. (how we know: data/buyers.yml, where the startup group's primary list is empty and the gate checks that it is) startup-offer-is-reverse-only

The lab, and what it is not

• specified, not built — The five pages at /lab/ are prototypes of a purchase flow, not a purchase flow. Nothing on them can be bought, no brief reaches us, no payment link sits behind anything on them, and which of the five (if any) becomes the real one is not decided. A build check fails the release if any of them stops saying so. (how we know: build.py, LAB_VIEWS and check_lab_is_marked in tools/check_site.py) lab-is-a-prototype
• delivered by a person — The mapping and policy work these briefs configure is done by a named security professional. Nothing in it is automated today, the seven-role team these prototypes describe is a specification rather than something staffed, and which parts could later be done without people is a decision nobody has taken. A brief is the thing a first call would otherwise be spent assembling — it is not a delivery. (how we know: 01__WHAT-TO-BUILD.md, the tier 4 row, read against what /lab/ configures) lab-fulfilment-is-people
• exists and runs — The configurator does not compute a price. Weighted selections add up, the total lands in one of four bands, and each band names one of the four tiers that already exist and its price. A configurator that emitted a number would be inventing a price, which is the first thing the pack says may not be invented — so the build fails if a band names an offer that is not on the list. (how we know: data/brief.yml, the bands table, and check_lab_bands in tools/check_site.py) lab-price-is-a-band
• specified, not built — The five prebaked scenarios are shapes somebody might arrive in, not counted frequencies. Nobody has measured how common any of them is. Each brief records which scenario it started from, so that what was assumed stays separable from what was answered — which is the only thing that makes starting from a guess safe. (how we know: data/brief.yml, the scenarios list) lab-scenarios-are-hypotheses
• exists and runs — A brief is written to the browser's own local storage and reaches nothing else. There is no form, input, textarea or select anywhere in this site's output and no page here that sells anything opens a network connection — both held by build checks — so exporting a brief hands the file to the reader rather than to us. (how we know: check_no_forms and check_no_network in tools/check_site.py) lab-brief-stays-local

How paying works, and why it works that way

• read, not run — A United Kingdom card account cannot tap in Portugal: the provider declines the transaction on detecting a different country, and says so in those words. A payment link is an online payment, so no cross-border rule applies to it. The conclusion the pack draws: no card reader should be bought. (how we know: The payment-rail brief, in the pack at /dev-packs/store/) card-reader-refused
• projected — The entry price has moved three times and every move is kept. £10 on 10 September, because at £5 the fixed card fee alone is about four per cent of the transaction. £5 on 15 September, by ruling, with the arithmetic unchanged and the judgement changed. £10 again on 16 September — and this time the number is not what moved. Two reviewers, one human and one invented, independently said £5 read as a commodity price for something sophisticated; the answer ruled was not a larger number for the same thing but a commercial licence over material that is public under CC BY, which is a different product rather than a dearer one. Every step stays on the page, because a price that moves quietly is a price nobody can argue with. (how we know: 01__WHAT-TO-BUILD.md, the price paragraph, and the pricing ruling of 15 September 2026) card-fee-floor
• projected — Prices are in pounds. Pricing in euros while settling in pounds adds about two per cent. (how we know: 01__WHAT-TO-BUILD.md, the price paragraph) pricing-in-pounds
• read, not run — The cloud marketplace's seller terms state that a seller is not permitted to collect customer payment information at any time. The two rails are therefore strictly separated: the marketplace is not a second button beside the card button, it is a different conversation with a different threshold. (how we know: The marketplace brief, in the pack at /dev-packs/store/) marketplace-no-customer-payment
• read, not run — The marketplace listing fee is 0.5 per cent, and falls to zero inside a qualifying multi-product solution. The pitch is procurement, not discount: the buyer already holds the marketplace's legal terms, so there is no master agreement, no vendor onboarding and no new purchase order. (how we know: The marketplace brief, in the pack at /dev-packs/store/) marketplace-fee
• read, not run — Professional services listings do not draw down committed spend on the cloud provider. Three independent sources state the exclusion. An earlier version of this claim said the opposite; the correction is recorded here rather than quietly dropped, and the old version appears on no page of this site. (how we know: The marketplace brief, correction carried in brief 2 of the pack) no-committed-spend
• specified, not built — Marketplace registration is the long pole: four to eight weeks. The listing is therefore a November surface, not an event surface, and nothing on this site depends on it. (how we know: 01__WHAT-TO-BUILD.md, the surface table) marketplace-registration
• part exists — One of the four levels can be paid for. Level one carries a payment link, created on 17 September 2026; levels two, three and four carry an empty checkout_url and render the reason rather than a button. Every link lives in data/offers.yml and nowhere else, and the gate holds whatever lands there to buy.stripe.com or checkout.stripe.com over HTTPS, so a checkout cannot quietly become a redirect through somewhere else. What the store sends with a buyer is the order reference, and the discount code when they arrived with one \u2014 never an amount, which is the provider's own. What comes back is nothing: this site has no server and no webhook, so it can say a line was sent to the provider and can never say it was paid. (how we know: data/offers.yml, and check_checkout_links in tools/check_site.py) checkout-links-not-issued
• read, not run — A standing payment link carries one price, and three of the six offers do not have one. Tier 2 and tier 3 are bands and tier 4 is a conversation, so only tier 1 can ever have a standing link; the banded tiers take a link issued once the band is fixed for the case. That is a property of a fixed-price link, not a policy, and it is why the checkout is not simply four buttons. (how we know: 01__WHAT-TO-BUILD.md, the price paragraph, read against how a fixed-price payment link works) checkout-bands-have-no-standing-link
• part exists — A discount code is recognised by the page, not by a rail. What ships is sha256 of the code and never the code, checked on every release against every byte of the built site — but a short code can be ground out of a hash, and that is said rather than dressed up. The thing that stops a stranger paying nothing is that a browser does not take money: a code changes the amount a payment link is issued for, and the rail decides what is charged. No rail exists yet, so today a code at a hundred per cent is how the whole flow gets walked without money. (how we know: data/discounts.yml and tools/check_site.py, check_discount_codes_are_not_printed) discount-code-is-in-the-browser
• read, not run — There is no , or anywhere in this site's output, and the reason boxes on [/review/](/review/) are the only place on this domain that can be typed into.** The rule was absolute until v0.1.15 and moved by ruling, to make room for a page that answers a partner's review — asking somebody to answer a critique with no way to answer it would have been the joke version of this site's whole argument. **What stayed absolute:** no, which is the element that submits; no and no, which is where a card number or an address gets typed; *no network connection on any page, which is the check that makes all of it a fact rather than a sentence; and no name attribute on the boxes, because a name is what a field is called when it is submitted and these are never submitted. What a reader types stays in their browser until they copy it out. *(how we know: tools/check_site.py, check_no_forms and check_the_typing_surface_is_inert) review-is-the-one-typing-surface
• read, not run — The entry level is a licence, not a download. The same files are published free under CC BY, which obliges anybody using them to attribute; what £10 buys is a commercial licence to the buyer over the same material, so it can go into client work, into a product or into a document for a regulator without carrying our name into it. It is grantable for one reason — the copyright in the pack is ours, because everything in it was written here — and that makes it a constraint on what may go into a pack from now on. The wording is not drafted. A grant to an unnamed holder has to read as a grant and not as a public re-licence of the same bytes, and until that is written this claim says what is intended rather than what is signed. (how we know: The project lead, 16 September 2026, and data/offers.yml) entry-level-dual-licence

What a finding is worth, and what may be promised

• measured — Recall-optimised agents run at 0.388 precision — about three findings in five are wrong. This is the reason the product is triage and never raw findings, and the reason every finding that reaches a buyer has been reproduced rather than reviewed. (how we know: The disclaimer brief, in the pack at /dev-packs/store/) precision-0388
• read, not run — The transparency article has applied since 2 August 2026 and reaches a third-country party whose output is used in the Union. Outputs here are model generated and are marked as such on the face of the artefact, not only in a footer. (how we know: The disclaimer brief, in the pack at /dev-packs/store/) transparency-article
• exists and runs — The regulation graph exists at 1,523 nodes, with amendments applied. It is the launch catalogue because the European regulation is expressly reusable commercially, including adaptation. (how we know: 01__WHAT-TO-BUILD.md and hard rule 10) graph-nodes
• read, not run — The international management standards are not adapted, translated, resold as a derivative, or fed to a model here — prohibited twice over, once as a derivative and once as a model input. The same prohibition covers the payment card standard and the centre's controls. Nothing on this site is derived from any of them. (how we know: 02__THE-HARD-RULES.md, rule 10) standards-not-adaptable

The words this site uses, and the words it does not

• read, not run — Tamper evident, given a witness — never the absolute form of that claim, which is false. A rewritten hash chain verifies against itself; tampering is detectable only when another party already holds an older hash. The witness is a second clone, which makes handing somebody a read key the act that makes the claim true. Append-only is stated as a policy, not a property. (how we know: 02__THE-HARD-RULES.md, rule 14) tamper-evident-witness
• does not exist yet — The sentence a reader expects from an encryption product — the one about what its operator can and cannot see — is not printed on this site in any form, because six questions about what leaks (filenames, directory structure, object sizes, commit timing, recovery or escrow, support access) have not been answered. In November 2020 a regulator acted against a company for claiming end-to-end encryption while its servers held the keys; the settlement imposed twenty years of third-party assessments. (how we know: 02__THE-HARD-RULES.md, rule 13) cannot-read-unanswered
• does not exist yet — Licence to operate — a permission granted by an authority, ruled 3 September — collides with a second phrase in the same vocabulary, written 17 July, which describes exposure already carried. They mean opposite things and both are in use. The collision was recorded on 8 September and is still open, so the second phrase appears on no page of this site and a build check keeps it off. (how we know: 03__THE-NAMES.md, the open collision) naming-collision-open
• read, not run — Three contested terms — one for encryption, one for recall, one for autonomy — do not appear anywhere on this site. What is used instead: end-to-end encrypted as the primary term, client-side encryption as the mechanical one, and durable for the property that resumes losslessly. The build fails if any of the three reaches a page. Each is described on the disclosures page↗. (how we know: 02__THE-HARD-RULES.md, rule 12) three-banned-words

The deadline, and what actually depends on it

• read, not run — The event is 17 and 18 September 2026, in Lisbon. The offer page and the payment codes are the only parts of this with a hard date. The merchandise surface, the catalogue of eight further offers and the marketplace listing do not depend on it. (how we know: 00__START-HERE.md, the deadline) event-dates
• read, not run — A ruling of 10 September placed a storefront under the risk product rather than on the platform domain. The instruction in hand overrode it and named this host. The ruling stands on the record, unedited, in the pack — and the build treats the host as moveable: every internal link is relative, the host appears in no copy, and the offer identifiers are stable. (how we know: 00__START-HERE.md and 03__THE-NAMES.md) domain-ruling-overruled

The handover, and what the two sites owe each other

• exists and runs — riskmandate.ai publishes one page per level — paid-t1 to paid-t4 — and since its v1.19.2 the level-one page is the download itself: the zip, its size, its sha256 and a check that hashes the file in the buyer's own browser against the hash that shape publishes. The size and the hash are stamped by their build, not typed, and a stale manifest fails their CI. This store does not copy any of it, because two copies of a hash is one hash that will go stale. (how we know: riskmandate.ai/after-payment.md, the table of four levels) post-sale-pages-exist
• does not exist yet — Nothing carries a sale from this store to the people who follow up. Their pages promise a person within 24 hours at the three vault levels, and that person needs the level, the order reference, the address paid with and — at £500 — the template chosen. A static site cannot send it: no page here opens a connection except to embed a published vault, and none will ever send anything about a reader. So until a rail exists whose receipt reaches them, the channel is the buyer's own first message from the page they land on. This is the one thing that gates the first paid order at those levels, and it is written here rather than assumed. (how we know: riskmandate.ai/after-payment.md, item 2 of five) sale-notification-absent
• built, not located — Their pages tell the buyer the order reference is on their receipt. No rail has issued a receipt yet, so what a real receipt says — and whether it carries the reference under that name or another — is not known. The store generates SG- plus six characters from an alphabet with no 0/O or 1/I, and hands it to the provider with the amount. What comes back on the receipt is the provider's to decide and has not been seen once. (how we know: riskmandate.ai/after-payment.md, the open list; data/checkout.yml, every url empty) receipt-reference-untested
• part exists — At £500 the buyer runs MAP-A-GRANT.md where the agent runs and sends back grant.json, mandate.json and the session record, with no secret in them. That route is email today. A write-only vault the buyer drops the files into is the intended route and does not exist yet; when it does, their level-three page changes and this store's wording changes with it. (how we know: riskmandate.ai/after-payment.md, the open list) level3-return-by-email
• built, not located — The four pages name one mailbox, and who owns it past the first orders is settled on neither site. This store names nobody: it links to the page that carries the address, so that when the person or the address changes it is one change on four pages there and none here. A mailbox duplicated onto a fifth page is a mailbox that will one day be wrong on one of them. (how we know: riskmandate.ai/after-payment.md, the open list) follow-up-owner-unnamed
• does not exist yet — The opinion add-on is listed here and has no page there. Their brief says: if the store lists it, say so and the page will be built in the same shape as the four. This store lists it — at /d/add-opinion/↗, marked absent, with the wording for a signed opinion recorded as not existing. The page after payment for it does not exist on either site, and nothing here says otherwise. (how we know: riskmandate.ai/after-payment.md, item 4 of five; data/offers.yml, add-opinion) opinion-add-on-has-no-page-there

What is true of what is sold here

• exists and runs — This work has been done, repeatedly, and it is published. Twenty-eight encrypted vaults are published at sgit.ai, each opened by a read key that site publishes on the vault's own page; six of them are this work — an agent's grant, its mandate and the delta between them, simulated end to end; an eleven-step risk-acceptance walk over one evolving register; a fact-to-risk graph explorer; a standard turned into something a position can be measured against; eleven linked threat models presented at a conference in Barcelona; and a regulation parsed into a graph you can cite a row of. What has not happened is a sale through this store. Those are two different sentences, and until this date this site printed only the second one and let a reader draw the first. (how we know: sgit.ai/demos/vaults/llms.txt, retrieved 16 September 2026, and data/evidence.yml) the-work-has-been-done

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