[uss_qualifier][ASTM F3548-21] Add dedicated scenario for Operational Intent version/OVN consistency across updates

[shai-karassikov]

Is your feature request related to a problem? Please describe.

I would like to request dedicated uss_qualifier coverage for ASTM F3548-21 Operational Intent Reference version / OVN consistency across updates and repeated peer USS refetches.

On May 20, 2026, Wing reported a production interoperability issue to Flytrex related to Strategic Conflict Detection. Wing observed several Flytrex Operational Intents in production that were receiving new OVNs frequently while the Operational Intent Reference / details version remained the same. Wing stated that they index on the version field to determine whether an intent has been updated and whether details need to be refetched, and that this was actively affecting their ability to plan near those intents.

Wing provided example Operational Intent IDs observed in production:

• b00fd142-fa96-4073-8300-cec8bfa60d4e
• 60eb1430-27d1-4d70-9845-f537e5cd8f0e
• 8184ba67-f61e-4f29-9a10-4c324c13500b
• 5618ba3f-b906-4837-9c54-41a136b86089

Flytrex investigated, identified an issue on our side, deployed a fix on May 21, 2026, and Wing later confirmed that they had no further observations of the issue that day.

The reason I am opening this request is that Flytrex had passed the existing automated qualifier coverage shortly before this production issue. In our April 17, 2026 qualifier run, Flytrex passed the relevant check, Operational intent details have not changed without publishing a new version to the DSS, 108 times with 0 failures. So, at least in this case, passing the existing qualifier coverage did not rule out this class of production interoperability issue.

The relevant behavior appears tied to existing ASTM / InterUSS requirement areas, especially astm.f3548.v21.USS0005 and astm.f3548.v21.USS0105,1. In particular, changes to Operational Intent details need to be discoverable through the DSS, and the version field is the mechanism a peer USS can use to know whether it needs to retrieve details again.

From reviewing the current uss_qualifier coverage, there are related checks, for example:

• Operational intent reference reported by USS matches the one published to the DSS
• Operational intent details have not changed without publishing a new version to the DSS

However, the current coverage seems indirect/incidental rather than a scenario whose main purpose is to validate this behavior. In particular, the USS-to-USS path appears to catch this only if the same Operational Intent is fetched more than once in the same scenario with the same (id, version) key, and the relevant change happens in that window.

So a USS may pass the existing qualifier while still exposing a production failure mode where OVN/details change behavior is not correctly coupled to version from a peer USS perspective.

Describe the solution you'd like

Add a dedicated uss_qualifier scenario/check that validates Operational Intent version / OVN consistency across updates and repeated peer USS refetches.

A possible scenario could:

1. Plan/create an Operational Intent.
2. Fetch the Operational Intent Reference from the DSS.
3. Fetch Operational Intent details from the managing USS.
4. Perform one or more Operational Intent updates that should result in a new DSS OVN / reference version.
5. Refetch the Operational Intent Reference and details.
6. Assert that the version reported by the USS in the Operational Intent details remains consistent with the reference/version behavior published through the DSS.
7. Repeat/refetch over a short window to catch cases where OVN/details change while the reported version remains stale.

The goal is to catch cases where a peer USS may reasonably cache/index by version, but the managing USS changes OVN/details without making that change discoverable through the expected version progression.

Describe alternatives you've considered

The existing shared Operational Intent validation checks already cover some related behavior, but they appear to catch this only incidentally depending on scenario timing and cache-key reuse.

Flytrex has added internal regression coverage for the issue, but this seems like a general interoperability behavior that would benefit from standard qualifier coverage, since other USS implementations could potentially expose the same class of issue.

Another possible approach is to verify this through MockUSS behavior in InterUSS test environments, similar to how a peer USS would detect the issue in production.

Additional context

The existing check documentation already references the relevant requirement area:

• monitoring/uss_qualifier/scenarios/astm/utm/validate_shared_operational_intent.md
• Check: Operational intent details have not changed without publishing a new version to the DSS
• Requirements referenced there include astm.f3548.v21.USS0005 and astm.f3548.v21.USS0105,1

There also appear to be validator functions that may be relevant to this type of check, such as validate_fetched_oir and validate_searched_oir, though they may not currently be exercised by a dedicated scenario for this behavior.

This request is not intended as a bug report against an existing specific scenario outcome. It is a request to close a coverage gap exposed by a real Flytrex/Wing production interoperability issue: a USS can apparently pass the current qualifier while still serving Operational Intent version/OVN behavior that causes peer USS cache/refetch logic to miss updates.

[BenjaminPelletier]

Thanks for the report as we are always interested in filling coverage gaps (though note that "complete" coverage is not an achievable goal). However, in this case, I thought we already had coverage as described in the desired solution: to set up for "Attempt to modify activated flight into conflict test case", the "Nominal planning: conflict with higher priority" test scenario asks control_uss to modify Flight 2 and then performs a bunch of checks on the operational intent change, including one that matches the reference to the details which should catch a mismatch between versions in reference and details.

Could you provide a sequence view page for that test scenario where Flytrex was acting as control_uss so we can see why a version mismatch wasn't caught? I would expect this check to catch the situation where a USS doesn't inform the DSS when they change their operational intent. We have a number of users already sensitive to the duration of test runs, so we try to take whatever opportunities are available to add coverage without increasing test run time by adding new scenarios before seeking to add entirely new scenarios.