# Meeting Minutes

## Metadata
| | |
|---|---|
| Client | Calderhaven |
| Reference | T788 |
| Meeting | Software — weekly check-in |
| Date | Tuesday 30 June 2026, 10:01 |
| Duration | 29m 06s |
| Attendees | Jacqui Fox, David Didsbury, Rebecca Gill (Trinzo); Marcus Oyelaran, Ines Duarte (Calderhaven) |

## Objectives
Resolve the outstanding questions on the SOUP list and anomaly review, and understand the status of the alarm regression testing ahead of the planned end-of-July release.

## Executive Summary
David Didsbury reopened the SOUP list, which stands at 43 items generated from the dependency lock file and therefore includes build and test tooling that never ships. Listing them is not wrong, but it obliges Calderhaven to perform anomaly analysis on all 43 when roughly 26 actually ship. The agreed approach is to split the list and cover the excluded category with a single written rationale pointing at the existing build environment control. Separately, the anomaly review records "none found" against around 30 items with no record of what was searched or when; a dated source column was agreed, and Ines Duarte offered to script it against the CVE API.

The alarm regression failed on audible alarm timing: 11 of 90 runs fell between 3.1 and 4.6 seconds against a 3-second requirement, and all 11 coincide with a full display redraw blocking the alarm path. The fix is understood and small, but requires a further two days of testing. Rebecca Gill raised whether the 3-second figure is clinically derived or arbitrary; David Didsbury agreed the provenance must be established but was firm that the requirement must not be changed in response to a failed test, as the sequence reads badly in a file regardless of the reasoning. The defect will be fixed either way. The end-of-July release date was explicitly not reconfirmed and is recorded as at risk.

## Key Discussion Points
| Topic | Discussion | Outcome |
|---|---|---|
| SOUP list scope | The list holds 43 items, up from 41, generated from the lock file and therefore including development dependencies such as the test runner. Roughly 26 form part of the released software item. Excluding the remainder requires a single category-level rationale referencing the build environment control, not an item-by-item review. | Agreed to split the list and write the exclusion rationale |
| Anomaly review evidence | Around 30 items are recorded as "none found" with no record of the source searched or the date. Ines Duarte believes the CVE database search was run around 12 February. David Didsbury asked for date, database, search term and result to be recorded, refreshed before each release. Marcus Oyelaran queried the burden at eight releases a year; Ines Duarte noted the search is scriptable via the API, roughly an afternoon of work. | Dated evidence columns agreed; scripting agreed but deferred behind the alarm regression |
| Alarm timing failure | Version 2.04 — distinct from the 2.4 in the other product line — failed audible alarm timing on the test rig. 11 of 90 runs measured between 3.1 and 4.6 seconds against a 3-second requirement. The failures are not random: all coincide with a full display redraw, which is blocking. The fix is estimated at an hour; re-running 90 runs takes two days because of the cool-down between runs. | Fix and full re-run agreed |
| Provenance of the 3-second requirement | Nobody present knows where the figure comes from. David Didsbury suggested 60601-1-8; Marcus Oyelaran acknowledged it may simply have been written by someone in 2019. Rebecca Gill noted that if the figure is arbitrary, 4.6 seconds might be acceptable and the retest unnecessary. David Didsbury rejected changing the requirement in response to the result, on the grounds that a sequence of failed test, changed requirement, passed test reads badly in a file even where the reasoning is sound. He also warned that if the source is 60601-1-8, the 3-second figure may apply only to high priority alarms, and Calderhaven has applied it to all alarms. | Requirement stands. Provenance to be traced separately and regardless of the test outcome |
| Unit test coverage | 81%, up from 79%. The untested remainder is largely the hardware abstraction layer, which cannot be tested without hardware. David Didsbury noted there is no coverage figure in the standard and that a justified 81% is stronger than an unjustified 95%. | Rationale to be written down rather than held informally |
| Release date | End of July was the standing plan. Two days of retest could still fit, but only if nothing else fails. Marcus Oyelaran declined to give a date and asked to revisit after the retest. | No date agreed. End of July formally recorded as at risk |

## Actions
| Owner | Action | Due |
|---|---|---|
| Ines Duarte | Split the SOUP list into items that form part of the released software and items that do not | Tue 7 July |
| Marcus Oyelaran | Write the exclusion rationale for build and test tooling, referencing the build environment control | Tue 7 July |
| Marcus Oyelaran | Fix the blocking display redraw and re-run the full 90-run alarm regression | Open — approximately two days of test time |
| Marcus Oyelaran | Trace the 3-second alarm requirement to its source, and establish which alarm priorities it applies to | Tue 14 July |
| Ines Duarte | Add date, database, search term and result columns to the anomaly review | Open |
| Ines Duarte | Script the CVE database search to write dated results into the anomaly sheet | Open — deferred behind the alarm regression |
| Ines Duarte | Document the rationale for the current unit test coverage and what is excluded | Open |

## Open Items
- End of July release date is at risk and will be revisited once the alarm regression re-run completes.
- Requirements history is accessible only to Marcus Oyelaran, which was noted as a separate problem and not addressed.