PaperlayerView exact revision on arXiv

Source-linked AI summary

Guidance on the Assurance of Machine Learning in Autonomous Systems (AMLAS)

Richard Hawkins, Colin Paterson, Chiara Picardi, Yan Jia, Radu Calinescu, Ibrahim Habli

arXiv:2102.01564v1cs.LGcs.AI

TL;DR

In open contexts, the gap between implicit intentions and explicit ML requirements makes safety requirements difficult to formalize, especially for rare events. AMLAS provides safety-case patterns and assurance activities; their integration into ML development has an explicit, structured safety case as a primary outcome.

  • Problem

    In open contexts, the semantic gap between implicit intentions and explicit requirements makes safety requirements difficult to formalize, while rare events challenge assurance based on data-encoded requirements.

    Source: Activity 3: Develop ML Safety… · p. 13

  • Method

    AMLAS combines safety-case patterns with a process and underlying assurance activities to integrate safety assurance into ML-component development and build its safety case.

    Source: Introduction · p. 3, Using this Document · p. 4

  • Results

    A primary outcome of AMLAS’s integration of safety assurance is an explicit and structured safety case.

    Source: Using this Document · p. 4

  • Takeaways & Limitations

    AMLAS provides an evidence base for explicitly justifying the acceptable safety of ML components integrated into autonomous-system applications.

    Source: Introduction · p. 3

    AMLAS is limited to the ML component and is not intended to replace system-level, domain-specific, or safe-autonomy standards and guidance.

    Source: Using this Document · p. 4

Abstract

from arXiv · show

Machine Learning (ML) is now used in a range of systems with results that are reported to exceed, under certain conditions, human performance. Many of these systems, in domains such as healthcare , automotive and manufacturing, exhibit high degrees of autonomy and are safety critical. Establishing justified confidence in ML forms a core part of the safety case for these systems. In this document we introduce a methodology for the Assurance of Machine Learning for use in Autonomous Systems (AMLAS). AMLAS comprises a set of safety case patterns and a process for (1) systematically integrating safety assurance into the development of ML components and (2) for generating the evidence base for explicitly justifying the acceptable safety of these components when integrated into autonomous system applications.

Introduction

AMLAS addresses the need for justified confidence in safety-critical autonomous systems using ML. It integrates safety assurance across ML development and builds evidence to justify component safety in its system context.

Introduction

  • AMLAS combines safety case patterns with a process for integrating assurance into ML development and generating evidence to justify component safety in autonomous systems.The guidance applies when ML components are integrated into autonomous system applications.Source: Introduction · p. 3
  • Its six lifecycle stages run from assurance scoping and safety requirements elicitation through data management, model learning, verification, and deployment.Scoping and requirements elicitation link system hazards and risks to ML safety requirements, which inform subsequent ML stages.Source: Introduction · p. 3
  • For each phase, AMLAS provides an argument pattern to explain how evidence supports safety claims while making assumptions, tradeoffs, and uncertainties explicit.The approach treats safety considerations within the wider system and operational context.Source: Introduction · p. 3

Overview of AMLAS

AMLAS is an iterative assurance process performed alongside ML component development, with stages that may need revisiting as evidence and interdependencies emerge. Each stage is organized around activities, artefacts, and an instantiated safety argument pattern.

Overview of AMLAS

  • The six-stage AMLAS process takes system safety requirements as input and develops an explicit safety case for an ML component in its system context.Assurance activities run in parallel with component development, and feedback links the stages in an iterative process.Source: Overview of AMLAS · p. 3, Figure 1 · p. 3
  • Stages may be repeated when verification finds requirements unmet, potentially prompting revision of model learning, data management, or the ML requirements themselves.The stages are interdependent, so activities may use artefacts produced earlier in other stages.Source: Overview of AMLAS · pp. 3–4
  • Each stage is presented through its objectives, inputs and outputs, and descriptions of activities, artefacts, and argument patterns.Stage descriptions also discuss common issues and misunderstandings.Source: Overview of AMLAS · p. 4
  • Each stage ends with an activity that instantiates a safety argument pattern from the artefacts and evidence generated during that stage.A safety case is a structured argument supported by evidence for a system's safety in a given application and operating environment; a safety case pattern is a reusable argument structure and evidence type.Source: Overview of AMLAS · p. 4

Using this Document

AMLAS guidance supports systematic safety assurance for ML components and the development of explicit safety cases. Its scope is component-level, so it complements rather than replaces broader safety, domain, and autonomy guidance.

Using this Document

  • AMLAS provides argument patterns and underlying assurance activities that can be instantiated to develop ML safety cases.The document aims to integrate safety assurance systematically into ML component development.Source: Using this Document · p. 4
  • AMLAS is limited to the ML component and should not be used alone in place of system, domain-specific, or safe-autonomy guidance.System safety requirements, including acceptable-risk targets, are expected from domain experts or relevant regulatory requirements.Source: Using this Document · p. 4
  • The guidance primarily focuses on offline supervised learning, especially classification, while reinforcement learning may also benefit in safety requirements and data management.Offline supervised learning is described as the predominant ML application for autonomous systems.Source: Using this Document · p. 4
  • The intended readers include safety engineers, ML developers, and stakeholders seeking assurance that safety considerations were explicitly and systematically considered.Readers are expected to have a basic understanding of ML, safety engineering, and autonomous systems.Source: Using this Document · pp. 4–5
  • AMLAS represents argument patterns using GSN, a graphical notation for explicitly capturing safety arguments.“Shall” marks a required guidance element, while notes and examples clarify activities; examples are not exhaustive, and planned case studies and experiments are expected to provide more complete examples.Source: Using this Document · p. 5

Stage 1. ML Safety Assurance Scoping

Stage 1 defines the ML component’s assurance scope within its system and operational context, then establishes a scoping argument linking allocated system safety requirements to the component. It uses system requirements and contextual artefacts to determine the allocation and document the resulting argument.

Objectives; Inputs to the Stage; Outputs of the Stage

  • The stage defines the safety-assurance and safety-case scope, establishes the top-level claim, and uses system safety requirements and context as inputs to produce allocated requirements and a scoping argument.Its inputs include system requirements, operating-environment and ML-component descriptions, and the scoping argument pattern.Source: Objectives · p. 6, Inputs to the Stage · p. 6

Description of the Stage

  • Two activities define the ML component’s assurance scope and generate artefacts used to instantiate the scoping argument pattern.An ML component comprises a model deployed on its intended computing platform, including hardware and software.Source: Description of the Stage · p. 6

Activity 1: Define the Safety Assurance Scope for the ML Component [E]

  • Allocated requirements control the ML component’s identified contributions to system hazards, accounting for architecture and operating environment without prescribing an ML technology or metric.The requirements are explicitly documented as artefact [E].Source: Activity 1: Define the Safety… · p. 6

Artefact [A]: System Safety Requirements

  • System safety requirements include concrete failure conditions linking ML outputs to potential hazards, and should state risk-acceptance criteria.Acceptance criteria may draw on comparisons with existing systems, standards, or stakeholder views.Source: Artefact [A]: System Safety Requirements · pp. 7–8

Artefact [B]: Description of System Environment

  • The operating environment must be explicitly described because deployment context, clinical oversight, and hospital ICU-admission criteria can affect requirements allocated to an ML component.The ICU example notes that admission criteria vary across hospitals with demand and capacity.Source: Artefact [B]: Description of System… · p. 9

Artefact [C]: System Description; Artefact [D]: ML Component Description

Activity 2: Instantiate ML Safety Assurance Scoping Argument Pattern [G]

Artefact [F]: ML Safety Assurance Scoping Argument pattern

  • The scoping argument’s top claim is that allocated system requirements are satisfied in the defined environment, linking the ML component’s safety case to the wider system argument.It assumes correct definition of allocated requirements; justification for that assumption belongs in the overall system safety case. The argument addresses development and deployment separately.Source: Artefact [F]: ML Safety Assurance… · p. 10

Stage 2. ML Safety Requirements Assurance

Stage 2 translates allocated system safety requirements into explicit ML safety requirements, validates them in context, and builds an assurance argument for their validity and satisfaction. Requirements address safety-related performance and robustness, while the argument connects them to model verification and the supporting data and learning processes.

Objectives; Inputs to the Stage; Outputs of the Stage

  • The stage develops ML safety requirements from allocated system requirements, validates them against system context, and creates an argument explaining the requirements, trade-offs, assumptions, and uncertainties.Its inputs include allocated requirements and an argument pattern; outputs include ML safety requirements, validation results, and an instantiated argument.Source: Objectives · p. 12, Inputs to the Stage · p. 12, Outputs of the Stage · p. 12

Description of the Stage

  • Three activities provide assurance in ML safety requirements, with this stage scoped to the model that produces the intended output.The generated artefacts are used to instantiate the requirements assurance argument pattern.Source: Description of the Stage · p. 12, Figure 6 · p. 12

Activity 3: Develop ML Safety Requirements [H]

  • ML safety requirements translate system-level hazard contributions into measurable performance and robustness criteria for safety-related outputs, while accounting for architecture and operating environment.The requirements should control identified risk contributions; examples include performance targets and robustness across specified lighting conditions or poses.Source: Activity 3: Develop ML Safety… · pp. 13–15
  • Requirements must address both performance and robustness because safety cannot generally be measured directly from the model, and different misclassifications can have different safety impacts.The guidance cautions against relying on a single metric, which may permit acceptance criteria to be met while unintended behaviour remains [1].Source: Activity 3: Develop ML Safety… · p. 14
  • Requirement development must make assumptions explicit and may derive requirements for emergent behaviour that could contribute to hazards.The guidance also identifies the semantic gap between implicit intentions for component outputs and concrete requirements, especially for rare safety events.Source: Activity 3: Develop ML Safety… · pp. 13, 15, 16

Activity 4: Validate ML Safety Requirements [J]

  • Validation checks whether ML safety requirements preserve the intent of allocated system requirements in context, using approaches such as expert review and simulation.Validation results are documented as artefact [J].Source: Activity 4: Validate ML Safety… · p. 16

Activity 5: Instantiate ML Safety Requirements Argument Pattern [K]

Artefact [I]: ML Safety requirements argument pattern

  • The argument pattern justifies translating allocated requirements into explicit ML requirements, then makes claims about their validity and satisfaction by the model.Performance and robustness claims are assessed requirement by requirement through verification; other requirement types, such as interpretability, may be included when relevant to system safety.Source: Artefact [I]: ML Safety requirements… · pp. 16, 18, 19

Stage 3. Data Management

Stage 3 provides assurance in ML data by defining data requirements, generating and analysing datasets against them, and documenting the resulting rationale and uncertainties. Its activities produce artefacts used to instantiate the ML data assurance argument.

Objectives

  • The stage defines data requirements, generates datasets for development and verification, assesses dataset sufficiency, and builds an argument from the resulting evidence.The argument states assumptions, trade-offs, and uncertainties in the requirements and their development and validation.Source: Objectives · p. 20

Inputs to the Stage; Outputs of the Stage

  • The stage takes ML safety requirements and a data argument pattern as inputs, and produces reports, datasets, logs, validation results, and an instantiated data argument.Listed outputs include internal test data and data-generation logs.Source: Inputs to the Stage · p. 20, Outputs of the Stage · p. 20

Description of the Stage

Activity 6: Define Data Requirements

Activity 6 derives data requirements from ML safety requirements so that data can support a model meeting them. Those requirements specify dataset characteristics, including relevance, completeness, accuracy, and balance.

Artefact [L]: Data Requirements

  • Data requirements specify relevance, completeness, accuracy, and balance, and explicitly state operating-environment assumptions and the data features needed to encode the domain.They are derived from ML safety requirements, especially those describing the system environment.Source: Artefact [L]: Data Requirements · p. 21, Activity 6: Define Data Requirements · p. 21
  • Data requirements for relevance specify how closely samples must match the intended operating domain, including representative vehicle sensor positioning or hospital imaging equipment.The examples exclude aerial-view road images and images from equipment outside the specified UK hospital context.Source: Artefact [L]: Data Requirements · pp. 21–22
  • Completeness requirements define coverage across measurable operating-domain variation, such as times and lighting conditions or a stated range of patient bilirubin levels.They can reference variation identified in ML safety requirements or the operating context.Source: Artefact [L]: Data Requirements · p. 22
  • Data requirements include development-data accuracy, with labels specifying the target position even for partially occluded pedestrians.The example records each pedestrian at the extremity closest to the roadway.Source: Artefact [L]: Data Requirements · pp. 22–23
  • A change in retinal-specialist labels produced a 30% relative reduction in errors, illustrating the importance of label quality to risk-acceptance criteria.The comparison was between majority voting by three specialists and adjudication by the same specialists.Source: Artefact [L]: Data Requirements · p. 23
  • Balance requirements specify sample distributions, but class-balanced data can still be biased across critical features such as environmental conditions, gender, or race.For a kidney-failure model intended for male and female patients, the training data was 93.6% male; the source notes limited diversity in other respects as well.Source: Artefact [L]: Data Requirements · p. 23

Artefact [M]: Data Requirements Justification Report

The data requirements justification report explains why the specified requirements can support a model meeting ML safety requirements. Activity 7 generates separate development, internal-test, and verification datasets through documented collection, preprocessing, and augmentation.

Artefact [M]: Data Requirements Justification Report

  • The data requirements justification report documents why the specified requirements are sufficient to make it possible to develop a model satisfying ML safety requirements.The justification may use expert review and statistical analysis to check that the data requirements preserve the intent of the safety requirements.Source: Artefact [M]: Data Requirements… · pp. 23–24

Activity 7: Generate ML Data [N], [O], [P]

  • Three datasets are generated to meet the data requirements: development data, internal test data, and verification data; the first two support development, while verification data is used in model verification.Development data includes training and validation data; developers test a model with internal test data before exposing it to verification data.Source: Activity 7: Generate ML Data [N], [O],… · p. 24
  • Data generation comprises collection, preprocessing, and augmentation, with collection using sources that address requirements and preprocessing preparing samples for the learning process.Collection may reuse suitable datasets or gather primary data; preprocessing can include labels and normalisation.Source: Activity 7: Generate ML Data [N], [O],… · pp. 24–25
  • Generation decisions and compromises, including missing-data handling and use of existing or simulated sources, should be documented with rationales in the data generation log.For simulators, configuration data supports repeatable collection and systematic verification and validation; separate assurance or approval may be needed.Source: Activity 7: Generate ML Data [N], [O],… · pp. 24–25
  • Augmentation can add data when real-world samples are infeasible to gather, using transformed samples or proxy systems; simulated conditions require documented justification as a sufficient reflection of reality.The examples include simulated lighting changes and rotations to represent a specified robustness range.Source: Activity 7: Generate ML Data [N], [O],… · pp. 25–26
  • Verification data collection seeks realistic failure conditions, keeps its information hidden from developers, and focuses on challenging combinations that may be absent from development data.A sample-specific fix does not establish robustness to the broader class of failures it represents.Source: Activity 7: Generate ML Data [N], [O],… · p. 26

Artefact [Q]:Data Generation Log

The data generation log records decisions made to produce datasets with the required features. Activity 8 validates whether the generated datasets meet data requirements and documents gaps and their justifications.

Artefact [Q]:Data Generation Log

  • A data generation log records decisions made during collection, processing, and augmentation to explain how the resulting datasets meet the data requirements.Expensive or impractical collection may leave gaps, for which the rationale should be stated; limited crossing types in the JAAD dataset may require justification for a planned deployment.Source: Artefact [Q]:Data Generation Log · p. 26, Activity 8: Validate ML Data [S] · p. 27

Activity 8: Validate ML Data [S]

  • Data validation checks whether all three generated datasets meet the data requirements and considers relevance, completeness, and balance.Discrepancies between generated data and requirements must be justified in the validation results.Source: Activity 8: Validate ML Data [S] · pp. 26–27
  • Relevance validation examines the gap between generated samples and the deployment environment, including whether simulated data assumptions are immaterial and context-specific features are represented.Cross-country use of hospital data should address how demographics, policies, and equipment differ and affect validity.Source: Activity 8: Validate ML Data [S] · p. 27
  • Completeness validation systematically seeks uncovered combinations of operating-domain variation; the search space grows combinatorially, and quantised continuous variables need justified levels.For road signs, the example spans 43 classes, seven time categories, seven weather categories, and eight occlusion levels, or 16,856 combinations; practical datasets may remain incomplete.Source: Activity 8: Validate ML Data [S] · p. 28
  • Balance validation considers class and feature distributions, and difficult-to-obtain or naturally rare classes may remain imbalanced if the validation results document and justify that imbalance.Feature balance may require examining combinations that are relatively rare, not just counting samples per class.Source: Activity 8: Validate ML Data [S] · pp. 28–29
  • Accuracy validation checks samples and preprocessing metadata against ground truth, using collection-process analysis, expert review of samples, or diverse data sources to identify systematic errors.Reused datasets may still need additional validation to ensure their labels fit the intended context.Source: Activity 8: Validate ML Data [S] · p. 29

Activity 9: Instantiate ML Data Argument Pattern [T]

Activity 9 uses the ML data argument pattern and artefacts from earlier activities to create an instantiated ML data argument.

Activity 9: Instantiate ML Data Argument Pattern [T]

Artefact [R]: ML Data argument pattern

The ML data argument pattern claims that development, test, and verification data are sufficient, and sets out how both the requirements and the datasets can be shown to support that claim.

Artefact [R]: ML Data argument pattern

  • The pattern claims sufficiency for all three datasets: development, test, and verification.Its argument proceeds through the defined ML data requirements.Source: Artefact [R]: ML Data argument pattern · p. 30
  • Data requirements must be sufficient to enable a model that can meet the ML safety requirements, though data alone cannot guarantee that outcome.The ML Data Requirements Justification Report supports the sufficiency claim.Source: Artefact [R]: ML Data argument pattern · p. 30
  • Lifecycle datasets must satisfy the defined requirements, with collection decisions logged and validation results used to assess each requirement type.The argument considers types such as relevance and completeness, with their inclusion justified explicitly.Source: Artefact [R]: ML Data argument pattern · p. 30

Stage 4. Model Learning

Stage 4 develops candidate models, tests them on internal data, selects among valid candidates against potentially conflicting requirements, and builds an assurance argument from the resulting evidence. The process records development decisions and explicitly addresses trade-offs, assumptions, and uncertainties.

Objectives

  • The stage develops a model against ML safety requirements, assesses it on internal test data not used in development, and builds an argument that explains trade-offs, assumptions, and uncertainties.These are the stage’s three stated objectives.Source: Objectives · p. 32

Description of the Stage

Activity 10: Create ML Model [V]

  • Developers choose a model type and tune candidate models using development data; cross-validation, leave-one-out, and early stopping are cited as ways to address overfitting.The choice rationale is recorded in the model development log.Source: Activity 10: Create ML Model [V] · pp. 32–33

Artefact [U]: Model Development Log

Activity 11: Test ML Model [V]

  • Candidates are tested on internal data withheld from development, and the process may iterate or revisit data management or requirements when no candidate meets them.In the example, bright-sunlight errors prompt consideration of collecting additional images for that failure mode.Source: Activity 11: Test ML Model [V] · p. 35
  • Selection is a multi-objective problem: valid models may trade off conflicting requirements, and the preferred balance can vary between rural and urban contexts.The text notes that multiple candidates may lie on the Pareto front and threshold choice matters.Source: Activity 11: Test ML Model [V] · p. 35

Artefact [X]: Internal Test Results

  • The retinal-diagnosis example uses ROC curves and confusion matrices to compare model and clinician performance, including 13 versus 20 urgent-to-routine errors for the model and specialist 1.The text says multiple metrics and a context-specific trade-off may be needed; a single human comparator may not be possible when human performance varies.Source: Artefact [X]: Internal Test Results · p. 36

Artefact [W]: Model Learning argument pattern

  • The learning argument supports model sufficiency through internal testing and the appropriateness of development activities, including model type, parameter tuning, and process decisions.The development log provides evidence for the model type, parameters, process, and tool-chain rationale.Source: Artefact [W]: Model Learning argument… · p. 38

Stage 5. Model Verification

Stage 5 verifies whether the model meets each ML safety requirement using test-based verification, formal verification, or both, and records evidence for an assurance argument. The guidance emphasizes independent, context-relevant verification and flags limits in translating formal results into operational meaning.

Objectives; Description of the Stage

Activity 13: Verify ML Model

  • At least one verification activity is required for every ML safety requirement; activities may combine test-based and formal verification, with results recorded.The verification strategy and any additional approaches should be justified.Source: Activity 13: Verify ML Model · p. 40, Artefact [BB]: ML Verification… · p. 45
  • Test-based verification uses independent data to examine learned properties, including robustness under adverse conditions, and may require added samples around uncertain or problematic regions.The guidance also calls for test completeness across variability dimensions and for keeping verification data from the development team.Source: Activity 13: Verify ML Model · pp. 41–42
  • Verification may use contextual mutators for blur robustness or human-in-the-loop evaluation for interpretability.The retinal-diagnosis example proposes showing segmentation maps without the diagnosis so users can assess their interpretability.Source: Activity 13: Verify ML Model · p. 42
  • Formal verification proves properties derived from safety requirements, but its results need valid abstractions and assumptions and may be hard to translate into operationally meaningful conditions.For high-dimensional images, a pointwise pixel-change bound may say little about robustness in rain; formal properties also require justified translation from requirements.Source: Activity 13: Verify ML Model · p. 43

Examples of verification evidence from testing; Examples of verification evidence from formal verification

  • Testing evidence can include neuron-activation corner cases or synthesized driving scenarios, while formal evidence can describe robust input regions or safe regions.The evidence should report examined scenarios and outcomes or the verified region dimensions, as applicable.Source: Examples of verification evidence from… · p. 44

Artefact [AA]: Verification Log

  • The verification log records strategy, test bounds and rationale, data-leakage controls, formal techniques, and the rationale for encoding natural-language requirements.Translating requirements into restricted formal languages may require domain expertise.Source: Artefact [AA]: Verification Log · pp. 44–45

Artefact [BB]: ML Verification Argument Pattern

  • The argument pattern links verification back to the safety-requirements claim and requires evidence of independence; its treatment of platform representativeness and formal-model validity is not developed further.The pattern allows testing, formal verification, or both, with justifications for the chosen combination and formal-property translation.Source: Artefact [BB]: ML Verification… · pp. 45, 47

Stage 6. Model Deployment

Stage 6 integrates the ML component into its target system and aims to show that allocated safety requirements remain satisfied during operation, supported by an assurance argument. It combines deployment activities, integration testing, and an argument pattern for integration and ongoing operation.

Inputs to the Stage

  • The stage takes system safety requirements, an environment description, and operational scenarios as inputs, and produces an erroneous behaviour log, integration test results, and a deployment argument.These are among the listed stage inputs and outputs.Source: Inputs to the Stage · pp. 6, 48, Outputs of the Stage · p. 48

Description of the Stage

  • Deployment involves three activities, and the resulting artefacts support instantiation of the deployment assurance argument; the process applies to initial and subsequent deployments.The activities provide a basis for deployment assurance.Source: Description of the Stage · p. 48, Figure 15 · p. 49

Activity 15: Integrate ML Model

  • System and environmental assumptions made during development should be monitored in operation, with mitigations for violations and their possible safety impact considered.The guidance gives daylight monitoring with handback to a human driver as an example.Source: Activity 15: Integrate ML Model · pp. 49–50
  • Integration must account for hardware suitability, computational capacity, input latency, and system-level handling of erroneous model outputs.For pedestrian detection, combining predictions across consecutive frames can compensate for possible single-image errors; the example specifies an 80% accuracy requirement.Source: Activity 15: Integrate ML Model · pp. 50–51

Artefact [DD]: Erroneous Behaviour Log

Activity 16: Test the Integration [FF]

Artefact [EE]: Operational Scenarios

  • Testing may use simulation, hardware-in-the-loop, or shadow deployment, but simulation requires evidence that it sufficiently represents the operational environment.Some physical properties are difficult to simulate and may require hardware-in-the-loop or real-system testing.Source: Artefact [EE]: Operational Scenarios · pp. 52–53

Artefact [GG]: ML Deployment Argument Pattern

  • The deployment argument separates the integration claim, supported by scenario testing and simulator evidence where applicable, from the claim that requirements continue to be met in operation.The operational claim includes system design and observed behaviour; the design argument addresses monitoring and acceptable responses to erroneous behaviour.Source: Artefact [GG]: ML Deployment Argument… · pp. 53, 55

Afterword

The authors thank reviewers and colleagues for their input. They describe the guidance as a first version, with case-study validation planned, and invite feedback and application experiences.

Acknowledgements

  • The authors thank colleagues and reviewers for contributing insights and feedback on an initial draft.The listed reviewers include Sean White.Source: Afterword · p. 56

Afterword

  • The document is a first version; validation through case studies in different domains was planned, with details to be added in an update.The authors also invite readers to apply the guidance and share their experiences.Source: Afterword · p. 56

Funding

  • The work was funded by Lloyds Register Foundation and the University of York through the Assuring Autonomy International Programme.Source: Afterword · p. 56
Loading 2102.01564v1…