NetRID slow-update scenario fails when Kentland RID KML is used with more than 2 SPs

[vgrafe]

Observed behavior

When running the netrid_early_integration_assessment configuration in qual-partners with 3 NetRID Service Providers, the run produces a broken HTML report and fails with:

ValueError: 3 service providers were specified, but data for only 2 test flights were provided

This appears to come from the scenario using the Kentland RID KML flight data:

monitoring/uss_qualifier/test_data/usa/kentland/rid.kml

That KML currently appears to define only 2 nominal flights:

• flight: south u
• flight: dairy circle

The scenario documentation for sp_operator_notify_slow_update says flights_data must contain 1 nominal flight per SP under test, so a 3-SP run needs 3 nominal flights.

Downstream issue with attached report artifact: https://github.com/utmimplementationus/tech_committee/issues/202

Test check

This fails before reaching a specific standards check. The relevant scenario appears to be:

monitoring/uss_qualifier/scenarios/astm/netrid/v22a/sp_operator_notify_slow_update.md

The mismatch is between:

• 3 configured service_providers
• 2 flights available in the flights_data source

Difference from expected behavior

A baseline qual configuration intended to run against 3 SPs should provide at least 3 nominal flights, or use a flight-data source that can generate enough flights for the configured SP count.

The ValueError itself appears correct, but the current baseline/data combination makes the qual run unusable for 3-SP testing. Also, the HTML report should ideally surface this as a clean configuration/setup failure rather than ending up broken.

Additional context

Possible fixes:

1. Add at least one more nominal flight to the Kentland RID KML, with distinct metadata and enough telemetry duration for the slow-update scenario.
2. Change the relevant baseline to use adjacent_circular_flights_simulation_source instead of the fixed Kentland KML source, so enough flights can be generated for the SP count.
3. Improve report generation for this configuration mismatch so the report remains readable even when the scenario cannot start.

[barroco]

Hi @vgrafe, thank you very much for opening this issue and related PRs.
I am wondering if this should not be addressed in your specific project. Examples provided by InterUSS are intentionally generic.
The problem you describe is a configuration issue and can be resolved at utmimplementationus configuration level by providing an appropriate KML file (like you proposed in #1535) with the test configuration. There is a similar need in another project which was addressed this way.

Regarding dynamic generation of the flights for the net rid test suite, may I kindly ask you to open a new issue as a feature request (suggested scope: Support dynamic generation of flights for the NRID test suite) so we can discuss it in the right context and perhaps other contributors can provide guidance on how to implement it.