Section 54.6: Deployment approval and safety cases

Approval is evidence traceability, not confidence performed in prose.

A Safety-Critical Controls Researcher

Why This Matters

Deployment approval and safety cases sits at the boundary between learning and safety engineering. The question is not whether the policy usually behaves well, but whether dangerous states are detected, blocked, or exited fast enough to protect people, equipment, and mission goals.

A simple approval tuple is $$A = (\mathrm{ODD}, \mathrm{evidence}, \mathrm{defeaters}, \mathrm{residual\ risk}, \mathrm{rollback}),$$ where every element must be explicit enough for an external reviewer or internal safety board to challenge. Many teams then arrange this tuple in a goal-structuring tree so each top-level release claim has child claims, evidence links, and explicit challenge conditions.

Worked Example

A delivery robot may be approved for indoor daytime office routes with marked lanes and trained operators, but not for crowded public spaces or unstructured loading docks. Approval is domain-bounded by design.

approval = {
    "odd_defined": True,
    "evidence_complete": False,
    "override_tested": True,
    "residual_risk_named": True,
}
approval["release_ready"] = all(approval.values())
print(approval)

{'odd_defined': True, 'evidence_complete': False, 'override_tested': True, 'residual_risk_named': True, 'release_ready': False}

Expected output: The release is blocked because the evidence set is incomplete. That is exactly how a safety gate should behave: incomplete evidence is itself a meaningful decision signal.

Good approval practice names the boundary conditions clearly. A system can be approved for one environment, one workload, or one operator model without implying readiness everywhere else. In mature programs, each approval claim is backed by a trace matrix that points to benchmark artifacts, monitor tests, override results, and the exact owner for unresolved residual risks.

Formally, a release gate should check an objective such as task utility subject to explicit constraints on hazard rate, intervention latency, monitor coverage, and residual risk. The approved policy is therefore not merely the argmax of performance, it is the member of the candidate set whose evidence satisfies the safety case under the frozen operating-domain assumptions.

One of the most dangerous approval failures is domain creep, where a system slowly begins operating outside the bounded domain because no one wrote the exclusions sharply enough or monitored them after release.

Cross-References

This section sets up the capstone logic of Section 54.7 on assurance arguments and prepares the transition to Chapter 55 on deployment architecture. The approval tuple introduced here (ODD, evidence, defeaters, residual risk, rollback) becomes the leaf structure of the full assurance graph in Section 54.7, where each element is expanded into a claim, context, and evidence pairing that a release board can trace and challenge individually.