Skip to content

Minutes 20 Mar 2025

Paul Albertella edited this page Mar 20, 2025 · 1 revision

Host: Paul Albertella

Participants: Pete Brink, Sebastian Hetze, Igor Stoppa, Daniel Krippner, Gab Paoloni, Naga Gamidi

Agenda

  • Updates on documents
  • 'Safe' Linux vs 'Safety' Linux
  • Trustable Software Framework

Discussion

Updates on documents

Pete: Has some input, but not sure how to address some of them yet. Hoping for some more concrete suggestions and input.

  • Paul: We should definitely have a superset of possible criteria and a specific proposed set (distillation) for ELISA, which would then be reviewed more widely.
  • Pete plans to share this with other members of the community

Igor: Should we also consider whether the criteria are attainable?

  • Can we express our degree of confidence?
  • May be something that could be progressed in parallel
  • Methodologies, certain classes of evidence and certain arguments are difficult to make concrete, verifiable statements about: i.e. are subjective

Pete: One aim of this is to remove subjectivity where possible.

If you are going to have a hypothesis, then you must also specify some way to prove it

Igor: Survival bias can be a reason why we decide to do things in certain ways “This seems to work”

Paul: And sometimes we have to rely on ‘expert opinion’ to inform our decisions

Daniel: Are we making decisions here? Aren’t these associated with business?

Pete: The decisions here are “Do we want to publish this as ‘ELISA’ material?”

What we should have as a baseline is: can we record what inputs informed a decision and what criteria we considered in making that decision.

Safe vs Safety = Safe vs Safely

Igor: Safe in spite of Linux

Paul: How can we use Linux safely?

Pete: This is a framing that is expressed as ‘QM’ : a known quantity

Gab: There are further complexities that need to be considered when considering QM and/or pre-existing software. Provenance and the complexity of the software itself are factors to consider here.

  • ‘Safe’ here means ‘behaving according to our stated expectations’ - i.e. making a systematic capability claim about the software, if used according to its specifications
  • Chainsaw analogy: “Safe if you are using it for chopping down a tree, but not if you use it as cutlery”
  • ‘Safe’ as an intrinsic property vs ‘safe’ as a result of things being used safely

Igor: Tendency to hide information makes this kind of determination more difficult

Clone this wiki locally