## Business cases, by the risk they change

A new section, from the lead's memo of today ([D16](briefs.html)). The business case for a security
product is a difference: the risk register for an agent deployment without it, and the register
with it, from the operator who is paged to the board that has to defend it. The memo asked for it
to serve three readers at once: people buying security, the companies building it, and us. And it
asked whether earlier work already covered risks owned at several altitudes. It does: the
RiskGraph Explorer demo holds 49 facts, 49 risks and ten roles escalating to the board, and this
section runs on that model rather than a new one.

- **[Business cases, by the risk they change](business-cases.html)** sets out the method in five
  steps, none of them by hand. State the deployment in the model's sixteen questions. Write what the
  product does in its own words. Write the answers it changes, and say what kind of change each one
  is: stating what is true, an expectation, a setting, or a boundary. Compute both registers. Read
  the difference by altitude. The rules are the site's: the vendor's words quoted and dated, no
  verdict and no ranking, no conformity language, and what a product *adds* as part of its case.
- **[The first case is ours](business-case-riskmandate-abp.html).** An Agent Behaviour Policy
  blocks nothing. It replaces *don't know what it can reach* with the answer, which retires two
  risks and brings a hidden one onto the register: the typical agent can reach customer-facing
  systems. The instructions it gives the agent are listed as three reductions in likelihood,
  called expectations, and never as retirements. That is the lead's point that a hope-level policy
  is better than nothing, stated at exactly the strength it has.
- **Twelve categories of product**, from gateways and MCP gateways to backup, kill switches and
  posture management, each computed against the typical deployment. Each row is our reading of what
  the category does, not any vendor's claim, and each has a column for what it adds. Most retire
  one or two entries. A register gets small by combining them.
- **The engine is the Explorer's.** Its three rules are reproduced in
  `scripts/site/business-case/engine.mjs`. The model is copied with a digest per file, and the build
  refuses if a file drifts from its digest. CI checks that every page matches its data.

What was not done: two named cases, agentgateway and Auth0 for AI Agents, are built from their own
documentation but kept as drafts. They are unlisted and marked noindex until the lead decides to
send them to the vendors, which the section's rules require before anything about somebody else's
product is listed. Products whose effect the sixteen questions do not ask about cannot yet be
expressed. And a test now fails if a menu group's entries are split in the page list, after
placing the new entries inside the *More* group split it in two and pushed the header past
1280 pixels on every page, before this release.