MB11 — Deployment Safety

Safety-case gap: does audited layer evidence plus bounded measured risk suffice for deployment-level safety? Precise bet: a certified safety case within deployment risk tolerance warrants abstract Safe.

What decision changes?

Before acting on a safety case, ask whether the argument stops at green layers and a risk bound, or whether it still needs an explicit deployment-tolerance judgment — and whether that judgment is inside the case's scope.

In the field this is Deployment Safety and the safety-case gap: does audited layer evidence plus bounded measured risk actually warrant deploying? Safety-case methodology, eval-to-deployment warrant talk, and GSAI-style assurance closure all orbit this crux. Where agendas agree: packaging a safety case; naming deployment risk tolerance. Where they diverge: Kosoy regret on MB2 is a value-learning cousin, not regret ⇒ Safe; packaging alone is not a bridge discharge; scope-exceeded is a defeater.

This project’s precise bet is MB11: a certified safety case within deployment risk tolerance is assumed to warrant abstract Safe. Lean assembles the case record (CertifiedSafetyCase: certification, invariants, eight alignment layers, RiskGap ≤ δ) from spine evidence — that step is bookkeeping. The only labeled arrow to Safe is MB11 plus a governance judgment WithinDeploymentRiskTolerance (a Prop-valued acceptance gate, not a computed failure probability).

This sits downstream of the other bridges and of the dynamical guarantee  framing in Chapter 3: safety is a trajectory claim, not a snapshot. MB11 names the residual bet that, once the antecedent is filled honestly, it is enough to act on. It is independently load-bearing — case plus tolerance do not imply Safe by logic alone.

What would count as evidence?

Evidence would include pre-registered eval batteries whose pass thresholds were fixed before outcomes were known, plus governance records showing the tolerance judgment was not reverse-engineered from the case.