ults efficiently from practical sample sizes.

    Keywords: software, safety, hazard, demonstration, operational profile, automata, confidence, statistics
author:
- '\'
title: Software Safety Demonstration and Indemnification
---

\[section\] \[theorem\][Lemma]{} \[theorem\][Corollary]{} \[theorem\][Conjecture]{} \[theorem\][Fact]{}

\[theorem\][Definition]{}

Prologue
========

Copyright {#S:COPYRIGHT}
---------

This document may be freely copied or modified in accordance with the Creative Commons Attribution license[^1].

Executive summary {#S:EXECUTIVE_SUMMARY}
-----------------

In systems of integrated hardware and software, the intangible nature of software raises the question of fitness in roles bearing safety risk. Such a safety risk in software, known as a hazard, is a region of code involving safety constraints (requirements) necessitating some degree of verification. Hazards are identified and monitored by safety engineers, and possess hypothetical (threatened) frequency and severity ratings. During its development, potentially hazardous software merits not only rigorously controlled general engineering process, but also quantitative assurance of hazards within particular products.

### Approach {#S:APPROACH}

The topic of this essay is assuring the interplay between safety constraints (requirements) and software control. Software is appreciated as a branching process whose permutations are intractably numerous to test exhaustively. Barring exhaustive testing, statistical verification remains an option.

The degree of statistical verification will be expressed as residual risk, a contravariant quantity. A software item’s total risk has many constituents. For instance, any software communicating with an operator runs human factors risk. Statistical safety risk, one constituent of total risk, focuses on hazardous code. Code is potentially hazardous if its statistical risk (numerical product of frequency of execution, probability of error, and expected safety loss per error) is sufficiently high.

The