Boundary of arguments

When we craft a safety argument it is of paramount importance to define its boundary, as it naturally exists due to commercial, technological, geographical, organisational, temporal, and other relevant barriers to which our scope of works interfaces. We need to be precise on what we assure for safety.

Key elements to attend are:

• Assumptions
• These are reasonable axioms grounded in natural laws or practice proven beyond reasonable doubt. 
• They need to remain valid to sustain safety argument.
• Constraints
• These can be limiting conditions of intended use of the system.
• These can be boundaries impacting safety argument during system emergence:
• Life cycle phases distribution
• Scope of works distribution
• Technological interfaces
• Georgaphic area or timing
• They need to be brought to awareness of stakeholders or/and end users to sustain safety argument.
• Exclusions
• These are commercial or organisational limitations for emergence of the system.
• They need to be brought to awareness of stakeholders to sustain performance argument.
• Dependencies
• These are incomplete or future actions of any stakeholder having impact on safety argument (including intended activities in remaining life cycle phases).
• They need to be resolved to complete safety argument
• These are administrative actions to enable a recorded safety control, they cannot amount to a new safety control (otherwise such one is to be managed separately).
• Configuration of hardware, firmware, midware, software and application data
• These are technical definitions of system under assurance
• They are subject to ongoing change management in the life cycle
• Configuration of documentation
• These are administrative and/or technical definitions of system under assurance
• They are subject to ongoing change management in the life cycle.

It is common to convert Dependencies and Constraints to safety related application conditions at system acceptance phase and beginning of operations. They can be transferred as safety records via safety cases/reports and/or Operation and Maintenance manuals. Configuration management is initiated by design and delivery organisation and sustained by the end user organisation during operations, it is relied upon as assumption at system emergence and use.

A well-defined claim of the safety argument should mention the safety target (what is achieved), safety principles (how it is achieved) and boundaries (where it is achieved), e.g.,

"The system is ready to be operated and maintained as safe to [GAMAB, ALARP, SFAIRP] principle subject to validity of assumptions, awareness of constraints, implementation of dependencies and adherence to conditions of indented use".

It is prudent to provide some recommendations to end users based on assumptions where monitoring or validation deems reasonably practicable in future.