Business cases, by the risk they change

A new section, from the lead's memo of today (D16↗). 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↗ 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↗. 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.