When the problem statement drew the boundary of what this work is set against, it made a deliberate exclusion. It named provenance, attestation, and policy as the mechanisms to measure the contribution against, and it set aside the safety-assurance literature, the discipline of assurance cases and safety arguments, on the grounds that it consumes admissibility judgements rather than producing them. An exclusion made in passing is a weakness. It invites the reader to suspect that the excluded field was set aside because it was inconvenient. So this entry does the opposite of setting it aside. It engages the safety-assurance literature directly, and at its closest approach to this work's own territory, to show that the boundary was real and that the field itself draws it.
What an assurance case is
A safety case, in the standard definition the field uses, is a structured argument, supported by a body of evidence, that provides a compelling and valid case that a system is safe for a given application in a given operating environment (Hawkins et al., 2021). The argument is typically drawn in a graphical notation that lays out the top claim, the sub-claims and strategies beneath it, the context and assumptions it rests on, and the evidence at its feet. It is a rigorous and valuable discipline, used across aviation, rail, nuclear, and automotive safety. And three of its properties, taken together, place it firmly outside the question this work asks.
It is made at design time, about a system or a component, for a stated operating context. It is authored by engineers and read by reviewers and regulators; it is a document, not a mechanism that runs. And, most importantly, it takes the standing of its evidence as an input rather than producing it. A safety argument organizes evidence to show that a claim about a system is adequately supported. The credibility of that evidence, the test results, the verification, the analysis, is assumed to arrive from elsewhere, generated by domain experts or derived from regulatory requirements (Hawkins et al., 2021). The argument adjudicates whether the evidence is sufficient for the safety claim. It does not adjudicate the standing of the evidence itself. That is what it means to say the field consumes admissibility judgements rather than producing them.
The hardest case: assurance for machine learning
The strongest challenge to this exclusion is not the general safety-assurance literature but its most recent and most pointed extension: the assurance of machine learning itself. A mature methodology now exists for building safety cases for machine-learned components in autonomous systems, developed at the University of York, complete with a process, a set of reusable argument patterns, and a lifecycle running from requirements through data, training, verification, and deployment. If any part of the safety-assurance world produced action-relative admissibility for the outputs of a probabilistic model, it would be here, in the discipline built expressly to assure such models. So this is the case to test the exclusion against.
It holds, and it holds structurally rather than by luck. The methodology assures the component. Its claims take the form of requirements on the model in a context: that when the vehicle is a set distance from a crossing, the detection component shall identify pedestrians in their correct position (Hawkins et al., 2021). It reasons, before deployment, about whether the trained model is acceptably safe for that specified condition. It says nothing, and is not built to say anything, about whether a particular detection, made at a particular moment, should be acted upon. Its unit is the component and the operating context. It is not the individual claim and the individual action. And the evidence it marshals enters its argument with its standing already assumed; the methodology decides whether that evidence suffices for a safety claim about the component, not whether a given output carries a basis sufficient for the next physical act. The representation of a claim's basis, carried across a boundary and adjudicated at the point of use, is the thing this work builds, and it is precisely the thing the assurance case presupposes and does not supply.
A concession in the footnotes
There is a detail in that methodology worth surfacing, because the excluded literature turns out to name the gap itself. In its guidance on scoping, where a human provides oversight or fallback for a machine-learned component, it warns that the safety argument must account for the human factors involved, and it names automation bias directly: the tendency of a person to over-trust the output of an automated system. The safety literature sees the risk clearly. It flags that the human receiving the model's output may promote it to a fact it has not earned, and it hands that problem onward to the human-factors field rather than building a mechanism against it. That hand-off is the admissibility gap, appearing as a footnote inside the very discipline that was set aside. The exclusion was not a refusal to look. It was a recognition that this field, looking at the same problem, points at it and passes it on.
References
Hawkins, R., Paterson, C., Picardi, C., Jia, Y., Calinescu, R. and Habli, I. (2021). Guidance on the Assurance of Machine Learning in Autonomous Systems (AMLAS). University of York. arXiv preprint arXiv:2102.01564. arxiv.org/abs/2102.01564