| Test characteristic | Value |
|---|---|
| Test run identifier | TR-2dba558 |
| Start time | 2026-03-03 21:57:40 UTC |
| End time | 2026-03-03 21:58:50 UTC |
| Test baseline identifier | TB-d714958 |
| Environment identifier | TE-c8d3580 |
| Codebase version | interuss/monitoring/v0.26.0-ede0a47 |
| Commit hash | ede0a4746bb52c78aead98c08eff4c68da1a9462 |
This artifact was generated by interuss/monitoring/v0.26.0-ede0a47
utm_auth (resources.communications.AuthAdapterResource)second_utm_auth (resources.communications.AuthAdapterResource)test_env_version_providers (resources.versioning.VersionProvidersResource)auth_adapter: From utm_auth resourceflight_planners (resources.flight_planning.FlightPlannersResource)auth_adapter: From utm_auth resourcedss (resources.astm.f3548.v21.DSSInstanceResource)auth_adapter: From utm_auth resourcedss_instances (resources.astm.f3548.v21.DSSInstancesResource)auth_adapter: From utm_auth resourcemock_uss (resources.interuss.mock_uss.client.MockUSSResource)auth_adapter: From utm_auth resourceprod_env_version_providers (resources.versioning.VersionProvidersResource)auth_adapter: From utm_auth resourceutm_client_identity (resources.communications.ClientIdentityResource)auth_adapter: From utm_auth resourceid_generator (resources.interuss.IDGeneratorResource)client_identity: From utm_client_identity resourceplanning_area_volume (resources.VolumeResource)planning_area (resources.PlanningAreaResource)volume: From planning_area_volume resourceproblematically_big_area (resources.VolumeResource)conflicting_flights (resources.flight_planning.FlightIntentsResource)invalid_flight_intents (resources.flight_planning.FlightIntentsResource)non_conflicting_flights (resources.flight_planning.FlightIntentsResource)This test scenario obtains versions for the specified systems.
A VersionProvidersResource containing the means by which to query system versions for each applicable participant.
✅ Provided by test_env_version_providers in top-level resource pool.
A SystemIdentityResource indicating the identity of the system for which to query the version from all providers.
✅ Provided by system_identity in suites.astm.utm.f3548_21.
Each version provider is queried for the version of its system (identified by system_identity) and the result is recorded as a note in the report.
If a valid response is not received from a version provider, they will have failed to meet versioning.ReportSystemVersion.
✅ uss1_core (2026-03-03T21:57:40.873895Z)
✅ uss2_core (2026-03-03T21:57:40.887593Z)
This scenario prepares flight planner systems for execution of controlled test scenarios by checking planner systems' readiness and having them remove any existing flights that may already be in the test area.
FlightPlannersResource listing all USSs undergoing planning tests so that they can be checked for readiness and instructed to remove any existing flights from the area in this scenario.
✅ Provided by flight_planners in top-level resource pool.
(Optional) MockUSSResource is checked for readiness and instructed to remove any existing flights from the area in this scenario.
✅ Provided by mock_uss in top-level resource pool.
DSSInstanceResource to check for lingering operational intents after the area has been cleared.
✅ Provided by dss in top-level resource pool.
FlightIntentsResource containing flight intents that will be used in subsequent tests, so all planners should be instructed to clear any area involved with any of these intents of flights it manages.
✅ Provided by invalid_flight_intents in top-level resource pool.
(Optional) If more than one FlightIntentsResource will be used in subsequent tests, additional intents may be specified with this resource.
✅ Provided by conflicting_flights in top-level resource pool.
(Optional) If more than one FlightIntentsResource will be used in subsequent tests, additional intents may be specified with this resource.
✅ Provided by conflicting_flights in top-level resource pool.
(Optional) If more than one FlightIntentsResource will be used in subsequent tests, additional intents may be specified with this resource.
✅ Provided by non_conflicting_flights in top-level resource pool.
All USSs are queried for their readiness to ensure later tests can proceed.
interuss.automated_testing.flight_planning.ImplementAPI
✅ uss1_core (2026-03-03T21:57:40.898127Z)
✅ uss2_core (2026-03-03T21:57:40.907155Z)
✅ mock_uss (2026-03-03T21:57:40.926761Z)
This readiness indicates the USS's ability to inject test data, so if this check fails, not only has the USS not met interuss.automated_testing.flight_planning.Readiness, but it also does not meet astm.f3548.v21.GEN0310.
✅ uss1_core (2026-03-03T21:57:40.898188Z)
✅ uss2_core (2026-03-03T21:57:40.907219Z)
✅ mock_uss (2026-03-03T21:57:40.926834Z)
All USSs are requested to remove all flights from the area under test.
interuss.automated_testing.flight_planning.ImplementAPI
✅ uss1_core (2026-03-03T21:57:40.963103Z)
✅ uss2_core (2026-03-03T21:57:40.996855Z)
✅ mock_uss (2026-03-03T21:57:41.035091Z)
✅ uss1_core (2026-03-03T21:57:41.052627Z)
✅ uss2_core (2026-03-03T21:57:41.070605Z)
✅ mock_uss (2026-03-03T21:57:41.084399Z)
✅ uss1_core (2026-03-03T21:57:41.097552Z)
✅ uss2_core (2026-03-03T21:57:41.110868Z)
✅ mock_uss (2026-03-03T21:57:41.124936Z)
✅ uss1_core (2026-03-03T21:57:41.138584Z)
✅ uss2_core (2026-03-03T21:57:41.152536Z)
✅ mock_uss (2026-03-03T21:57:41.166180Z)
interuss.automated_testing.flight_planning.ClearArea
✅ uss1_core (2026-03-03T21:57:40.963183Z)
✅ uss2_core (2026-03-03T21:57:40.996935Z)
✅ mock_uss (2026-03-03T21:57:41.035206Z)
✅ uss1_core (2026-03-03T21:57:41.052760Z)
✅ uss2_core (2026-03-03T21:57:41.070694Z)
✅ mock_uss (2026-03-03T21:57:41.084483Z)
✅ uss1_core (2026-03-03T21:57:41.097640Z)
✅ uss2_core (2026-03-03T21:57:41.110963Z)
✅ mock_uss (2026-03-03T21:57:41.125060Z)
✅ uss1_core (2026-03-03T21:57:41.138689Z)
✅ uss2_core (2026-03-03T21:57:41.152647Z)
✅ mock_uss (2026-03-03T21:57:41.166299Z)
uss_qualifier verifies with the DSS that there are no operational intents remaining in the area.
If the DSS fails to reply to a query concerning operational intent references in a given area, or fails to allow the deletion of an operational intent from its own creator, it is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:57:41.173965Z)
✅ uss1_dss (2026-03-03T21:57:41.178633Z)
✅ uss1_dss (2026-03-03T21:57:41.182543Z)
✅ uss1_dss (2026-03-03T21:57:41.186494Z)
If operational intents exist in the 4D area(s) that should be clear, then the current state of the test environment is not suitable to conduct tests so this check will fail.
This step examines whether any operational intents remain. If any foreign (other than uss_qualifier-owned) operational intents remain, then this step's checks will fail. If any uss_qualifier-owned operational intents remain, the checks for this step do not fail but instead we proceed to the next test case. If the area is clear, we skip the next test case.
✅ (2026-03-03T21:57:41.174124Z)
✅ (2026-03-03T21:57:41.178721Z)
✅ (2026-03-03T21:57:41.182621Z)
✅ (2026-03-03T21:57:41.186572Z)
∅ This test case was not applicable to this test run and is therefore not statused.
In addition to foreign flight planners, uss_qualifier may have left operational intents in the DSS from an incomplete previous run. This test case attempts to clean them up if they exist. If there are no operational intents from uss_qualifier in the flight intent areas, this test case will be skipped.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
The operational intent references managed by uss_qualifier discovered in the previous test case are removed.
uss_qualifier verifies with the DSS that there are no operational intents remaining in the area.
If the DSS fails to reply to a query concerning operational intent references in a given area, or fails to allow the deletion of an operational intent from its own creator, it is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,2, and this check will fail.
If operational intents exist in the 4D area(s) that should be clear, then the current state of the test environment is not suitable to conduct tests so this check will fail.
After removing the operational intents of all flight planning participants previously, and just having attempted to remove uss_qualifier-owned operational intents, the area should now be fully clear.
Verifies the behavior of a DSS for interactions pertaining to operational intent references being attached to explicit subscriptions.
DSSInstanceResource the DSS instance through which entities are created, modified and deleted.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
IDGeneratorResource providing the base entity ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
ClientIdentityResource the client identity that will be used to create and update operational intent references.
✅ Provided by utm_client_identity in top-level resource pool.
PlanningAreaResource describes the 3D volume in which operational intent references will be created.
✅ Provided by planning_area in top-level resource pool.
This test case ensures that no entities with the known test IDs exists in the DSS.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.196720Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:41.192927Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:41.202068Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:41.207916Z)
✅ uss1_dss (2026-03-03T21:57:41.211136Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
Ensures that the explicit subscription provided upon creation of an OIR is properly validated and attached to the OIR.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:41.227667Z)
This step verifies that an OIR cannot be created when an explicit subscription that does not cover the extent of the OIR is specified.
If the DSS under test allows the qualifier to create an OIR with an explicit subscription that does not cover the extent of the OIR, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:41.237416Z)
When the provided subscription covers the extent of the OIR, the OIR can be created, and is then properly attached to the specified subscription.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:41.270724Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.278817Z)
If the OIR returned by the DSS under test is not attached to the expected subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:41.278896Z)
Ensures that when the explicit subscription tied to an OIR is replaced with another explicit subscription, this subscription is properly validated and attached to the OIR.
Create an additional explicit subscription to be used in this test case.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:41.290914Z)
This step verifies that an OIR's existing explicit subscription cannot be replaced with an explicit subscription that does not cover the extent of the OIR.
If the DSS under test allows the qualifier to replace an OIR's existing explicit subscription with an explicit subscription that does not cover the extent of the OIR, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:41.302201Z)
∅ This test step was not applicable to this test run and is therefore not statused.
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
If the OIR returned by the DSS under test is not attached to the expected subscription, it is in violation of astm.f3548.v21.DSS0005,1
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss1_dss (2026-03-03T21:57:41.328482Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.307754Z)
If the OIR returned by the DSS under test is not attached to the expected subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:41.307833Z)
The test case that follows requires the creation of a fresh OIR and subscription. Therefore, this test case will clean up after itself.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.351173Z)
This test step fragment validates that a query to remove a subscription succeeds.
An attempt to delete a subscription when the correct version is provided should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:41.365410Z)
Checks that a DSS allows an OIR to be created in the accepted state without any subscription.
This step verifies that an OIR can be created in the ACCEPTED state without providing any subscription information (implicit or explicit) in the request.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:41.384528Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.394166Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:41.397404Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss1_dss (2026-03-03T21:57:41.397317Z)
Ensures that an explicit subscription can be attached to an OIR without subscription attached, and that the subscription is required to properly cover the OIR.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:41.409723Z)
This step verifies that the DSS refuses the request to attach an insufficient subscription to an OIR that currently has no subscription.
If the DSS under test allows the qualifier to attach an insufficient explicit subscription to a subscription-free OIR, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:41.421670Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.425910Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:41.429122Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss1_dss (2026-03-03T21:57:41.428996Z)
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss1_dss (2026-03-03T21:57:41.449033Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.457121Z)
If the OIR returned by the DSS under test is not attached to the expected subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:41.457177Z)
Checks that an OIR in the ACCEPTED state that is attached to an explicit subscription can be mutated in order to not be attached to any subscription.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss1_dss (2026-03-03T21:57:41.472260Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.479540Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:41.481753Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss1_dss (2026-03-03T21:57:41.481710Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.503812Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:41.496713Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.496685Z)
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:41.508490Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:41.514619Z)
✅ uss1_dss (2026-03-03T21:57:41.527486Z)
✅ uss1_dss (2026-03-03T21:57:41.537315Z)
✅ uss1_dss (2026-03-03T21:57:41.539671Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:41.522238Z)
✅ uss1_dss (2026-03-03T21:57:41.534550Z)
Checks that implicit subscriptions are properly created, mutated and cleaned up.
DSSInstanceResource to be tested in this scenario.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
IDGeneratorResource providing the Subscription IDs for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which subscriptions will be created.
✅ Provided by planning_area in top-level resource pool.
ClientIdentityResource provides the identity that will be used to interact with the DSS.
✅ Provided by utm_client_identity in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.547571Z)
✅ uss1_dss (2026-03-03T21:57:41.550766Z)
✅ uss1_dss (2026-03-03T21:57:41.553341Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:41.545061Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:41.556351Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:41.559055Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
This step creates an OIR with an implicit subscription and confirms that the subscription can be queried
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:41.576761Z)
This test step fragment validates that implicit subscriptions are created and can be queried, and that they have the correct temporal parameters.
The creation of an operational intent which:
is expected to trigger the creation of a new implicit subscription.
If the DSS does not create the implicit subscription, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.586689Z)
This test step fragment validates the time-bounds of an implicit subscription
If the implicit subscription time boundaries do not cover the OIR's, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.587604Z)
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.600116Z)
Upon deletion of an OIR that is associated to an implicit subscription, if the subscription has no other associated OIRs, the DSS is expected to remove it.
If a query attempting to fetch the implicit subscription succeeds, it implies that the implicit subscription has not been removed, and the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.607455Z)
If, after the DSS is left in the same state as it was 'found' for an area, the subscriptions currently active do not correspond to the ones that were present when the test case started, the DSS may be failing to properly implement astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:41.607509Z)
This test case verifies that implicit subscriptions belonging to OIRs that are created, updated and deleted are properly managed.
In particular, the scenario verifies that:
Create an OIR with which interactions will be tested and request an implicit subscription to be created.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:41.621254Z)
This test step fragment validates that implicit subscriptions are created and can be queried, and that they have the correct temporal parameters.
The creation of an operational intent which:
is expected to trigger the creation of a new implicit subscription.
If the DSS does not create the implicit subscription, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.630591Z)
This test step fragment validates the time-bounds of an implicit subscription
If the implicit subscription time boundaries do not cover the OIR's, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.631513Z)
This step creates an OIR in the ACCEPTED state that overlaps with the previously created OIR:
it does not request the creation of an implicit subscription and does not attach the OIR to any subscription explicitly.
This step expects that the implicit subscription from the previously created OIR is mentioned in the response's notifications, and that no new implicit subscription is created.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:41.644782Z)
If the newly created OIR does not mention the implicit subscription from the previous OIR in its notifications, the DSS is either improperly managing implicit subscriptions, or failing to report the subscriptions relevant to an OIR, and therefore in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,5 respectively.
✅ uss1_dss (2026-03-03T21:57:41.647117Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.652299Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:41.647059Z)
✅ uss1_dss (2026-03-03T21:57:41.654385Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss1_dss (2026-03-03T21:57:41.654346Z)
This step mutates the first OIR, which has an implicit subscription, to no longer overlap with the second OIR.
The mutation request does not specify an existing subscription, and provides the parameters required for the creation of an implicit subscription.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss1_dss (2026-03-03T21:57:41.674797Z)
The implicit subscription attached to the mutated OIR should be able to be queried.
If it cannot, the DSS is either improperly managing implicit subscriptions for OIRs, or failing to report the subscriptions relevant to an OIR, in which case the DSS is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,5, respectively.
✅ uss1_dss (2026-03-03T21:57:41.684092Z)
This test step fragment validates the time-bounds of an implicit subscription
If the implicit subscription time boundaries do not cover the OIR's, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.684985Z)
If the DSS chose to create a new implicit subscription instead of updating the existing one, and the DSS did not remove the previous subscription, the DSS is in violation of either astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:41.687612Z)
This step creates a new OIR that only overlaps the OIR that has no implicit subscription, and expects to not have to notify any subscription related to the OIRs created in this scenario.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:41.699761Z)
Within a geotemporal area that does not intersect with any of the implicit subscriptions that are left within the DSS, the subscriptions returned for an OIR created within said area should correspond to the ones that were present when the test case started.
Otherwise, the DSS may be failing to properly implement astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:41.701948Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.707951Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:41.701900Z)
✅ uss1_dss (2026-03-03T21:57:41.710159Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss1_dss (2026-03-03T21:57:41.710120Z)
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.718510Z)
✅ uss1_dss (2026-03-03T21:57:41.733933Z)
✅ uss1_dss (2026-03-03T21:57:41.745319Z)
This test case verifies that implicit subscriptions are properly removed if they become unnecessary following the mutation of an OIR.
Creates two OIRs with an implicit subscription, which will then be replaced by an explicitly created subscription and deleted by an update that requests no subscription, respectively.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:41.762115Z)
✅ uss1_dss (2026-03-03T21:57:41.789803Z)
This test step fragment validates that implicit subscriptions are created and can be queried, and that they have the correct temporal parameters.
The creation of an operational intent which:
is expected to trigger the creation of a new implicit subscription.
If the DSS does not create the implicit subscription, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.771415Z)
✅ uss1_dss (2026-03-03T21:57:41.798845Z)
This test step fragment validates the time-bounds of an implicit subscription
If the implicit subscription time boundaries do not cover the OIR's, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.772901Z)
✅ uss1_dss (2026-03-03T21:57:41.799815Z)
This test step creates a subscription that will be used to replace the implicit subscription that was created for an OIR.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
Check creation succeeds and response is correct.
✅ uss1_dss (2026-03-03T21:57:41.809049Z)
This step updates the OIR to use the subscription that was created in the previous step, and expects the previous implicit subscription to be removed.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss1_dss (2026-03-03T21:57:41.830624Z)
If the implicit subscription that was attached to the OIR is still present after the OIR is updated to use another subscription, the DSS is failing to properly manage implicit subscriptions for OIRs, and is therefore in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.838089Z)
This step updates the OIR to not use any subscription, and expects the implicit subscription to be removed.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss1_dss (2026-03-03T21:57:41.854779Z)
If the implicit subscription that was attached to the OIR is still present after the OIR is updated to use another subscription, the DSS is failing to properly manage implicit subscriptions for OIRs, and is therefore in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.861916Z)
This fragment can be used by test cases that need to clean up after themselves by deleting the OIRs and subscriptions created during the test.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.872494Z)
✅ uss1_dss (2026-03-03T21:57:41.882335Z)
This test step fragment validates that a query to remove a subscription succeeds.
An attempt to delete a subscription when the correct version is provided should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:41.889198Z)
This test case checks that a DSS will properly expand an implicit subscription to cover an OIR that is being attached to it.
Create an OIR with which interactions will be tested and request an implicit subscription to be created.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:41.907826Z)
This test step fragment validates that implicit subscriptions are created and can be queried, and that they have the correct temporal parameters.
The creation of an operational intent which:
is expected to trigger the creation of a new implicit subscription.
If the DSS does not create the implicit subscription, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.916845Z)
This test step fragment validates the time-bounds of an implicit subscription
If the implicit subscription time boundaries do not cover the OIR's, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.917729Z)
Expand the previously created OIR's duration while explicitly specifying the implicit subscription that was automatically created for it.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss1_dss (2026-03-03T21:57:41.933916Z)
The implicit subscription attached to the mutated OIR should be able to be queried.
If it cannot, the DSS is either improperly managing implicit subscriptions for OIRs, or failing to report the subscriptions relevant to an OIR, in which case the DSS is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,5, respectively.
✅ uss1_dss (2026-03-03T21:57:41.942194Z)
This test step fragment validates the time-bounds of an implicit subscription with respect to the OIRs it needs to cover.
If the implicit subscription's time boundaries do not cover every OIR attached to it, the DSS is in violation of astm.f3548.v21.DSS0005,1.
Ensure that the attached implicit subscription has been expanded
✅ uss1_dss (2026-03-03T21:57:41.943144Z)
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:41.955339Z)
This test case verifies that an implicit subscription can be used to replace an explicit subscription attached to an OIR.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
Create an explicit subscription to be initially set on the first OIR created in this test case
✅ uss1_dss (2026-03-03T21:57:41.964735Z)
Create an OIR bound to the explicit subscription created in the previous step.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:41.981869Z)
Create a second OIR with an implicit subscription, which will then be used in the next step.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:41.998070Z)
This test step fragment validates that implicit subscriptions are created and can be queried, and that they have the correct temporal parameters.
The creation of an operational intent which:
is expected to trigger the creation of a new implicit subscription.
If the DSS does not create the implicit subscription, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.006286Z)
This test step fragment validates the time-bounds of an implicit subscription
If the implicit subscription time boundaries do not cover the OIR's, the DSS is in violation of astm.f3548.v21.DSS0005,1.
Confirm that an implicit subscription was created.
✅ uss1_dss (2026-03-03T21:57:42.007157Z)
Replace the first OIR's explicit subscription with the implicit one created in the previous step.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
Confirm that the query to replace the second OIR's explicit subscription with the second OIR's implicit subscription succeeds.
✅ uss1_dss (2026-03-03T21:57:42.025479Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.032693Z)
If the OIR returned by the DSS under test is not attached to the expected subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:42.025536Z)
✅ uss1_dss (2026-03-03T21:57:42.032741Z)
This fragment can be used by test cases that need to clean up after themselves by deleting the OIRs and subscriptions created during the test.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.044563Z)
✅ uss1_dss (2026-03-03T21:57:42.060905Z)
This test step fragment validates that a query to remove a subscription succeeds.
An attempt to delete a subscription when the correct version is provided should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:42.071754Z)
This test case verifies that an implicit subscription can be attached to an OIR that is not currently attached to any subscription.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:42.088237Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.096281Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:42.090359Z)
✅ uss1_dss (2026-03-03T21:57:42.098383Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss1_dss (2026-03-03T21:57:42.098341Z)
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:42.114049Z)
This test step fragment validates that implicit subscriptions are created and can be queried, and that they have the correct temporal parameters.
The creation of an operational intent which:
is expected to trigger the creation of a new implicit subscription.
If the DSS does not create the implicit subscription, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.122575Z)
This test step fragment validates the time-bounds of an implicit subscription
If the implicit subscription time boundaries do not cover the OIR's, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.123511Z)
Attach the first OIR to the implicit subscription created with the second OIR.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss1_dss (2026-03-03T21:57:42.141633Z)
Confirms that the DSS properly attached the first OIR to the implicit subscription created with the second OIR.
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.149213Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.149213Z)
If the OIR returned by the DSS under test is not attached to the expected subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:42.141735Z)
✅ uss1_dss (2026-03-03T21:57:42.149270Z)
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.160503Z)
✅ uss1_dss (2026-03-03T21:57:42.175985Z)
This test case ensures that, when a client mutates an OIR not attached to any subscription without specifiying either a subscription identifier nor parameters for an implicit subscription, the DSS under test will correctly keep the OIR unattached to any subscription.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:42.189655Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.196758Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:42.191888Z)
✅ uss1_dss (2026-03-03T21:57:42.198938Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss1_dss (2026-03-03T21:57:42.198897Z)
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss1_dss (2026-03-03T21:57:42.211212Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.218188Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:42.220456Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss1_dss (2026-03-03T21:57:42.220407Z)
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.229562Z)
This test case ensures that a DSS properly allows a client to request that a new implicit subscription be created for an existing OIR with an explicit subscription attached.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:42.238719Z)
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:42.259141Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.267163Z)
If the OIR returned by the DSS under test is not attached to the expected subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:42.267218Z)
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss1_dss (2026-03-03T21:57:42.284569Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.292740Z)
If the DSS under test fails to attach the OIR to a subscription that is different from the one it is currently attached to when it is requested to do so, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.284673Z)
✅ uss1_dss (2026-03-03T21:57:42.292794Z)
This test step fragment validates that a query to read a subscription succeeds.
If a subscription cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:42.296923Z)
If the DSS under test fails to attach the OIR to an implicit subscription (which may either already exist or be newly created) when it is requested to do so, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.296971Z)
This fragment can be used by test cases that need to clean up after themselves by deleting the OIRs and subscriptions created during the test.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.310265Z)
This test step fragment validates that a query to remove a subscription succeeds.
An attempt to delete a subscription when the correct version is provided should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:42.322050Z)
This test case ensures that a DSS properly allows a client to request that a new implicit subscription be created for an existing OIR that is not attached to any subscription.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:42.336970Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.344400Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:42.339069Z)
✅ uss1_dss (2026-03-03T21:57:42.346427Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss1_dss (2026-03-03T21:57:42.346387Z)
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss1_dss (2026-03-03T21:57:42.361257Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.369562Z)
If the DSS under test fails to attach the OIR to a subscription when it is requested to do so, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.361353Z)
✅ uss1_dss (2026-03-03T21:57:42.369611Z)
This test step fragment validates that a query to read a subscription succeeds.
If a subscription cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:42.373929Z)
If the DSS under test fails to attach the OIR to an implicit subscription (which may either already exist or be newly created) when it is requested to do so, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.373976Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.406799Z)
✅ uss1_dss (2026-03-03T21:57:42.410032Z)
✅ uss1_dss (2026-03-03T21:57:42.417077Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:42.395347Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.395298Z)
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:42.422569Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:42.425153Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
Verifies the behavior of a DSS for simple interactions pertaining to operational intent references.
DSSInstanceResource the DSS instance through which entities are created, modified and deleted.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
IDGeneratorResource providing the base entity ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
ClientIdentityResource the client identity that will be used to create and update operational intent references.
✅ Provided by utm_client_identity in top-level resource pool.
PlanningAreaResource describes the 3D volume in which operational intent references will be created. Note that any start or end times specified in the underlying volume template
will be ignored.
✅ Provided by planning_area in top-level resource pool.
This test case ensures that no entities with the known test IDs exists in the DSS.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.435320Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:42.432524Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
This test case confirms that an OIR can be created when the correct parameters are provided, and that it can be deleted when the proper OVN is provided.
This test step fragment validates that:
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:42.449465Z)
This test step fragment validates that an operational intent references creation returns a body in the correct format.
The response to a successful operational intent reference creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.604600Z)
A successful operational intent reference creation query is expected to return a body, the content of which reflects the created operational intent reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:42.605640Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.605312Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.605356Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.605390Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.605626Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.605422Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.605455Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.605484Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.605543Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.605511Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.605572Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
Create an OIR with allowed parameters.
✅ uss1_dss (2026-03-03T21:57:42.605599Z)
This test step fragment validates that deleting an operational intent reference succeeds and returns the expected deleted operational intent reference.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.615457Z)
The response to a successful operational intent reference deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.623183Z)
A successful operational intent reference deletion query is expected to return a body, the content of which reflects the operational intent reference at the moment of deletion. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:42.624231Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.623735Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.623788Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.623823Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.624217Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.623861Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.623893Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.623922Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.623981Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.623950Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.624036Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.624123Z)
This test step fragment attempts to validate a single operational intent reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the oir_validator.py class.
If the version of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.624181Z)
If the OVN of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
Delete the OIR created in the previous step.
✅ uss1_dss (2026-03-03T21:57:42.624071Z)
Ensures that a DSS will only delete OIRs when the correct OVN is presented.
This test step fragment validates that:
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:42.638970Z)
This test step fragment validates that an operational intent references creation returns a body in the correct format.
The response to a successful operational intent reference creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.646721Z)
A successful operational intent reference creation query is expected to return a body, the content of which reflects the created operational intent reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:42.647610Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.647288Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.647331Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.647365Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.647596Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.647395Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.647425Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.647452Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.647512Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.647480Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.647540Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
Create an OIR to be used in this test case.
✅ uss1_dss (2026-03-03T21:57:42.647569Z)
This step verifies that an existing OIR cannot be deleted with a missing OVN.
If the DSS under test allows the qualifier to delete an existing OIR with a request that provided an empty OVN, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:42.649047Z)
This step verifies that an existing OIR cannot be deleted with an incorrect OVN.
If the DSS under test allows the qualifier to delete an existing OIR with a request that provided an incorrect OVN, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:42.651849Z)
This test step fragment validates that deleting an operational intent reference succeeds and returns the expected deleted operational intent reference.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.660920Z)
The response to a successful operational intent reference deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.668854Z)
A successful operational intent reference deletion query is expected to return a body, the content of which reflects the operational intent reference at the moment of deletion. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:42.669855Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.669425Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.669470Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.669504Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.669835Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.669537Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.669568Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.669596Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.669655Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.669624Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.669684Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.669740Z)
This test step fragment attempts to validate a single operational intent reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the oir_validator.py class.
If the version of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.669769Z)
If the OVN of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
Cleanup the OIR created in this test case.
✅ uss1_dss (2026-03-03T21:57:42.669712Z)
Test DSS behavior when mutation requests are not providing the required OVN.
This test step fragment validates that:
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:42.682287Z)
This test step fragment validates that an operational intent references creation returns a body in the correct format.
The response to a successful operational intent reference creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.690776Z)
A successful operational intent reference creation query is expected to return a body, the content of which reflects the created operational intent reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:42.691768Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.691380Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.691424Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.691458Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.691753Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.691488Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.691516Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.691544Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.691612Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.691572Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.691671Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
Create an OIR to be used in this test case.
✅ uss1_dss (2026-03-03T21:57:42.691721Z)
This step verifies that an existing OIR cannot be mutated with a missing OVN.
If the DSS under test allows the qualifier to mutate an existing OIR with a request that provided an empty OVN, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:42.697081Z)
This step verifies that an existing OIR cannot be mutated with an incorrect OVN.
If the DSS under test allows the qualifier to mutate an existing OIR with a request that provided an incorrect OVN, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss1_dss (2026-03-03T21:57:42.701819Z)
This test step fragment validates that operational intent references can be updated.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss1_dss (2026-03-03T21:57:42.717918Z)
This test step fragment validates that updates to operational intent references return a body in the correct format.
The response to a successful operational intent reference mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.726866Z)
A successful operational intent reference mutation query is expected to return a well-defined body, the content of which reflects the updated operational intent reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:42.727980Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.727568Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.727636Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.727674Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.727967Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.727706Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.727739Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.727768Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.727826Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.727796Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.727855Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.727912Z)
This test step fragment attempts to validate a single operational intent reference returned by the DSS, usually after it has been mutated.
The code for these checks lives in the oir_validator.py class.
Following a mutation, the DSS needs to update the operational intent reference version, otherwise it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.727939Z)
Following a mutation, the DSS needs to update the operational intent reference OVN, otherwise it is in violation of astm.f3548.v21.DSS0005,1.
Confirm that an OIR can be mutated when the correct OVN is provided.
✅ uss1_dss (2026-03-03T21:57:42.727884Z)
This test step fragment validates that deleting an operational intent reference succeeds and returns the expected deleted operational intent reference.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.742135Z)
The response to a successful operational intent reference deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.750069Z)
A successful operational intent reference deletion query is expected to return a body, the content of which reflects the operational intent reference at the moment of deletion. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:42.751185Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.750695Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.750738Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.750773Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.751171Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.750830Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.750888Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.750923Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.750986Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.750954Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.751031Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.751107Z)
This test step fragment attempts to validate a single operational intent reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the oir_validator.py class.
If the version of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.751142Z)
If the OVN of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.751061Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:42.757772Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:42.755477Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
Remove any lingering OIRs left by this scenario. ∅ This check was not applicable to this test run and is therefore not statused.
Verifies the behavior of a DSS for simple interactions pertaining to constraint references.
DSSInstanceResource the DSS instance through which entities are created, modified and deleted.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
IDGeneratorResource providing the base entity ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
ClientIdentityResource the client identity that will be used to create and update constraint references.
✅ Provided by utm_client_identity in top-level resource pool.
PlanningAreaResource describes the 3D volume in which constraint references will be created.
✅ Provided by planning_area in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any constraint references from the DSS that may have been left behind from testing efforts.
If an existing constraint reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.772181Z)
A client with valid credentials should be allowed to search for constraint references in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:42.769483Z)
If an existing constraint cannot be deleted by its manager when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
This step ensures that no entities with the known test IDs exists in the DSS.
∅ This check was not applicable to this test run and is therefore not statused.
This test step fragment validates that a query to create a constraint reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,3, the DSS API must allow callers to create a constraint reference with either one or both of the start and end time missing, provided all the required parameters are valid.
This step creates the constraint reference to be used in this scenario.
✅ uss1_dss (2026-03-03T21:57:42.781452Z)
Ensures that an existing CR can only be deleted when the correct OVN is provided.
This step verifies that an existing CR cannot be deleted with a missing OVN.
If the DSS under test allows the qualifier to delete an existing CR with a request that provided an empty OVN, it is in violation of astm.f3548.v21.DSS0005,3
✅ uss1_dss (2026-03-03T21:57:42.782748Z)
This step verifies that an existing CR cannot be deleted with an incorrect OVN.
If the DSS under test allows the qualifier to delete an existing CR with a request that provided an incorrect OVN, it is in violation of astm.f3548.v21.DSS0005,3
✅ uss1_dss (2026-03-03T21:57:42.784973Z)
Ensures that an existing CR can only be mutated when the correct OVN is provided.
This step verifies that an existing CR cannot be mutated with a missing OVN.
If the DSS under test allows the qualifier to mutate an existing CR with a request that provided an empty OVN, it is in violation of astm.f3548.v21.DSS0005,3
✅ uss1_dss (2026-03-03T21:57:42.788133Z)
This step verifies that an existing CR cannot be mutated with an incorrect OVN.
If the DSS under test allows the qualifier to mutate an existing CR with a request that provided an incorrect OVN, it is in violation of astm.f3548.v21.DSS0005,3
✅ uss1_dss (2026-03-03T21:57:42.790980Z)
Ensure a clean workspace for testing interactions with a DSS by removing any constraint references from the DSS that may have been left behind from testing efforts.
If an existing constraint reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.804414Z)
A client with valid credentials should be allowed to search for constraint references in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:42.795363Z)
If an existing constraint cannot be deleted by its manager when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.802373Z)
Verifies that all CRUD operations on constraint references performed on a given DSS instance are properly propagated to every other DSS instance participating in the deployment.
DSSInstanceResource the DSS instance through which entities are created, modified and deleted.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
DSSInstancesResource pointing to the DSS instances used to confirm that entities are properly propagated.
✅ Provided by dss_instances in top-level resource pool.
IDGeneratorResource providing the constraint reference ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which constraint reference will be created. Note that any start or end times specified in the underlying volume template
will be ignored.
✅ Provided by planning_area in top-level resource pool.
ClientIdentityResource to be used for this scenario.
✅ Provided by utm_client_identity in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any constraint references from the DSS that may have been left behind from testing efforts.
If an existing constraint reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.811437Z)
A client with valid credentials should be allowed to search for constraint references in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:42.809320Z)
If an existing constraint cannot be deleted by its manager when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
∅ This check was not applicable to this test run and is therefore not statused.
∅ This test step was not applicable to this test run and is therefore not statused.
Ensures that a secondary DSS is ready to be used for testing by confirming that no CR bearing an ID used for testing exists on it.
If an existing constraint reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
If a CR that was deleted from the primary DSS can still be found on a secondary DSS, either one of them may be improperly pooled and in violation of astm.f3548.v21.DSS0020.
This test case creates an constraint reference on the main DSS, and verifies that it is properly synchronized to the other DSS instances.
It then goes on to mutate and delete it, each time confirming that all other DSSes return the expected results.
This test step fragment validates that:
This test step fragment validates that a query to create a constraint reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,3, the DSS API must allow callers to create a constraint reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:42.818467Z)
This test step fragment validates that a constraint references creation returns a body in the correct format.
The response to a successful constraint reference creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.826119Z)
A successful constraint reference creation query is expected to return a body, the content of which reflects the created constraint reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:42.827048Z)
This test step fragment attempts to validate the content of a single constraint reference returned by the DSS.
The code for these checks lives in the cr_validator.py class.
If the returned constraint reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.826727Z)
If the returned constraint reference has no manager defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.826771Z)
The returned manager must correspond to the identity of the client that created the constraint at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.826806Z)
If the returned constraint reference has no USS base URL defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.826837Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at constraint reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.826869Z)
If the returned constraint reference has no start time defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.826898Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.826956Z)
Constraint references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.826925Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.826986Z)
If the returned constraint reference has no OVN defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.827031Z)
If the returned constraint reference has no version defined, astm.f3548.v21.DSS0005,3 is not respected.
∅ This check was not applicable to this test run and is therefore not statused.
Retrieve and validate synchronization of the created constraint at every DSS provided in dss_instances.
This test step fragment validates that a known constraint references can be read, and that its content is as expected.
This test step fragment validates that a query to retrieve an existing constraint reference with valid parameters succeeds.
If an existing constraint reference cannot successfully be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.830716Z)
✅ uss2_dss (2026-03-03T21:57:42.845564Z)
This test step fragment validates that a request for a constraint reference returns a properly formatted body.
The response to a successful get constraint reference query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.838253Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.853207Z)
A successful constraint reference creation query is expected to return a body, the content of which reflects a constraint reference that was created earlier. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:42.839267Z)
✅ uss1_dss (2026-03-03T21:57:42.854121Z)
If the constraint retrieved from a secondary DSS instance is not consistent with the newly created one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1a, astm.f3548.v21.DSS0210,A2-7-2,1f, astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.831519Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.846312Z)
This test step fragment validates that constraint references are properly synchronized across a set of DSS instances by querying a constraint reference that is known to exist at each one of the DSS instances.
If the previously created or mutated constraint reference cannot be found at a DSS, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.830781Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.845644Z)
This test step fragment validates that constraint reference attributes are properly synchronized across a set of DSS instances.
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct manager, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.830879Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.845712Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.830923Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.845750Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct start time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.831463Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.846257Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct end time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.831504Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.846297Z)
This test step fragment attempts to validate the content of a single constraint reference returned by the DSS.
The code for these checks lives in the cr_validator.py class.
If the returned constraint reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.838842Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.853724Z)
If the returned constraint reference has no manager defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.838890Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.853769Z)
The returned manager must correspond to the identity of the client that created the constraint at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.838928Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.853805Z)
If the returned constraint reference has no USS base URL defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.838964Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.853839Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at constraint reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.838998Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.853871Z)
If the returned constraint reference has no start time defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.839054Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.853902Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.839127Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.853962Z)
Constraint references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.839090Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.853931Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.839161Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.853993Z)
If the returned constraint reference has no OVN defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.839193Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.854043Z)
If the returned constraint reference has no version defined, astm.f3548.v21.DSS0005,3 is not respected.
∅ This check was not applicable to this test run and is therefore not statused.
This test step fragment attempts to validate a single constraint reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the cr_validator.py class.
If the version of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.839254Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.854107Z)
If the OVN of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.839224Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.854076Z)
Search for and validate synchronization of the created constraint at every DSS provided in dss_instances.
This test step fragment validates that known constraint references can be searched for, and that the returned content is as expected.
This test step fragment validates that a query to search for constraint references with valid parameters succeeds.
If the DSS fails to let us search in the area for which the CR was created, it is failing to meet astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:42.857534Z)
✅ uss2_dss (2026-03-03T21:57:42.869136Z)
This test step fragment validates that constraint references search responses are properly formatted.
The response to a successful constraint reference search query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:42.864772Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.876955Z)
If the existing constraint reference is not returned in a search that covers the area it was created for, the DSS is not properly implementing astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:42.865293Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.877478Z)
A successful constraint reference search query is expected to return a body, the content of which reflects any constraint reference present in the searched area. This includes the previously created constraint reference, which should accurately represent the constraint reference as it was requested. If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,4.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:42.865703Z)
✅ uss1_dss (2026-03-03T21:57:42.877896Z)
If the constraint searched from a secondary DSS instance is not consistent with the newly created one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1a, astm.f3548.v21.DSS0210,A2-7-2,1e, , astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.858365Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.869882Z)
This test step fragment validates that constraint references are properly synchronized across a set of DSS instances by searching for a constraint reference that is known to exist in a specific area at each one of the DSS instances.
When querying a secondary DSS for constraints in the planning area that contains the propagated constraint, if the propagated constraint is not contained in the response, then the general area in which the propagated constraint is located is not synchronized across DSS instances. As such, either the primary or the secondary DSS fail to properly one of the following requirements:
astm.f3548.v21.DSS0210,2e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.857591Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.869203Z)
This test step fragment validates that constraint reference attributes are properly synchronized across a set of DSS instances.
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct manager, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.857666Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.869297Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.857717Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.869339Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct start time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.858310Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.869829Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct end time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
Confirm that each DSS returns the constraint in relevant search results. Confirm that the constraint reference that was just created is properly synchronized across all DSS instances.
✅ uss1_dss (2026-03-03T21:57:42.858351Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.869868Z)
This test step fragment attempts to validate the content of a single constraint reference returned by the DSS.
The code for these checks lives in the cr_validator.py class.
If the returned constraint reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.865340Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.877525Z)
If the returned constraint reference has no manager defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.865377Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.877562Z)
The returned manager must correspond to the identity of the client that created the constraint at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.865410Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.877596Z)
If the returned constraint reference has no USS base URL defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.865443Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.877631Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at constraint reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.865475Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.877663Z)
If the returned constraint reference has no start time defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.865505Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.877695Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.865569Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.877760Z)
Constraint references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.865536Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.877727Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.865601Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.877792Z)
If the returned constraint reference has no OVN defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.865630Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.877822Z)
If the returned constraint reference has no version defined, astm.f3548.v21.DSS0005,3 is not respected.
∅ This check was not applicable to this test run and is therefore not statused.
This test step fragment attempts to validate a single constraint reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the cr_validator.py class.
If the version of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.865691Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.877883Z)
If the OVN of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.865660Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.877852Z)
This test step mutates the previously created constraint reference to verify that the DSS reacts properly: notably, it checks that the constraint reference version is updated, including for changes that are not directly visible, such as changing the constraint reference's footprint.
This test step fragment validates that constraint references can be updated.
This test step fragment validates that a query to update a constraint reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,3, the DSS API must allow callers to mutate a constraint reference.
✅ uss1_dss (2026-03-03T21:57:42.886553Z)
This test step fragment validates that updates to constraint references return a body in the correct format.
The response to a successful constraint reference mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.893484Z)
A successful constraint reference mutation query is expected to return a well-defined body, the content of which reflects the updated constraint reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:42.894376Z)
This test step fragment attempts to validate the content of a single constraint reference returned by the DSS.
The code for these checks lives in the cr_validator.py class.
If the returned constraint reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.893999Z)
If the returned constraint reference has no manager defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.894061Z)
The returned manager must correspond to the identity of the client that created the constraint at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.894100Z)
If the returned constraint reference has no USS base URL defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.894133Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at constraint reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.894164Z)
If the returned constraint reference has no start time defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.894192Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.894250Z)
Constraint references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.894220Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.894279Z)
If the returned constraint reference has no OVN defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.894308Z)
If the returned constraint reference has no version defined, astm.f3548.v21.DSS0005,3 is not respected.
∅ This check was not applicable to this test run and is therefore not statused.
This test step fragment attempts to validate a single constraint reference returned by the DSS, usually after it has been mutated.
The code for these checks lives in the cr_validator.py class.
Following a mutation, the DSS needs to update the constraint reference version, otherwise it is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.894363Z)
Following a mutation, the DSS needs to update the constraint reference OVN, otherwise it is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.894336Z)
Retrieve and validate synchronization of the updated constraint at every DSS provided in dss_instances.
This test step fragment validates that a known constraint references can be read, and that its content is as expected.
This test step fragment validates that a query to retrieve an existing constraint reference with valid parameters succeeds.
If an existing constraint reference cannot successfully be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.897375Z)
✅ uss2_dss (2026-03-03T21:57:42.908813Z)
This test step fragment validates that a request for a constraint reference returns a properly formatted body.
The response to a successful get constraint reference query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.905105Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.916283Z)
A successful constraint reference creation query is expected to return a body, the content of which reflects a constraint reference that was created earlier. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:42.906051Z)
✅ uss1_dss (2026-03-03T21:57:42.917244Z)
If the constraint retrieved from a secondary DSS instance is not consistent with the updated one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1b, astm.f3548.v21.DSS0210,A2-7-2,1d, astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.898141Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.909536Z)
This test step fragment validates that constraint references are properly synchronized across a set of DSS instances by querying a constraint reference that is known to exist at each one of the DSS instances.
If the previously created or mutated constraint reference cannot be found at a DSS, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.897447Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.908867Z)
This test step fragment validates that constraint reference attributes are properly synchronized across a set of DSS instances.
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct manager, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.897509Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.908925Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.897545Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.908961Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct start time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.898084Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.909483Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct end time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
Confirm that each DSS provides direct access to the updated constraint reference. Confirm that the constraint reference that was just updated is properly synchronized across all DSS instances.
✅ uss1_dss (2026-03-03T21:57:42.898126Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.909523Z)
This test step fragment attempts to validate the content of a single constraint reference returned by the DSS.
The code for these checks lives in the cr_validator.py class.
If the returned constraint reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.905637Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.916828Z)
If the returned constraint reference has no manager defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.905683Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.916875Z)
The returned manager must correspond to the identity of the client that created the constraint at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.905720Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.916912Z)
If the returned constraint reference has no USS base URL defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.905754Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.916948Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at constraint reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.905787Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.916981Z)
If the returned constraint reference has no start time defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.905819Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.917040Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.905881Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.917109Z)
Constraint references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.905849Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.917075Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.905911Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.917141Z)
If the returned constraint reference has no OVN defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.905941Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.917171Z)
If the returned constraint reference has no version defined, astm.f3548.v21.DSS0005,3 is not respected.
∅ This check was not applicable to this test run and is therefore not statused.
This test step fragment attempts to validate a single constraint reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the cr_validator.py class.
If the version of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.906000Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.917231Z)
If the OVN of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.905971Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.917201Z)
Search for and validate synchronization of the updated constraint at every DSS provided in dss_instances.
This test step fragment validates that known constraint references can be searched for, and that the returned content is as expected.
This test step fragment validates that a query to search for constraint references with valid parameters succeeds.
If the DSS fails to let us search in the area for which the CR was created, it is failing to meet astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:42.920849Z)
✅ uss2_dss (2026-03-03T21:57:42.936425Z)
This test step fragment validates that constraint references search responses are properly formatted.
The response to a successful constraint reference search query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:42.931564Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.944166Z)
If the existing constraint reference is not returned in a search that covers the area it was created for, the DSS is not properly implementing astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:42.932163Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.944672Z)
A successful constraint reference search query is expected to return a body, the content of which reflects any constraint reference present in the searched area. This includes the previously created constraint reference, which should accurately represent the constraint reference as it was requested. If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,4.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:42.932580Z)
✅ uss1_dss (2026-03-03T21:57:42.945115Z)
If the constraint searched from a secondary DSS instance is not consistent with the updated one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1b, astm.f3548.v21.DSS0210,A2-7-2,1e, astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.921652Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.937194Z)
This test step fragment validates that constraint references are properly synchronized across a set of DSS instances by searching for a constraint reference that is known to exist in a specific area at each one of the DSS instances.
When querying a secondary DSS for constraints in the planning area that contains the propagated constraint, if the propagated constraint is not contained in the response, then the general area in which the propagated constraint is located is not synchronized across DSS instances. As such, either the primary or the secondary DSS fail to properly one of the following requirements:
astm.f3548.v21.DSS0210,2e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.920950Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.936492Z)
This test step fragment validates that constraint reference attributes are properly synchronized across a set of DSS instances.
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct manager, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.921050Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.936554Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.921094Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.936590Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct start time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:42.921599Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.937140Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct end time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
Confirm that each DSS returns the constraint in relevant search results. Confirm that the constraint reference that was just updated is properly synchronized across all DSS instances.
✅ uss1_dss (2026-03-03T21:57:42.921638Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.937180Z)
This test step fragment attempts to validate the content of a single constraint reference returned by the DSS.
The code for these checks lives in the cr_validator.py class.
If the returned constraint reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.932215Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.944719Z)
If the returned constraint reference has no manager defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.932253Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.944757Z)
The returned manager must correspond to the identity of the client that created the constraint at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.932287Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.944792Z)
If the returned constraint reference has no USS base URL defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.932320Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.944824Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at constraint reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.932353Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.944857Z)
If the returned constraint reference has no start time defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.932385Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.944888Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.932447Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.944952Z)
Constraint references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.932415Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.944919Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.932478Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.944984Z)
If the returned constraint reference has no OVN defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.932508Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.945034Z)
If the returned constraint reference has no version defined, astm.f3548.v21.DSS0005,3 is not respected.
∅ This check was not applicable to this test run and is therefore not statused.
This test step fragment attempts to validate a single constraint reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the cr_validator.py class.
If the version of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.932567Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.945101Z)
If the OVN of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.932537Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:42.945069Z)
Attempt to delete the constraint reference in various ways and ensure that the DSS reacts properly.
This also checks that the constraint reference data returned by a successful deletion is correct.
This test step fragment validates that constraint references can be deleted
A query to delete a constraint reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.952660Z)
This test step fragment validates that a constraint references deletion returns a body in the correct format.
The response to a successful constraint reference deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.959804Z)
A successful constraint reference deletion query is expected to return a body, the content of which reflects the constraint reference at the moment of deletion. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:42.960735Z)
This test step fragment attempts to validate the content of a single constraint reference returned by the DSS.
The code for these checks lives in the cr_validator.py class.
If the returned constraint reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.960384Z)
If the returned constraint reference has no manager defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.960428Z)
The returned manager must correspond to the identity of the client that created the constraint at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.960462Z)
If the returned constraint reference has no USS base URL defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.960493Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at constraint reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.960524Z)
If the returned constraint reference has no start time defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.960553Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.960612Z)
Constraint references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.960581Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.960641Z)
If the returned constraint reference has no OVN defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss1_dss (2026-03-03T21:57:42.960669Z)
If the returned constraint reference has no version defined, astm.f3548.v21.DSS0005,3 is not respected.
∅ This check was not applicable to this test run and is therefore not statused.
This test step fragment attempts to validate a single constraint reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the cr_validator.py class.
If the version of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.960722Z)
If the OVN of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.960695Z)
Attempt to query and search for the deleted constraint reference in various ways
This test step fragment validates that a known constraint references can be read, and that its content is as expected.
This test step fragment validates that a query to retrieve an existing constraint reference with valid parameters succeeds.
If an existing constraint reference cannot successfully be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.963485Z)
✅ uss2_dss (2026-03-03T21:57:42.968940Z)
This test step fragment validates that a request for a constraint reference returns a properly formatted body.
The response to a successful get constraint reference query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
∅ This check was not applicable to this test run and is therefore not statused.
A successful constraint reference creation query is expected to return a body, the content of which reflects a constraint reference that was created earlier. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
This check will usually be performing a series of sub-checks from the validate fragments.
∅ This check was not applicable to this test run and is therefore not statused.
If a DSS returns an constraint reference that was previously successfully deleted from the primary DSS, either one of the primary DSS or the DSS that returned the constraint reference is in violation of astm.f3548.v21.DSS0210,2a, astm.f3548.v21.DSS0210,A2-7-2,3b, astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:42.963531Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:42.968982Z)
This test step fragment validates that a query to search for constraint references with valid parameters succeeds.
If the DSS fails to let us search in the area for which the CR was created, it is failing to meet astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:42.966683Z)
✅ uss2_dss (2026-03-03T21:57:42.971745Z)
If a DSS returns an constraint reference that was previously successfully deleted from the primary DSS, either one of the primary DSS or the DSS that returned the constraint reference is in violation of astm.f3548.v21.DSS0210,2a, astm.f3548.v21.DSS0210,A2-7-2,3a, astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:42.966730Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:42.971790Z)
Ensure a clean workspace for testing interactions with a DSS by removing any constraint references from the DSS that may have been left behind from testing efforts.
If an existing constraint reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:42.977291Z)
A client with valid credentials should be allowed to search for constraint references in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:42.975103Z)
If an existing constraint cannot be deleted by its manager when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3. ∅ This check was not applicable to this test run and is therefore not statused.
Verifies that all CRUD operations for USS availabilities on a given DSS instance are properly propagated to every other DSS instance participating in the deployment.
DSSInstanceResource the DSS instance through which USS availabilities are created, modified and deleted.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
DSSInstancesResource pointing to the DSS instances used to confirm that USS availabilities are properly propagated.
✅ Provided by dss_instances in top-level resource pool.
ClientIdentityResource to be used for this scenario: it contains the identifier of the USS
for which availabilities will be updated.
✅ Provided by utm_client_identity in top-level resource pool.
For the setup of this test case, the scenario ensures that the availability for the USS specified in the client_identity resource
is Unknown, which is the default expected state when nothing else is known.
This step ensures that the scenario starts from a state where the USS availability is Unknown.
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI spec referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:42.983359Z)
✅ uss1_dss (2026-03-03T21:57:42.986213Z)
✅ uss2_dss (2026-03-03T21:57:42.991226Z)
A valid request to set the availability of a USS to Unknown should be accepted by the DSS,
otherwise it is failing to implement the OpenAPI spec referenced by astm.f3548.v21.DSS0100,1.
∅ This check was not applicable to this test run and is therefore not statused.
If the reported availability for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3a, if the USS identifier is not properly synced; astm.f3548.v21.DSS0210,3b, if the USS availability is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:42.986260Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:42.991272Z)
If the reported availability version for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3c, if the USS availability version is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:42.986301Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:42.991302Z)
Checks that updates to a USS availability on one DSS instance are properly propagated to every other DSS instance in the deployment.
Ensures that this is true for every possible availability state.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:42.996836Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:42.999312Z)
✅ uss2_dss (2026-03-03T21:57:43.001629Z)
If the reported availability for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3a, if the USS identifier is not properly synced; astm.f3548.v21.DSS0210,3b, if the USS availability is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:42.999359Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:43.001673Z)
If the reported availability version for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3c, if the USS availability version is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:42.999389Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:43.001704Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:43.005964Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:43.008232Z)
✅ uss2_dss (2026-03-03T21:57:43.010543Z)
If the reported availability for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3a, if the USS identifier is not properly synced; astm.f3548.v21.DSS0210,3b, if the USS availability is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:43.008275Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:43.010584Z)
If the reported availability version for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3c, if the USS availability version is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:43.008304Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:43.010630Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:43.015077Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:43.017399Z)
✅ uss2_dss (2026-03-03T21:57:43.019877Z)
If the reported availability for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3a, if the USS identifier is not properly synced; astm.f3548.v21.DSS0210,3b, if the USS availability is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:43.017442Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:43.019938Z)
If the reported availability version for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3c, if the USS availability version is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:43.017472Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:43.019971Z)
Checks that if queried for a USS it does not know about, any DSS will return an Unknown availability.
This test step requests the availability for a USS identifier that is not known to any DSS instance, and expects
to receive an Unknown availability along with an unset version. This should be true for every DSS that is part of the same deployment.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:43.025383Z)
✅ uss2_dss (2026-03-03T21:57:43.027809Z)
If the primary DSS instance does not return an Unknown availability for a USS identifier that has not received any updates,
it is in violation of the OpenAPI spec referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:43.022483Z)
If the primary DSS instance reports a non-empty version for the availability of an USS identifier that should not be known to the DSS, it is in violation of the OpenAPI spec referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:43.022527Z)
If the reported availability for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3a, if the USS identifier is not properly synced; astm.f3548.v21.DSS0210,3b, if the USS availability is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:43.025427Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:43.027865Z)
If the reported availability version for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3c, if the USS availability version is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:43.025456Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:43.027909Z)
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI spec referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:43.030394Z)
A valid request to set the availability of a USS to Unknown should be accepted by the DSS,
otherwise it is failing to implement the OpenAPI spec referenced by astm.f3548.v21.DSS0100,1.
∅ This check was not applicable to this test run and is therefore not statused.
This scenario ensures that a DSS will only let the owner of an operational intent reference modify it.
A resources.flight_planning.FlightIntentsResource containing the flight intents to be used in this scenario:
This scenario expects to find at least one flight intent in this resource. It will use its extents to create and mutate an operational intent reference, but ignore any specified states, as this scenario will iterate over all allowed states.
✅ Provided by non_conflicting_flights in top-level resource pool.
A resources.astm.f3548.v21.DSSInstanceResource pointing to the DSS instance to test for this scenario.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
A resources.interuss.IDGeneratorResource that will be used to generate the IDs of the operational intent references created in this scenario.
✅ Provided by id_generator in top-level resource pool.
Makes sure that the DSS is in a clean and expected state before running the test, and that the passed resources work as required.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:43.036273Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:43.039923Z)
✅ uss1_dss (2026-03-03T21:57:43.043379Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
If, after cleanup, one or more operational intent reference are still present at the DSS, this scenario cannot proceed.
This scenario is able to remove any operational intent reference that belongs to the configured credentials, but it cannot remove references that belong to other credentials.
A regular failure of this check indicates that other scenarios might not properly clean up their resources, or that the Prepare Flight Planners scenario should be moved in front of the present one.
If this check fails, the rest of the scenario is entirely skipped.
✅ uss1_dss (2026-03-03T21:57:43.043424Z)
This test case attempts to create an operational intent reference with a state that would require the utm.conformance_monitoring_sa scope while only using
the utm.strategic_coordination scope.
This test step attempts to directly create an operational intent reference with a state that is not allowable.
The creation of such an entity is expected to fail for two reasons:
Acceptedutm.conformance_monitoring_sa, a client is not allowed to request an Off-nominal state.If the DSS allows a client with the utm.strategic_coordination scope to create an operational intent reference in the Nonconforming state,
it is in violation of astm.f3548.v21.SCD0100 and astm.f3548.v21.DSS0005,1.
✅ uss1_dss, mock_uss (2026-03-03T21:57:43.047513Z)
If the DSS allows a client with the utm.strategic_coordination scope to create an operational intent reference in the Contingent state,
it is in violation of astm.f3548.v21.SCD0100 and astm.f3548.v21.DSS0005,1.
✅ uss1_dss, mock_uss (2026-03-03T21:57:43.049662Z)
This test case attempts to transition an existing operational intent reference to a state that would require the utm.conformance_monitoring_sa scope while only using
the utm.strategic_coordination scope.
This step sets up an operational intent reference in the Accepted state.
If the DSS does not allow a client with the utm.strategic_coordination scope to create an operational intent reference in the Accepted state,
it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:43.064609Z)
This test step attempts to transition an existing operational intent reference to a state it should not be allowed to when using the ``utm.strategic_coordination` scope.
If the DSS allows a client with the utm.strategic_coordination scope to transition an operational intent reference from the Accepted state to the Nonconforming state,
it is in violation of astm.f3548.v21.SCD0100.
✅ uss1_dss, mock_uss (2026-03-03T21:57:43.066367Z)
If the DSS allows a client with the utm.strategic_coordination scope to transition an operational intent reference from the Accepted state to the Contingent state,
it is in violation of astm.f3548.v21.SCD0100.
✅ uss1_dss, mock_uss (2026-03-03T21:57:43.067832Z)
This step transitions the operational intent reference to the Activated state.
If the DSS does not allow a client with the utm.strategic_coordination scope to transition an operational intent reference from the Accepted state to the Activated state,
it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:43.084408Z)
If the DSS allows a client with the utm.strategic_coordination scope to transition an operational intent reference from the Activated state to the Nonconforming state,
it is in violation of astm.f3548.v21.SCD0100.
✅ uss1_dss, mock_uss (2026-03-03T21:57:43.086254Z)
If the DSS allows a client with the utm.strategic_coordination scope to transition an operational intent reference from the Activated state to the Contingent state,
it is in violation of astm.f3548.v21.SCD0100.
✅ uss1_dss, mock_uss (2026-03-03T21:57:43.087840Z)
If the DSS does not allow a client with the utm.strategic_coordination scope to transition an operational intent reference from the Activated state to the Ended state,
it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:43.103721Z)
If the DSS allows a client with the utm.strategic_coordination scope to transition an operational intent reference from the Ended state to the Nonconforming state,
it is in violation of astm.f3548.v21.SCD0100 and astm.f3548.v21.DSS0005,1.
✅ uss1_dss, mock_uss (2026-03-03T21:57:43.105633Z)
If the DSS allows a client with the utm.strategic_coordination scope to transition an operational intent reference from the Ended state to the Contingent state,
it is in violation of astm.f3548.v21.SCD0100 and astm.f3548.v21.DSS0005,1.
✅ uss1_dss, mock_uss (2026-03-03T21:57:43.107798Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:43.111345Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
∅ This check was not applicable to this test run and is therefore not statused.
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:43.122461Z)
Create and mutate subscriptions as well as entities, and verify that the DSS handles notifications and expiry correctly.
DSSInstanceResource to be tested in this scenario.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
DSSInstancesResource pointing to the DSS instances used to confirm that entities are properly propagated.
✅ Provided by dss_instances in top-level resource pool.
IDGeneratorResource providing the Subscription IDs for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which subscriptions will be created.
✅ Provided by planning_area in top-level resource pool.
ClientIdentityResource provides the identity that will be used to interact with the DSS.
✅ Provided by utm_client_identity in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:43.130322Z)
✅ uss1_dss (2026-03-03T21:57:43.132506Z)
✅ uss1_dss (2026-03-03T21:57:43.134664Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:43.127949Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:43.137357Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:43.139463Z)
✅ uss1_dss (2026-03-03T21:57:43.141516Z)
✅ uss1_dss (2026-03-03T21:57:43.143541Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
This test step queries all secondary instances to confirm that none of the test IDs that are used in the scenario exist.
Ensures that a secondary DSS is ready to be used for testing by confirming that no OIR bearing an ID used for testing exists on it.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:43.146470Z)
✅ uss1_dss (2026-03-03T21:57:43.148835Z)
✅ uss1_dss (2026-03-03T21:57:43.150988Z)
✅ uss2_dss (2026-03-03T21:57:43.159875Z)
✅ uss2_dss (2026-03-03T21:57:43.162112Z)
✅ uss2_dss (2026-03-03T21:57:43.164247Z)
If an OIR that was deleted from the primary DSS can still be found on a secondary DSS, either one of them may be improperly pooled and in violation of astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:43.146528Z)
✅ uss1_dss (2026-03-03T21:57:43.148879Z)
✅ uss1_dss (2026-03-03T21:57:43.151048Z)
✅ uss2_dss (2026-03-03T21:57:43.159914Z)
✅ uss2_dss (2026-03-03T21:57:43.162152Z)
✅ uss2_dss (2026-03-03T21:57:43.164284Z)
Ensures that a secondary DSS is ready to be used for testing by confirming that no Subscription bearing an ID used for testing exists on it.
If an existing subscription cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:43.153142Z)
✅ uss1_dss (2026-03-03T21:57:43.155149Z)
✅ uss1_dss (2026-03-03T21:57:43.157202Z)
✅ uss2_dss (2026-03-03T21:57:43.166420Z)
✅ uss2_dss (2026-03-03T21:57:43.168595Z)
✅ uss2_dss (2026-03-03T21:57:43.170743Z)
If a Subscription that was deleted from the primary DSS can still be found on a secondary DSS, either one of them may be improperly pooled and in violation of astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:43.153179Z)
✅ uss1_dss (2026-03-03T21:57:43.155190Z)
✅ uss1_dss (2026-03-03T21:57:43.157236Z)
✅ uss2_dss (2026-03-03T21:57:43.166454Z)
✅ uss2_dss (2026-03-03T21:57:43.168630Z)
✅ uss2_dss (2026-03-03T21:57:43.170783Z)
This test case verifies that after a subscription is deleted from a DSS instance, it cannot be retrieved from any other DSS instance.
This test step will create a new subscription at every DSS, in sequence.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
Check that the subscription creation succeeds.
✅ uss1_dss (2026-03-03T21:57:43.178761Z)
✅ uss1_dss (2026-03-03T21:57:43.187694Z)
✅ uss1_dss (2026-03-03T21:57:43.196901Z)
This test step will delete the freshly created subscription at every DSS, in sequence. It then verifies that the subscription has been deleted from all DSS instances.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to remove a subscription succeeds.
An attempt to delete a subscription when the correct version is provided should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
Check that the subscription deletion succeeds.
✅ uss1_dss (2026-03-03T21:57:43.204783Z)
✅ uss1_dss (2026-03-03T21:57:43.216267Z)
✅ uss2_dss (2026-03-03T21:57:43.227448Z)
This test step fragment validates that a query to read a subscription succeeds.
If a subscription cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
Check that the subscription retrieval from all DSS instance succeeds. It is expected to be not found, but that is validated in the check below.
✅ uss1_dss (2026-03-03T21:57:43.207218Z)
✅ uss2_dss (2026-03-03T21:57:43.209540Z)
✅ uss2_dss (2026-03-03T21:57:43.218550Z)
✅ uss1_dss (2026-03-03T21:57:43.220721Z)
✅ uss1_dss (2026-03-03T21:57:43.230071Z)
✅ uss1_dss (2026-03-03T21:57:43.232314Z)
The subscription deleted on a DSS instance must have been removed from all other DSS instances.
If the subscription still exists on one of the other DSS instances, one of the instances fails to comply with astm.f3548.v21.DSS0210,A2-7-2,5a.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:43.207285Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:43.209584Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:43.218609Z)
✅ uss1_dss, uss1_dss (2026-03-03T21:57:43.220762Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:43.230119Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:43.232357Z)
This test case verifies that after a subscription is deleted, newly created or modified OIRs will not receive the relevant subscriptions to notify from the DSS instance, regardless of which instance was used to create or modify the entity.
This test step will create an operational intent reference at every DSS, in sequence, each time verifying that the DSS does not require notification for any previously deleted subscription that intersects with the newly created OIR.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
Check that the OIR creation query succeeds.
✅ uss1_dss (2026-03-03T21:57:43.251910Z)
✅ uss1_dss (2026-03-03T21:57:43.270441Z)
✅ uss2_dss (2026-03-03T21:57:43.289230Z)
The response from a DSS to a valid OIR creation request is expected to contain any relevant subscription for the OIR's extents. This does not include subscriptions deleted earlier.
If the DSS includes a deleted subscription, it fails to implement astm.f3548.v21.DSS0210,A2-7-2,5b.
✅ uss1_dss (2026-03-03T21:57:43.251997Z)
✅ uss1_dss (2026-03-03T21:57:43.270509Z)
✅ uss2_dss (2026-03-03T21:57:43.289295Z)
This test step will modify an operational intent reference at every DSS, in sequence, each time verifying that the DSS does not require notification for any previously deleted subscription that intersects with the modified OIR.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
Check that the OIR modification query succeeds.
✅ uss1_dss (2026-03-03T21:57:43.308776Z)
✅ uss1_dss (2026-03-03T21:57:43.328266Z)
✅ uss2_dss (2026-03-03T21:57:43.348053Z)
The response from a DSS to a valid OIR modification request is expected to contain any relevant subscription for the OIR's extents. This does not include subscriptions deleted earlier.
If the DSS includes a deleted subscription, it fails to implement astm.f3548.v21.DSS0210,A2-7-2,5c.
✅ uss1_dss (2026-03-03T21:57:43.308868Z)
✅ uss1_dss (2026-03-03T21:57:43.328335Z)
✅ uss2_dss (2026-03-03T21:57:43.348125Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:43.406517Z)
✅ uss1_dss (2026-03-03T21:57:43.408598Z)
✅ uss1_dss (2026-03-03T21:57:43.411490Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:43.404217Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:43.373526Z)
✅ uss1_dss (2026-03-03T21:57:43.389229Z)
✅ uss1_dss (2026-03-03T21:57:43.404188Z)
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:43.414279Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:43.416444Z)
✅ uss1_dss (2026-03-03T21:57:43.418426Z)
✅ uss1_dss (2026-03-03T21:57:43.420394Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created. ∅ This check was not applicable to this test run and is therefore not statused.
Create and mutate subscriptions as well as entities, and verify that the DSS handles notifications and expiry correctly.
DSSInstanceResource to be tested in this scenario.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
DSSInstancesResource pointing to the DSS instances used to confirm that entities are properly propagated.
✅ Provided by dss_instances in top-level resource pool.
IDGeneratorResource providing the Subscription IDs for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which subscriptions will be created.
✅ Provided by planning_area in top-level resource pool.
ClientIdentityResource provides the identity that will be used to interact with the DSS.
✅ Provided by utm_client_identity in top-level resource pool.
Ensure that no subscriptions and OIRs with the known test IDs exists in the DSS deployment.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:43.427331Z)
✅ uss1_dss (2026-03-03T21:57:43.429331Z)
✅ uss1_dss (2026-03-03T21:57:43.431318Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:43.425252Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:43.433881Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:43.435921Z)
✅ uss1_dss (2026-03-03T21:57:43.437939Z)
✅ uss1_dss (2026-03-03T21:57:43.439921Z)
✅ uss1_dss (2026-03-03T21:57:43.441909Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
This test step queries all secondary instances to confirm that none of the test IDs that are used in the scenario exist.
Ensures that a secondary DSS is ready to be used for testing by confirming that no OIR bearing an ID used for testing exists on it.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:43.444677Z)
✅ uss1_dss (2026-03-03T21:57:43.446704Z)
✅ uss1_dss (2026-03-03T21:57:43.448756Z)
✅ uss2_dss (2026-03-03T21:57:43.457215Z)
✅ uss2_dss (2026-03-03T21:57:43.459210Z)
✅ uss2_dss (2026-03-03T21:57:43.461296Z)
If an OIR that was deleted from the primary DSS can still be found on a secondary DSS, either one of them may be improperly pooled and in violation of astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:43.444718Z)
✅ uss1_dss (2026-03-03T21:57:43.446744Z)
✅ uss1_dss (2026-03-03T21:57:43.448794Z)
✅ uss2_dss (2026-03-03T21:57:43.457254Z)
✅ uss2_dss (2026-03-03T21:57:43.459251Z)
✅ uss2_dss (2026-03-03T21:57:43.461336Z)
Ensures that a secondary DSS is ready to be used for testing by confirming that no Subscription bearing an ID used for testing exists on it.
If an existing subscription cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:43.450726Z)
✅ uss1_dss (2026-03-03T21:57:43.452722Z)
✅ uss1_dss (2026-03-03T21:57:43.454667Z)
✅ uss2_dss (2026-03-03T21:57:43.463284Z)
✅ uss2_dss (2026-03-03T21:57:43.465205Z)
✅ uss2_dss (2026-03-03T21:57:43.467151Z)
If a Subscription that was deleted from the primary DSS can still be found on a secondary DSS, either one of them may be improperly pooled and in violation of astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:43.450760Z)
✅ uss1_dss (2026-03-03T21:57:43.452756Z)
✅ uss1_dss (2026-03-03T21:57:43.454701Z)
✅ uss2_dss (2026-03-03T21:57:43.463318Z)
✅ uss2_dss (2026-03-03T21:57:43.465239Z)
✅ uss2_dss (2026-03-03T21:57:43.467185Z)
∅ This check was not applicable to this test run and is therefore not statused.
∅ This check was not applicable to this test run and is therefore not statused.
This test case verifies that newly created or modified OIRs will receive the relevant subscriptions to notify from the DSS instance, regardless of which instance was used to create the entity.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
Sets up the subscription that cover the planning area from 'now' to 20 minutes in the future, and which will be used as part of the interaction tests.
✅ uss1_dss (2026-03-03T21:57:43.474983Z)
This test step will create an operational intent reference and assorted subscription at every DSS, in sequence, each time verifying that the DSS requires notifications for any previously established subscription that intersects with the newly created OIR.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
Check that the OIR creation query succeeds
✅ uss1_dss (2026-03-03T21:57:43.494545Z)
✅ uss1_dss (2026-03-03T21:57:43.513296Z)
✅ uss2_dss (2026-03-03T21:57:43.531370Z)
The response from a DSS to a valid OIR creation request is expected to contain any relevant subscription for the OIR's extents. This includes the subscription created earlier, as it is designed to intersect with the OIRs being created.
If the DSS omits the intersecting subscription, it fails to implement astm.f3548.v21.DSS0210,A2-7-2,4b.
✅ uss1_dss (2026-03-03T21:57:43.494611Z)
✅ uss1_dss (2026-03-03T21:57:43.513362Z)
✅ uss2_dss (2026-03-03T21:57:43.531449Z)
The response from a DSS to a valid OIR creation request is expected to contain any relevant subscription for the OIR's extents. This includes any implicit subscription previously created on the DSS as part of a previously created OIR.
If the DSS omits any of the implicit subscriptions belonging to an OIR previously created on another DSS (which are designed to all intersect), any of the DSSes at which an earlier OIR was created, or the DSS at which the current OIR has been created, are in violation of astm.f3548.v21.DSS0210,A2-7-2,4b.
✅ uss1_dss, uss1_dss, uss2_dss (2026-03-03T21:57:43.494646Z)
✅ uss1_dss, uss1_dss, uss2_dss (2026-03-03T21:57:43.513399Z)
✅ uss1_dss, uss1_dss, uss2_dss (2026-03-03T21:57:43.531497Z)
This test step will modify the previously created operational intent reference and assorted subscription at every DSS, in sequence, each time verifying that the DSS requires notifications for any previously established subscription that intersects with the modified OIR.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
Check that the OIR modification query succeeds
✅ uss1_dss (2026-03-03T21:57:43.549940Z)
✅ uss1_dss (2026-03-03T21:57:43.568466Z)
✅ uss2_dss (2026-03-03T21:57:43.587582Z)
The response from a DSS to a valid OIR modification request is expected to contain any relevant subscription for the OIR's extents. This includes the subscription created earlier, as it is designed to intersect with the OIRs being modified.
If the DSS omits the intersecting subscription, it fails to implement astm.f3548.v21.DSS0210,A2-7-2,4c.
✅ uss1_dss (2026-03-03T21:57:43.550038Z)
✅ uss1_dss (2026-03-03T21:57:43.568529Z)
✅ uss2_dss (2026-03-03T21:57:43.587646Z)
The response from a DSS to a valid OIR modification request is expected to contain any relevant subscription for the OIR's extents. This includes any implicit subscription previously created on the DSS as part of a previously created OIR.
If the DSS omits any of the implicit subscriptions belonging to an OIR previously created over time range A on another DSS (which are designed to all intersect), any of the DSSes at which an earlier OIR was created, or the DSS at which the current OIR has been modified, are in violation of astm.f3548.v21.DSS0210,A2-7-2,4c.
✅ uss1_dss, uss1_dss, uss2_dss (2026-03-03T21:57:43.550088Z)
✅ uss1_dss, uss1_dss, uss2_dss (2026-03-03T21:57:43.568569Z)
✅ uss1_dss, uss1_dss, uss2_dss (2026-03-03T21:57:43.587684Z)
This test case checks that, when a newly created subscription intersects with an existing OIR and that the subscription is intended for operational intent references, the DSS includes the relevant OIRs in the response to the creation.
This test step will create a new subscription at every DSS, in sequence, each time verifying that the DSS returns any OIRs that intersect with the newly created subscription.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
Check that the subscription creation succeeds.
✅ uss1_dss (2026-03-03T21:57:43.597829Z)
The response from a DSS to a valid subscription creation request is expected to contain any relevant OIRs for the subscription's extents if the subscription had the notify_for_op_intents flag set to true.
If the DSS omits the intersecting OIR, it fails to comply with astm.f3548.v21.DSS0210,A2-7-2,4a.
✅ uss1_dss (2026-03-03T21:57:43.597886Z)
This test step fragment validates that a query to read a subscription succeeds.
If a subscription cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:57:43.601637Z)
✅ uss1_dss (2026-03-03T21:57:43.605838Z)
The subscription created on a DSS instance must be retrievable from all other DSS instances.
If the subscription does not exist on one of the other DSS instances, one of the instances fails to comply with astm.f3548.v21.DSS0210,A2-7-2,4a.
✅ uss1_dss, uss2_dss (2026-03-03T21:57:43.601683Z)
✅ uss1_dss, uss1_dss (2026-03-03T21:57:43.605883Z)
This test case validates that expired subscriptions (created explicitly) are removed from all DSS instances. To validate this requirement, the subscriptions that were previously created at each DSS instance are modified so that they expire shortly after the modification. Then it is checked that all the associated subscriptions were removed from all the DSS instances by searching for them in their planning area. Do note that they are not queried directly, as it is deemed acceptable for expired subscription that were not explicitly deleted to still be retrievable.
This test step will modify explicit subscriptions that were previously created at each DSS instance so that they expire shortly after the modification.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to update a subscription succeeds.
If a subscription cannot be updated with a valid set of parameters, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
Check that the subscription modifications succeed and wait for them to expire.
✅ uss1_dss (2026-03-03T21:57:43.650415Z)
✅ uss1_dss (2026-03-03T21:57:43.659490Z)
✅ uss2_dss (2026-03-03T21:57:43.668232Z)
This test step fragment validates that a query to search for subscriptions succeeds.
If the DSS fails to let us search in the area for which the subscription was created, it is failing to meet astm.f3548.v21.DSS0005,5.
Check that query succeeds.
✅ uss1_dss (2026-03-03T21:57:50.679018Z)
✅ uss1_dss (2026-03-03T21:57:50.690322Z)
✅ uss1_dss (2026-03-03T21:57:50.704494Z)
✅ uss1_dss (2026-03-03T21:57:50.720730Z)
✅ uss2_dss (2026-03-03T21:57:50.734419Z)
✅ uss2_dss (2026-03-03T21:57:50.750973Z)
The explicit subscription expired on a DSS instance must have been removed from all other DSS instances.
If the subscription still exists on one of the other DSS instances, one of the instances fails to comply with astm.f3548.v21.DSS0210,A2-7-2,4d.
✅ uss1_dss, uss2_dss (2026-03-03T21:57:50.681941Z)
✅ uss1_dss, uss1_dss (2026-03-03T21:57:50.693286Z)
✅ uss1_dss, uss1_dss (2026-03-03T21:57:50.709609Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:50.723769Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:50.739706Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:50.754181Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:50.819422Z)
✅ uss1_dss (2026-03-03T21:57:50.821748Z)
✅ uss1_dss (2026-03-03T21:57:50.824485Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:50.817032Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:50.783345Z)
✅ uss1_dss (2026-03-03T21:57:50.799843Z)
✅ uss1_dss (2026-03-03T21:57:50.816981Z)
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:50.827810Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:50.832514Z)
✅ uss1_dss (2026-03-03T21:57:50.841709Z)
✅ uss1_dss (2026-03-03T21:57:50.845796Z)
✅ uss1_dss (2026-03-03T21:57:50.855467Z)
✅ uss1_dss (2026-03-03T21:57:50.865189Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:50.839511Z)
✅ uss1_dss (2026-03-03T21:57:50.851873Z)
✅ uss1_dss (2026-03-03T21:57:50.861616Z)
✅ uss1_dss (2026-03-03T21:57:50.871610Z)
Verifies that a DSS requires from a client creating or updating operational intent references that they provide all OVNs for all currently relevant entities.
DSSInstanceResource the DSS instance through which entities are created, modified and deleted.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
IDGeneratorResource providing the base entity ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
ClientIdentityResource the client identity that will be used to create and update operational intent references.
✅ Provided by utm_client_identity in top-level resource pool.
PlanningAreaResource describes the 3D volume in which operational intent references will be created.
✅ Provided by planning_area in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:50.878958Z)
✅ uss1_dss (2026-03-03T21:57:50.881113Z)
✅ uss1_dss (2026-03-03T21:57:50.883201Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:50.876797Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
This step ensures that no operational intent references with the known test IDs exists in the DSS.
∅ This check was not applicable to this test run and is therefore not statused.
This test case will create multiple operational intent references and verify that the key field
of the parameters to create or update an operational intent reference is properly validated.
That is: the DSS should require that the client provides the OVNs for each entity that is in the vicinity, both geographically and temporally, of the client's operational intent reference.
This step creates one operational intent references. As no other operational intent reference is present,
the key field may remain empty.
With no potentially conflicting entity present, the DSS is expected to allow the creation of an operational intent without
the client specifying any OVN in the key field.
If the DSS rejects a well-formed request to create the operational intent reference, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:50.904663Z)
This step creates a second operational intent references that does not overlap in time with the first, and
should therefore not require any entry in the key field.
With a single existing OIR in the area that is not overlapping in time, the DSS is expected to allow the creation of an operational intent without
the client specifying any OVN in the key field.
If the DSS rejects a well-formed request to create the operational intent reference, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:50.922403Z)
This test step will attempt to create an operational intent reference that intersects with the first of the previously created OIR,
and expect the DSS to require its OVN to be provided in the key field.
This step will validate the response body for the HTTP 409 error response from the DSS when it contains the optional missing_operational_intents field.
This test step fragment validates that requests for operational intent reference creation that don't show that they have been de-conflicted are rejected with the proper error.
If the DSS allows the creation of an operational intent reference that is missing the required OVNs for other entities that exist in its geo-temporal vicinity, it is in violation of astm.f3548.v21.DSS0005,1 and astm.f3548.v21.DSS0210,A2-7-2,2a
✅ uss1_dss (2026-03-03T21:57:50.937665Z)
The DSS is expected to return a HTTP 409 error response when the creation of an operational intent reference fails due to a conflict.
This response is expected to conform to the OpenAPI spec that is part of astm.f3548.v21.DSS0005,1.
Should this not be the case, then the DSS is in violation of the aforementioned requirement.
✅ uss1_dss (2026-03-03T21:57:50.945871Z)
If the DSS returns a HTTP 409 error response due to a conflict, and the response body contains a missing_operational_intents field,
this field is expected to contain the conflicting OVNs.
If the field exists but does not contain the conflicting OVNs, then the DSS is in violation of astm.f3548.v21.DSS0005,1.
Checks that an attempt to create an OIR without specifying the OVN of the already existing and overlapping OIR fails.
✅ uss1_dss (2026-03-03T21:57:50.946887Z)
This test step will attempt to create an operational intent reference that intersects with the second of the previously created OIR,
and expect the DSS to require its OVN to be provided in the key field.
This step will validate the response body for the HTTP 409 error response from the DSS when it contains the optional missing_operational_intents field.
This test step fragment validates that requests for operational intent reference creation that don't show that they have been de-conflicted are rejected with the proper error.
If the DSS allows the creation of an operational intent reference that is missing the required OVNs for other entities that exist in its geo-temporal vicinity, it is in violation of astm.f3548.v21.DSS0005,1 and astm.f3548.v21.DSS0210,A2-7-2,2a
✅ uss1_dss (2026-03-03T21:57:50.959142Z)
The DSS is expected to return a HTTP 409 error response when the creation of an operational intent reference fails due to a conflict.
This response is expected to conform to the OpenAPI spec that is part of astm.f3548.v21.DSS0005,1.
Should this not be the case, then the DSS is in violation of the aforementioned requirement.
✅ uss1_dss (2026-03-03T21:57:50.966806Z)
If the DSS returns a HTTP 409 error response due to a conflict, and the response body contains a missing_operational_intents field,
this field is expected to contain the conflicting OVNs.
If the field exists but does not contain the conflicting OVNs, then the DSS is in violation of astm.f3548.v21.DSS0005,1.
Checks that an attempt to create an OIR without specifying the OVN of the already existing and overlapping OIR fails.
✅ uss1_dss (2026-03-03T21:57:50.967455Z)
This test step will attempt to create an operational intent reference that intersects with both of the previously created OIRs,
and expect the DSS to require their OVNs to be provided in the key field.
This step will validate the response body for the HTTP 409 error response from the DSS when it contains the optional missing_operational_intents field.
This test step fragment validates that requests for operational intent reference creation that don't show that they have been de-conflicted are rejected with the proper error.
If the DSS allows the creation of an operational intent reference that is missing the required OVNs for other entities that exist in its geo-temporal vicinity, it is in violation of astm.f3548.v21.DSS0005,1 and astm.f3548.v21.DSS0210,A2-7-2,2a
✅ uss1_dss (2026-03-03T21:57:50.978548Z)
The DSS is expected to return a HTTP 409 error response when the creation of an operational intent reference fails due to a conflict.
This response is expected to conform to the OpenAPI spec that is part of astm.f3548.v21.DSS0005,1.
Should this not be the case, then the DSS is in violation of the aforementioned requirement.
✅ uss1_dss (2026-03-03T21:57:50.985415Z)
If the DSS returns a HTTP 409 error response due to a conflict, and the response body contains a missing_operational_intents field,
this field is expected to contain the conflicting OVNs.
If the field exists but does not contain the conflicting OVNs, then the DSS is in violation of astm.f3548.v21.DSS0005,1.
Checks that an attempt to create an OIR without specifying the OVNs of the already existing and overlapping OIRs fails.
✅ uss1_dss (2026-03-03T21:57:50.986348Z)
This test step will attempt to create an operational intent reference that intersects with both of the previously created OIRs,
while providing the required OVNs in the key field.
After this test step succeeds, three OIRs are expected to exist in the DSS, with one intersecting with the two others.
If the DSS prevents the creation of an operational intent reference that is providing all required OVNs for other entities that exist in its geo-temporal vicinity, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.002544Z)
This test case will update multiple operational intent references and verify that the key field
of the parameters to create or update an operational intent reference is properly validated.
That is: the DSS should require that the client provides the OVNs for each entity that is in the vicinity, both geographically and temporally, of the client's operational intent reference.
This test step will attempt to mutate the third previously created operational intent reference so that it keeps overlapping with the others,
while omitting their OVNs in the key field.
The expectation is that the DSS will require the two missing OVNs.
This test step fragment validates that requests for operational intent references updates that don't show that they have been de-conflicted are rejected with the proper error.
If the DSS allows the mutation of an operational intent reference that is missing the required OVNs for other entities that exist in its geo-temporal vicinity, it is in violation of astm.f3548.v21.DSS0005,1 and astm.f3548.v21.DSS0210,A2-7-2,2b
✅ uss1_dss (2026-03-03T21:57:51.017703Z)
The DSS is expected to return a HTTP 409 error response when the creation of an operational intent reference fails due to a conflict.
This response is expected to conform to the OpenAPI spec that is part of astm.f3548.v21.DSS0005,1.
Should this not be the case, then the DSS is in violation of the aforementioned requirement.
✅ uss1_dss (2026-03-03T21:57:51.025441Z)
If the DSS returns a HTTP 409 error response due to a conflict, and the response body contains a missing_operational_intents field,
this field is expected to contain the conflicting OVNs.
If the field exists but does not contain the conflicting OVNs, then the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.026397Z)
This test step will attempt to mutate the third previously created operational intent reference so that it keeps overlapping with the others,
while omitting the first OVN in the key field.
The expectation is that the DSS will require the missing OVN.
This test step fragment validates that requests for operational intent references updates that don't show that they have been de-conflicted are rejected with the proper error.
If the DSS allows the mutation of an operational intent reference that is missing the required OVNs for other entities that exist in its geo-temporal vicinity, it is in violation of astm.f3548.v21.DSS0005,1 and astm.f3548.v21.DSS0210,A2-7-2,2b
✅ uss1_dss (2026-03-03T21:57:51.039100Z)
The DSS is expected to return a HTTP 409 error response when the creation of an operational intent reference fails due to a conflict.
This response is expected to conform to the OpenAPI spec that is part of astm.f3548.v21.DSS0005,1.
Should this not be the case, then the DSS is in violation of the aforementioned requirement.
✅ uss1_dss (2026-03-03T21:57:51.045844Z)
If the DSS returns a HTTP 409 error response due to a conflict, and the response body contains a missing_operational_intents field,
this field is expected to contain the conflicting OVNs.
If the field exists but does not contain the conflicting OVNs, then the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.046439Z)
This test step will attempt to mutate the third previously created operational intent reference so that it overlaps with the first one,
while omitting the first OVN in the key field.
The expectation is that the DSS will require the missing OVN.
This test step fragment validates that requests for operational intent references updates that don't show that they have been de-conflicted are rejected with the proper error.
If the DSS allows the mutation of an operational intent reference that is missing the required OVNs for other entities that exist in its geo-temporal vicinity, it is in violation of astm.f3548.v21.DSS0005,1 and astm.f3548.v21.DSS0210,A2-7-2,2b
✅ uss1_dss (2026-03-03T21:57:51.059472Z)
The DSS is expected to return a HTTP 409 error response when the creation of an operational intent reference fails due to a conflict.
This response is expected to conform to the OpenAPI spec that is part of astm.f3548.v21.DSS0005,1.
Should this not be the case, then the DSS is in violation of the aforementioned requirement.
✅ uss1_dss (2026-03-03T21:57:51.066296Z)
If the DSS returns a HTTP 409 error response due to a conflict, and the response body contains a missing_operational_intents field,
this field is expected to contain the conflicting OVNs.
If the field exists but does not contain the conflicting OVNs, then the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.066854Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.120644Z)
✅ uss1_dss (2026-03-03T21:57:51.122790Z)
✅ uss1_dss (2026-03-03T21:57:51.125128Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:51.118195Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.087486Z)
✅ uss1_dss (2026-03-03T21:57:51.101924Z)
✅ uss1_dss (2026-03-03T21:57:51.118164Z)
Verifies that all CRUD operations on operational intent references performed on a given DSS instance are properly propagated to every other DSS instance participating in the deployment.
DSSInstanceResource the DSS instance through which entities are created, modified and deleted.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
DSSInstancesResource pointing to the DSS instances used to confirm that entities are properly propagated.
✅ Provided by dss_instances in top-level resource pool.
IDGeneratorResource providing the operational intent reference ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which operational intent reference will be created.
✅ Provided by planning_area in top-level resource pool.
ClientIdentityResource to be used for this scenario.
✅ Provided by utm_client_identity in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.133180Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:51.131045Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
Ensures that a secondary DSS is ready to be used for testing by confirming that no OIR bearing an ID used for testing exists on it.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.135703Z)
✅ uss2_dss (2026-03-03T21:57:51.138260Z)
If an OIR that was deleted from the primary DSS can still be found on a secondary DSS, either one of them may be improperly pooled and in violation of astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.135741Z)
✅ uss2_dss (2026-03-03T21:57:51.138297Z)
This test case creates an operational intent reference on the main DSS, and verifies that it is properly synchronized to the other DSS instances.
It then goes on to mutate and delete it, each time confirming that all other DSSes return the expected results.
This test step fragment validates that:
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:51.153275Z)
This test step fragment validates that an operational intent references creation returns a body in the correct format.
The response to a successful operational intent reference creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.161410Z)
A successful operational intent reference creation query is expected to return a body, the content of which reflects the created operational intent reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:51.162369Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.162049Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.162093Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.162126Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.162355Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.162157Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.162188Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.162216Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.162272Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.162243Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.162300Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.162327Z)
Retrieve and validate synchronization of the created operational intent at every DSS provided in dss_instances.
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.165702Z)
✅ uss2_dss (2026-03-03T21:57:51.170214Z)
If the operational intent retrieved from a secondary DSS instance is not consistent with the newly created one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1a, astm.f3548.v21.DSS0210,A2-7-2,1d, , astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.166415Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.170874Z)
This test step fragment validates that operational intent references are properly synchronized across a set of DSS instances by querying an operational intent reference that is known to exist at each one of the DSS instances.
If the previously created or mutated operational intent reference cannot be found at a DSS, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.165751Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.170261Z)
This test step fragment validates that operational intent reference attributes are properly synchronized across a set of DSS instances.
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct manager, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.165797Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.170309Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.165828Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.170341Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct state, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.165861Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.170370Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct start time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.166368Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.170827Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct end time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.166401Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.170861Z)
Search for and validate synchronization of the created operational intent at every DSS provided in dss_instances.
This test step fragment validates that a query to search for operational intent references with valid parameters succeeds.
If the DSS fails to let us search in the area for which the OIR was created, it is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.175701Z)
✅ uss2_dss (2026-03-03T21:57:51.181210Z)
If the operational intent searched from a secondary DSS instance is not consistent with the newly created one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1a, astm.f3548.v21.DSS0210,A2-7-2,1c, , astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.176392Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.181871Z)
This test step fragment validates that operational intent references are properly synchronized across a set of DSS instances by searching for an operational intent reference that is known to exist in a specific area at each one of the DSS instances.
When querying a secondary DSS for operational intents in the planning area that contains the propagated operational intent, if the propagated operational intent is not contained in the response, then the general area in which the propagated operational intent is located is not synchronized across DSS instances. As such, either the primary or the secondary DSS fails to properly implement one of the following requirements:
astm.f3548.v21.DSS0210,2e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.175747Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.181256Z)
This test step fragment validates that operational intent reference attributes are properly synchronized across a set of DSS instances.
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct manager, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.175792Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.181302Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.175821Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.181331Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct state, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.175849Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.181359Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct start time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.176341Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.181812Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct end time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.176373Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.181845Z)
This test step mutates the previously created operational intent reference to verify that the DSS reacts properly: notably, it checks that the operational intent reference version is updated, including for changes that are not directly visible, such as changing the operational intent reference's footprint.
This test step fragment validates that operational intent references can be updated.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss1_dss (2026-03-03T21:57:51.200338Z)
This test step fragment validates that updates to operational intent references return a body in the correct format.
The response to a successful operational intent reference mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.208678Z)
A successful operational intent reference mutation query is expected to return a well-defined body, the content of which reflects the updated operational intent reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:51.209695Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.209316Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.209360Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.209394Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.209682Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.209424Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.209455Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.209484Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.209541Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.209512Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.209570Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.209627Z)
This test step fragment attempts to validate a single operational intent reference returned by the DSS, usually after it has been mutated.
The code for these checks lives in the oir_validator.py class.
Following a mutation, the DSS needs to update the operational intent reference version, otherwise it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.209654Z)
Following a mutation, the DSS needs to update the operational intent reference OVN, otherwise it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.209598Z)
Retrieve and validate synchronization of the updated operational intent at every DSS provided in dss_instances.
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.212934Z)
✅ uss2_dss (2026-03-03T21:57:51.216690Z)
If the operational intent retrieved from a secondary DSS instance is not consistent with the updated one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1b and astm.f3548.v21.DSS0210,A2-7-2,1d.
✅ uss1_dss (2026-03-03T21:57:51.213653Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.217377Z)
This test step fragment validates that operational intent references are properly synchronized across a set of DSS instances by querying an operational intent reference that is known to exist at each one of the DSS instances.
If the previously created or mutated operational intent reference cannot be found at a DSS, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.212981Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.216738Z)
This test step fragment validates that operational intent reference attributes are properly synchronized across a set of DSS instances.
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct manager, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.213064Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.216784Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.213100Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.216814Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct state, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.213128Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.216841Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct start time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.213606Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.217331Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct end time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.213639Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.217364Z)
Search for and validate synchronization of the updated operational intent at every DSS provided in dss_instances.
This test step fragment validates that a query to search for operational intent references with valid parameters succeeds.
If the DSS fails to let us search in the area for which the OIR was created, it is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.222234Z)
✅ uss2_dss (2026-03-03T21:57:51.227765Z)
If the operational intent searched from a secondary DSS instance is not consistent with the updated one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1b and astm.f3548.v21.DSS0210,A2-7-2,1c.
✅ uss1_dss (2026-03-03T21:57:51.222901Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.228497Z)
This test step fragment validates that operational intent references are properly synchronized across a set of DSS instances by searching for an operational intent reference that is known to exist in a specific area at each one of the DSS instances.
When querying a secondary DSS for operational intents in the planning area that contains the propagated operational intent, if the propagated operational intent is not contained in the response, then the general area in which the propagated operational intent is located is not synchronized across DSS instances. As such, either the primary or the secondary DSS fails to properly implement one of the following requirements:
astm.f3548.v21.DSS0210,2e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.222280Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.227818Z)
This test step fragment validates that operational intent reference attributes are properly synchronized across a set of DSS instances.
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct manager, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.222324Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.227885Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.222359Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.227919Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct state, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.222386Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.227948Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct start time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.222851Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.228451Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct end time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:51.222883Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:51.228484Z)
This test step fragment validates that deleting an operational intent reference succeeds and returns the expected deleted operational intent reference.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.242543Z)
The response to a successful operational intent reference deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.250392Z)
A successful operational intent reference deletion query is expected to return a body, the content of which reflects the operational intent reference at the moment of deletion. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:51.251430Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.251044Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.251088Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.251122Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.251416Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.251153Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.251184Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.251213Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.251270Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.251241Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.251300Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss1_dss (2026-03-03T21:57:51.251355Z)
This test step fragment attempts to validate a single operational intent reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the oir_validator.py class.
If the version of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.251388Z)
If the OVN of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.251328Z)
Attempt to query and search for the deleted operational intent reference in various ways
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
Check that read query succeeds.
✅ uss1_dss (2026-03-03T21:57:51.254044Z)
✅ uss2_dss (2026-03-03T21:57:51.259665Z)
If a DSS returns an operational intent reference that was previously successfully deleted from the primary DSS, either one of the primary DSS or the DSS that returned the operational intent reference is in violation of astm.f3548.v21.DSS0210,2a and astm.f3548.v21.DSS0210,A2-7-2,3b.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:51.254109Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:51.259707Z)
This test step fragment validates that a query to search for operational intent references with valid parameters succeeds.
If the DSS fails to let us search in the area for which the OIR was created, it is failing to meet astm.f3548.v21.DSS0005,1.
Check that search query succeeds.
✅ uss1_dss (2026-03-03T21:57:51.257588Z)
✅ uss2_dss (2026-03-03T21:57:51.263083Z)
If a DSS returns an operational intent reference that was previously successfully deleted from the primary DSS, either one of the primary DSS or the DSS that returned the operational intent reference is in violation of astm.f3548.v21.DSS0210,2a and astm.f3548.v21.DSS0210,A2-7-2,3a.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:51.257628Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:51.263127Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.269271Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:51.267164Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1. ∅ This check was not applicable to this test run and is therefore not statused.
Ensures that a DSS properly authenticates requests to all its endpoints.
Note that this does not cover authorization.
DSSInstanceResource to be tested in this scenario.
Note that to benefit from the maximum coverage, the DSS' AuthAdapterResource must be able to obtain credentials for multiple scopes (so that a wrong scope may be used in place of the correct one) as well as an empty scope (that is, provide credentials where the scope is an empty string).
This scenario will check for the scope's availability and transparently ignore checks that can't be conducted.
At least one of the following scopes needs to be available for this scenario to at least partially run:
utm.strategic_coordinationutm.availability_arbitrationutm.constraint_managementIn order to verify each endpoint group, all scopes above must be available.
Optional scopes that will allow the scenario to provide additional coverage:
"" (empty string)✅ Provided by instance 1 in dss_instances in top-level resource pool.
IDGeneratorResource providing the Subscription ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which entities will be created.
✅ Provided by planning_area in top-level resource pool.
To perform this scenario, the area must be clear of test entities with the IDs we intend to use.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.272626Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
∅ This check was not applicable to this test run and is therefore not statused.
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:51.286926Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:51.274781Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any constraint references from the DSS that may have been left behind from testing efforts.
If an existing constraint reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:51.277350Z)
A client with valid credentials should be allowed to search for constraint references in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,4.
∅ This check was not applicable to this test run and is therefore not statused.
If an existing constraint cannot be deleted by its manager when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
This step ensures that the availability for the test identifier is set to Unknown.
∅ This check was not applicable to this test run and is therefore not statused.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:51.280042Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:51.284213Z)
This test case ensures that the DSS properly authenticates requests to all its endpoints.
If the DSS under test does not return a proper error message body when an unauthorized request is received, it fails to properly implement the OpenAPI specification that is part of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:51.297625Z)
✅ uss1_dss (2026-03-03T21:57:51.302735Z)
✅ uss1_dss (2026-03-03T21:57:51.355329Z)
✅ uss1_dss (2026-03-03T21:57:51.360684Z)
✅ uss1_dss (2026-03-03T21:57:51.369146Z)
✅ uss1_dss (2026-03-03T21:57:51.374156Z)
✅ uss1_dss (2026-03-03T21:57:51.384778Z)
✅ uss1_dss (2026-03-03T21:57:51.389758Z)
✅ uss1_dss (2026-03-03T21:57:51.406381Z)
✅ uss1_dss (2026-03-03T21:57:51.413127Z)
✅ uss1_dss (2026-03-03T21:57:51.419256Z)
✅ uss1_dss (2026-03-03T21:57:51.425440Z)
✅ uss1_dss (2026-03-03T21:57:51.443859Z)
✅ uss1_dss (2026-03-03T21:57:51.454106Z)
✅ uss1_dss (2026-03-03T21:57:51.464148Z)
✅ uss1_dss (2026-03-03T21:57:51.474744Z)
✅ uss1_dss (2026-03-03T21:57:51.492389Z)
✅ uss1_dss (2026-03-03T21:57:51.502107Z)
✅ uss1_dss (2026-03-03T21:57:51.512528Z)
✅ uss1_dss (2026-03-03T21:57:51.523893Z)
✅ uss1_dss (2026-03-03T21:57:51.542269Z)
✅ uss1_dss (2026-03-03T21:57:51.549967Z)
✅ uss1_dss (2026-03-03T21:57:51.556970Z)
✅ uss1_dss (2026-03-03T21:57:51.565490Z)
If the DSS under test allows the creation of a subscription without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.297657Z)
If the DSS under test allows the creation of a subscription with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.355363Z)
If the DSS under test allows the creation of a subscription with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.369178Z)
If the DSS under test allows the creation of a subscription with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.384810Z)
If the DSS does not allow the creation of a subscription when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:51.399251Z)
If the DSS under test allows the fetching of a subscription without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.400915Z)
If the DSS under test allows the fetching of a subscription with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.407657Z)
If the DSS under test allows the fetching of a subscription with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.414220Z)
If the DSS under test allows the fetching of a subscription with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.420397Z)
If the DSS does not allow fetching a subscription when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:51.429037Z)
If the DSS under test allows the mutation of a subscription without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.434641Z)
If the DSS under test allows the mutation of a subscription with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.449089Z)
If the DSS under test allows the mutation of a subscription with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.458999Z)
If the DSS under test allows the mutation of a subscription with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.469359Z)
If the DSS does not allow the mutation of a subscription when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:51.482199Z)
If the DSS under test allows the deletion of a subscription without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.487105Z)
If the DSS under test allows the deletion of a subscription with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.496890Z)
If the DSS under test allows the deletion of a subscription with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.506760Z)
If the DSS under test allows the deletion of a subscription with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.517294Z)
If the DSS does not allow the deletion of a subscription when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:51.532510Z)
✅ uss1_dss (2026-03-03T21:57:51.534989Z)
If the DSS under test allows searching for subscriptions without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.536430Z)
If the DSS under test allows searching for subscriptions with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.544308Z)
If the DSS under test allows searching for subscriptions with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.551384Z)
If the DSS under test allows searching for subscriptions with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.558983Z)
If the DSS does not allow searching for subscriptions when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:51.568969Z)
If the DSS under test does not return a proper error message body when an unauthorized request is received, it fails to properly implement the OpenAPI specification that is part of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.578628Z)
✅ uss1_dss (2026-03-03T21:57:51.587294Z)
✅ uss1_dss (2026-03-03T21:57:51.595734Z)
✅ uss1_dss (2026-03-03T21:57:51.604732Z)
✅ uss1_dss (2026-03-03T21:57:51.627256Z)
✅ uss1_dss (2026-03-03T21:57:51.633765Z)
✅ uss1_dss (2026-03-03T21:57:51.640350Z)
✅ uss1_dss (2026-03-03T21:57:51.646750Z)
✅ uss1_dss (2026-03-03T21:57:51.659204Z)
✅ uss1_dss (2026-03-03T21:57:51.669029Z)
✅ uss1_dss (2026-03-03T21:57:51.678453Z)
✅ uss1_dss (2026-03-03T21:57:51.688045Z)
✅ uss1_dss (2026-03-03T21:57:51.707829Z)
✅ uss1_dss (2026-03-03T21:57:51.714232Z)
✅ uss1_dss (2026-03-03T21:57:51.720350Z)
✅ uss1_dss (2026-03-03T21:57:51.727050Z)
✅ uss1_dss (2026-03-03T21:57:51.743314Z)
✅ uss1_dss (2026-03-03T21:57:51.750149Z)
✅ uss1_dss (2026-03-03T21:57:51.756241Z)
✅ uss1_dss (2026-03-03T21:57:51.762757Z)
If the DSS under test allows the creation of an operational intent without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.572993Z)
If the DSS under test allows the creation of an operational intent with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.582242Z)
If the DSS under test allows the creation of an operational intent with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.590682Z)
If the DSS under test allows the creation of an operational intent with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.599183Z)
If the DSS does not allow the creation of an operational intent when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.619644Z)
This test step fragment validates that an operational intent references creation returns a body in the correct format.
The response to a successful operational intent reference creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
Check response format of a creation request.
✅ uss1_dss (2026-03-03T21:57:51.620345Z)
If the DSS under test allows the fetching of an operational intent without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.621403Z)
If the DSS under test allows the fetching of an operational intent with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.628546Z)
If the DSS under test allows the fetching of an operational intent with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.634793Z)
If the DSS under test allows the fetching of an operational intent with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.641508Z)
If the DSS does not allow fetching an operational intent when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.649613Z)
If the DSS under test allows the mutation of an operational intent without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.653890Z)
If the DSS under test allows the mutation of an operational intent with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.663636Z)
If the DSS under test allows the mutation of an operational intent with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.673314Z)
If the DSS under test allows the mutation of an operational intent with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.682816Z)
If the DSS does not allow the mutation of an operational intent when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.700274Z)
This test step fragment validates that updates to operational intent references return a body in the correct format.
The response to a successful operational intent reference mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
Check response format of a mutation.
✅ uss1_dss (2026-03-03T21:57:51.700799Z)
If the DSS under test allows the deletion of an operational intent without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.701929Z)
If the DSS under test allows the deletion of an operational intent with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.709081Z)
If the DSS under test allows the deletion of an operational intent with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.715272Z)
If the DSS under test allows the deletion of an operational intent with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.721613Z)
If the DSS does not allow the deletion of an operational intent when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.735922Z)
If the DSS under test allows searching for operational intents without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.737606Z)
If the DSS under test allows searching for operational intents with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.744702Z)
If the DSS under test allows searching for operational intents with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.751258Z)
If the DSS under test allows searching for operational intents with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.757533Z)
If the DSS does not allow searching for operational intents when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:51.766391Z)
If the DSS under test does not return a proper error message body when an unauthorized request is received, it fails to properly implement the OpenAPI specification that is part of astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:51.773577Z)
✅ uss1_dss (2026-03-03T21:57:51.785274Z)
✅ uss1_dss (2026-03-03T21:57:51.791686Z)
✅ uss1_dss (2026-03-03T21:57:51.797850Z)
✅ uss1_dss (2026-03-03T21:57:51.809188Z)
✅ uss1_dss (2026-03-03T21:57:51.817762Z)
✅ uss1_dss (2026-03-03T21:57:51.826153Z)
✅ uss1_dss (2026-03-03T21:57:51.834932Z)
If the DSS under test allows the fetching of a USS's availability without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.768367Z)
If the DSS under test allows the fetching of a USS's availability with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.776230Z)
If the DSS under test allows the fetching of a USS's availability with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.786203Z)
If the DSS under test allows the fetching of a USS's availability with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.792849Z)
If the DSS does not allow fetching a USS's availability when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:51.800172Z)
✅ uss1_dss (2026-03-03T21:57:51.803755Z)
✅ uss1_dss (2026-03-03T21:57:51.812626Z)
✅ uss1_dss (2026-03-03T21:57:51.820960Z)
✅ uss1_dss (2026-03-03T21:57:51.829449Z)
The response to a successful USS Availability request is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21,
otherwise, the DSS is failing to implement astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:51.800336Z)
If the DSS under test allows the setting of a USS's availability without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.803779Z)
If the DSS under test allows the setting of a USS's availability with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.812650Z)
If the DSS under test allows the setting of a USS's availability with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.820985Z)
If the DSS under test allows the setting of a USS's availability with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.829474Z)
If the DSS does not allow setting a USS's availability when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:51.839730Z)
The response to a successful USS Availability Set request is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21,
otherwise, the DSS is failing to implement astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:51.839892Z)
If the DSS under test does not return a proper error message body when an unauthorized request is received, it fails to properly implement the OpenAPI specification that is part of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:51.850539Z)
✅ uss1_dss (2026-03-03T21:57:51.860763Z)
✅ uss1_dss (2026-03-03T21:57:51.868963Z)
✅ uss1_dss (2026-03-03T21:57:51.877250Z)
✅ uss1_dss (2026-03-03T21:57:51.892060Z)
✅ uss1_dss (2026-03-03T21:57:51.898348Z)
✅ uss1_dss (2026-03-03T21:57:51.904521Z)
✅ uss1_dss (2026-03-03T21:57:51.911197Z)
✅ uss1_dss (2026-03-03T21:57:51.922930Z)
✅ uss1_dss (2026-03-03T21:57:51.931953Z)
✅ uss1_dss (2026-03-03T21:57:51.941821Z)
✅ uss1_dss (2026-03-03T21:57:51.950907Z)
✅ uss1_dss (2026-03-03T21:57:51.964933Z)
✅ uss1_dss (2026-03-03T21:57:51.971673Z)
✅ uss1_dss (2026-03-03T21:57:51.977784Z)
✅ uss1_dss (2026-03-03T21:57:51.984041Z)
✅ uss1_dss (2026-03-03T21:57:51.999204Z)
✅ uss1_dss (2026-03-03T21:57:52.005707Z)
✅ uss1_dss (2026-03-03T21:57:52.012258Z)
✅ uss1_dss (2026-03-03T21:57:52.019066Z)
If the DSS under test allows the creation of a constraint reference without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.845111Z)
If the DSS under test allows the creation of a constraint reference with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.855252Z)
If the DSS under test allows the creation of a constraint reference with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.863824Z)
If the DSS under test allows the creation of a constraint reference with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.872143Z)
If the DSS does not allow the creation of a constraint reference when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:51.884649Z)
This test step fragment validates that a constraint references creation returns a body in the correct format.
The response to a successful constraint reference creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
Check response format of a creation request.
✅ uss1_dss (2026-03-03T21:57:51.885354Z)
If the DSS under test allows the fetching of a constraint reference without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.886378Z)
If the DSS under test allows the fetching of a constraint reference with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.893247Z)
If the DSS under test allows the fetching of a constraint reference with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.899327Z)
If the DSS under test allows the fetching of a constraint reference with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.905694Z)
If the DSS does not allow fetching a constraint reference when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:51.913455Z)
This test step fragment validates that a request for a constraint reference returns a properly formatted body.
The response to a successful get constraint reference query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
Check response format of a mutation.
✅ uss1_dss (2026-03-03T21:57:51.913994Z)
If the DSS under test allows the mutation of a constraint reference without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.917893Z)
If the DSS under test allows the mutation of a constraint reference with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.926895Z)
If the DSS under test allows the mutation of a constraint reference with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.936407Z)
If the DSS under test allows the mutation of a constraint reference with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.945773Z)
If the DSS does not allow the mutation of a constraint reference when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:51.957847Z)
This test step fragment validates that updates to constraint references return a body in the correct format.
The response to a successful constraint reference mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
Check response format of a mutation.
✅ uss1_dss (2026-03-03T21:57:51.958444Z)
If the DSS under test allows the deletion of a constraint reference without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.959574Z)
If the DSS under test allows the deletion of a constraint reference with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.966202Z)
If the DSS under test allows the deletion of a constraint reference with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.972690Z)
If the DSS under test allows the deletion of a constraint reference with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.979064Z)
If the DSS does not allow the deletion of a constraint reference when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:51.990581Z)
This test step fragment validates that a constraint references deletion returns a body in the correct format.
The response to a successful constraint reference deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
Check response format of a deletion.
✅ uss1_dss (2026-03-03T21:57:51.991201Z)
If the DSS under test allows searching for constraint references without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:51.992818Z)
If the DSS under test allows searching for constraint references with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:52.000574Z)
If the DSS under test allows searching for constraint references with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:52.006943Z)
If the DSS under test allows searching for constraint references with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss1_dss (2026-03-03T21:57:52.013625Z)
If the DSS does not allow searching for constraint references when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:52.022683Z)
This test step fragment validates that constraint references search responses are properly formatted.
The response to a successful constraint reference search query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,4.
Check response format of a search.
✅ uss1_dss (2026-03-03T21:57:52.022806Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:52.025680Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
∅ This check was not applicable to this test run and is therefore not statused.
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:52.027721Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any constraint references from the DSS that may have been left behind from testing efforts.
If an existing constraint reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:52.029675Z)
A client with valid credentials should be allowed to search for constraint references in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,4.
∅ This check was not applicable to this test run and is therefore not statused.
If an existing constraint cannot be deleted by its manager when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
∅ This check was not applicable to this test run and is therefore not statused.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:52.031922Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
The cleanup phase of this test scenario removes the subscription with the known test ID if it has not been removed before.
✅ uss1_dss (2026-03-03T21:57:52.036563Z)
Perform basic operations on a single DSS instance to create, update and delete subscriptions.
DSSInstanceResource to be tested in this scenario.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
IDGeneratorResource providing the Subscription IDs for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which subscriptions will be created.
✅ Provided by planning_area in top-level resource pool.
VolumeResource describing an area designed to be too big to be accepted by the DSS as a subscription area.
✅ Provided by problematically_big_area in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:52.040590Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:52.042797Z)
✅ uss1_dss (2026-03-03T21:57:52.044793Z)
✅ uss1_dss (2026-03-03T21:57:52.046924Z)
✅ uss1_dss (2026-03-03T21:57:52.048923Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
This test case creates multiple subscriptions, goes on to query and search for them, then deletes and searches for them again.
This test step creates multiple subscriptions with different combinations of the optional end and start time parameters.
All subscriptions are left on the DSS when this step ends, as they are expected to be present for the subsequent step.
This test step fragment validates that subscriptions can be created.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:52.057485Z)
✅ uss1_dss (2026-03-03T21:57:52.076497Z)
✅ uss1_dss (2026-03-03T21:57:52.093907Z)
✅ uss1_dss (2026-03-03T21:57:52.110436Z)
The response to a successful subscription creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.065843Z)
✅ uss1_dss (2026-03-03T21:57:52.084338Z)
✅ uss1_dss (2026-03-03T21:57:52.100747Z)
✅ uss1_dss (2026-03-03T21:57:52.117658Z)
A successful subscription creation query is expected to return a well-defined body, the content of which reflects the created subscription.
If the content of the response does not correspond to the requested content, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.067467Z)
✅ uss1_dss (2026-03-03T21:57:52.085757Z)
✅ uss1_dss (2026-03-03T21:57:52.102121Z)
✅ uss1_dss (2026-03-03T21:57:52.119134Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.066616Z)
✅ uss1_dss (2026-03-03T21:57:52.084862Z)
✅ uss1_dss (2026-03-03T21:57:52.101281Z)
✅ uss1_dss (2026-03-03T21:57:52.118227Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.066665Z)
✅ uss1_dss (2026-03-03T21:57:52.084906Z)
✅ uss1_dss (2026-03-03T21:57:52.101323Z)
✅ uss1_dss (2026-03-03T21:57:52.118270Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.066717Z)
✅ uss1_dss (2026-03-03T21:57:52.084942Z)
✅ uss1_dss (2026-03-03T21:57:52.101356Z)
✅ uss1_dss (2026-03-03T21:57:52.118304Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.066761Z)
✅ uss1_dss (2026-03-03T21:57:52.084973Z)
✅ uss1_dss (2026-03-03T21:57:52.101386Z)
✅ uss1_dss (2026-03-03T21:57:52.118335Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.101448Z)
✅ uss1_dss (2026-03-03T21:57:52.118397Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.066794Z)
✅ uss1_dss (2026-03-03T21:57:52.085024Z)
✅ uss1_dss (2026-03-03T21:57:52.101414Z)
✅ uss1_dss (2026-03-03T21:57:52.118363Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.085066Z)
✅ uss1_dss (2026-03-03T21:57:52.118434Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.066825Z)
✅ uss1_dss (2026-03-03T21:57:52.085117Z)
✅ uss1_dss (2026-03-03T21:57:52.101508Z)
✅ uss1_dss (2026-03-03T21:57:52.118461Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.066854Z)
✅ uss1_dss (2026-03-03T21:57:52.085180Z)
✅ uss1_dss (2026-03-03T21:57:52.101570Z)
✅ uss1_dss (2026-03-03T21:57:52.118489Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.066883Z)
✅ uss1_dss (2026-03-03T21:57:52.085216Z)
✅ uss1_dss (2026-03-03T21:57:52.101605Z)
✅ uss1_dss (2026-03-03T21:57:52.118544Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.066911Z)
✅ uss1_dss (2026-03-03T21:57:52.085246Z)
✅ uss1_dss (2026-03-03T21:57:52.101635Z)
✅ uss1_dss (2026-03-03T21:57:52.118597Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after the creation of a subscription.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
The notification index of a newly created subscription must be 0, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.067443Z)
✅ uss1_dss (2026-03-03T21:57:52.085733Z)
✅ uss1_dss (2026-03-03T21:57:52.102099Z)
✅ uss1_dss (2026-03-03T21:57:52.119108Z)
Query and search for the created subscription in various ways
If the query to get an existing subscription fails, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.263861Z)
✅ uss1_dss (2026-03-03T21:57:52.275088Z)
✅ uss1_dss (2026-03-03T21:57:52.286606Z)
✅ uss1_dss (2026-03-03T21:57:52.297469Z)
A successful get subscription query is expected to return a well-defined body, the content of which reflects the created subscription. If the format and content of the response are not conforming, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.271520Z)
✅ uss1_dss (2026-03-03T21:57:52.283054Z)
✅ uss1_dss (2026-03-03T21:57:52.293965Z)
✅ uss1_dss (2026-03-03T21:57:52.305046Z)
The response to a successful get subscription query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.270560Z)
✅ uss1_dss (2026-03-03T21:57:52.282051Z)
✅ uss1_dss (2026-03-03T21:57:52.292999Z)
✅ uss1_dss (2026-03-03T21:57:52.304122Z)
If the search query for the area for which the subscription was just created fails, it is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.309537Z)
A successful search query is expected to return a well-defined body, the content of which reflects the created subscription as well as any other subscription in the area. If the format and content of the response are not conforming, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.319704Z)
✅ uss1_dss (2026-03-03T21:57:52.330195Z)
✅ uss1_dss (2026-03-03T21:57:52.340132Z)
✅ uss1_dss (2026-03-03T21:57:52.350072Z)
The response to a successful subscription search query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.319230Z)
✅ uss1_dss (2026-03-03T21:57:52.329629Z)
✅ uss1_dss (2026-03-03T21:57:52.339641Z)
✅ uss1_dss (2026-03-03T21:57:52.349574Z)
If the created subscription is not returned in a search that covers the area it was created for, the DSS is not properly implementing astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.319289Z)
✅ uss1_dss (2026-03-03T21:57:52.329687Z)
✅ uss1_dss (2026-03-03T21:57:52.339699Z)
✅ uss1_dss (2026-03-03T21:57:52.349632Z)
In accordance with astm.f3548.v21.DSS0005,5, the DSS should not allow searches for areas that are too big.
✅ uss1_dss (2026-03-03T21:57:52.352506Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.271116Z)
✅ uss1_dss (2026-03-03T21:57:52.282572Z)
✅ uss1_dss (2026-03-03T21:57:52.293561Z)
✅ uss1_dss (2026-03-03T21:57:52.304632Z)
✅ uss1_dss (2026-03-03T21:57:52.319329Z)
✅ uss1_dss (2026-03-03T21:57:52.329727Z)
✅ uss1_dss (2026-03-03T21:57:52.339738Z)
✅ uss1_dss (2026-03-03T21:57:52.349672Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.271162Z)
✅ uss1_dss (2026-03-03T21:57:52.282617Z)
✅ uss1_dss (2026-03-03T21:57:52.293607Z)
✅ uss1_dss (2026-03-03T21:57:52.304676Z)
✅ uss1_dss (2026-03-03T21:57:52.319362Z)
✅ uss1_dss (2026-03-03T21:57:52.329760Z)
✅ uss1_dss (2026-03-03T21:57:52.339771Z)
✅ uss1_dss (2026-03-03T21:57:52.349706Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.271198Z)
✅ uss1_dss (2026-03-03T21:57:52.282653Z)
✅ uss1_dss (2026-03-03T21:57:52.293643Z)
✅ uss1_dss (2026-03-03T21:57:52.304711Z)
✅ uss1_dss (2026-03-03T21:57:52.319395Z)
✅ uss1_dss (2026-03-03T21:57:52.329792Z)
✅ uss1_dss (2026-03-03T21:57:52.339803Z)
✅ uss1_dss (2026-03-03T21:57:52.349738Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.271230Z)
✅ uss1_dss (2026-03-03T21:57:52.282686Z)
✅ uss1_dss (2026-03-03T21:57:52.293675Z)
✅ uss1_dss (2026-03-03T21:57:52.304744Z)
✅ uss1_dss (2026-03-03T21:57:52.319425Z)
✅ uss1_dss (2026-03-03T21:57:52.329822Z)
✅ uss1_dss (2026-03-03T21:57:52.339833Z)
✅ uss1_dss (2026-03-03T21:57:52.349768Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.271295Z)
✅ uss1_dss (2026-03-03T21:57:52.282750Z)
✅ uss1_dss (2026-03-03T21:57:52.293740Z)
✅ uss1_dss (2026-03-03T21:57:52.304808Z)
✅ uss1_dss (2026-03-03T21:57:52.319487Z)
✅ uss1_dss (2026-03-03T21:57:52.329889Z)
✅ uss1_dss (2026-03-03T21:57:52.339894Z)
✅ uss1_dss (2026-03-03T21:57:52.349829Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.271262Z)
✅ uss1_dss (2026-03-03T21:57:52.282716Z)
✅ uss1_dss (2026-03-03T21:57:52.293705Z)
✅ uss1_dss (2026-03-03T21:57:52.304775Z)
✅ uss1_dss (2026-03-03T21:57:52.319454Z)
✅ uss1_dss (2026-03-03T21:57:52.329856Z)
✅ uss1_dss (2026-03-03T21:57:52.339861Z)
✅ uss1_dss (2026-03-03T21:57:52.349797Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.271326Z)
✅ uss1_dss (2026-03-03T21:57:52.282783Z)
✅ uss1_dss (2026-03-03T21:57:52.293772Z)
✅ uss1_dss (2026-03-03T21:57:52.304839Z)
✅ uss1_dss (2026-03-03T21:57:52.319519Z)
✅ uss1_dss (2026-03-03T21:57:52.329923Z)
✅ uss1_dss (2026-03-03T21:57:52.339926Z)
✅ uss1_dss (2026-03-03T21:57:52.349861Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.271355Z)
✅ uss1_dss (2026-03-03T21:57:52.282813Z)
✅ uss1_dss (2026-03-03T21:57:52.293802Z)
✅ uss1_dss (2026-03-03T21:57:52.304868Z)
✅ uss1_dss (2026-03-03T21:57:52.319548Z)
✅ uss1_dss (2026-03-03T21:57:52.329952Z)
✅ uss1_dss (2026-03-03T21:57:52.339955Z)
✅ uss1_dss (2026-03-03T21:57:52.349889Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.271416Z)
✅ uss1_dss (2026-03-03T21:57:52.282872Z)
✅ uss1_dss (2026-03-03T21:57:52.293860Z)
✅ uss1_dss (2026-03-03T21:57:52.304924Z)
✅ uss1_dss (2026-03-03T21:57:52.319605Z)
✅ uss1_dss (2026-03-03T21:57:52.330084Z)
✅ uss1_dss (2026-03-03T21:57:52.340028Z)
✅ uss1_dss (2026-03-03T21:57:52.349946Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.271446Z)
✅ uss1_dss (2026-03-03T21:57:52.282903Z)
✅ uss1_dss (2026-03-03T21:57:52.293890Z)
✅ uss1_dss (2026-03-03T21:57:52.304953Z)
✅ uss1_dss (2026-03-03T21:57:52.319634Z)
✅ uss1_dss (2026-03-03T21:57:52.330120Z)
✅ uss1_dss (2026-03-03T21:57:52.340061Z)
✅ uss1_dss (2026-03-03T21:57:52.349975Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
Verify that the subscription returned by the DSS via the search is correctly formatted and corresponds to what was created earlier.
✅ uss1_dss (2026-03-03T21:57:52.271476Z)
✅ uss1_dss (2026-03-03T21:57:52.282972Z)
✅ uss1_dss (2026-03-03T21:57:52.293919Z)
✅ uss1_dss (2026-03-03T21:57:52.304981Z)
✅ uss1_dss (2026-03-03T21:57:52.319662Z)
✅ uss1_dss (2026-03-03T21:57:52.330151Z)
✅ uss1_dss (2026-03-03T21:57:52.340090Z)
✅ uss1_dss (2026-03-03T21:57:52.350017Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its creation or mutation.
The code for these checks lives in the subscription_validator.py class.
If the version of the subscription is updated without there having been any mutation of the subscription, the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.271386Z)
✅ uss1_dss (2026-03-03T21:57:52.282843Z)
✅ uss1_dss (2026-03-03T21:57:52.293831Z)
✅ uss1_dss (2026-03-03T21:57:52.304896Z)
✅ uss1_dss (2026-03-03T21:57:52.319576Z)
✅ uss1_dss (2026-03-03T21:57:52.330031Z)
✅ uss1_dss (2026-03-03T21:57:52.339984Z)
✅ uss1_dss (2026-03-03T21:57:52.349918Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
Verify that the version field is as expected.
✅ uss1_dss (2026-03-03T21:57:52.271507Z)
✅ uss1_dss (2026-03-03T21:57:52.283036Z)
✅ uss1_dss (2026-03-03T21:57:52.293951Z)
✅ uss1_dss (2026-03-03T21:57:52.305030Z)
✅ uss1_dss (2026-03-03T21:57:52.319690Z)
✅ uss1_dss (2026-03-03T21:57:52.330180Z)
✅ uss1_dss (2026-03-03T21:57:52.340118Z)
✅ uss1_dss (2026-03-03T21:57:52.350056Z)
This test step attempts to mutate the subscription both with a missing and incorrect OVN, and checks that the DSS reacts properly.
If a request to mutate a subscription is missing the version and succeeds, the DSS is failing to properly implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.123285Z)
If a request to mutate a subscription providing the wrong version succeeds, the DSS is failing to properly implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.126541Z)
This test step mutates the previously created subscription to verify that the DSS reacts properly: notably, it checks that the subscription version is updated, including for changes that are not directly visible, such as changing the subscription's footprint.
If the query to mutate a subscription with valid parameters is not successful, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.134000Z)
✅ uss1_dss (2026-03-03T21:57:52.149490Z)
✅ uss1_dss (2026-03-03T21:57:52.170832Z)
✅ uss1_dss (2026-03-03T21:57:52.186704Z)
✅ uss1_dss (2026-03-03T21:57:52.202686Z)
✅ uss1_dss (2026-03-03T21:57:52.218567Z)
✅ uss1_dss (2026-03-03T21:57:52.235325Z)
✅ uss1_dss (2026-03-03T21:57:52.251090Z)
A successful subscription mutation query is expected to return a well-defined body, the content of which reflects the newly defined subscription. If the format and content of the response are not conforming, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.141914Z)
✅ uss1_dss (2026-03-03T21:57:52.161636Z)
✅ uss1_dss (2026-03-03T21:57:52.178775Z)
✅ uss1_dss (2026-03-03T21:57:52.194799Z)
✅ uss1_dss (2026-03-03T21:57:52.210643Z)
✅ uss1_dss (2026-03-03T21:57:52.226818Z)
✅ uss1_dss (2026-03-03T21:57:52.243112Z)
✅ uss1_dss (2026-03-03T21:57:52.259700Z)
The response to a successful subscription mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.140932Z)
✅ uss1_dss (2026-03-03T21:57:52.160660Z)
✅ uss1_dss (2026-03-03T21:57:52.177677Z)
✅ uss1_dss (2026-03-03T21:57:52.193879Z)
✅ uss1_dss (2026-03-03T21:57:52.209668Z)
✅ uss1_dss (2026-03-03T21:57:52.225888Z)
✅ uss1_dss (2026-03-03T21:57:52.242148Z)
✅ uss1_dss (2026-03-03T21:57:52.258731Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.141522Z)
✅ uss1_dss (2026-03-03T21:57:52.161253Z)
✅ uss1_dss (2026-03-03T21:57:52.178246Z)
✅ uss1_dss (2026-03-03T21:57:52.194421Z)
✅ uss1_dss (2026-03-03T21:57:52.210266Z)
✅ uss1_dss (2026-03-03T21:57:52.226430Z)
✅ uss1_dss (2026-03-03T21:57:52.242704Z)
✅ uss1_dss (2026-03-03T21:57:52.259279Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.141566Z)
✅ uss1_dss (2026-03-03T21:57:52.161300Z)
✅ uss1_dss (2026-03-03T21:57:52.178290Z)
✅ uss1_dss (2026-03-03T21:57:52.194463Z)
✅ uss1_dss (2026-03-03T21:57:52.210311Z)
✅ uss1_dss (2026-03-03T21:57:52.226473Z)
✅ uss1_dss (2026-03-03T21:57:52.242748Z)
✅ uss1_dss (2026-03-03T21:57:52.259322Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.141601Z)
✅ uss1_dss (2026-03-03T21:57:52.161337Z)
✅ uss1_dss (2026-03-03T21:57:52.178327Z)
✅ uss1_dss (2026-03-03T21:57:52.194497Z)
✅ uss1_dss (2026-03-03T21:57:52.210346Z)
✅ uss1_dss (2026-03-03T21:57:52.226509Z)
✅ uss1_dss (2026-03-03T21:57:52.242783Z)
✅ uss1_dss (2026-03-03T21:57:52.259357Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.141638Z)
✅ uss1_dss (2026-03-03T21:57:52.161367Z)
✅ uss1_dss (2026-03-03T21:57:52.178358Z)
✅ uss1_dss (2026-03-03T21:57:52.194527Z)
✅ uss1_dss (2026-03-03T21:57:52.210376Z)
✅ uss1_dss (2026-03-03T21:57:52.226539Z)
✅ uss1_dss (2026-03-03T21:57:52.242814Z)
✅ uss1_dss (2026-03-03T21:57:52.259387Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.141701Z)
✅ uss1_dss (2026-03-03T21:57:52.161427Z)
✅ uss1_dss (2026-03-03T21:57:52.178456Z)
✅ uss1_dss (2026-03-03T21:57:52.194587Z)
✅ uss1_dss (2026-03-03T21:57:52.210435Z)
✅ uss1_dss (2026-03-03T21:57:52.226608Z)
✅ uss1_dss (2026-03-03T21:57:52.242875Z)
✅ uss1_dss (2026-03-03T21:57:52.259447Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.141668Z)
✅ uss1_dss (2026-03-03T21:57:52.161395Z)
✅ uss1_dss (2026-03-03T21:57:52.178387Z)
✅ uss1_dss (2026-03-03T21:57:52.194556Z)
✅ uss1_dss (2026-03-03T21:57:52.210404Z)
✅ uss1_dss (2026-03-03T21:57:52.226574Z)
✅ uss1_dss (2026-03-03T21:57:52.242843Z)
✅ uss1_dss (2026-03-03T21:57:52.259416Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.141732Z)
✅ uss1_dss (2026-03-03T21:57:52.161458Z)
✅ uss1_dss (2026-03-03T21:57:52.178516Z)
✅ uss1_dss (2026-03-03T21:57:52.194617Z)
✅ uss1_dss (2026-03-03T21:57:52.210465Z)
✅ uss1_dss (2026-03-03T21:57:52.226638Z)
✅ uss1_dss (2026-03-03T21:57:52.242906Z)
✅ uss1_dss (2026-03-03T21:57:52.259476Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.141761Z)
✅ uss1_dss (2026-03-03T21:57:52.161485Z)
✅ uss1_dss (2026-03-03T21:57:52.178551Z)
✅ uss1_dss (2026-03-03T21:57:52.194644Z)
✅ uss1_dss (2026-03-03T21:57:52.210491Z)
✅ uss1_dss (2026-03-03T21:57:52.226665Z)
✅ uss1_dss (2026-03-03T21:57:52.242934Z)
✅ uss1_dss (2026-03-03T21:57:52.259504Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.141819Z)
✅ uss1_dss (2026-03-03T21:57:52.161541Z)
✅ uss1_dss (2026-03-03T21:57:52.178634Z)
✅ uss1_dss (2026-03-03T21:57:52.194700Z)
✅ uss1_dss (2026-03-03T21:57:52.210546Z)
✅ uss1_dss (2026-03-03T21:57:52.226718Z)
✅ uss1_dss (2026-03-03T21:57:52.242989Z)
✅ uss1_dss (2026-03-03T21:57:52.259578Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.141846Z)
✅ uss1_dss (2026-03-03T21:57:52.161568Z)
✅ uss1_dss (2026-03-03T21:57:52.178665Z)
✅ uss1_dss (2026-03-03T21:57:52.194729Z)
✅ uss1_dss (2026-03-03T21:57:52.210573Z)
✅ uss1_dss (2026-03-03T21:57:52.226746Z)
✅ uss1_dss (2026-03-03T21:57:52.243036Z)
✅ uss1_dss (2026-03-03T21:57:52.259625Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
Verify that the subscription returned by the DSS via the mutation is properly formatted and contains the correct content.
✅ uss1_dss (2026-03-03T21:57:52.141873Z)
✅ uss1_dss (2026-03-03T21:57:52.161595Z)
✅ uss1_dss (2026-03-03T21:57:52.178716Z)
✅ uss1_dss (2026-03-03T21:57:52.194757Z)
✅ uss1_dss (2026-03-03T21:57:52.210601Z)
✅ uss1_dss (2026-03-03T21:57:52.226775Z)
✅ uss1_dss (2026-03-03T21:57:52.243068Z)
✅ uss1_dss (2026-03-03T21:57:52.259656Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its mutation.
The code for these checks lives in the subscription_validator.py class.
Following a mutation, the DSS needs to update the subscription version, otherwise it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.141790Z)
✅ uss1_dss (2026-03-03T21:57:52.161513Z)
✅ uss1_dss (2026-03-03T21:57:52.178600Z)
✅ uss1_dss (2026-03-03T21:57:52.194673Z)
✅ uss1_dss (2026-03-03T21:57:52.210518Z)
✅ uss1_dss (2026-03-03T21:57:52.226691Z)
✅ uss1_dss (2026-03-03T21:57:52.242961Z)
✅ uss1_dss (2026-03-03T21:57:52.259530Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
Verify that the version field has been mutated.
✅ uss1_dss (2026-03-03T21:57:52.141902Z)
✅ uss1_dss (2026-03-03T21:57:52.161623Z)
✅ uss1_dss (2026-03-03T21:57:52.178750Z)
✅ uss1_dss (2026-03-03T21:57:52.194786Z)
✅ uss1_dss (2026-03-03T21:57:52.210630Z)
✅ uss1_dss (2026-03-03T21:57:52.226805Z)
✅ uss1_dss (2026-03-03T21:57:52.243099Z)
✅ uss1_dss (2026-03-03T21:57:52.259687Z)
Attempt to delete the subscription in various ways and ensure that the DSS reacts properly.
This also checks that the subscription data returned by a successful deletion is correct.
An attempt to delete a subscription without providing a version should fail, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.353619Z)
✅ uss1_dss (2026-03-03T21:57:52.357351Z)
✅ uss1_dss (2026-03-03T21:57:52.360939Z)
✅ uss1_dss (2026-03-03T21:57:52.364581Z)
An attempt to delete a subscription while providing an incorrect version should fail, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.356214Z)
✅ uss1_dss (2026-03-03T21:57:52.359866Z)
✅ uss1_dss (2026-03-03T21:57:52.363482Z)
✅ uss1_dss (2026-03-03T21:57:52.367067Z)
If the query to delete an existing subscription fails, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.373689Z)
✅ uss1_dss (2026-03-03T21:57:52.387603Z)
✅ uss1_dss (2026-03-03T21:57:52.400861Z)
✅ uss1_dss (2026-03-03T21:57:52.413965Z)
A successful delete subscription query is expected to return a well-defined body, the content of which reflects the content of the subscription before deletion. If the format and content of the response are not conforming, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.381665Z)
✅ uss1_dss (2026-03-03T21:57:52.395131Z)
✅ uss1_dss (2026-03-03T21:57:52.408275Z)
✅ uss1_dss (2026-03-03T21:57:52.421218Z)
The response to a successful delete subscription query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.381211Z)
✅ uss1_dss (2026-03-03T21:57:52.394660Z)
✅ uss1_dss (2026-03-03T21:57:52.407750Z)
✅ uss1_dss (2026-03-03T21:57:52.420606Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.381274Z)
✅ uss1_dss (2026-03-03T21:57:52.394722Z)
✅ uss1_dss (2026-03-03T21:57:52.407811Z)
✅ uss1_dss (2026-03-03T21:57:52.420680Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.381314Z)
✅ uss1_dss (2026-03-03T21:57:52.394761Z)
✅ uss1_dss (2026-03-03T21:57:52.407886Z)
✅ uss1_dss (2026-03-03T21:57:52.420731Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.381350Z)
✅ uss1_dss (2026-03-03T21:57:52.394796Z)
✅ uss1_dss (2026-03-03T21:57:52.407936Z)
✅ uss1_dss (2026-03-03T21:57:52.420800Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.381381Z)
✅ uss1_dss (2026-03-03T21:57:52.394826Z)
✅ uss1_dss (2026-03-03T21:57:52.407969Z)
✅ uss1_dss (2026-03-03T21:57:52.420845Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.381449Z)
✅ uss1_dss (2026-03-03T21:57:52.394889Z)
✅ uss1_dss (2026-03-03T21:57:52.408055Z)
✅ uss1_dss (2026-03-03T21:57:52.420958Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.381411Z)
✅ uss1_dss (2026-03-03T21:57:52.394856Z)
✅ uss1_dss (2026-03-03T21:57:52.407999Z)
✅ uss1_dss (2026-03-03T21:57:52.420904Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.381482Z)
✅ uss1_dss (2026-03-03T21:57:52.394921Z)
✅ uss1_dss (2026-03-03T21:57:52.408088Z)
✅ uss1_dss (2026-03-03T21:57:52.420994Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.381511Z)
✅ uss1_dss (2026-03-03T21:57:52.394954Z)
✅ uss1_dss (2026-03-03T21:57:52.408117Z)
✅ uss1_dss (2026-03-03T21:57:52.421056Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.381567Z)
✅ uss1_dss (2026-03-03T21:57:52.395028Z)
✅ uss1_dss (2026-03-03T21:57:52.408177Z)
✅ uss1_dss (2026-03-03T21:57:52.421117Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.381596Z)
✅ uss1_dss (2026-03-03T21:57:52.395060Z)
✅ uss1_dss (2026-03-03T21:57:52.408206Z)
✅ uss1_dss (2026-03-03T21:57:52.421145Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
Verify that the subscription returned by the DSS via the deletion is properly formatted and contains the correct content.
✅ uss1_dss (2026-03-03T21:57:52.381624Z)
✅ uss1_dss (2026-03-03T21:57:52.395089Z)
✅ uss1_dss (2026-03-03T21:57:52.408234Z)
✅ uss1_dss (2026-03-03T21:57:52.421177Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its creation or mutation.
The code for these checks lives in the subscription_validator.py class.
If the version of the subscription is updated without there having been any mutation of the subscription, the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.381539Z)
✅ uss1_dss (2026-03-03T21:57:52.394983Z)
✅ uss1_dss (2026-03-03T21:57:52.408144Z)
✅ uss1_dss (2026-03-03T21:57:52.421089Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
Verify that the version field is as expected.
✅ uss1_dss (2026-03-03T21:57:52.381652Z)
✅ uss1_dss (2026-03-03T21:57:52.395118Z)
✅ uss1_dss (2026-03-03T21:57:52.408262Z)
✅ uss1_dss (2026-03-03T21:57:52.421206Z)
Attempt to query and search for the deleted subscription in various ways
If the DSS provides a successful reply to a direct query for the deleted subscription, it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.423260Z)
✅ uss1_dss (2026-03-03T21:57:52.425196Z)
✅ uss1_dss (2026-03-03T21:57:52.427137Z)
✅ uss1_dss (2026-03-03T21:57:52.429073Z)
If the DSS fails to let us search in the area for which the subscription was just created, it is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.431674Z)
If the DSS returns the deleted subscription in a search that covers the area it was originally created for, the DSS is not properly implementing astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.431758Z)
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:52.433739Z)
✅ uss1_dss (2026-03-03T21:57:52.435698Z)
✅ uss1_dss (2026-03-03T21:57:52.437584Z)
✅ uss1_dss (2026-03-03T21:57:52.439550Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created. ∅ This check was not applicable to this test run and is therefore not statused.
Ensures that a DSS properly enforces limitations on created subscriptions
DSSInstanceResource to be tested in this scenario.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
IDGeneratorResource providing the Subscription ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which subscriptions will be created.
✅ Provided by planning_area in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:52.443307Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:52.445342Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
This test attempts to create subscriptions that should be rejected or adapted by the DSS.
This test step attempts to create a subscription that exceeds the maximal subscription duration on the DSS.
It does so directly, by attempting to create a subscription that exceeds the maximal duration of DSSMaxSubscriptionDuration (24 hours),
and indirectly, by first creating a valid subscription and then attempting to mutate it to exceed the maximal duration.
If the DSS under test does not allow the creation of a subscription of the maximal allowed duration of DSSMaxSubscriptionDuration,
it is failing to create a subscription using valid parameters, and is thus failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.455424Z)
If the DSS under test does not reject a subscription that exceeds the maximal allowed duration of DSSMaxSubscriptionDuration,
or fails to truncate the duration of the subscription to this duration, it is in violation of astm.f3548.v21.DSS0015.
✅ uss1_dss (2026-03-03T21:57:52.448313Z)
If the DSS under test does not reject a mutation that would cause a subscription to exceed the maximal allowed duration of DSSMaxSubscriptionDuration,
or fails to truncate the duration of the subscription to this duration, it is in violation of astm.f3548.v21.DSS0015.
✅ uss1_dss (2026-03-03T21:57:52.459351Z)
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:52.463212Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:52.469061Z)
This scenario ensures that a DSS will only let the owner of an operational intent reference modify it.
A resources.flight_planning.FlightIntentsResource containing the flight intents to be used in this scenario:
This scenario expects to find at least two separate flight intents in this resource, as it will use their extent to create two operational intents references.
✅ Provided by non_conflicting_flights in top-level resource pool.
A resources.astm.f3548.v21.DSSInstanceResource pointing to the DSS instance to test for this scenario.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
A resources.communications.AuthAdapterResource containing a second set of valid credentials for interacting with the DSS.
This second set of credentials is required to validate that the DSS is properly enforcing access control rules, and properly limits the actions of a client against the resources exposed by the DSS.
The participant under test is responsible for providing this second set of credentials along the primary ones used in most other scenarios.
In general, these test credentials may be in all points equal to the ones used by the AuthAdapterResource that is
provided to the dss resources above, except for the value contained in the sub claim of the token.
For the purpose of this scenario, these credentials must be allowed to create, modify and delete operational intents on the DSS, as well as querying operational intent references.
For the purpose of this scenario, the second_utm_auth resource must provide access to a token with at least the following scope:
utm.strategic_coordinationNote that the subscription (or 'sub' claim) of the token that will be obtained for this resource
MUST be different from the one of the dss resources mentioned above:
this will be verified at runtime, and this scenario will fail if the second set of credentials belong to the same subscription as the main one.
✅ Provided by second_utm_auth in top-level resource pool.
A resources.interuss.IDGeneratorResource that will be used to generate the IDs of the operational intent references created in this scenario.
✅ Provided by id_generator in top-level resource pool.
Makes sure that the DSS is in a clean and expected state before running the test, and that the passed resources work as required.
The setup will create two separate operational intent references: one for each set of the available credentials.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:52.477535Z)
✅ uss1_dss (2026-03-03T21:57:52.482787Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:52.485975Z)
✅ uss1_dss (2026-03-03T21:57:52.489120Z)
✅ uss1_dss (2026-03-03T21:57:52.492285Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
If, after cleanup, one or more operational intent reference are still present at the DSS, this scenario cannot proceed.
This scenario is able to remove any operational intent reference that belongs to the configured credentials, but it cannot remove references that belong to other credentials.
A regular failure of this check indicates that other scenarios might not properly clean up their resources, or that the Prepare Flight Planners scenario should be moved in front of the present one.
If this check fails, the rest of the scenario is entirely skipped.
✅ uss1_dss (2026-03-03T21:57:52.492327Z)
This test step ensures that an operation intent reference created with the main credentials is available for the main test case.
To verify that the second credentials are valid, it will also create an operational intent reference with those credentials.
If the DSS does not allow the creation of operation intents when the required parameters and credentials are provided, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:52.508628Z)
✅ uss1_dss (2026-03-03T21:57:52.522958Z)
This scenario requires two sets of credentials that have a different 'sub' claim in order to validate that the DSS properly controls access to operational intents.
✅ uss1_dss (2026-03-03T21:57:52.523091Z)
This test case ensures that the DSS does not allow a caller to modify or delete operational intent references that they did not create.
This test step will attempt to modify the operational intent references that was created using the configured dss resource,
using the credentials provided in the second_utm_auth resource, and expect all such attempts to fail.
If an existing operational intent cannot directly be queried by its ID, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:52.539761Z)
If an operational intent reference can be modified by a client which did not create it, the DSS implementation is in violation of astm.f3548.v21.OPIN0035.
✅ uss1_dss, mock_uss (2026-03-03T21:57:52.529792Z)
✅ uss1_dss, mock_uss (2026-03-03T21:57:52.534363Z)
✅ uss1_dss, mock_uss (2026-03-03T21:57:52.539805Z)
If an operational intent reference can be deleted by a client which did not create it, the DSS implementation is in violation of astm.f3548.v21.OPIN0035.
✅ uss1_dss, mock_uss (2026-03-03T21:57:52.536837Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:52.542802Z)
✅ uss1_dss (2026-03-03T21:57:52.555904Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:52.553053Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:52.566368Z)
TODO: Complete with details once we check more than the prerequisites.
This scenario currently only checks that all specified DSS instances are publicly addressable and reachable.
A resources.astm.f3548.v21.DSSInstanceResource containing the "primary" DSS instance for this scenario.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
A resources.astm.f3548.v21.DSSInstancesResource containing at least two DSS instances complying with ASTM F3548-21.
✅ Provided by dss_instances in top-level resource pool.
A resources.PlanningAreaResource containing a planning area that covers the area of interest for this
✅ Provided by planning_area in top-level resource pool.
A resources.dev.TestExclusionsResource containing test exclusions parameters like whether private addresses are allowed. This resource is optional.
∅ This resource was not applicable to this test run and was therefore not provided.
As per astm.f3548.v21.DSS0300 the DSS instance should be publicly addressable.
As such, this check will fail if the resolved IP of the DSS host is a private IP address.
This check is skipped if the test exclusion allow_private_addresses is set to True.
❌ uss1_dss (2026-03-03T21:57:52.567286Z)
❌ uss2_dss (2026-03-03T21:57:52.573184Z)
As per astm.f3548.v21.DSS0300 the DSS instance should be publicly addressable. As such, this check will fail if the DSS is not reachable with a dummy query.
✅ uss1_dss (2026-03-03T21:57:52.572849Z)
✅ uss2_dss (2026-03-03T21:57:52.578109Z)
Verifies that all subscription CRUD operations performed on a single DSS instance are properly propagated to every other DSS
DSSInstanceResource the DSS instance through which entities are created, modified and deleted.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
DSSInstancesResource pointing to the DSS instances used to confirm that entities are properly propagated.
✅ Provided by dss_instances in top-level resource pool.
IDGeneratorResource providing the Subscription ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which subscriptions will be created.
✅ Provided by planning_area in top-level resource pool.
A resources.communications.AuthAdapterResource containing a second set of valid credentials for interacting with the DSS.
This second set of credentials is required to validate that the DSS properly synchronizes the manager of a subscription to other DSS instances.
The test designer should provide this second set of credentials when full testing of manager synchronization behavior is desired.
In general, these test credentials may be in all points equal to the ones used by the AuthAdapterResource that is
provided to the dss resources above, except for the value contained in the sub claim of the token.
Note that most checks in this scenario will work if the second set of credentials is not provided.
For the purpose of this scenario, the second_utm_auth resource must provide access to a token with at least the following scope:
utm.strategic_coordinationNote that the subject (or 'sub' claim) of the token that will be obtained for this resource
MUST be different from the one of the dss resources mentioned above:
this will be verified at runtime, and the depending checks will not be run if this is not the case.
✅ Provided by second_utm_auth in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss1_dss (2026-03-03T21:57:52.581990Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:52.584059Z)
✅ uss1_dss (2026-03-03T21:57:52.586058Z)
✅ uss1_dss (2026-03-03T21:57:52.587975Z)
✅ uss1_dss (2026-03-03T21:57:52.590485Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
This includes the main test subscription used in this test, as well as the extra subscription
used for testing the manager field sync, if the test is configured to test for it.
∅ This check was not applicable to this test run and is therefore not statused.
This test step queries all secondary instances to confirm that none of the test IDs that are used in the scenario exist.
Ensures that a secondary DSS is ready to be used for testing by confirming that no Subscription bearing an ID used for testing exists on it.
If an existing subscription cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:52.592904Z)
✅ uss1_dss (2026-03-03T21:57:52.594865Z)
✅ uss1_dss (2026-03-03T21:57:52.596808Z)
✅ uss2_dss (2026-03-03T21:57:52.599308Z)
✅ uss2_dss (2026-03-03T21:57:52.601280Z)
✅ uss2_dss (2026-03-03T21:57:52.603248Z)
If a Subscription that was deleted from the primary DSS can still be found on a secondary DSS, either one of them may be improperly pooled and in violation of astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.592938Z)
✅ uss1_dss (2026-03-03T21:57:52.594897Z)
✅ uss1_dss (2026-03-03T21:57:52.596841Z)
✅ uss2_dss (2026-03-03T21:57:52.599341Z)
✅ uss2_dss (2026-03-03T21:57:52.601312Z)
✅ uss2_dss (2026-03-03T21:57:52.603280Z)
This test case create a subscription on the main DSS, and verifies that it is properly synchronized to the other DSS instances.
It then goes on to mutate and delete it, each time confirming that all other DSSes return the expected results.
This test step creates multiple subscriptions with different combinations of the optional end and start time parameters.
All subscriptions are left on the DSS when this step ends, as they are expected to be present for the subsequent step.
This test step fragment validates that subscriptions can be created.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:52.611326Z)
✅ uss1_dss (2026-03-03T21:57:52.629558Z)
✅ uss1_dss (2026-03-03T21:57:52.646191Z)
The response to a successful subscription creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.619322Z)
✅ uss1_dss (2026-03-03T21:57:52.636765Z)
✅ uss1_dss (2026-03-03T21:57:52.653514Z)
A successful subscription creation query is expected to return a well-defined body, the content of which reflects the created subscription.
If the content of the response does not correspond to the requested content, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.620834Z)
✅ uss1_dss (2026-03-03T21:57:52.638145Z)
✅ uss1_dss (2026-03-03T21:57:52.654917Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.620030Z)
✅ uss1_dss (2026-03-03T21:57:52.637296Z)
✅ uss1_dss (2026-03-03T21:57:52.654087Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.620079Z)
✅ uss1_dss (2026-03-03T21:57:52.637337Z)
✅ uss1_dss (2026-03-03T21:57:52.654130Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.620116Z)
✅ uss1_dss (2026-03-03T21:57:52.637371Z)
✅ uss1_dss (2026-03-03T21:57:52.654166Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.620148Z)
✅ uss1_dss (2026-03-03T21:57:52.637401Z)
✅ uss1_dss (2026-03-03T21:57:52.654213Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.620211Z)
✅ uss1_dss (2026-03-03T21:57:52.637461Z)
✅ uss1_dss (2026-03-03T21:57:52.654296Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.620178Z)
✅ uss1_dss (2026-03-03T21:57:52.637429Z)
✅ uss1_dss (2026-03-03T21:57:52.654260Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.620241Z)
✅ uss1_dss (2026-03-03T21:57:52.637492Z)
✅ uss1_dss (2026-03-03T21:57:52.654327Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.620268Z)
✅ uss1_dss (2026-03-03T21:57:52.637519Z)
✅ uss1_dss (2026-03-03T21:57:52.654354Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.620295Z)
✅ uss1_dss (2026-03-03T21:57:52.637546Z)
✅ uss1_dss (2026-03-03T21:57:52.654381Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.620330Z)
✅ uss1_dss (2026-03-03T21:57:52.637574Z)
✅ uss1_dss (2026-03-03T21:57:52.654408Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.620357Z)
✅ uss1_dss (2026-03-03T21:57:52.637608Z)
✅ uss1_dss (2026-03-03T21:57:52.654435Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after the creation of a subscription.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
The notification index of a newly created subscription must be 0, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.620812Z)
✅ uss1_dss (2026-03-03T21:57:52.638115Z)
✅ uss1_dss (2026-03-03T21:57:52.654895Z)
Query the created subscription at every DSS provided in dss_instances to confirm that it is properly synchronized across all DSS instances,
and that it can be accessed directly by ID or searched for by area.
This test step fragment validates that subscriptions are properly synchronized across a set of DSS instances.
If the previously created or mutated subscription cannot be found at a DSS, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.659162Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.681048Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct USS base URL, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.659663Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.681557Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct start time, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.659714Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.681611Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct end time, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.659757Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.681654Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct version, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.659794Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.681691Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct notification flags, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1g, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.659831Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.681731Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct implicit flag, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1h, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.659881Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.681766Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the expected notification count, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1i, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.659936Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.681799Z)
The secondary DSS should be aware of the subscription's area: when a search query is issued for an area that encompasses the created subscription, the secondary DSS should return the subscription in its search results.
Otherwise, it is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.674523Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.701616Z)
The secondary DSS should be aware of the subscription's area: when a search query is issued for an area not in the vicinity of the created subscription, the secondary DSS should not return it in its search results.
Otherwise, it is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.677641Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.704702Z)
This test step fragment validates that a known subscriptions can be read, and that its content is correct.
This test step fragment validates that a query to read a subscription succeeds.
If a subscription cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.659108Z)
✅ uss2_dss (2026-03-03T21:57:52.680962Z)
The response to a successful get subscription query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.667297Z)
✅ uss2_dss (2026-03-03T21:57:52.694402Z)
A successful query for a subscription is expected to return a body, the content of which reflects the created subscription. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:52.661321Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.683137Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.660812Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.682670Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.660856Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.682716Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.660894Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.682755Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.660928Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.682791Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.661058Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.682861Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.660980Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.682824Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.661101Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.682907Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.661136Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.682938Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.661210Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.683017Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.661243Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.683056Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.661275Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.683089Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its creation or mutation.
The code for these checks lives in the subscription_validator.py class.
If the version of the subscription is updated without there having been any mutation of the subscription, the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.661174Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.682970Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.661308Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.683123Z)
This test step fragment validates that a query to search for subscriptions succeeds.
If the DSS fails to let us search in the area for which the subscription was created, it is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.672150Z)
✅ uss1_dss (2026-03-03T21:57:52.677582Z)
✅ uss2_dss (2026-03-03T21:57:52.699218Z)
✅ uss2_dss (2026-03-03T21:57:52.704642Z)
This test step mutates the previously created subscription, by accessing the primary DSS, to verify that the update is propagated to all other DSSes. Notably, it checks that the subscription version is updated, including for changes that are not directly visible, such as changing the subscription's footprint.
This test step fragment validates that subscriptions can be updated.
This test step fragment validates that a query to update a subscription succeeds.
If a subscription cannot be updated with a valid set of parameters, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.712947Z)
This test step fragment validates that subscriptions can be updated but does not contain a check related to the query itself.
This fragment is intended to be used in scenarios that define their own query verification check, usually when more specific requirements are being tested.
The response to a successful subscription mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.720471Z)
A successful subscription mutation query is expected to return a well-defined body, the content of which reflects the mutated subscription.
If the content of the response does correspond to the requested mutation, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.721437Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.721050Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.721095Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.721131Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.721163Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.721226Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.721192Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.721257Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.721284Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.721339Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.721367Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.721394Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its mutation.
The code for these checks lives in the subscription_validator.py class.
Following a mutation, the DSS needs to update the subscription version, otherwise it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.721312Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.721423Z)
Query the updated subscription at every DSS provided in dss_instances to confirm that the mutation is properly synchronized across all DSS instances,
This test step fragment validates that subscriptions are properly synchronized across a set of DSS instances.
If the previously created or mutated subscription cannot be found at a DSS, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.725416Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.747952Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct USS base URL, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.725948Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.748489Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct start time, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.726028Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.748540Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct end time, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.726082Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.748584Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct version, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.726123Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.748621Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct notification flags, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1g, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.726162Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.748659Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct implicit flag, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1h, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.726199Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.748694Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the expected notification count, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1i, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.726235Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.748728Z)
The secondary DSS should be aware of the subscription's area: when a search query is issued for an area that encompasses the created subscription, the secondary DSS should return the subscription in its search results.
Otherwise, it is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.741580Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.763402Z)
The secondary DSS should be aware of the subscription's area: when a search query is issued for an area not in the vicinity of the created subscription, the secondary DSS should not return it in its search results.
Otherwise, it is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.744631Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.766369Z)
This test step fragment validates that a known subscriptions can be read, and that its content is correct.
This test step fragment validates that a query to read a subscription succeeds.
If a subscription cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.725362Z)
✅ uss2_dss (2026-03-03T21:57:52.747901Z)
The response to a successful get subscription query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.734425Z)
✅ uss2_dss (2026-03-03T21:57:52.756203Z)
A successful query for a subscription is expected to return a body, the content of which reflects the created subscription. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:52.728099Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.750070Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.727444Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.749608Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.727505Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.749653Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.727555Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.749691Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.727612Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.749725Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.727714Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.749795Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.727655Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.749759Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.727756Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.749831Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.727810Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.749863Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.727899Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.749928Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.727937Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.749960Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.727992Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.749993Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its creation or mutation.
The code for these checks lives in the subscription_validator.py class.
If the version of the subscription is updated without there having been any mutation of the subscription, the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.727846Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.749896Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.728077Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.750052Z)
This test step fragment validates that a query to search for subscriptions succeeds.
If the DSS fails to let us search in the area for which the subscription was created, it is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.739145Z)
✅ uss1_dss (2026-03-03T21:57:52.744570Z)
✅ uss2_dss (2026-03-03T21:57:52.760929Z)
✅ uss2_dss (2026-03-03T21:57:52.766308Z)
This test step attempts to mutate the subscription on every secondary DSS instance (that is, instances through which the subscription has not been created) to confirm that such mutations are properly propagated to every DSS.
Note that this step is repeated for every secondary DSS instance.
If the secondary DSS does not allow the subscription to be mutated, either the secondary DSS or the primary DSS are in violation of one or both of the following requirements:
astm.f3548.v21.DSS0210,1b, if the manager of the subscription fails to be taken into account (either because the primary DSS did not propagated it, or because the secondary failed to consider it);
astm.f3548.v21.DSS0005,5, if the secondary DSS fails to properly implement the API to mutate subscriptions.
✅ uss1_dss (2026-03-03T21:57:52.788318Z)
This test step fragment validates that subscriptions can be updated but does not contain a check related to the query itself.
This fragment is intended to be used in scenarios that define their own query verification check, usually when more specific requirements are being tested.
The response to a successful subscription mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.796288Z)
A successful subscription mutation query is expected to return a well-defined body, the content of which reflects the mutated subscription.
If the content of the response does correspond to the requested mutation, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.797220Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.796806Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.796849Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.796886Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.796918Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.796982Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.796948Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.797032Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.797065Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.797122Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.797150Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.797178Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its mutation.
The code for these checks lives in the subscription_validator.py class.
Following a mutation, the DSS needs to update the subscription version, otherwise it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.797094Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.797207Z)
This step verifies that the mutation of the subscription on a secondary instance, from the previous step, is properly propagated to every other DSS.
Note that this step is repeated for every secondary DSS instance.
This test step fragment validates that subscriptions are properly synchronized across a set of DSS instances.
If the previously created or mutated subscription cannot be found at a DSS, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.801116Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.823091Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct USS base URL, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.801645Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.823608Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct start time, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.801696Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.823659Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct end time, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.801740Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.823700Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct version, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.801778Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.823737Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct notification flags, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1g, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.801815Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.823775Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct implicit flag, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1h, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.801849Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.823810Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the expected notification count, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1i, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.801883Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.823844Z)
The secondary DSS should be aware of the subscription's area: when a search query is issued for an area that encompasses the created subscription, the secondary DSS should return the subscription in its search results.
Otherwise, it is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.816632Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.839028Z)
The secondary DSS should be aware of the subscription's area: when a search query is issued for an area not in the vicinity of the created subscription, the secondary DSS should not return it in its search results.
Otherwise, it is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:52.819652Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.842026Z)
This test step fragment validates that a known subscriptions can be read, and that its content is correct.
This test step fragment validates that a query to read a subscription succeeds.
If a subscription cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.801062Z)
✅ uss2_dss (2026-03-03T21:57:52.823001Z)
The response to a successful get subscription query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.809358Z)
✅ uss2_dss (2026-03-03T21:57:52.831942Z)
A successful query for a subscription is expected to return a body, the content of which reflects the created subscription. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss1_dss (2026-03-03T21:57:52.803321Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.825191Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.802842Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.824730Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.802890Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.824776Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.802928Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.824814Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.802963Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.824849Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.803062Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.824920Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.802998Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.824882Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.803102Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.824956Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.803136Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.824989Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.803202Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.825077Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.803235Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.825111Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.803266Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.825143Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its creation or mutation.
The code for these checks lives in the subscription_validator.py class.
If the version of the subscription is updated without there having been any mutation of the subscription, the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.803170Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.825041Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.803307Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.825178Z)
This test step fragment validates that a query to search for subscriptions succeeds.
If the DSS fails to let us search in the area for which the subscription was created, it is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.814159Z)
✅ uss1_dss (2026-03-03T21:57:52.819592Z)
✅ uss2_dss (2026-03-03T21:57:52.836491Z)
✅ uss2_dss (2026-03-03T21:57:52.841946Z)
If the second set of credentials is provided, this test step will create a subscription using these credentials, in order to prepare the next step that checks manager synchronization.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss1_dss (2026-03-03T21:57:52.774310Z)
If the second set of credentials is provided, checks that the manager of a subscription is properly synchronized across all DSS instances.
This is done by verifying that the main credentials are not able to delete the subscription via any of the secondary DSS instances.
If the subscription can be deleted by a client which did not create it, via a DSS instance to which the subscription was synced following its creation on the primary DSS, either one of the primary DSS or the DSS that accepted the deletion failed to properly broadcast, respectively take into account, the manage of the subscription, and therefore violates astm.f3548.v21.DSS0210,1b.
✅ uss1_dss (2026-03-03T21:57:52.777500Z)
✅ uss2_dss (2026-03-03T21:57:52.780252Z)
Attempt to delete the subscription that was created on the primary DSS through the primary DSS in various ways, and ensure that the DSS reacts properly.
This also checks that the subscription data returned by a successful deletion is correct.
This test step fragment validates that subscriptions can be deleted.
This test step fragment validates that a query to remove a subscription succeeds.
An attempt to delete a subscription when the correct version is provided should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.909685Z)
The response to a successful subscription deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.917344Z)
A successful subscription deletion query is expected to return a well-defined body, the content of which reflects the deleted subscription.
If the content of the response does not correspond to the subscription at the time of deletion, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.917780Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.917403Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.917442Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.917476Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.917506Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.917568Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.917535Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.917599Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.917627Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.917681Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.917708Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.917735Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its creation or mutation.
The code for these checks lives in the subscription_validator.py class.
If the version of the subscription is updated without there having been any mutation of the subscription, the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.917654Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.917763Z)
Attempt to query and search for the deleted subscription in various ways
If a DSS returns a subscription that was previously successfully deleted from the primary DSS, either one of the primary DSS or the DSS that returned the subscription is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS through which the subscription was deleted is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:52.919984Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.922143Z)
Attempt to delete subscriptions that were created through the primary DSS via the secondary DSS instances.
This test step fragment validates that subscriptions can be deleted.
This test step fragment validates that a query to remove a subscription succeeds.
An attempt to delete a subscription when the correct version is provided should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.928381Z)
✅ uss2_dss (2026-03-03T21:57:52.948299Z)
The response to a successful subscription deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.935604Z)
✅ uss2_dss (2026-03-03T21:57:52.955709Z)
A successful subscription deletion query is expected to return a well-defined body, the content of which reflects the deleted subscription.
If the content of the response does not correspond to the subscription at the time of deletion, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.936088Z)
✅ uss2_dss (2026-03-03T21:57:52.956178Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.935664Z)
✅ uss2_dss (2026-03-03T21:57:52.955770Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.935703Z)
✅ uss2_dss (2026-03-03T21:57:52.955809Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.935738Z)
✅ uss2_dss (2026-03-03T21:57:52.955844Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.935769Z)
✅ uss2_dss (2026-03-03T21:57:52.955875Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.935831Z)
✅ uss2_dss (2026-03-03T21:57:52.955937Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.935798Z)
✅ uss2_dss (2026-03-03T21:57:52.955904Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.935862Z)
✅ uss2_dss (2026-03-03T21:57:52.955969Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:57:52.935895Z)
✅ uss2_dss (2026-03-03T21:57:52.955998Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.935952Z)
✅ uss2_dss (2026-03-03T21:57:52.956075Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.935980Z)
✅ uss2_dss (2026-03-03T21:57:52.956109Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.936042Z)
✅ uss2_dss (2026-03-03T21:57:52.956138Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its creation or mutation.
The code for these checks lives in the subscription_validator.py class.
If the version of the subscription is updated without there having been any mutation of the subscription, the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.935925Z)
✅ uss2_dss (2026-03-03T21:57:52.956046Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:52.936074Z)
✅ uss2_dss (2026-03-03T21:57:52.956166Z)
If a DSS returns a subscription that was previously successfully deleted from the primary DSS, either one of the primary DSS or the DSS that returned the subscription is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS through which the subscription was deleted is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss, uss1_dss (2026-03-03T21:57:52.938215Z)
✅ uss1_dss, uss1_dss (2026-03-03T21:57:52.940291Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:52.942211Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:52.958287Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:52.960333Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:52.962386Z)
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:52.964505Z)
✅ uss1_dss (2026-03-03T21:57:52.966570Z)
✅ uss1_dss (2026-03-03T21:57:52.968564Z)
✅ uss1_dss (2026-03-03T21:57:52.972228Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
This includes the main test subscription used in this test, as well as the extra subscription
used for testing the manager field sync, if the test is configured to test for it.
✅ uss1_dss (2026-03-03T21:57:52.978344Z)
This instance of this test scenario was skipped in this test run because: Test suite action to run ActionType.TestScenario scenarios.astm.utm.dss.DatastoreAccess could not find required resource ID "dss_datastore_cluster" used to populate child resource ID "datastore_cluster"
This test validates that a DSS correctly implements the OVN Request Optional Extension to ASTM F3548-21.
DSSInstanceResource to be tested in this scenario.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
IDGeneratorResource providing the base entity ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
ClientIdentityResource the client identity that will be used to create and update operational intent references.
✅ Provided by utm_client_identity in top-level resource pool.
PlanningAreaResource describes the 3D volume in which operational intent references will be created.
✅ Provided by planning_area in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:52.986714Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss1_dss (2026-03-03T21:57:52.984457Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
This case validates the nominal behavior of the OVN request.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid. Check that the OIR creation query succeeds.
✅ uss1_dss (2026-03-03T21:57:53.004141Z)
This test step fragment validates that the DSS has set the expected OVN correctly after an USS requested a suffix.
If the DSS has not set the OVN according to the specifications, it will fail this check as per interuss.f3548.ovn_request.ImplementAPI. Check that the DSS has set the expected OVN correctly.
✅ uss1_dss (2026-03-03T21:57:53.004193Z)
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference. Check that the OIR update query succeeds.
✅ uss1_dss (2026-03-03T21:57:53.026532Z)
This test step fragment validates that the DSS has set the expected OVN correctly after an USS requested a suffix.
If the DSS has not set the OVN according to the specifications, it will fail this check as per interuss.f3548.ovn_request.ImplementAPI. Check that the DSS has set the expected OVN correctly.
✅ uss1_dss (2026-03-03T21:57:53.026586Z)
This case validates the off-nominal behaviors of the OVN request.
This test step fragment validates that the DSS rejects invalid attempts to request an OVN suffix.
If the DSS accepts the OVN suffix, or fails with an error other than an HTTP code 400, this check will fail as per interuss.f3548.ovn_request.ImplementAPI. Check that the DSS rejects OVN suffix that are not UUIDs. If the DSS accepts the OVN suffix, or fails with an unexpected error, this check will fail.
✅ uss1_dss (2026-03-03T21:57:53.028218Z)
This test step fragment validates that the DSS rejects invalid attempts to request an OVN suffix.
If the DSS accepts the OVN suffix, or fails with an error other than an HTTP code 400, this check will fail as per interuss.f3548.ovn_request.ImplementAPI. Check that the DSS rejects OVN suffix that are empty. If the DSS accepts the OVN suffix, or fails with an unexpected error, this check will fail.
✅ uss1_dss (2026-03-03T21:57:53.029676Z)
This test step fragment validates that the DSS rejects invalid attempts to request an OVN suffix.
If the DSS accepts the OVN suffix, or fails with an error other than an HTTP code 400, this check will fail as per interuss.f3548.ovn_request.ImplementAPI. Check that the DSS rejects OVN suffix that are UUIDs but not v7. If the DSS accepts the OVN suffix, or fails with an unexpected error, this check will fail.
✅ uss1_dss (2026-03-03T21:57:53.031073Z)
This test step fragment validates that the DSS rejects invalid attempts to request an OVN suffix.
If the DSS accepts the OVN suffix, or fails with an error other than an HTTP code 400, this check will fail as per interuss.f3548.ovn_request.ImplementAPI. Check that the DSS rejects OVN suffix that are outdated UUIDv7. If the DSS accepts the OVN suffix, or fails with an unexpected error, this check will fail.
✅ uss1_dss (2026-03-03T21:57:53.032826Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:53.036189Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
∅ This check was not applicable to this test run and is therefore not statused.
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:53.051085Z)
This scenario tests the ability of the DSS to receive DSS reports.
DSSInstanceResource to be tested in this scenario.
✅ Provided by instance 1 in dss_instances in top-level resource pool.
This test attempts to submit to the DSS a report about a communication issue with a DSS that might otherwise go unnoticed.
A dummy getOperationalIntentReference query is made to a non-existent DSS in order to produce a realistic report, as if a DSS was not reachable when trying to retrieve an operational intent reference.
This step makes a report to the DSS.
See make_dss_report in test_steps_fragments.py.
If the submission of the report to the DSS does not succeed, this check will fail per astm.f3548.v21.DSS0100,2.
✅ uss1_dss (2026-03-03T21:57:53.232440Z)
If the ID returned by the DSS is not present or is empty, this check will fail per astm.f3548.v21.DSS0100,2.
✅ uss1_dss (2026-03-03T21:57:53.232514Z)
Verifies the behavior of a DSS for interactions pertaining to operational intent references being attached to explicit subscriptions.
DSSInstanceResource the DSS instance through which entities are created, modified and deleted.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
IDGeneratorResource providing the base entity ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
ClientIdentityResource the client identity that will be used to create and update operational intent references.
✅ Provided by utm_client_identity in top-level resource pool.
PlanningAreaResource describes the 3D volume in which operational intent references will be created.
✅ Provided by planning_area in top-level resource pool.
This test case ensures that no entities with the known test IDs exists in the DSS.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.243233Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:57:53.240707Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss2_dss (2026-03-03T21:57:53.246598Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:57:53.248997Z)
✅ uss2_dss (2026-03-03T21:57:53.251254Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
Ensures that the explicit subscription provided upon creation of an OIR is properly validated and attached to the OIR.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:53.262266Z)
This step verifies that an OIR cannot be created when an explicit subscription that does not cover the extent of the OIR is specified.
If the DSS under test allows the qualifier to create an OIR with an explicit subscription that does not cover the extent of the OIR, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:53.274120Z)
When the provided subscription covers the extent of the OIR, the OIR can be created, and is then properly attached to the specified subscription.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:53.290390Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.298478Z)
If the OIR returned by the DSS under test is not attached to the expected subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:53.298526Z)
Ensures that when the explicit subscription tied to an OIR is replaced with another explicit subscription, this subscription is properly validated and attached to the OIR.
Create an additional explicit subscription to be used in this test case.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:53.307784Z)
This step verifies that an OIR's existing explicit subscription cannot be replaced with an explicit subscription that does not cover the extent of the OIR.
If the DSS under test allows the qualifier to replace an OIR's existing explicit subscription with an explicit subscription that does not cover the extent of the OIR, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:53.319277Z)
∅ This test step was not applicable to this test run and is therefore not statused.
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
If the OIR returned by the DSS under test is not attached to the expected subscription, it is in violation of astm.f3548.v21.DSS0005,1
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss2_dss (2026-03-03T21:57:53.340182Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.322253Z)
If the OIR returned by the DSS under test is not attached to the expected subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:53.322297Z)
The test case that follows requires the creation of a fresh OIR and subscription. Therefore, this test case will clean up after itself.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.360561Z)
This test step fragment validates that a query to remove a subscription succeeds.
An attempt to delete a subscription when the correct version is provided should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:57:53.371466Z)
Checks that a DSS allows an OIR to be created in the accepted state without any subscription.
This step verifies that an OIR can be created in the ACCEPTED state without providing any subscription information (implicit or explicit) in the request.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:53.391048Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.398943Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:53.401099Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss2_dss (2026-03-03T21:57:53.401057Z)
Ensures that an explicit subscription can be attached to an OIR without subscription attached, and that the subscription is required to properly cover the OIR.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:53.411882Z)
This step verifies that the DSS refuses the request to attach an insufficient subscription to an OIR that currently has no subscription.
If the DSS under test allows the qualifier to attach an insufficient explicit subscription to a subscription-free OIR, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:53.423678Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.427358Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:53.429508Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss2_dss (2026-03-03T21:57:53.429468Z)
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss2_dss (2026-03-03T21:57:53.450381Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.459248Z)
If the OIR returned by the DSS under test is not attached to the expected subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:53.459300Z)
Checks that an OIR in the ACCEPTED state that is attached to an explicit subscription can be mutated in order to not be attached to any subscription.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss2_dss (2026-03-03T21:57:53.482446Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.492794Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:53.496492Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss2_dss (2026-03-03T21:57:53.496433Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.534491Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:57:53.526046Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.525984Z)
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss2_dss (2026-03-03T21:57:53.541455Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:57:53.549611Z)
✅ uss2_dss (2026-03-03T21:57:53.563154Z)
✅ uss2_dss (2026-03-03T21:57:53.573491Z)
✅ uss2_dss (2026-03-03T21:57:53.575779Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
✅ uss2_dss (2026-03-03T21:57:53.558593Z)
✅ uss2_dss (2026-03-03T21:57:53.570991Z)
Checks that implicit subscriptions are properly created, mutated and cleaned up.
DSSInstanceResource to be tested in this scenario.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
IDGeneratorResource providing the Subscription IDs for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which subscriptions will be created.
✅ Provided by planning_area in top-level resource pool.
ClientIdentityResource provides the identity that will be used to interact with the DSS.
✅ Provided by utm_client_identity in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.584640Z)
✅ uss2_dss (2026-03-03T21:57:53.587049Z)
✅ uss2_dss (2026-03-03T21:57:53.589685Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:57:53.582288Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss2_dss (2026-03-03T21:57:53.592714Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:57:53.594795Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
This step creates an OIR with an implicit subscription and confirms that the subscription can be queried
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:53.612798Z)
This test step fragment validates that implicit subscriptions are created and can be queried, and that they have the correct temporal parameters.
The creation of an operational intent which:
is expected to trigger the creation of a new implicit subscription.
If the DSS does not create the implicit subscription, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.622235Z)
This test step fragment validates the time-bounds of an implicit subscription
If the implicit subscription time boundaries do not cover the OIR's, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.623112Z)
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.645515Z)
Upon deletion of an OIR that is associated to an implicit subscription, if the subscription has no other associated OIRs, the DSS is expected to remove it.
If a query attempting to fetch the implicit subscription succeeds, it implies that the implicit subscription has not been removed, and the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.653306Z)
If, after the DSS is left in the same state as it was 'found' for an area, the subscriptions currently active do not correspond to the ones that were present when the test case started, the DSS may be failing to properly implement astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:57:53.653385Z)
This test case verifies that implicit subscriptions belonging to OIRs that are created, updated and deleted are properly managed.
In particular, the scenario verifies that:
Create an OIR with which interactions will be tested and request an implicit subscription to be created.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:53.680414Z)
This test step fragment validates that implicit subscriptions are created and can be queried, and that they have the correct temporal parameters.
The creation of an operational intent which:
is expected to trigger the creation of a new implicit subscription.
If the DSS does not create the implicit subscription, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.692214Z)
This test step fragment validates the time-bounds of an implicit subscription
If the implicit subscription time boundaries do not cover the OIR's, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.693123Z)
This step creates an OIR in the ACCEPTED state that overlaps with the previously created OIR:
it does not request the creation of an implicit subscription and does not attach the OIR to any subscription explicitly.
This step expects that the implicit subscription from the previously created OIR is mentioned in the response's notifications, and that no new implicit subscription is created.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:53.709453Z)
If the newly created OIR does not mention the implicit subscription from the previous OIR in its notifications, the DSS is either improperly managing implicit subscriptions, or failing to report the subscriptions relevant to an OIR, and therefore in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,5 respectively.
✅ uss2_dss (2026-03-03T21:57:53.711715Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.716594Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:53.711651Z)
✅ uss2_dss (2026-03-03T21:57:53.718746Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss2_dss (2026-03-03T21:57:53.718704Z)
This step mutates the first OIR, which has an implicit subscription, to no longer overlap with the second OIR.
The mutation request does not specify an existing subscription, and provides the parameters required for the creation of an implicit subscription.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss2_dss (2026-03-03T21:57:53.742381Z)
The implicit subscription attached to the mutated OIR should be able to be queried.
If it cannot, the DSS is either improperly managing implicit subscriptions for OIRs, or failing to report the subscriptions relevant to an OIR, in which case the DSS is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,5, respectively.
✅ uss2_dss (2026-03-03T21:57:53.752243Z)
This test step fragment validates the time-bounds of an implicit subscription
If the implicit subscription time boundaries do not cover the OIR's, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.753132Z)
If the DSS chose to create a new implicit subscription instead of updating the existing one, and the DSS did not remove the previous subscription, the DSS is in violation of either astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:57:53.755869Z)
This step creates a new OIR that only overlaps the OIR that has no implicit subscription, and expects to not have to notify any subscription related to the OIRs created in this scenario.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:53.774926Z)
Within a geotemporal area that does not intersect with any of the implicit subscriptions that are left within the DSS, the subscriptions returned for an OIR created within said area should correspond to the ones that were present when the test case started.
Otherwise, the DSS may be failing to properly implement astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:57:53.778138Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.783315Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:53.778055Z)
✅ uss2_dss (2026-03-03T21:57:53.786079Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss2_dss (2026-03-03T21:57:53.785995Z)
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.799238Z)
✅ uss2_dss (2026-03-03T21:57:53.818698Z)
✅ uss2_dss (2026-03-03T21:57:53.833389Z)
This test case verifies that implicit subscriptions are properly removed if they become unnecessary following the mutation of an OIR.
Creates two OIRs with an implicit subscription, which will then be replaced by an explicitly created subscription and deleted by an update that requests no subscription, respectively.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:53.851204Z)
✅ uss2_dss (2026-03-03T21:57:53.880206Z)
This test step fragment validates that implicit subscriptions are created and can be queried, and that they have the correct temporal parameters.
The creation of an operational intent which:
is expected to trigger the creation of a new implicit subscription.
If the DSS does not create the implicit subscription, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.860561Z)
✅ uss2_dss (2026-03-03T21:57:53.889320Z)
This test step fragment validates the time-bounds of an implicit subscription
If the implicit subscription time boundaries do not cover the OIR's, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.861453Z)
✅ uss2_dss (2026-03-03T21:57:53.890230Z)
This test step creates a subscription that will be used to replace the implicit subscription that was created for an OIR.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
Check creation succeeds and response is correct.
✅ uss2_dss (2026-03-03T21:57:53.900212Z)
This step updates the OIR to use the subscription that was created in the previous step, and expects the previous implicit subscription to be removed.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss2_dss (2026-03-03T21:57:53.924485Z)
If the implicit subscription that was attached to the OIR is still present after the OIR is updated to use another subscription, the DSS is failing to properly manage implicit subscriptions for OIRs, and is therefore in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.931779Z)
This step updates the OIR to not use any subscription, and expects the implicit subscription to be removed.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss2_dss (2026-03-03T21:57:53.952674Z)
If the implicit subscription that was attached to the OIR is still present after the OIR is updated to use another subscription, the DSS is failing to properly manage implicit subscriptions for OIRs, and is therefore in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.959442Z)
This fragment can be used by test cases that need to clean up after themselves by deleting the OIRs and subscriptions created during the test.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:53.975215Z)
✅ uss2_dss (2026-03-03T21:57:53.991122Z)
This test step fragment validates that a query to remove a subscription succeeds.
An attempt to delete a subscription when the correct version is provided should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:57:53.999803Z)
This test case checks that a DSS will properly expand an implicit subscription to cover an OIR that is being attached to it.
Create an OIR with which interactions will be tested and request an implicit subscription to be created.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:54.022744Z)
This test step fragment validates that implicit subscriptions are created and can be queried, and that they have the correct temporal parameters.
The creation of an operational intent which:
is expected to trigger the creation of a new implicit subscription.
If the DSS does not create the implicit subscription, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.030660Z)
This test step fragment validates the time-bounds of an implicit subscription
If the implicit subscription time boundaries do not cover the OIR's, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.031520Z)
Expand the previously created OIR's duration while explicitly specifying the implicit subscription that was automatically created for it.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss2_dss (2026-03-03T21:57:54.050566Z)
The implicit subscription attached to the mutated OIR should be able to be queried.
If it cannot, the DSS is either improperly managing implicit subscriptions for OIRs, or failing to report the subscriptions relevant to an OIR, in which case the DSS is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,5, respectively.
✅ uss2_dss (2026-03-03T21:57:54.059100Z)
This test step fragment validates the time-bounds of an implicit subscription with respect to the OIRs it needs to cover.
If the implicit subscription's time boundaries do not cover every OIR attached to it, the DSS is in violation of astm.f3548.v21.DSS0005,1.
Ensure that the attached implicit subscription has been expanded
✅ uss2_dss (2026-03-03T21:57:54.060035Z)
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.074548Z)
This test case verifies that an implicit subscription can be used to replace an explicit subscription attached to an OIR.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
Create an explicit subscription to be initially set on the first OIR created in this test case
✅ uss2_dss (2026-03-03T21:57:54.084975Z)
Create an OIR bound to the explicit subscription created in the previous step.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:54.104808Z)
Create a second OIR with an implicit subscription, which will then be used in the next step.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:54.122742Z)
This test step fragment validates that implicit subscriptions are created and can be queried, and that they have the correct temporal parameters.
The creation of an operational intent which:
is expected to trigger the creation of a new implicit subscription.
If the DSS does not create the implicit subscription, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.132074Z)
This test step fragment validates the time-bounds of an implicit subscription
If the implicit subscription time boundaries do not cover the OIR's, the DSS is in violation of astm.f3548.v21.DSS0005,1.
Confirm that an implicit subscription was created.
✅ uss2_dss (2026-03-03T21:57:54.132918Z)
Replace the first OIR's explicit subscription with the implicit one created in the previous step.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
Confirm that the query to replace the second OIR's explicit subscription with the second OIR's implicit subscription succeeds.
✅ uss2_dss (2026-03-03T21:57:54.153546Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.161496Z)
If the OIR returned by the DSS under test is not attached to the expected subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:54.153607Z)
✅ uss2_dss (2026-03-03T21:57:54.161546Z)
This fragment can be used by test cases that need to clean up after themselves by deleting the OIRs and subscriptions created during the test.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.174760Z)
✅ uss2_dss (2026-03-03T21:57:54.190421Z)
This test step fragment validates that a query to remove a subscription succeeds.
An attempt to delete a subscription when the correct version is provided should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:57:54.202265Z)
This test case verifies that an implicit subscription can be attached to an OIR that is not currently attached to any subscription.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:54.220780Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.228851Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:54.222928Z)
✅ uss2_dss (2026-03-03T21:57:54.231053Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss2_dss (2026-03-03T21:57:54.230979Z)
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:54.249143Z)
This test step fragment validates that implicit subscriptions are created and can be queried, and that they have the correct temporal parameters.
The creation of an operational intent which:
is expected to trigger the creation of a new implicit subscription.
If the DSS does not create the implicit subscription, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.258056Z)
This test step fragment validates the time-bounds of an implicit subscription
If the implicit subscription time boundaries do not cover the OIR's, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.258937Z)
Attach the first OIR to the implicit subscription created with the second OIR.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss2_dss (2026-03-03T21:57:54.279971Z)
Confirms that the DSS properly attached the first OIR to the implicit subscription created with the second OIR.
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.287658Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.287658Z)
If the OIR returned by the DSS under test is not attached to the expected subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:54.280094Z)
✅ uss2_dss (2026-03-03T21:57:54.287706Z)
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.301674Z)
✅ uss2_dss (2026-03-03T21:57:54.318199Z)
This test case ensures that, when a client mutates an OIR not attached to any subscription without specifiying either a subscription identifier nor parameters for an implicit subscription, the DSS under test will correctly keep the OIR unattached to any subscription.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:54.333478Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.341455Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:54.335588Z)
✅ uss2_dss (2026-03-03T21:57:54.343522Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss2_dss (2026-03-03T21:57:54.343483Z)
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss2_dss (2026-03-03T21:57:54.357842Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.365816Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:54.367951Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss2_dss (2026-03-03T21:57:54.367913Z)
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.378445Z)
This test case ensures that a DSS properly allows a client to request that a new implicit subscription be created for an existing OIR with an explicit subscription attached.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:54.388717Z)
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:54.408409Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.416720Z)
If the OIR returned by the DSS under test is not attached to the expected subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:54.416769Z)
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss2_dss (2026-03-03T21:57:54.437538Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.445644Z)
If the DSS under test fails to attach the OIR to a subscription that is different from the one it is currently attached to when it is requested to do so, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.437642Z)
✅ uss2_dss (2026-03-03T21:57:54.445694Z)
This test step fragment validates that a query to read a subscription succeeds.
If a subscription cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:57:54.449908Z)
If the DSS under test fails to attach the OIR to an implicit subscription (which may either already exist or be newly created) when it is requested to do so, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.449956Z)
This fragment can be used by test cases that need to clean up after themselves by deleting the OIRs and subscriptions created during the test.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.466654Z)
This test step fragment validates that a query to remove a subscription succeeds.
An attempt to delete a subscription when the correct version is provided should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:57:54.478300Z)
This test case ensures that a DSS properly allows a client to request that a new implicit subscription be created for an existing OIR that is not attached to any subscription.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:54.496313Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.504358Z)
If the OIR returned by the DSS under test is not attached to a subscription, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:54.498440Z)
✅ uss2_dss (2026-03-03T21:57:54.506517Z)
Attempt to fetch the subscription referenced by the OIR in order to confirm that it does not exist.
This check will fail if the DSS under test does not return a 400 or 404 error when the subscription that it reported in the OIR is queried, as the DSS is in violation of astm.f3548.v21.DSS0005,1.
This check is run in circumstances where the subscription is expected to not exist, and will result in attempts
to obtain the null subscription ID with value 00000000-0000-4000-8000-000000000000, unless the DSS instances
under test chose to use another placeholder for non-existent subscriptions.
✅ uss2_dss (2026-03-03T21:57:54.506477Z)
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss2_dss (2026-03-03T21:57:54.526417Z)
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.534764Z)
If the DSS under test fails to attach the OIR to a subscription when it is requested to do so, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.526513Z)
✅ uss2_dss (2026-03-03T21:57:54.534833Z)
This test step fragment validates that a query to read a subscription succeeds.
If a subscription cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:57:54.539267Z)
If the DSS under test fails to attach the OIR to an implicit subscription (which may either already exist or be newly created) when it is requested to do so, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.539317Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.567177Z)
✅ uss2_dss (2026-03-03T21:57:54.569593Z)
✅ uss2_dss (2026-03-03T21:57:54.572191Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:57:54.559813Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.559786Z)
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss2_dss (2026-03-03T21:57:54.575783Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:57:54.578163Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
Verifies the behavior of a DSS for simple interactions pertaining to operational intent references.
DSSInstanceResource the DSS instance through which entities are created, modified and deleted.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
IDGeneratorResource providing the base entity ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
ClientIdentityResource the client identity that will be used to create and update operational intent references.
✅ Provided by utm_client_identity in top-level resource pool.
PlanningAreaResource describes the 3D volume in which operational intent references will be created. Note that any start or end times specified in the underlying volume template
will be ignored.
✅ Provided by planning_area in top-level resource pool.
This test case ensures that no entities with the known test IDs exists in the DSS.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.587603Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:57:54.585245Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
This test case confirms that an OIR can be created when the correct parameters are provided, and that it can be deleted when the proper OVN is provided.
This test step fragment validates that:
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:54.605919Z)
This test step fragment validates that an operational intent references creation returns a body in the correct format.
The response to a successful operational intent reference creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.614774Z)
A successful operational intent reference creation query is expected to return a body, the content of which reflects the created operational intent reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:57:54.615732Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.615365Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.615431Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.615479Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.615718Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.615513Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.615549Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.615578Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.615636Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.615606Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.615664Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
Create an OIR with allowed parameters.
✅ uss2_dss (2026-03-03T21:57:54.615691Z)
This test step fragment validates that deleting an operational intent reference succeeds and returns the expected deleted operational intent reference.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.644722Z)
The response to a successful operational intent reference deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.652464Z)
A successful operational intent reference deletion query is expected to return a body, the content of which reflects the operational intent reference at the moment of deletion. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:57:54.653480Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.653048Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.653094Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.653128Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.653465Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.653159Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.653195Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.653225Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.653285Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.653254Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.653316Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.653371Z)
This test step fragment attempts to validate a single operational intent reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the oir_validator.py class.
If the version of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.653429Z)
If the OVN of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
Delete the OIR created in the previous step.
✅ uss2_dss (2026-03-03T21:57:54.653344Z)
Ensures that a DSS will only delete OIRs when the correct OVN is presented.
This test step fragment validates that:
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:54.669779Z)
This test step fragment validates that an operational intent references creation returns a body in the correct format.
The response to a successful operational intent reference creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.677810Z)
A successful operational intent reference creation query is expected to return a body, the content of which reflects the created operational intent reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:57:54.678687Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.678359Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.678401Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.678434Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.678673Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.678466Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.678504Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.678534Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.678592Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.678563Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.678620Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
Create an OIR to be used in this test case.
✅ uss2_dss (2026-03-03T21:57:54.678646Z)
This step verifies that an existing OIR cannot be deleted with a missing OVN.
If the DSS under test allows the qualifier to delete an existing OIR with a request that provided an empty OVN, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:54.680171Z)
This step verifies that an existing OIR cannot be deleted with an incorrect OVN.
If the DSS under test allows the qualifier to delete an existing OIR with a request that provided an incorrect OVN, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:54.682911Z)
This test step fragment validates that deleting an operational intent reference succeeds and returns the expected deleted operational intent reference.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.693973Z)
The response to a successful operational intent reference deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.701596Z)
A successful operational intent reference deletion query is expected to return a body, the content of which reflects the operational intent reference at the moment of deletion. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:57:54.702536Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.702153Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.702197Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.702231Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.702523Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.702263Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.702294Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.702322Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.702378Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.702349Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.702413Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.702469Z)
This test step fragment attempts to validate a single operational intent reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the oir_validator.py class.
If the version of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.702496Z)
If the OVN of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
Cleanup the OIR created in this test case.
✅ uss2_dss (2026-03-03T21:57:54.702442Z)
Test DSS behavior when mutation requests are not providing the required OVN.
This test step fragment validates that:
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:54.718494Z)
This test step fragment validates that an operational intent references creation returns a body in the correct format.
The response to a successful operational intent reference creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.726950Z)
A successful operational intent reference creation query is expected to return a body, the content of which reflects the created operational intent reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:57:54.727824Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.727510Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.727553Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.727586Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.727811Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.727616Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.727646Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.727674Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.727730Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.727701Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.727758Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
Create an OIR to be used in this test case.
✅ uss2_dss (2026-03-03T21:57:54.727784Z)
This step verifies that an existing OIR cannot be mutated with a missing OVN.
If the DSS under test allows the qualifier to mutate an existing OIR with a request that provided an empty OVN, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:54.733778Z)
This step verifies that an existing OIR cannot be mutated with an incorrect OVN.
If the DSS under test allows the qualifier to mutate an existing OIR with a request that provided an incorrect OVN, it is in violation of astm.f3548.v21.DSS0005,1
✅ uss2_dss (2026-03-03T21:57:54.739496Z)
This test step fragment validates that operational intent references can be updated.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss2_dss (2026-03-03T21:57:54.758333Z)
This test step fragment validates that updates to operational intent references return a body in the correct format.
The response to a successful operational intent reference mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.766275Z)
A successful operational intent reference mutation query is expected to return a well-defined body, the content of which reflects the updated operational intent reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:57:54.767296Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.766890Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.766934Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.766967Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.767282Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.766998Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.767050Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.767080Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.767138Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.767108Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.767167Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.767222Z)
This test step fragment attempts to validate a single operational intent reference returned by the DSS, usually after it has been mutated.
The code for these checks lives in the oir_validator.py class.
Following a mutation, the DSS needs to update the operational intent reference version, otherwise it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.767249Z)
Following a mutation, the DSS needs to update the operational intent reference OVN, otherwise it is in violation of astm.f3548.v21.DSS0005,1.
Confirm that an OIR can be mutated when the correct OVN is provided.
✅ uss2_dss (2026-03-03T21:57:54.767194Z)
This test step fragment validates that deleting an operational intent reference succeeds and returns the expected deleted operational intent reference.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.783685Z)
The response to a successful operational intent reference deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.796116Z)
A successful operational intent reference deletion query is expected to return a body, the content of which reflects the operational intent reference at the moment of deletion. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:57:54.797131Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.796729Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.796771Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.796805Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.797117Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.796836Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.796866Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.796895Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.796953Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.796923Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.796983Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.797061Z)
This test step fragment attempts to validate a single operational intent reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the oir_validator.py class.
If the version of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.797089Z)
If the OVN of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.797029Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:54.804630Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:57:54.802450Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
Remove any lingering OIRs left by this scenario. ∅ This check was not applicable to this test run and is therefore not statused.
Verifies the behavior of a DSS for simple interactions pertaining to constraint references.
DSSInstanceResource the DSS instance through which entities are created, modified and deleted.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
IDGeneratorResource providing the base entity ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
ClientIdentityResource the client identity that will be used to create and update constraint references.
✅ Provided by utm_client_identity in top-level resource pool.
PlanningAreaResource describes the 3D volume in which constraint references will be created.
✅ Provided by planning_area in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any constraint references from the DSS that may have been left behind from testing efforts.
If an existing constraint reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:54.811914Z)
A client with valid credentials should be allowed to search for constraint references in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,4.
✅ uss2_dss (2026-03-03T21:57:54.809627Z)
If an existing constraint cannot be deleted by its manager when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
This step ensures that no entities with the known test IDs exists in the DSS.
∅ This check was not applicable to this test run and is therefore not statused.
This test step fragment validates that a query to create a constraint reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,3, the DSS API must allow callers to create a constraint reference with either one or both of the start and end time missing, provided all the required parameters are valid.
This step creates the constraint reference to be used in this scenario.
✅ uss2_dss (2026-03-03T21:57:54.821989Z)
Ensures that an existing CR can only be deleted when the correct OVN is provided.
This step verifies that an existing CR cannot be deleted with a missing OVN.
If the DSS under test allows the qualifier to delete an existing CR with a request that provided an empty OVN, it is in violation of astm.f3548.v21.DSS0005,3
✅ uss2_dss (2026-03-03T21:57:54.823345Z)
This step verifies that an existing CR cannot be deleted with an incorrect OVN.
If the DSS under test allows the qualifier to delete an existing CR with a request that provided an incorrect OVN, it is in violation of astm.f3548.v21.DSS0005,3
✅ uss2_dss (2026-03-03T21:57:54.825535Z)
Ensures that an existing CR can only be mutated when the correct OVN is provided.
This step verifies that an existing CR cannot be mutated with a missing OVN.
If the DSS under test allows the qualifier to mutate an existing CR with a request that provided an empty OVN, it is in violation of astm.f3548.v21.DSS0005,3
✅ uss2_dss (2026-03-03T21:57:54.828354Z)
This step verifies that an existing CR cannot be mutated with an incorrect OVN.
If the DSS under test allows the qualifier to mutate an existing CR with a request that provided an incorrect OVN, it is in violation of astm.f3548.v21.DSS0005,3
✅ uss2_dss (2026-03-03T21:57:54.831161Z)
Ensure a clean workspace for testing interactions with a DSS by removing any constraint references from the DSS that may have been left behind from testing efforts.
If an existing constraint reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:54.845290Z)
A client with valid credentials should be allowed to search for constraint references in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,4.
✅ uss2_dss (2026-03-03T21:57:54.835730Z)
If an existing constraint cannot be deleted by its manager when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:54.843266Z)
Verifies that all CRUD operations on constraint references performed on a given DSS instance are properly propagated to every other DSS instance participating in the deployment.
DSSInstanceResource the DSS instance through which entities are created, modified and deleted.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
DSSInstancesResource pointing to the DSS instances used to confirm that entities are properly propagated.
✅ Provided by dss_instances in top-level resource pool.
IDGeneratorResource providing the constraint reference ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which constraint reference will be created. Note that any start or end times specified in the underlying volume template
will be ignored.
✅ Provided by planning_area in top-level resource pool.
ClientIdentityResource to be used for this scenario.
✅ Provided by utm_client_identity in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any constraint references from the DSS that may have been left behind from testing efforts.
If an existing constraint reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:54.852356Z)
A client with valid credentials should be allowed to search for constraint references in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,4.
✅ uss2_dss (2026-03-03T21:57:54.850102Z)
If an existing constraint cannot be deleted by its manager when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
∅ This check was not applicable to this test run and is therefore not statused.
∅ This test step was not applicable to this test run and is therefore not statused.
Ensures that a secondary DSS is ready to be used for testing by confirming that no CR bearing an ID used for testing exists on it.
If an existing constraint reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
If a CR that was deleted from the primary DSS can still be found on a secondary DSS, either one of them may be improperly pooled and in violation of astm.f3548.v21.DSS0020.
This test case creates an constraint reference on the main DSS, and verifies that it is properly synchronized to the other DSS instances.
It then goes on to mutate and delete it, each time confirming that all other DSSes return the expected results.
This test step fragment validates that:
This test step fragment validates that a query to create a constraint reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,3, the DSS API must allow callers to create a constraint reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:57:54.860828Z)
This test step fragment validates that a constraint references creation returns a body in the correct format.
The response to a successful constraint reference creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:54.868081Z)
A successful constraint reference creation query is expected to return a body, the content of which reflects the created constraint reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:57:54.868897Z)
This test step fragment attempts to validate the content of a single constraint reference returned by the DSS.
The code for these checks lives in the cr_validator.py class.
If the returned constraint reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.868597Z)
If the returned constraint reference has no manager defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.868639Z)
The returned manager must correspond to the identity of the client that created the constraint at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:54.868675Z)
If the returned constraint reference has no USS base URL defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.868707Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at constraint reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:54.868738Z)
If the returned constraint reference has no start time defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.868767Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:54.868827Z)
Constraint references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:54.868796Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:54.868856Z)
If the returned constraint reference has no OVN defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:54.868883Z)
If the returned constraint reference has no version defined, astm.f3548.v21.DSS0005,3 is not respected.
∅ This check was not applicable to this test run and is therefore not statused.
Retrieve and validate synchronization of the created constraint at every DSS provided in dss_instances.
This test step fragment validates that a known constraint references can be read, and that its content is as expected.
This test step fragment validates that a query to retrieve an existing constraint reference with valid parameters succeeds.
If an existing constraint reference cannot successfully be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:54.872468Z)
✅ uss2_dss (2026-03-03T21:57:54.960335Z)
This test step fragment validates that a request for a constraint reference returns a properly formatted body.
The response to a successful get constraint reference query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.954893Z)
✅ uss2_dss (2026-03-03T21:57:54.968154Z)
A successful constraint reference creation query is expected to return a body, the content of which reflects a constraint reference that was created earlier. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:57:54.955880Z)
✅ uss2_dss (2026-03-03T21:57:54.969083Z)
If the constraint retrieved from a secondary DSS instance is not consistent with the newly created one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1a, astm.f3548.v21.DSS0210,A2-7-2,1f, astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.873414Z)
✅ uss2_dss (2026-03-03T21:57:54.961304Z)
This test step fragment validates that constraint references are properly synchronized across a set of DSS instances by querying a constraint reference that is known to exist at each one of the DSS instances.
If the previously created or mutated constraint reference cannot be found at a DSS, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.872543Z)
✅ uss2_dss (2026-03-03T21:57:54.960399Z)
This test step fragment validates that constraint reference attributes are properly synchronized across a set of DSS instances.
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct manager, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.872624Z)
✅ uss2_dss (2026-03-03T21:57:54.960479Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.872666Z)
✅ uss2_dss (2026-03-03T21:57:54.960538Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct start time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.873338Z)
✅ uss2_dss (2026-03-03T21:57:54.961225Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct end time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.873396Z)
✅ uss2_dss (2026-03-03T21:57:54.961287Z)
This test step fragment attempts to validate the content of a single constraint reference returned by the DSS.
The code for these checks lives in the cr_validator.py class.
If the returned constraint reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.955490Z)
✅ uss2_dss (2026-03-03T21:57:54.968652Z)
If the returned constraint reference has no manager defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.955539Z)
✅ uss2_dss (2026-03-03T21:57:54.968697Z)
The returned manager must correspond to the identity of the client that created the constraint at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.955578Z)
✅ uss2_dss (2026-03-03T21:57:54.968733Z)
If the returned constraint reference has no USS base URL defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.955613Z)
✅ uss2_dss (2026-03-03T21:57:54.968767Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at constraint reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.955647Z)
✅ uss2_dss (2026-03-03T21:57:54.968801Z)
If the returned constraint reference has no start time defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.955680Z)
✅ uss2_dss (2026-03-03T21:57:54.968833Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.955745Z)
✅ uss2_dss (2026-03-03T21:57:54.968898Z)
Constraint references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.955711Z)
✅ uss2_dss (2026-03-03T21:57:54.968866Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.955777Z)
✅ uss2_dss (2026-03-03T21:57:54.968930Z)
If the returned constraint reference has no OVN defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.955807Z)
✅ uss2_dss (2026-03-03T21:57:54.968961Z)
If the returned constraint reference has no version defined, astm.f3548.v21.DSS0005,3 is not respected.
∅ This check was not applicable to this test run and is therefore not statused.
This test step fragment attempts to validate a single constraint reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the cr_validator.py class.
If the version of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.955867Z)
✅ uss2_dss (2026-03-03T21:57:54.969061Z)
If the OVN of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.955837Z)
✅ uss2_dss (2026-03-03T21:57:54.968990Z)
Search for and validate synchronization of the created constraint at every DSS provided in dss_instances.
This test step fragment validates that known constraint references can be searched for, and that the returned content is as expected.
This test step fragment validates that a query to search for constraint references with valid parameters succeeds.
If the DSS fails to let us search in the area for which the CR was created, it is failing to meet astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:54.973225Z)
✅ uss2_dss (2026-03-03T21:57:54.985516Z)
This test step fragment validates that constraint references search responses are properly formatted.
The response to a successful constraint reference search query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,4.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.981155Z)
✅ uss2_dss (2026-03-03T21:57:54.992669Z)
If the existing constraint reference is not returned in a search that covers the area it was created for, the DSS is not properly implementing astm.f3548.v21.DSS0005,4.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.981662Z)
✅ uss2_dss (2026-03-03T21:57:54.993188Z)
A successful constraint reference search query is expected to return a body, the content of which reflects any constraint reference present in the searched area. This includes the previously created constraint reference, which should accurately represent the constraint reference as it was requested. If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,4.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:57:54.982105Z)
✅ uss2_dss (2026-03-03T21:57:54.993612Z)
If the constraint searched from a secondary DSS instance is not consistent with the newly created one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1a, astm.f3548.v21.DSS0210,A2-7-2,1e, , astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.973967Z)
✅ uss2_dss (2026-03-03T21:57:54.986279Z)
This test step fragment validates that constraint references are properly synchronized across a set of DSS instances by searching for a constraint reference that is known to exist in a specific area at each one of the DSS instances.
When querying a secondary DSS for constraints in the planning area that contains the propagated constraint, if the propagated constraint is not contained in the response, then the general area in which the propagated constraint is located is not synchronized across DSS instances. As such, either the primary or the secondary DSS fail to properly one of the following requirements:
astm.f3548.v21.DSS0210,2e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.973281Z)
✅ uss2_dss (2026-03-03T21:57:54.985589Z)
This test step fragment validates that constraint reference attributes are properly synchronized across a set of DSS instances.
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct manager, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.973340Z)
✅ uss2_dss (2026-03-03T21:57:54.985677Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.973377Z)
✅ uss2_dss (2026-03-03T21:57:54.985721Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct start time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.973913Z)
✅ uss2_dss (2026-03-03T21:57:54.986226Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct end time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
Confirm that each DSS returns the constraint in relevant search results. Confirm that the constraint reference that was just created is properly synchronized across all DSS instances.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.973953Z)
✅ uss2_dss (2026-03-03T21:57:54.986265Z)
This test step fragment attempts to validate the content of a single constraint reference returned by the DSS.
The code for these checks lives in the cr_validator.py class.
If the returned constraint reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.981709Z)
✅ uss2_dss (2026-03-03T21:57:54.993236Z)
If the returned constraint reference has no manager defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.981745Z)
✅ uss2_dss (2026-03-03T21:57:54.993273Z)
The returned manager must correspond to the identity of the client that created the constraint at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.981779Z)
✅ uss2_dss (2026-03-03T21:57:54.993307Z)
If the returned constraint reference has no USS base URL defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.981812Z)
✅ uss2_dss (2026-03-03T21:57:54.993340Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at constraint reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.981845Z)
✅ uss2_dss (2026-03-03T21:57:54.993373Z)
If the returned constraint reference has no start time defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.981877Z)
✅ uss2_dss (2026-03-03T21:57:54.993405Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.981942Z)
✅ uss2_dss (2026-03-03T21:57:54.993475Z)
Constraint references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.981908Z)
✅ uss2_dss (2026-03-03T21:57:54.993436Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.981973Z)
✅ uss2_dss (2026-03-03T21:57:54.993509Z)
If the returned constraint reference has no OVN defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.982021Z)
✅ uss2_dss (2026-03-03T21:57:54.993539Z)
If the returned constraint reference has no version defined, astm.f3548.v21.DSS0005,3 is not respected.
∅ This check was not applicable to this test run and is therefore not statused.
This test step fragment attempts to validate a single constraint reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the cr_validator.py class.
If the version of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.982091Z)
✅ uss2_dss (2026-03-03T21:57:54.993600Z)
If the OVN of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:54.982058Z)
✅ uss2_dss (2026-03-03T21:57:54.993570Z)
This test step mutates the previously created constraint reference to verify that the DSS reacts properly: notably, it checks that the constraint reference version is updated, including for changes that are not directly visible, such as changing the constraint reference's footprint.
This test step fragment validates that constraint references can be updated.
This test step fragment validates that a query to update a constraint reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,3, the DSS API must allow callers to mutate a constraint reference.
✅ uss2_dss (2026-03-03T21:57:55.003553Z)
This test step fragment validates that updates to constraint references return a body in the correct format.
The response to a successful constraint reference mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.010850Z)
A successful constraint reference mutation query is expected to return a well-defined body, the content of which reflects the updated constraint reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:57:55.011939Z)
This test step fragment attempts to validate the content of a single constraint reference returned by the DSS.
The code for these checks lives in the cr_validator.py class.
If the returned constraint reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:55.011537Z)
If the returned constraint reference has no manager defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:55.011583Z)
The returned manager must correspond to the identity of the client that created the constraint at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.011638Z)
If the returned constraint reference has no USS base URL defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:55.011673Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at constraint reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.011724Z)
If the returned constraint reference has no start time defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:55.011757Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.011815Z)
Constraint references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.011786Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.011843Z)
If the returned constraint reference has no OVN defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:55.011870Z)
If the returned constraint reference has no version defined, astm.f3548.v21.DSS0005,3 is not respected.
∅ This check was not applicable to this test run and is therefore not statused.
This test step fragment attempts to validate a single constraint reference returned by the DSS, usually after it has been mutated.
The code for these checks lives in the cr_validator.py class.
Following a mutation, the DSS needs to update the constraint reference version, otherwise it is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.011926Z)
Following a mutation, the DSS needs to update the constraint reference OVN, otherwise it is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.011898Z)
Retrieve and validate synchronization of the updated constraint at every DSS provided in dss_instances.
This test step fragment validates that a known constraint references can be read, and that its content is as expected.
This test step fragment validates that a query to retrieve an existing constraint reference with valid parameters succeeds.
If an existing constraint reference cannot successfully be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:55.014738Z)
✅ uss2_dss (2026-03-03T21:57:55.025595Z)
This test step fragment validates that a request for a constraint reference returns a properly formatted body.
The response to a successful get constraint reference query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.021911Z)
✅ uss2_dss (2026-03-03T21:57:55.033134Z)
A successful constraint reference creation query is expected to return a body, the content of which reflects a constraint reference that was created earlier. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:57:55.022793Z)
✅ uss2_dss (2026-03-03T21:57:55.034294Z)
If the constraint retrieved from a secondary DSS instance is not consistent with the updated one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1b, astm.f3548.v21.DSS0210,A2-7-2,1d, astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.015519Z)
✅ uss2_dss (2026-03-03T21:57:55.026308Z)
This test step fragment validates that constraint references are properly synchronized across a set of DSS instances by querying a constraint reference that is known to exist at each one of the DSS instances.
If the previously created or mutated constraint reference cannot be found at a DSS, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.014792Z)
✅ uss2_dss (2026-03-03T21:57:55.025648Z)
This test step fragment validates that constraint reference attributes are properly synchronized across a set of DSS instances.
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct manager, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.014866Z)
✅ uss2_dss (2026-03-03T21:57:55.025707Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.014914Z)
✅ uss2_dss (2026-03-03T21:57:55.025742Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct start time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.015463Z)
✅ uss2_dss (2026-03-03T21:57:55.026254Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct end time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
Confirm that each DSS provides direct access to the updated constraint reference. Confirm that the constraint reference that was just updated is properly synchronized across all DSS instances.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.015504Z)
✅ uss2_dss (2026-03-03T21:57:55.026293Z)
This test step fragment attempts to validate the content of a single constraint reference returned by the DSS.
The code for these checks lives in the cr_validator.py class.
If the returned constraint reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.022412Z)
✅ uss2_dss (2026-03-03T21:57:55.033684Z)
If the returned constraint reference has no manager defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.022457Z)
✅ uss2_dss (2026-03-03T21:57:55.033750Z)
The returned manager must correspond to the identity of the client that created the constraint at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.022495Z)
✅ uss2_dss (2026-03-03T21:57:55.033797Z)
If the returned constraint reference has no USS base URL defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.022530Z)
✅ uss2_dss (2026-03-03T21:57:55.033849Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at constraint reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.022563Z)
✅ uss2_dss (2026-03-03T21:57:55.033895Z)
If the returned constraint reference has no start time defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.022595Z)
✅ uss2_dss (2026-03-03T21:57:55.033955Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.022659Z)
✅ uss2_dss (2026-03-03T21:57:55.034093Z)
Constraint references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.022626Z)
✅ uss2_dss (2026-03-03T21:57:55.034034Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.022692Z)
✅ uss2_dss (2026-03-03T21:57:55.034150Z)
If the returned constraint reference has no OVN defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.022721Z)
✅ uss2_dss (2026-03-03T21:57:55.034210Z)
If the returned constraint reference has no version defined, astm.f3548.v21.DSS0005,3 is not respected.
∅ This check was not applicable to this test run and is therefore not statused.
This test step fragment attempts to validate a single constraint reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the cr_validator.py class.
If the version of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.022780Z)
✅ uss2_dss (2026-03-03T21:57:55.034281Z)
If the OVN of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.022751Z)
✅ uss2_dss (2026-03-03T21:57:55.034248Z)
Search for and validate synchronization of the updated constraint at every DSS provided in dss_instances.
This test step fragment validates that known constraint references can be searched for, and that the returned content is as expected.
This test step fragment validates that a query to search for constraint references with valid parameters succeeds.
If the DSS fails to let us search in the area for which the CR was created, it is failing to meet astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:55.037532Z)
✅ uss2_dss (2026-03-03T21:57:55.048849Z)
This test step fragment validates that constraint references search responses are properly formatted.
The response to a successful constraint reference search query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,4.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.044637Z)
✅ uss2_dss (2026-03-03T21:57:55.056545Z)
If the existing constraint reference is not returned in a search that covers the area it was created for, the DSS is not properly implementing astm.f3548.v21.DSS0005,4.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.045159Z)
✅ uss2_dss (2026-03-03T21:57:55.057065Z)
A successful constraint reference search query is expected to return a body, the content of which reflects any constraint reference present in the searched area. This includes the previously created constraint reference, which should accurately represent the constraint reference as it was requested. If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,4.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:57:55.045572Z)
✅ uss2_dss (2026-03-03T21:57:55.057488Z)
If the constraint searched from a secondary DSS instance is not consistent with the updated one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1b, astm.f3548.v21.DSS0210,A2-7-2,1e, astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.038251Z)
✅ uss2_dss (2026-03-03T21:57:55.049576Z)
This test step fragment validates that constraint references are properly synchronized across a set of DSS instances by searching for a constraint reference that is known to exist in a specific area at each one of the DSS instances.
When querying a secondary DSS for constraints in the planning area that contains the propagated constraint, if the propagated constraint is not contained in the response, then the general area in which the propagated constraint is located is not synchronized across DSS instances. As such, either the primary or the secondary DSS fail to properly one of the following requirements:
astm.f3548.v21.DSS0210,2e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.037586Z)
✅ uss2_dss (2026-03-03T21:57:55.048902Z)
This test step fragment validates that constraint reference attributes are properly synchronized across a set of DSS instances.
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct manager, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.037645Z)
✅ uss2_dss (2026-03-03T21:57:55.048962Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.037682Z)
✅ uss2_dss (2026-03-03T21:57:55.048999Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct start time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.038196Z)
✅ uss2_dss (2026-03-03T21:57:55.049524Z)
If the constraint reference returned by a DSS to which the constraint reference was synchronized to does not contain the correct end time, either one of the instances at which the constraint reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
Confirm that each DSS returns the constraint in relevant search results. Confirm that the constraint reference that was just updated is properly synchronized across all DSS instances.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.038237Z)
✅ uss2_dss (2026-03-03T21:57:55.049563Z)
This test step fragment attempts to validate the content of a single constraint reference returned by the DSS.
The code for these checks lives in the cr_validator.py class.
If the returned constraint reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.045207Z)
✅ uss2_dss (2026-03-03T21:57:55.057113Z)
If the returned constraint reference has no manager defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.045245Z)
✅ uss2_dss (2026-03-03T21:57:55.057151Z)
The returned manager must correspond to the identity of the client that created the constraint at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.045279Z)
✅ uss2_dss (2026-03-03T21:57:55.057185Z)
If the returned constraint reference has no USS base URL defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.045311Z)
✅ uss2_dss (2026-03-03T21:57:55.057225Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at constraint reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.045343Z)
✅ uss2_dss (2026-03-03T21:57:55.057258Z)
If the returned constraint reference has no start time defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.045374Z)
✅ uss2_dss (2026-03-03T21:57:55.057289Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.045438Z)
✅ uss2_dss (2026-03-03T21:57:55.057353Z)
Constraint references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.045405Z)
✅ uss2_dss (2026-03-03T21:57:55.057320Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.045470Z)
✅ uss2_dss (2026-03-03T21:57:55.057384Z)
If the returned constraint reference has no OVN defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.045500Z)
✅ uss2_dss (2026-03-03T21:57:55.057414Z)
If the returned constraint reference has no version defined, astm.f3548.v21.DSS0005,3 is not respected.
∅ This check was not applicable to this test run and is therefore not statused.
This test step fragment attempts to validate a single constraint reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the cr_validator.py class.
If the version of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.045560Z)
✅ uss2_dss (2026-03-03T21:57:55.057475Z)
If the OVN of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.045530Z)
✅ uss2_dss (2026-03-03T21:57:55.057445Z)
Attempt to delete the constraint reference in various ways and ensure that the DSS reacts properly.
This also checks that the constraint reference data returned by a successful deletion is correct.
This test step fragment validates that constraint references can be deleted
A query to delete a constraint reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.066569Z)
This test step fragment validates that a constraint references deletion returns a body in the correct format.
The response to a successful constraint reference deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.073305Z)
A successful constraint reference deletion query is expected to return a body, the content of which reflects the constraint reference at the moment of deletion. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:57:55.074273Z)
This test step fragment attempts to validate the content of a single constraint reference returned by the DSS.
The code for these checks lives in the cr_validator.py class.
If the returned constraint reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:55.073895Z)
If the returned constraint reference has no manager defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:55.073939Z)
The returned manager must correspond to the identity of the client that created the constraint at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.073974Z)
If the returned constraint reference has no USS base URL defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:55.074024Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at constraint reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.074059Z)
If the returned constraint reference has no start time defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:55.074089Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.074150Z)
Constraint references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.074119Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.074179Z)
If the returned constraint reference has no OVN defined, astm.f3548.v21.DSS0005,3 is not respected.
✅ uss2_dss (2026-03-03T21:57:55.074207Z)
If the returned constraint reference has no version defined, astm.f3548.v21.DSS0005,3 is not respected.
∅ This check was not applicable to this test run and is therefore not statused.
This test step fragment attempts to validate a single constraint reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the cr_validator.py class.
If the version of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.074260Z)
If the OVN of the constraint reference is updated without there having been any mutation of the constraint reference, the DSS is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.074233Z)
Attempt to query and search for the deleted constraint reference in various ways
This test step fragment validates that a known constraint references can be read, and that its content is as expected.
This test step fragment validates that a query to retrieve an existing constraint reference with valid parameters succeeds.
If an existing constraint reference cannot successfully be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,3.
✅ uss1_dss (2026-03-03T21:57:55.076540Z)
✅ uss2_dss (2026-03-03T21:57:55.081475Z)
This test step fragment validates that a request for a constraint reference returns a properly formatted body.
The response to a successful get constraint reference query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
∅ This check was not applicable to this test run and is therefore not statused.
A successful constraint reference creation query is expected to return a body, the content of which reflects a constraint reference that was created earlier. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
This check will usually be performing a series of sub-checks from the validate fragments.
∅ This check was not applicable to this test run and is therefore not statused.
If a DSS returns an constraint reference that was previously successfully deleted from the primary DSS, either one of the primary DSS or the DSS that returned the constraint reference is in violation of astm.f3548.v21.DSS0210,2a, astm.f3548.v21.DSS0210,A2-7-2,3b, astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.076583Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.081516Z)
This test step fragment validates that a query to search for constraint references with valid parameters succeeds.
If the DSS fails to let us search in the area for which the CR was created, it is failing to meet astm.f3548.v21.DSS0005,4.
✅ uss1_dss (2026-03-03T21:57:55.079304Z)
✅ uss2_dss (2026-03-03T21:57:55.084088Z)
If a DSS returns an constraint reference that was previously successfully deleted from the primary DSS, either one of the primary DSS or the DSS that returned the constraint reference is in violation of astm.f3548.v21.DSS0210,2a, astm.f3548.v21.DSS0210,A2-7-2,3a, astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.079349Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.084133Z)
Ensure a clean workspace for testing interactions with a DSS by removing any constraint references from the DSS that may have been left behind from testing efforts.
If an existing constraint reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:57:55.089280Z)
A client with valid credentials should be allowed to search for constraint references in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,4.
✅ uss2_dss (2026-03-03T21:57:55.087180Z)
If an existing constraint cannot be deleted by its manager when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3. ∅ This check was not applicable to this test run and is therefore not statused.
Verifies that all CRUD operations for USS availabilities on a given DSS instance are properly propagated to every other DSS instance participating in the deployment.
DSSInstanceResource the DSS instance through which USS availabilities are created, modified and deleted.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
DSSInstancesResource pointing to the DSS instances used to confirm that USS availabilities are properly propagated.
✅ Provided by dss_instances in top-level resource pool.
ClientIdentityResource to be used for this scenario: it contains the identifier of the USS
for which availabilities will be updated.
✅ Provided by utm_client_identity in top-level resource pool.
For the setup of this test case, the scenario ensures that the availability for the USS specified in the client_identity resource
is Unknown, which is the default expected state when nothing else is known.
This step ensures that the scenario starts from a state where the USS availability is Unknown.
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI spec referenced by astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:57:55.095082Z)
✅ uss1_dss (2026-03-03T21:57:55.097979Z)
✅ uss2_dss (2026-03-03T21:57:55.100752Z)
A valid request to set the availability of a USS to Unknown should be accepted by the DSS,
otherwise it is failing to implement the OpenAPI spec referenced by astm.f3548.v21.DSS0100,1.
∅ This check was not applicable to this test run and is therefore not statused.
If the reported availability for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3a, if the USS identifier is not properly synced; astm.f3548.v21.DSS0210,3b, if the USS availability is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.098069Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.100796Z)
If the reported availability version for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3c, if the USS availability version is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.098105Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.100854Z)
Checks that updates to a USS availability on one DSS instance are properly propagated to every other DSS instance in the deployment.
Ensures that this is true for every possible availability state.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:57:55.106053Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:55.108324Z)
✅ uss2_dss (2026-03-03T21:57:55.110507Z)
If the reported availability for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3a, if the USS identifier is not properly synced; astm.f3548.v21.DSS0210,3b, if the USS availability is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.108368Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.110549Z)
If the reported availability version for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3c, if the USS availability version is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.108400Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.110578Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:57:55.114746Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:55.117080Z)
✅ uss2_dss (2026-03-03T21:57:55.119371Z)
If the reported availability for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3a, if the USS identifier is not properly synced; astm.f3548.v21.DSS0210,3b, if the USS availability is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.117123Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.119413Z)
If the reported availability version for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3c, if the USS availability version is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.117153Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.119443Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:57:55.123765Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:55.126047Z)
✅ uss2_dss (2026-03-03T21:57:55.128324Z)
If the reported availability for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3a, if the USS identifier is not properly synced; astm.f3548.v21.DSS0210,3b, if the USS availability is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.126092Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.128365Z)
If the reported availability version for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3c, if the USS availability version is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.126124Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.128395Z)
Checks that if queried for a USS it does not know about, any DSS will return an Unknown availability.
This test step requests the availability for a USS identifier that is not known to any DSS instance, and expects
to receive an Unknown availability along with an unset version. This should be true for every DSS that is part of the same deployment.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:57:55.132910Z)
✅ uss2_dss (2026-03-03T21:57:55.135193Z)
If the primary DSS instance does not return an Unknown availability for a USS identifier that has not received any updates,
it is in violation of the OpenAPI spec referenced by astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:57:55.130680Z)
If the primary DSS instance reports a non-empty version for the availability of an USS identifier that should not be known to the DSS, it is in violation of the OpenAPI spec referenced by astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:57:55.130725Z)
If the reported availability for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3a, if the USS identifier is not properly synced; astm.f3548.v21.DSS0210,3b, if the USS availability is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.132953Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.135237Z)
If the reported availability version for a USS is not consistent, across a set of DSS instances, with the value that was previously read or set on an arbitrary DSS instance, either the DSS through which the value was set or the one through which the values was retrieved is failing to meet at least one of these requirements:
astm.f3548.v21.DSS0210,3c, if the USS availability version is not properly synced; astm.f3548.v21.DSS0215, if the DSS returns API calls before having committed the changes to the underlying distributed store.
As a consequence, the DSS also fails to meet astm.f3548.v21.DSS0210,A2-7-2,6 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.132985Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.135267Z)
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI spec referenced by astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:57:55.137401Z)
A valid request to set the availability of a USS to Unknown should be accepted by the DSS,
otherwise it is failing to implement the OpenAPI spec referenced by astm.f3548.v21.DSS0100,1.
∅ This check was not applicable to this test run and is therefore not statused.
This scenario ensures that a DSS will only let the owner of an operational intent reference modify it.
A resources.flight_planning.FlightIntentsResource containing the flight intents to be used in this scenario:
This scenario expects to find at least one flight intent in this resource. It will use its extents to create and mutate an operational intent reference, but ignore any specified states, as this scenario will iterate over all allowed states.
✅ Provided by non_conflicting_flights in top-level resource pool.
A resources.astm.f3548.v21.DSSInstanceResource pointing to the DSS instance to test for this scenario.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
A resources.interuss.IDGeneratorResource that will be used to generate the IDs of the operational intent references created in this scenario.
✅ Provided by id_generator in top-level resource pool.
Makes sure that the DSS is in a clean and expected state before running the test, and that the passed resources work as required.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:55.143071Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:57:55.146537Z)
✅ uss2_dss (2026-03-03T21:57:55.149613Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
If, after cleanup, one or more operational intent reference are still present at the DSS, this scenario cannot proceed.
This scenario is able to remove any operational intent reference that belongs to the configured credentials, but it cannot remove references that belong to other credentials.
A regular failure of this check indicates that other scenarios might not properly clean up their resources, or that the Prepare Flight Planners scenario should be moved in front of the present one.
If this check fails, the rest of the scenario is entirely skipped.
✅ uss2_dss (2026-03-03T21:57:55.149654Z)
This test case attempts to create an operational intent reference with a state that would require the utm.conformance_monitoring_sa scope while only using
the utm.strategic_coordination scope.
This test step attempts to directly create an operational intent reference with a state that is not allowable.
The creation of such an entity is expected to fail for two reasons:
Acceptedutm.conformance_monitoring_sa, a client is not allowed to request an Off-nominal state.If the DSS allows a client with the utm.strategic_coordination scope to create an operational intent reference in the Nonconforming state,
it is in violation of astm.f3548.v21.SCD0100 and astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:55.153388Z)
If the DSS allows a client with the utm.strategic_coordination scope to create an operational intent reference in the Contingent state,
it is in violation of astm.f3548.v21.SCD0100 and astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:55.155168Z)
This test case attempts to transition an existing operational intent reference to a state that would require the utm.conformance_monitoring_sa scope while only using
the utm.strategic_coordination scope.
This step sets up an operational intent reference in the Accepted state.
If the DSS does not allow a client with the utm.strategic_coordination scope to create an operational intent reference in the Accepted state,
it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:55.169242Z)
This test step attempts to transition an existing operational intent reference to a state it should not be allowed to when using the ``utm.strategic_coordination` scope.
If the DSS allows a client with the utm.strategic_coordination scope to transition an operational intent reference from the Accepted state to the Nonconforming state,
it is in violation of astm.f3548.v21.SCD0100.
✅ uss2_dss (2026-03-03T21:57:55.170733Z)
If the DSS allows a client with the utm.strategic_coordination scope to transition an operational intent reference from the Accepted state to the Contingent state,
it is in violation of astm.f3548.v21.SCD0100.
✅ uss2_dss (2026-03-03T21:57:55.172129Z)
This step transitions the operational intent reference to the Activated state.
If the DSS does not allow a client with the utm.strategic_coordination scope to transition an operational intent reference from the Accepted state to the Activated state,
it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:55.188681Z)
If the DSS allows a client with the utm.strategic_coordination scope to transition an operational intent reference from the Activated state to the Nonconforming state,
it is in violation of astm.f3548.v21.SCD0100.
✅ uss2_dss (2026-03-03T21:57:55.190302Z)
If the DSS allows a client with the utm.strategic_coordination scope to transition an operational intent reference from the Activated state to the Contingent state,
it is in violation of astm.f3548.v21.SCD0100.
✅ uss2_dss (2026-03-03T21:57:55.191669Z)
If the DSS does not allow a client with the utm.strategic_coordination scope to transition an operational intent reference from the Activated state to the Ended state,
it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:55.208341Z)
If the DSS allows a client with the utm.strategic_coordination scope to transition an operational intent reference from the Ended state to the Nonconforming state,
it is in violation of astm.f3548.v21.SCD0100 and astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:55.209825Z)
If the DSS allows a client with the utm.strategic_coordination scope to transition an operational intent reference from the Ended state to the Contingent state,
it is in violation of astm.f3548.v21.SCD0100 and astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:55.211246Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:55.215432Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
∅ This check was not applicable to this test run and is therefore not statused.
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:55.226537Z)
Create and mutate subscriptions as well as entities, and verify that the DSS handles notifications and expiry correctly.
DSSInstanceResource to be tested in this scenario.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
DSSInstancesResource pointing to the DSS instances used to confirm that entities are properly propagated.
✅ Provided by dss_instances in top-level resource pool.
IDGeneratorResource providing the Subscription IDs for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which subscriptions will be created.
✅ Provided by planning_area in top-level resource pool.
ClientIdentityResource provides the identity that will be used to interact with the DSS.
✅ Provided by utm_client_identity in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:55.234879Z)
✅ uss2_dss (2026-03-03T21:57:55.237051Z)
✅ uss2_dss (2026-03-03T21:57:55.239197Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:57:55.232580Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss2_dss (2026-03-03T21:57:55.241872Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:57:55.243937Z)
✅ uss2_dss (2026-03-03T21:57:55.245976Z)
✅ uss2_dss (2026-03-03T21:57:55.247964Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
This test step queries all secondary instances to confirm that none of the test IDs that are used in the scenario exist.
Ensures that a secondary DSS is ready to be used for testing by confirming that no OIR bearing an ID used for testing exists on it.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:55.250713Z)
✅ uss1_dss (2026-03-03T21:57:55.252737Z)
✅ uss1_dss (2026-03-03T21:57:55.255038Z)
✅ uss2_dss (2026-03-03T21:57:55.265017Z)
✅ uss2_dss (2026-03-03T21:57:55.267287Z)
✅ uss2_dss (2026-03-03T21:57:55.269457Z)
If an OIR that was deleted from the primary DSS can still be found on a secondary DSS, either one of them may be improperly pooled and in violation of astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:55.250752Z)
✅ uss1_dss (2026-03-03T21:57:55.252775Z)
✅ uss1_dss (2026-03-03T21:57:55.255102Z)
✅ uss2_dss (2026-03-03T21:57:55.265060Z)
✅ uss2_dss (2026-03-03T21:57:55.267344Z)
✅ uss2_dss (2026-03-03T21:57:55.269495Z)
Ensures that a secondary DSS is ready to be used for testing by confirming that no Subscription bearing an ID used for testing exists on it.
If an existing subscription cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:55.257293Z)
✅ uss1_dss (2026-03-03T21:57:55.259469Z)
✅ uss1_dss (2026-03-03T21:57:55.262288Z)
✅ uss2_dss (2026-03-03T21:57:55.271473Z)
✅ uss2_dss (2026-03-03T21:57:55.273531Z)
✅ uss2_dss (2026-03-03T21:57:55.275553Z)
If a Subscription that was deleted from the primary DSS can still be found on a secondary DSS, either one of them may be improperly pooled and in violation of astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:55.257329Z)
✅ uss1_dss (2026-03-03T21:57:55.259502Z)
✅ uss1_dss (2026-03-03T21:57:55.262324Z)
✅ uss2_dss (2026-03-03T21:57:55.271508Z)
✅ uss2_dss (2026-03-03T21:57:55.273565Z)
✅ uss2_dss (2026-03-03T21:57:55.275587Z)
This test case verifies that after a subscription is deleted from a DSS instance, it cannot be retrieved from any other DSS instance.
This test step will create a new subscription at every DSS, in sequence.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
Check that the subscription creation succeeds.
✅ uss2_dss (2026-03-03T21:57:55.284653Z)
✅ uss2_dss (2026-03-03T21:57:55.293469Z)
✅ uss2_dss (2026-03-03T21:57:55.302567Z)
This test step will delete the freshly created subscription at every DSS, in sequence. It then verifies that the subscription has been deleted from all DSS instances.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to remove a subscription succeeds.
An attempt to delete a subscription when the correct version is provided should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
Check that the subscription deletion succeeds.
✅ uss2_dss (2026-03-03T21:57:55.310150Z)
✅ uss1_dss (2026-03-03T21:57:55.320493Z)
✅ uss2_dss (2026-03-03T21:57:55.332437Z)
This test step fragment validates that a query to read a subscription succeeds.
If a subscription cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
Check that the subscription retrieval from all DSS instance succeeds. It is expected to be not found, but that is validated in the check below.
✅ uss2_dss (2026-03-03T21:57:55.312264Z)
✅ uss1_dss (2026-03-03T21:57:55.314344Z)
✅ uss2_dss (2026-03-03T21:57:55.322730Z)
✅ uss2_dss (2026-03-03T21:57:55.324833Z)
✅ uss2_dss (2026-03-03T21:57:55.334653Z)
✅ uss1_dss (2026-03-03T21:57:55.336816Z)
The subscription deleted on a DSS instance must have been removed from all other DSS instances.
If the subscription still exists on one of the other DSS instances, one of the instances fails to comply with astm.f3548.v21.DSS0210,A2-7-2,5a.
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.312323Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.314384Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:55.322770Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:57:55.324874Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.334695Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.336856Z)
This test case verifies that after a subscription is deleted, newly created or modified OIRs will not receive the relevant subscriptions to notify from the DSS instance, regardless of which instance was used to create or modify the entity.
This test step will create an operational intent reference at every DSS, in sequence, each time verifying that the DSS does not require notification for any previously deleted subscription that intersects with the newly created OIR.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
Check that the OIR creation query succeeds.
✅ uss2_dss (2026-03-03T21:57:55.357666Z)
✅ uss1_dss (2026-03-03T21:57:55.385367Z)
✅ uss2_dss (2026-03-03T21:57:55.408572Z)
The response from a DSS to a valid OIR creation request is expected to contain any relevant subscription for the OIR's extents. This does not include subscriptions deleted earlier.
If the DSS includes a deleted subscription, it fails to implement astm.f3548.v21.DSS0210,A2-7-2,5b.
✅ uss2_dss (2026-03-03T21:57:55.357745Z)
✅ uss1_dss (2026-03-03T21:57:55.385440Z)
✅ uss2_dss (2026-03-03T21:57:55.408632Z)
This test step will modify an operational intent reference at every DSS, in sequence, each time verifying that the DSS does not require notification for any previously deleted subscription that intersects with the modified OIR.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
Check that the OIR modification query succeeds.
✅ uss2_dss (2026-03-03T21:57:55.430353Z)
✅ uss1_dss (2026-03-03T21:57:55.451140Z)
✅ uss2_dss (2026-03-03T21:57:55.473423Z)
The response from a DSS to a valid OIR modification request is expected to contain any relevant subscription for the OIR's extents. This does not include subscriptions deleted earlier.
If the DSS includes a deleted subscription, it fails to implement astm.f3548.v21.DSS0210,A2-7-2,5c.
✅ uss2_dss (2026-03-03T21:57:55.430409Z)
✅ uss1_dss (2026-03-03T21:57:55.451195Z)
✅ uss2_dss (2026-03-03T21:57:55.473480Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:55.532279Z)
✅ uss2_dss (2026-03-03T21:57:55.535871Z)
✅ uss2_dss (2026-03-03T21:57:55.539389Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:57:55.528754Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:55.496617Z)
✅ uss2_dss (2026-03-03T21:57:55.513235Z)
✅ uss2_dss (2026-03-03T21:57:55.528722Z)
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss2_dss (2026-03-03T21:57:55.544137Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:57:55.547267Z)
✅ uss2_dss (2026-03-03T21:57:55.550633Z)
✅ uss2_dss (2026-03-03T21:57:55.553266Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created. ∅ This check was not applicable to this test run and is therefore not statused.
Create and mutate subscriptions as well as entities, and verify that the DSS handles notifications and expiry correctly.
DSSInstanceResource to be tested in this scenario.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
DSSInstancesResource pointing to the DSS instances used to confirm that entities are properly propagated.
✅ Provided by dss_instances in top-level resource pool.
IDGeneratorResource providing the Subscription IDs for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which subscriptions will be created.
✅ Provided by planning_area in top-level resource pool.
ClientIdentityResource provides the identity that will be used to interact with the DSS.
✅ Provided by utm_client_identity in top-level resource pool.
Ensure that no subscriptions and OIRs with the known test IDs exists in the DSS deployment.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:57:55.563571Z)
✅ uss2_dss (2026-03-03T21:57:55.566031Z)
✅ uss2_dss (2026-03-03T21:57:55.569305Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:57:55.560485Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss2_dss (2026-03-03T21:57:55.572238Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:57:55.574354Z)
✅ uss2_dss (2026-03-03T21:57:55.576331Z)
✅ uss2_dss (2026-03-03T21:57:55.578373Z)
✅ uss2_dss (2026-03-03T21:57:55.580404Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
This test step queries all secondary instances to confirm that none of the test IDs that are used in the scenario exist.
Ensures that a secondary DSS is ready to be used for testing by confirming that no OIR bearing an ID used for testing exists on it.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:57:55.592288Z)
✅ uss1_dss (2026-03-03T21:57:55.594527Z)
✅ uss1_dss (2026-03-03T21:57:55.596598Z)
✅ uss2_dss (2026-03-03T21:57:55.605281Z)
✅ uss2_dss (2026-03-03T21:57:55.608109Z)
✅ uss2_dss (2026-03-03T21:57:55.610274Z)
If an OIR that was deleted from the primary DSS can still be found on a secondary DSS, either one of them may be improperly pooled and in violation of astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:55.592348Z)
✅ uss1_dss (2026-03-03T21:57:55.594567Z)
✅ uss1_dss (2026-03-03T21:57:55.596638Z)
✅ uss2_dss (2026-03-03T21:57:55.605321Z)
✅ uss2_dss (2026-03-03T21:57:55.608154Z)
✅ uss2_dss (2026-03-03T21:57:55.610314Z)
Ensures that a secondary DSS is ready to be used for testing by confirming that no Subscription bearing an ID used for testing exists on it.
If an existing subscription cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:57:55.598622Z)
✅ uss1_dss (2026-03-03T21:57:55.600603Z)
✅ uss1_dss (2026-03-03T21:57:55.602707Z)
✅ uss2_dss (2026-03-03T21:57:55.612289Z)
✅ uss2_dss (2026-03-03T21:57:55.614384Z)
✅ uss2_dss (2026-03-03T21:57:55.616530Z)
If a Subscription that was deleted from the primary DSS can still be found on a secondary DSS, either one of them may be improperly pooled and in violation of astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:57:55.598658Z)
✅ uss1_dss (2026-03-03T21:57:55.600638Z)
✅ uss1_dss (2026-03-03T21:57:55.602742Z)
✅ uss2_dss (2026-03-03T21:57:55.612324Z)
✅ uss2_dss (2026-03-03T21:57:55.614421Z)
✅ uss2_dss (2026-03-03T21:57:55.616565Z)
∅ This check was not applicable to this test run and is therefore not statused.
∅ This check was not applicable to this test run and is therefore not statused.
This test case verifies that newly created or modified OIRs will receive the relevant subscriptions to notify from the DSS instance, regardless of which instance was used to create the entity.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
Sets up the subscription that cover the planning area from 'now' to 20 minutes in the future, and which will be used as part of the interaction tests.
✅ uss2_dss (2026-03-03T21:57:55.625669Z)
This test step will create an operational intent reference and assorted subscription at every DSS, in sequence, each time verifying that the DSS requires notifications for any previously established subscription that intersects with the newly created OIR.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
Check that the OIR creation query succeeds
✅ uss2_dss (2026-03-03T21:57:55.648492Z)
✅ uss1_dss (2026-03-03T21:57:55.669818Z)
✅ uss2_dss (2026-03-03T21:57:55.690827Z)
The response from a DSS to a valid OIR creation request is expected to contain any relevant subscription for the OIR's extents. This includes the subscription created earlier, as it is designed to intersect with the OIRs being created.
If the DSS omits the intersecting subscription, it fails to implement astm.f3548.v21.DSS0210,A2-7-2,4b.
✅ uss2_dss (2026-03-03T21:57:55.648555Z)
✅ uss1_dss (2026-03-03T21:57:55.669877Z)
✅ uss2_dss (2026-03-03T21:57:55.690887Z)
The response from a DSS to a valid OIR creation request is expected to contain any relevant subscription for the OIR's extents. This includes any implicit subscription previously created on the DSS as part of a previously created OIR.
If the DSS omits any of the implicit subscriptions belonging to an OIR previously created on another DSS (which are designed to all intersect), any of the DSSes at which an earlier OIR was created, or the DSS at which the current OIR has been created, are in violation of astm.f3548.v21.DSS0210,A2-7-2,4b.
✅ uss2_dss, uss1_dss, uss2_dss (2026-03-03T21:57:55.648590Z)
✅ uss2_dss, uss1_dss, uss2_dss (2026-03-03T21:57:55.669913Z)
✅ uss2_dss, uss1_dss, uss2_dss (2026-03-03T21:57:55.690924Z)
This test step will modify the previously created operational intent reference and assorted subscription at every DSS, in sequence, each time verifying that the DSS requires notifications for any previously established subscription that intersects with the modified OIR.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
Check that the OIR modification query succeeds
✅ uss2_dss (2026-03-03T21:57:55.712547Z)
✅ uss1_dss (2026-03-03T21:57:55.733877Z)
✅ uss2_dss (2026-03-03T21:57:55.754693Z)
The response from a DSS to a valid OIR modification request is expected to contain any relevant subscription for the OIR's extents. This includes the subscription created earlier, as it is designed to intersect with the OIRs being modified.
If the DSS omits the intersecting subscription, it fails to implement astm.f3548.v21.DSS0210,A2-7-2,4c.
✅ uss2_dss (2026-03-03T21:57:55.712604Z)
✅ uss1_dss (2026-03-03T21:57:55.733933Z)
✅ uss2_dss (2026-03-03T21:57:55.754749Z)
The response from a DSS to a valid OIR modification request is expected to contain any relevant subscription for the OIR's extents. This includes any implicit subscription previously created on the DSS as part of a previously created OIR.
If the DSS omits any of the implicit subscriptions belonging to an OIR previously created over time range A on another DSS (which are designed to all intersect), any of the DSSes at which an earlier OIR was created, or the DSS at which the current OIR has been modified, are in violation of astm.f3548.v21.DSS0210,A2-7-2,4c.
✅ uss2_dss, uss1_dss, uss2_dss (2026-03-03T21:57:55.712642Z)
✅ uss2_dss, uss1_dss, uss2_dss (2026-03-03T21:57:55.733972Z)
✅ uss2_dss, uss1_dss, uss2_dss (2026-03-03T21:57:55.754788Z)
This test case checks that, when a newly created subscription intersects with an existing OIR and that the subscription is intended for operational intent references, the DSS includes the relevant OIRs in the response to the creation.
This test step will create a new subscription at every DSS, in sequence, each time verifying that the DSS returns any OIRs that intersect with the newly created subscription.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
Check that the subscription creation succeeds.
✅ uss2_dss (2026-03-03T21:57:55.765231Z)
The response from a DSS to a valid subscription creation request is expected to contain any relevant OIRs for the subscription's extents if the subscription had the notify_for_op_intents flag set to true.
If the DSS omits the intersecting OIR, it fails to comply with astm.f3548.v21.DSS0210,A2-7-2,4a.
✅ uss2_dss (2026-03-03T21:57:55.765281Z)
This test step fragment validates that a query to read a subscription succeeds.
If a subscription cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:57:55.768938Z)
✅ uss2_dss (2026-03-03T21:57:55.772906Z)
The subscription created on a DSS instance must be retrievable from all other DSS instances.
If the subscription does not exist on one of the other DSS instances, one of the instances fails to comply with astm.f3548.v21.DSS0210,A2-7-2,4a.
✅ uss2_dss, uss1_dss (2026-03-03T21:57:55.769027Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:57:55.772949Z)
This test case validates that expired subscriptions (created explicitly) are removed from all DSS instances. To validate this requirement, the subscriptions that were previously created at each DSS instance are modified so that they expire shortly after the modification. Then it is checked that all the associated subscriptions were removed from all the DSS instances by searching for them in their planning area. Do note that they are not queried directly, as it is deemed acceptable for expired subscription that were not explicitly deleted to still be retrievable.
This test step will modify explicit subscriptions that were previously created at each DSS instance so that they expire shortly after the modification.
Note that this step is run once for each involved DSS (that is, once for the primary DSS and once for every secondary DSS)
This test step fragment validates that a query to update a subscription succeeds.
If a subscription cannot be updated with a valid set of parameters, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
Check that the subscription modifications succeed and wait for them to expire.
✅ uss2_dss (2026-03-03T21:57:55.819969Z)
✅ uss1_dss (2026-03-03T21:57:55.829285Z)
✅ uss2_dss (2026-03-03T21:57:55.838359Z)
This test step fragment validates that a query to search for subscriptions succeeds.
If the DSS fails to let us search in the area for which the subscription was created, it is failing to meet astm.f3548.v21.DSS0005,5.
Check that query succeeds.
✅ uss2_dss (2026-03-03T21:58:02.853475Z)
✅ uss2_dss (2026-03-03T21:58:02.868858Z)
✅ uss1_dss (2026-03-03T21:58:02.881271Z)
✅ uss1_dss (2026-03-03T21:58:02.893636Z)
✅ uss2_dss (2026-03-03T21:58:02.906078Z)
✅ uss2_dss (2026-03-03T21:58:02.918038Z)
The explicit subscription expired on a DSS instance must have been removed from all other DSS instances.
If the subscription still exists on one of the other DSS instances, one of the instances fails to comply with astm.f3548.v21.DSS0210,A2-7-2,4d.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:02.858665Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:58:02.871940Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:58:02.884260Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:58:02.896636Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:58:02.908963Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:58:02.920932Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:02.995122Z)
✅ uss2_dss (2026-03-03T21:58:02.997156Z)
✅ uss2_dss (2026-03-03T21:58:02.999656Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:58:02.992820Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:02.949609Z)
✅ uss2_dss (2026-03-03T21:58:02.968025Z)
✅ uss2_dss (2026-03-03T21:58:02.992791Z)
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss2_dss (2026-03-03T21:58:03.002951Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:58:03.007444Z)
✅ uss2_dss (2026-03-03T21:58:03.015816Z)
✅ uss2_dss (2026-03-03T21:58:03.019519Z)
✅ uss2_dss (2026-03-03T21:58:03.029313Z)
✅ uss2_dss (2026-03-03T21:58:03.039174Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
✅ uss2_dss (2026-03-03T21:58:03.013686Z)
✅ uss2_dss (2026-03-03T21:58:03.025546Z)
✅ uss2_dss (2026-03-03T21:58:03.035317Z)
✅ uss2_dss (2026-03-03T21:58:03.045523Z)
Verifies that a DSS requires from a client creating or updating operational intent references that they provide all OVNs for all currently relevant entities.
DSSInstanceResource the DSS instance through which entities are created, modified and deleted.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
IDGeneratorResource providing the base entity ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
ClientIdentityResource the client identity that will be used to create and update operational intent references.
✅ Provided by utm_client_identity in top-level resource pool.
PlanningAreaResource describes the 3D volume in which operational intent references will be created.
✅ Provided by planning_area in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.053967Z)
✅ uss2_dss (2026-03-03T21:58:03.056077Z)
✅ uss2_dss (2026-03-03T21:58:03.058150Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:58:03.051841Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
This step ensures that no operational intent references with the known test IDs exists in the DSS.
∅ This check was not applicable to this test run and is therefore not statused.
This test case will create multiple operational intent references and verify that the key field
of the parameters to create or update an operational intent reference is properly validated.
That is: the DSS should require that the client provides the OVNs for each entity that is in the vicinity, both geographically and temporally, of the client's operational intent reference.
This step creates one operational intent references. As no other operational intent reference is present,
the key field may remain empty.
With no potentially conflicting entity present, the DSS is expected to allow the creation of an operational intent without
the client specifying any OVN in the key field.
If the DSS rejects a well-formed request to create the operational intent reference, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.076967Z)
This step creates a second operational intent references that does not overlap in time with the first, and
should therefore not require any entry in the key field.
With a single existing OIR in the area that is not overlapping in time, the DSS is expected to allow the creation of an operational intent without
the client specifying any OVN in the key field.
If the DSS rejects a well-formed request to create the operational intent reference, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.099228Z)
This test step will attempt to create an operational intent reference that intersects with the first of the previously created OIR,
and expect the DSS to require its OVN to be provided in the key field.
This step will validate the response body for the HTTP 409 error response from the DSS when it contains the optional missing_operational_intents field.
This test step fragment validates that requests for operational intent reference creation that don't show that they have been de-conflicted are rejected with the proper error.
If the DSS allows the creation of an operational intent reference that is missing the required OVNs for other entities that exist in its geo-temporal vicinity, it is in violation of astm.f3548.v21.DSS0005,1 and astm.f3548.v21.DSS0210,A2-7-2,2a
✅ uss2_dss (2026-03-03T21:58:03.111293Z)
The DSS is expected to return a HTTP 409 error response when the creation of an operational intent reference fails due to a conflict.
This response is expected to conform to the OpenAPI spec that is part of astm.f3548.v21.DSS0005,1.
Should this not be the case, then the DSS is in violation of the aforementioned requirement.
✅ uss2_dss (2026-03-03T21:58:03.120715Z)
If the DSS returns a HTTP 409 error response due to a conflict, and the response body contains a missing_operational_intents field,
this field is expected to contain the conflicting OVNs.
If the field exists but does not contain the conflicting OVNs, then the DSS is in violation of astm.f3548.v21.DSS0005,1.
Checks that an attempt to create an OIR without specifying the OVN of the already existing and overlapping OIR fails.
✅ uss2_dss (2026-03-03T21:58:03.121358Z)
This test step will attempt to create an operational intent reference that intersects with the second of the previously created OIR,
and expect the DSS to require its OVN to be provided in the key field.
This step will validate the response body for the HTTP 409 error response from the DSS when it contains the optional missing_operational_intents field.
This test step fragment validates that requests for operational intent reference creation that don't show that they have been de-conflicted are rejected with the proper error.
If the DSS allows the creation of an operational intent reference that is missing the required OVNs for other entities that exist in its geo-temporal vicinity, it is in violation of astm.f3548.v21.DSS0005,1 and astm.f3548.v21.DSS0210,A2-7-2,2a
✅ uss2_dss (2026-03-03T21:58:03.136766Z)
The DSS is expected to return a HTTP 409 error response when the creation of an operational intent reference fails due to a conflict.
This response is expected to conform to the OpenAPI spec that is part of astm.f3548.v21.DSS0005,1.
Should this not be the case, then the DSS is in violation of the aforementioned requirement.
✅ uss2_dss (2026-03-03T21:58:03.143804Z)
If the DSS returns a HTTP 409 error response due to a conflict, and the response body contains a missing_operational_intents field,
this field is expected to contain the conflicting OVNs.
If the field exists but does not contain the conflicting OVNs, then the DSS is in violation of astm.f3548.v21.DSS0005,1.
Checks that an attempt to create an OIR without specifying the OVN of the already existing and overlapping OIR fails.
✅ uss2_dss (2026-03-03T21:58:03.144410Z)
This test step will attempt to create an operational intent reference that intersects with both of the previously created OIRs,
and expect the DSS to require their OVNs to be provided in the key field.
This step will validate the response body for the HTTP 409 error response from the DSS when it contains the optional missing_operational_intents field.
This test step fragment validates that requests for operational intent reference creation that don't show that they have been de-conflicted are rejected with the proper error.
If the DSS allows the creation of an operational intent reference that is missing the required OVNs for other entities that exist in its geo-temporal vicinity, it is in violation of astm.f3548.v21.DSS0005,1 and astm.f3548.v21.DSS0210,A2-7-2,2a
✅ uss2_dss (2026-03-03T21:58:03.160665Z)
The DSS is expected to return a HTTP 409 error response when the creation of an operational intent reference fails due to a conflict.
This response is expected to conform to the OpenAPI spec that is part of astm.f3548.v21.DSS0005,1.
Should this not be the case, then the DSS is in violation of the aforementioned requirement.
✅ uss2_dss (2026-03-03T21:58:03.170029Z)
If the DSS returns a HTTP 409 error response due to a conflict, and the response body contains a missing_operational_intents field,
this field is expected to contain the conflicting OVNs.
If the field exists but does not contain the conflicting OVNs, then the DSS is in violation of astm.f3548.v21.DSS0005,1.
Checks that an attempt to create an OIR without specifying the OVNs of the already existing and overlapping OIRs fails.
✅ uss2_dss (2026-03-03T21:58:03.170951Z)
This test step will attempt to create an operational intent reference that intersects with both of the previously created OIRs,
while providing the required OVNs in the key field.
After this test step succeeds, three OIRs are expected to exist in the DSS, with one intersecting with the two others.
If the DSS prevents the creation of an operational intent reference that is providing all required OVNs for other entities that exist in its geo-temporal vicinity, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.190760Z)
This test case will update multiple operational intent references and verify that the key field
of the parameters to create or update an operational intent reference is properly validated.
That is: the DSS should require that the client provides the OVNs for each entity that is in the vicinity, both geographically and temporally, of the client's operational intent reference.
This test step will attempt to mutate the third previously created operational intent reference so that it keeps overlapping with the others,
while omitting their OVNs in the key field.
The expectation is that the DSS will require the two missing OVNs.
This test step fragment validates that requests for operational intent references updates that don't show that they have been de-conflicted are rejected with the proper error.
If the DSS allows the mutation of an operational intent reference that is missing the required OVNs for other entities that exist in its geo-temporal vicinity, it is in violation of astm.f3548.v21.DSS0005,1 and astm.f3548.v21.DSS0210,A2-7-2,2b
✅ uss2_dss (2026-03-03T21:58:03.207254Z)
The DSS is expected to return a HTTP 409 error response when the creation of an operational intent reference fails due to a conflict.
This response is expected to conform to the OpenAPI spec that is part of astm.f3548.v21.DSS0005,1.
Should this not be the case, then the DSS is in violation of the aforementioned requirement.
✅ uss2_dss (2026-03-03T21:58:03.214202Z)
If the DSS returns a HTTP 409 error response due to a conflict, and the response body contains a missing_operational_intents field,
this field is expected to contain the conflicting OVNs.
If the field exists but does not contain the conflicting OVNs, then the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.215122Z)
This test step will attempt to mutate the third previously created operational intent reference so that it keeps overlapping with the others,
while omitting the first OVN in the key field.
The expectation is that the DSS will require the missing OVN.
This test step fragment validates that requests for operational intent references updates that don't show that they have been de-conflicted are rejected with the proper error.
If the DSS allows the mutation of an operational intent reference that is missing the required OVNs for other entities that exist in its geo-temporal vicinity, it is in violation of astm.f3548.v21.DSS0005,1 and astm.f3548.v21.DSS0210,A2-7-2,2b
✅ uss2_dss (2026-03-03T21:58:03.228392Z)
The DSS is expected to return a HTTP 409 error response when the creation of an operational intent reference fails due to a conflict.
This response is expected to conform to the OpenAPI spec that is part of astm.f3548.v21.DSS0005,1.
Should this not be the case, then the DSS is in violation of the aforementioned requirement.
✅ uss2_dss (2026-03-03T21:58:03.235622Z)
If the DSS returns a HTTP 409 error response due to a conflict, and the response body contains a missing_operational_intents field,
this field is expected to contain the conflicting OVNs.
If the field exists but does not contain the conflicting OVNs, then the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.236236Z)
This test step will attempt to mutate the third previously created operational intent reference so that it overlaps with the first one,
while omitting the first OVN in the key field.
The expectation is that the DSS will require the missing OVN.
This test step fragment validates that requests for operational intent references updates that don't show that they have been de-conflicted are rejected with the proper error.
If the DSS allows the mutation of an operational intent reference that is missing the required OVNs for other entities that exist in its geo-temporal vicinity, it is in violation of astm.f3548.v21.DSS0005,1 and astm.f3548.v21.DSS0210,A2-7-2,2b
✅ uss2_dss (2026-03-03T21:58:03.249972Z)
The DSS is expected to return a HTTP 409 error response when the creation of an operational intent reference fails due to a conflict.
This response is expected to conform to the OpenAPI spec that is part of astm.f3548.v21.DSS0005,1.
Should this not be the case, then the DSS is in violation of the aforementioned requirement.
✅ uss2_dss (2026-03-03T21:58:03.257132Z)
If the DSS returns a HTTP 409 error response due to a conflict, and the response body contains a missing_operational_intents field,
this field is expected to contain the conflicting OVNs.
If the field exists but does not contain the conflicting OVNs, then the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.257975Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.314400Z)
✅ uss2_dss (2026-03-03T21:58:03.316469Z)
✅ uss2_dss (2026-03-03T21:58:03.318812Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:58:03.312249Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.280076Z)
✅ uss2_dss (2026-03-03T21:58:03.295357Z)
✅ uss2_dss (2026-03-03T21:58:03.312221Z)
Verifies that all CRUD operations on operational intent references performed on a given DSS instance are properly propagated to every other DSS instance participating in the deployment.
DSSInstanceResource the DSS instance through which entities are created, modified and deleted.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
DSSInstancesResource pointing to the DSS instances used to confirm that entities are properly propagated.
✅ Provided by dss_instances in top-level resource pool.
IDGeneratorResource providing the operational intent reference ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which operational intent reference will be created.
✅ Provided by planning_area in top-level resource pool.
ClientIdentityResource to be used for this scenario.
✅ Provided by utm_client_identity in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.327732Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:58:03.325647Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
Ensures that a secondary DSS is ready to be used for testing by confirming that no OIR bearing an ID used for testing exists on it.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:58:03.330311Z)
✅ uss2_dss (2026-03-03T21:58:03.332820Z)
If an OIR that was deleted from the primary DSS can still be found on a secondary DSS, either one of them may be improperly pooled and in violation of astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:58:03.330348Z)
✅ uss2_dss (2026-03-03T21:58:03.332858Z)
This test case creates an operational intent reference on the main DSS, and verifies that it is properly synchronized to the other DSS instances.
It then goes on to mutate and delete it, each time confirming that all other DSSes return the expected results.
This test step fragment validates that:
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:58:03.351475Z)
This test step fragment validates that an operational intent references creation returns a body in the correct format.
The response to a successful operational intent reference creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.363985Z)
A successful operational intent reference creation query is expected to return a body, the content of which reflects the created operational intent reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:58:03.364937Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.364620Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.364663Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.364697Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.364924Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.364728Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.364758Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.364786Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.364842Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.364813Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.364871Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.364897Z)
Retrieve and validate synchronization of the created operational intent at every DSS provided in dss_instances.
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:58:03.368408Z)
✅ uss2_dss (2026-03-03T21:58:03.372294Z)
If the operational intent retrieved from a secondary DSS instance is not consistent with the newly created one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1a, astm.f3548.v21.DSS0210,A2-7-2,1d, , astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.369095Z)
✅ uss2_dss (2026-03-03T21:58:03.372965Z)
This test step fragment validates that operational intent references are properly synchronized across a set of DSS instances by querying an operational intent reference that is known to exist at each one of the DSS instances.
If the previously created or mutated operational intent reference cannot be found at a DSS, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.368456Z)
✅ uss2_dss (2026-03-03T21:58:03.372340Z)
This test step fragment validates that operational intent reference attributes are properly synchronized across a set of DSS instances.
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct manager, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.368503Z)
✅ uss2_dss (2026-03-03T21:58:03.372385Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.368532Z)
✅ uss2_dss (2026-03-03T21:58:03.372414Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct state, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.368558Z)
✅ uss2_dss (2026-03-03T21:58:03.372441Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct start time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.369047Z)
✅ uss2_dss (2026-03-03T21:58:03.372920Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct end time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.369081Z)
✅ uss2_dss (2026-03-03T21:58:03.372952Z)
Search for and validate synchronization of the created operational intent at every DSS provided in dss_instances.
This test step fragment validates that a query to search for operational intent references with valid parameters succeeds.
If the DSS fails to let us search in the area for which the OIR was created, it is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:58:03.378540Z)
✅ uss2_dss (2026-03-03T21:58:03.384555Z)
If the operational intent searched from a secondary DSS instance is not consistent with the newly created one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1a, astm.f3548.v21.DSS0210,A2-7-2,1c, , astm.f3548.v21.DSS0215 and astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.379219Z)
✅ uss2_dss (2026-03-03T21:58:03.385227Z)
This test step fragment validates that operational intent references are properly synchronized across a set of DSS instances by searching for an operational intent reference that is known to exist in a specific area at each one of the DSS instances.
When querying a secondary DSS for operational intents in the planning area that contains the propagated operational intent, if the propagated operational intent is not contained in the response, then the general area in which the propagated operational intent is located is not synchronized across DSS instances. As such, either the primary or the secondary DSS fails to properly implement one of the following requirements:
astm.f3548.v21.DSS0210,2e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.378585Z)
✅ uss2_dss (2026-03-03T21:58:03.384600Z)
This test step fragment validates that operational intent reference attributes are properly synchronized across a set of DSS instances.
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct manager, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.378628Z)
✅ uss2_dss (2026-03-03T21:58:03.384644Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.378657Z)
✅ uss2_dss (2026-03-03T21:58:03.384673Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct state, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.378684Z)
✅ uss2_dss (2026-03-03T21:58:03.384700Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct start time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.379172Z)
✅ uss2_dss (2026-03-03T21:58:03.385180Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct end time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.379205Z)
✅ uss2_dss (2026-03-03T21:58:03.385214Z)
This test step mutates the previously created operational intent reference to verify that the DSS reacts properly: notably, it checks that the operational intent reference version is updated, including for changes that are not directly visible, such as changing the operational intent reference's footprint.
This test step fragment validates that operational intent references can be updated.
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference.
✅ uss2_dss (2026-03-03T21:58:03.407105Z)
This test step fragment validates that updates to operational intent references return a body in the correct format.
The response to a successful operational intent reference mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.415156Z)
A successful operational intent reference mutation query is expected to return a well-defined body, the content of which reflects the updated operational intent reference. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:58:03.416196Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.415786Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.415831Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.415864Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.416182Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.415895Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.415927Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.415956Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.416034Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.415983Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.416068Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.416127Z)
This test step fragment attempts to validate a single operational intent reference returned by the DSS, usually after it has been mutated.
The code for these checks lives in the oir_validator.py class.
Following a mutation, the DSS needs to update the operational intent reference version, otherwise it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.416154Z)
Following a mutation, the DSS needs to update the operational intent reference OVN, otherwise it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.416098Z)
Retrieve and validate synchronization of the updated operational intent at every DSS provided in dss_instances.
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:58:03.419606Z)
✅ uss2_dss (2026-03-03T21:58:03.423492Z)
If the operational intent retrieved from a secondary DSS instance is not consistent with the updated one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1b and astm.f3548.v21.DSS0210,A2-7-2,1d.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.420299Z)
✅ uss2_dss (2026-03-03T21:58:03.424182Z)
This test step fragment validates that operational intent references are properly synchronized across a set of DSS instances by querying an operational intent reference that is known to exist at each one of the DSS instances.
If the previously created or mutated operational intent reference cannot be found at a DSS, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.419656Z)
✅ uss2_dss (2026-03-03T21:58:03.423538Z)
This test step fragment validates that operational intent reference attributes are properly synchronized across a set of DSS instances.
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct manager, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.419700Z)
✅ uss2_dss (2026-03-03T21:58:03.423585Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.419729Z)
✅ uss2_dss (2026-03-03T21:58:03.423615Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct state, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.419755Z)
✅ uss2_dss (2026-03-03T21:58:03.423641Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct start time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.420253Z)
✅ uss2_dss (2026-03-03T21:58:03.424136Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct end time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.420285Z)
✅ uss2_dss (2026-03-03T21:58:03.424169Z)
Search for and validate synchronization of the updated operational intent at every DSS provided in dss_instances.
This test step fragment validates that a query to search for operational intent references with valid parameters succeeds.
If the DSS fails to let us search in the area for which the OIR was created, it is failing to meet astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:58:03.430298Z)
✅ uss2_dss (2026-03-03T21:58:03.436746Z)
If the operational intent searched from a secondary DSS instance is not consistent with the updated one on the primary DSS instance, this check will fail per astm.f3548.v21.DSS0210,A2-7-2,1b and astm.f3548.v21.DSS0210,A2-7-2,1c.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.430969Z)
✅ uss2_dss (2026-03-03T21:58:03.437478Z)
This test step fragment validates that operational intent references are properly synchronized across a set of DSS instances by searching for an operational intent reference that is known to exist in a specific area at each one of the DSS instances.
When querying a secondary DSS for operational intents in the planning area that contains the propagated operational intent, if the propagated operational intent is not contained in the response, then the general area in which the propagated operational intent is located is not synchronized across DSS instances. As such, either the primary or the secondary DSS fails to properly implement one of the following requirements:
astm.f3548.v21.DSS0210,2e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.430347Z)
✅ uss2_dss (2026-03-03T21:58:03.436794Z)
This test step fragment validates that operational intent reference attributes are properly synchronized across a set of DSS instances.
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct manager, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2b, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.430393Z)
✅ uss2_dss (2026-03-03T21:58:03.436841Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct USS base URL, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.430424Z)
✅ uss2_dss (2026-03-03T21:58:03.436872Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct state, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.430452Z)
✅ uss2_dss (2026-03-03T21:58:03.436901Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct start time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.430923Z)
✅ uss2_dss (2026-03-03T21:58:03.437424Z)
If the operational intent reference returned by a DSS to which the operational intent reference was synchronized to does not contain the correct end time, either one of the instances at which the operational intent reference was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,2f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.430955Z)
✅ uss2_dss (2026-03-03T21:58:03.437458Z)
This test step fragment validates that deleting an operational intent reference succeeds and returns the expected deleted operational intent reference.
This test step fragment validates that an operational intent reference was deleted successfully
A query to delete an operational intent reference, by its owner and when the correct OVN is provided, should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.454114Z)
The response to a successful operational intent reference deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.462513Z)
A successful operational intent reference deletion query is expected to return a body, the content of which reflects the operational intent reference at the moment of deletion. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss (2026-03-03T21:58:03.463607Z)
This test step fragment attempts to validate the content of a single operational intent reference returned by the DSS.
Fields that require different handling based on if the operational intent reference was mutated or not are covered
The code for these checks lives in the oir_validator.py class.
If the returned operational intent reference ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.463213Z)
If the returned operational intent reference has no manager defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.463258Z)
The returned manager must correspond to the identity of the client that created the operational intent at the DSS, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.463292Z)
The returned state must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.463593Z)
If the returned operational intent reference has no USS base URL defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.463325Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at operational intent reference creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.463364Z)
If the returned operational intent reference has no start time defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.463395Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.463454Z)
Operational intent references need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.463424Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.463483Z)
If the returned operational intent reference has no version defined, astm.f3548.v21.DSS0005,1 is not respected.
✅ uss2_dss (2026-03-03T21:58:03.463539Z)
This test step fragment attempts to validate a single operational intent reference returned by the DSS, usually after it has been created or to confirm it has not been mutated by an action.
The code for these checks lives in the oir_validator.py class.
If the version of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.463566Z)
If the OVN of the operational intent reference is updated without there having been any mutation of the operational intent reference, the DSS is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.463511Z)
Attempt to query and search for the deleted operational intent reference in various ways
This test step fragment validates that a query to retrieve an operational intent reference with valid parameters succeeds.
If an operational intent reference cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,1.
Check that read query succeeds.
✅ uss1_dss (2026-03-03T21:58:03.465910Z)
✅ uss2_dss (2026-03-03T21:58:03.472249Z)
If a DSS returns an operational intent reference that was previously successfully deleted from the primary DSS, either one of the primary DSS or the DSS that returned the operational intent reference is in violation of astm.f3548.v21.DSS0210,2a and astm.f3548.v21.DSS0210,A2-7-2,3b.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.465952Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:58:03.472290Z)
This test step fragment validates that a query to search for operational intent references with valid parameters succeeds.
If the DSS fails to let us search in the area for which the OIR was created, it is failing to meet astm.f3548.v21.DSS0005,1.
Check that search query succeeds.
✅ uss1_dss (2026-03-03T21:58:03.470150Z)
✅ uss2_dss (2026-03-03T21:58:03.476160Z)
If a DSS returns an operational intent reference that was previously successfully deleted from the primary DSS, either one of the primary DSS or the DSS that returned the operational intent reference is in violation of astm.f3548.v21.DSS0210,2a and astm.f3548.v21.DSS0210,A2-7-2,3a.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:03.470193Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:58:03.476200Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.482703Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:58:03.480650Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1. ∅ This check was not applicable to this test run and is therefore not statused.
Ensures that a DSS properly authenticates requests to all its endpoints.
Note that this does not cover authorization.
DSSInstanceResource to be tested in this scenario.
Note that to benefit from the maximum coverage, the DSS' AuthAdapterResource must be able to obtain credentials for multiple scopes (so that a wrong scope may be used in place of the correct one) as well as an empty scope (that is, provide credentials where the scope is an empty string).
This scenario will check for the scope's availability and transparently ignore checks that can't be conducted.
At least one of the following scopes needs to be available for this scenario to at least partially run:
utm.strategic_coordinationutm.availability_arbitrationutm.constraint_managementIn order to verify each endpoint group, all scopes above must be available.
Optional scopes that will allow the scenario to provide additional coverage:
"" (empty string)✅ Provided by instance 2 in dss_instances in top-level resource pool.
IDGeneratorResource providing the Subscription ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which entities will be created.
✅ Provided by planning_area in top-level resource pool.
To perform this scenario, the area must be clear of test entities with the IDs we intend to use.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.486097Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
∅ This check was not applicable to this test run and is therefore not statused.
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss2_dss (2026-03-03T21:58:03.500581Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:58:03.488223Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any constraint references from the DSS that may have been left behind from testing efforts.
If an existing constraint reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:58:03.490739Z)
A client with valid credentials should be allowed to search for constraint references in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,4.
∅ This check was not applicable to this test run and is therefore not statused.
If an existing constraint cannot be deleted by its manager when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
This step ensures that the availability for the test identifier is set to Unknown.
∅ This check was not applicable to this test run and is therefore not statused.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:58:03.493445Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:58:03.497744Z)
This test case ensures that the DSS properly authenticates requests to all its endpoints.
If the DSS under test does not return a proper error message body when an unauthorized request is received, it fails to properly implement the OpenAPI specification that is part of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:03.510838Z)
✅ uss2_dss (2026-03-03T21:58:03.516407Z)
✅ uss2_dss (2026-03-03T21:58:03.526329Z)
✅ uss2_dss (2026-03-03T21:58:03.531408Z)
✅ uss2_dss (2026-03-03T21:58:03.539898Z)
✅ uss2_dss (2026-03-03T21:58:03.545291Z)
✅ uss2_dss (2026-03-03T21:58:03.555564Z)
✅ uss2_dss (2026-03-03T21:58:03.560875Z)
✅ uss2_dss (2026-03-03T21:58:03.575468Z)
✅ uss2_dss (2026-03-03T21:58:03.581646Z)
✅ uss2_dss (2026-03-03T21:58:03.588120Z)
✅ uss2_dss (2026-03-03T21:58:03.594495Z)
✅ uss2_dss (2026-03-03T21:58:03.608577Z)
✅ uss2_dss (2026-03-03T21:58:03.619305Z)
✅ uss2_dss (2026-03-03T21:58:03.629493Z)
✅ uss2_dss (2026-03-03T21:58:03.640098Z)
✅ uss2_dss (2026-03-03T21:58:03.659711Z)
✅ uss2_dss (2026-03-03T21:58:03.669561Z)
✅ uss2_dss (2026-03-03T21:58:03.679467Z)
✅ uss2_dss (2026-03-03T21:58:03.690548Z)
✅ uss2_dss (2026-03-03T21:58:03.707274Z)
✅ uss2_dss (2026-03-03T21:58:03.713940Z)
✅ uss2_dss (2026-03-03T21:58:03.722277Z)
✅ uss2_dss (2026-03-03T21:58:03.729466Z)
If the DSS under test allows the creation of a subscription without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.510870Z)
If the DSS under test allows the creation of a subscription with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.526361Z)
If the DSS under test allows the creation of a subscription with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.539930Z)
If the DSS under test allows the creation of a subscription with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.555596Z)
If the DSS does not allow the creation of a subscription when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:03.568422Z)
If the DSS under test allows the fetching of a subscription without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.570040Z)
If the DSS under test allows the fetching of a subscription with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.576617Z)
If the DSS under test allows the fetching of a subscription with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.582647Z)
If the DSS under test allows the fetching of a subscription with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.589335Z)
If the DSS does not allow fetching a subscription when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:03.597887Z)
If the DSS under test allows the mutation of a subscription without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.603373Z)
If the DSS under test allows the mutation of a subscription with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.613712Z)
If the DSS under test allows the mutation of a subscription with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.624286Z)
If the DSS under test allows the mutation of a subscription with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.634828Z)
If the DSS does not allow the mutation of a subscription when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:03.648931Z)
If the DSS under test allows the deletion of a subscription without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.653832Z)
If the DSS under test allows the deletion of a subscription with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.664402Z)
If the DSS under test allows the deletion of a subscription with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.673901Z)
If the DSS under test allows the deletion of a subscription with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.684533Z)
If the DSS does not allow the deletion of a subscription when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:03.697724Z)
✅ uss2_dss (2026-03-03T21:58:03.699949Z)
If the DSS under test allows searching for subscriptions without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.701247Z)
If the DSS under test allows searching for subscriptions with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.708707Z)
If the DSS under test allows searching for subscriptions with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.715316Z)
If the DSS under test allows searching for subscriptions with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.724059Z)
If the DSS does not allow searching for subscriptions when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:03.732608Z)
If the DSS under test does not return a proper error message body when an unauthorized request is received, it fails to properly implement the OpenAPI specification that is part of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.742076Z)
✅ uss2_dss (2026-03-03T21:58:03.750431Z)
✅ uss2_dss (2026-03-03T21:58:03.763018Z)
✅ uss2_dss (2026-03-03T21:58:03.771295Z)
✅ uss2_dss (2026-03-03T21:58:03.794957Z)
✅ uss2_dss (2026-03-03T21:58:03.802125Z)
✅ uss2_dss (2026-03-03T21:58:03.808163Z)
✅ uss2_dss (2026-03-03T21:58:03.814432Z)
✅ uss2_dss (2026-03-03T21:58:03.826885Z)
✅ uss2_dss (2026-03-03T21:58:03.836420Z)
✅ uss2_dss (2026-03-03T21:58:03.845858Z)
✅ uss2_dss (2026-03-03T21:58:03.855717Z)
✅ uss2_dss (2026-03-03T21:58:03.877882Z)
✅ uss2_dss (2026-03-03T21:58:03.884134Z)
✅ uss2_dss (2026-03-03T21:58:03.890511Z)
✅ uss2_dss (2026-03-03T21:58:03.896791Z)
✅ uss2_dss (2026-03-03T21:58:03.915356Z)
✅ uss2_dss (2026-03-03T21:58:03.922087Z)
✅ uss2_dss (2026-03-03T21:58:03.928348Z)
✅ uss2_dss (2026-03-03T21:58:03.934734Z)
If the DSS under test allows the creation of an operational intent without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.736471Z)
If the DSS under test allows the creation of an operational intent with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.745413Z)
If the DSS under test allows the creation of an operational intent with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.753698Z)
If the DSS under test allows the creation of an operational intent with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.766351Z)
If the DSS does not allow the creation of an operational intent when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.787313Z)
This test step fragment validates that an operational intent references creation returns a body in the correct format.
The response to a successful operational intent reference creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
Check response format of a creation request.
✅ uss2_dss (2026-03-03T21:58:03.787981Z)
If the DSS under test allows the fetching of an operational intent without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.788999Z)
If the DSS under test allows the fetching of an operational intent with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.796790Z)
If the DSS under test allows the fetching of an operational intent with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.803134Z)
If the DSS under test allows the fetching of an operational intent with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.809392Z)
If the DSS does not allow fetching an operational intent when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.817319Z)
If the DSS under test allows the mutation of an operational intent without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.821566Z)
If the DSS under test allows the mutation of an operational intent with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.831313Z)
If the DSS under test allows the mutation of an operational intent with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.840715Z)
If the DSS under test allows the mutation of an operational intent with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.850321Z)
If the DSS does not allow the mutation of an operational intent when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.870696Z)
This test step fragment validates that updates to operational intent references return a body in the correct format.
The response to a successful operational intent reference mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,1.
Check response format of a mutation.
✅ uss2_dss (2026-03-03T21:58:03.871304Z)
If the DSS under test allows the deletion of an operational intent without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.872420Z)
If the DSS under test allows the deletion of an operational intent with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.879184Z)
If the DSS under test allows the deletion of an operational intent with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.885221Z)
If the DSS under test allows the deletion of an operational intent with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.891780Z)
If the DSS does not allow the deletion of an operational intent when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.907985Z)
If the DSS under test allows searching for operational intents without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.909647Z)
If the DSS under test allows searching for operational intents with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.916698Z)
If the DSS under test allows searching for operational intents with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.923259Z)
If the DSS under test allows searching for operational intents with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.929704Z)
If the DSS does not allow searching for operational intents when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:03.938969Z)
If the DSS under test does not return a proper error message body when an unauthorized request is received, it fails to properly implement the OpenAPI specification that is part of astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:58:03.946965Z)
✅ uss2_dss (2026-03-03T21:58:03.954570Z)
✅ uss2_dss (2026-03-03T21:58:03.960944Z)
✅ uss2_dss (2026-03-03T21:58:03.967454Z)
✅ uss2_dss (2026-03-03T21:58:03.978288Z)
✅ uss2_dss (2026-03-03T21:58:03.986689Z)
✅ uss2_dss (2026-03-03T21:58:03.995583Z)
✅ uss2_dss (2026-03-03T21:58:04.004153Z)
If the DSS under test allows the fetching of a USS's availability without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.940992Z)
If the DSS under test allows the fetching of a USS's availability with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.949453Z)
If the DSS under test allows the fetching of a USS's availability with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.955465Z)
If the DSS under test allows the fetching of a USS's availability with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.962106Z)
If the DSS does not allow fetching a USS's availability when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:58:03.969713Z)
✅ uss2_dss (2026-03-03T21:58:03.973150Z)
✅ uss2_dss (2026-03-03T21:58:03.981655Z)
✅ uss2_dss (2026-03-03T21:58:03.990131Z)
✅ uss2_dss (2026-03-03T21:58:03.998999Z)
The response to a successful USS Availability request is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21,
otherwise, the DSS is failing to implement astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:58:03.969878Z)
If the DSS under test allows the setting of a USS's availability without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.973175Z)
If the DSS under test allows the setting of a USS's availability with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.981680Z)
If the DSS under test allows the setting of a USS's availability with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.990159Z)
If the DSS under test allows the setting of a USS's availability with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:03.999049Z)
If the DSS does not allow setting a USS's availability when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:58:04.008226Z)
The response to a successful USS Availability Set request is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21,
otherwise, the DSS is failing to implement astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:58:04.008402Z)
If the DSS under test does not return a proper error message body when an unauthorized request is received, it fails to properly implement the OpenAPI specification that is part of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:58:04.018953Z)
✅ uss2_dss (2026-03-03T21:58:04.029175Z)
✅ uss2_dss (2026-03-03T21:58:04.037633Z)
✅ uss2_dss (2026-03-03T21:58:04.046643Z)
✅ uss2_dss (2026-03-03T21:58:04.062205Z)
✅ uss2_dss (2026-03-03T21:58:04.068663Z)
✅ uss2_dss (2026-03-03T21:58:04.074648Z)
✅ uss2_dss (2026-03-03T21:58:04.084703Z)
✅ uss2_dss (2026-03-03T21:58:04.096334Z)
✅ uss2_dss (2026-03-03T21:58:04.105618Z)
✅ uss2_dss (2026-03-03T21:58:04.114964Z)
✅ uss2_dss (2026-03-03T21:58:04.124298Z)
✅ uss2_dss (2026-03-03T21:58:04.139436Z)
✅ uss2_dss (2026-03-03T21:58:04.146066Z)
✅ uss2_dss (2026-03-03T21:58:04.152134Z)
✅ uss2_dss (2026-03-03T21:58:04.158406Z)
✅ uss2_dss (2026-03-03T21:58:04.174264Z)
✅ uss2_dss (2026-03-03T21:58:04.180813Z)
✅ uss2_dss (2026-03-03T21:58:04.187184Z)
✅ uss2_dss (2026-03-03T21:58:04.193983Z)
If the DSS under test allows the creation of a constraint reference without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.013287Z)
If the DSS under test allows the creation of a constraint reference with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.023881Z)
If the DSS under test allows the creation of a constraint reference with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.032299Z)
If the DSS under test allows the creation of a constraint reference with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.041557Z)
If the DSS does not allow the creation of a constraint reference when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:58:04.055578Z)
This test step fragment validates that a constraint references creation returns a body in the correct format.
The response to a successful constraint reference creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
Check response format of a creation request.
✅ uss2_dss (2026-03-03T21:58:04.056213Z)
If the DSS under test allows the fetching of a constraint reference without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.057162Z)
If the DSS under test allows the fetching of a constraint reference with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.063390Z)
If the DSS under test allows the fetching of a constraint reference with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.069611Z)
If the DSS under test allows the fetching of a constraint reference with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.075845Z)
If the DSS does not allow fetching a constraint reference when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:58:04.086969Z)
This test step fragment validates that a request for a constraint reference returns a properly formatted body.
The response to a successful get constraint reference query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
Check response format of a mutation.
✅ uss2_dss (2026-03-03T21:58:04.087514Z)
If the DSS under test allows the mutation of a constraint reference without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.091399Z)
If the DSS under test allows the mutation of a constraint reference with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.100468Z)
If the DSS under test allows the mutation of a constraint reference with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.109460Z)
If the DSS under test allows the mutation of a constraint reference with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.119204Z)
If the DSS does not allow the mutation of a constraint reference when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:58:04.132741Z)
This test step fragment validates that updates to constraint references return a body in the correct format.
The response to a successful constraint reference mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
Check response format of a mutation.
✅ uss2_dss (2026-03-03T21:58:04.133268Z)
If the DSS under test allows the deletion of a constraint reference without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.134356Z)
If the DSS under test allows the deletion of a constraint reference with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.140670Z)
If the DSS under test allows the deletion of a constraint reference with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.147162Z)
If the DSS under test allows the deletion of a constraint reference with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.153378Z)
If the DSS does not allow the deletion of a constraint reference when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:58:04.166212Z)
This test step fragment validates that a constraint references deletion returns a body in the correct format.
The response to a successful constraint reference deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,3.
Check response format of a deletion.
✅ uss2_dss (2026-03-03T21:58:04.166838Z)
If the DSS under test allows searching for constraint references without any credentials being presented, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.168601Z)
If the DSS under test allows searching for constraint references with credentials that are well-formed but invalid, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.175627Z)
If the DSS under test allows searching for constraint references with valid credentials but a missing scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.182038Z)
If the DSS under test allows searching for constraint references with valid credentials but an incorrect scope, it is in violation of astm.f3548.v21.DSS0210,A2-7-2,7.
✅ uss2_dss (2026-03-03T21:58:04.188592Z)
If the DSS does not allow searching for constraint references when valid credentials are presented, it is in violation of astm.f3548.v21.DSS0005,4.
✅ uss2_dss (2026-03-03T21:58:04.197064Z)
This test step fragment validates that constraint references search responses are properly formatted.
The response to a successful constraint reference search query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,4.
Check response format of a search.
✅ uss2_dss (2026-03-03T21:58:04.197190Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:04.200059Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
∅ This check was not applicable to this test run and is therefore not statused.
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:58:04.202123Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
Ensure a clean workspace for testing interactions with a DSS by removing any constraint references from the DSS that may have been left behind from testing efforts.
If an existing constraint reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
✅ uss2_dss (2026-03-03T21:58:04.204136Z)
A client with valid credentials should be allowed to search for constraint references in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,4.
∅ This check was not applicable to this test run and is therefore not statused.
If an existing constraint cannot be deleted by its manager when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,3.
∅ This check was not applicable to this test run and is therefore not statused.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss2_dss (2026-03-03T21:58:04.206402Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
The cleanup phase of this test scenario removes the subscription with the known test ID if it has not been removed before.
✅ uss2_dss (2026-03-03T21:58:04.210623Z)
Perform basic operations on a single DSS instance to create, update and delete subscriptions.
DSSInstanceResource to be tested in this scenario.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
IDGeneratorResource providing the Subscription IDs for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which subscriptions will be created.
✅ Provided by planning_area in top-level resource pool.
VolumeResource describing an area designed to be too big to be accepted by the DSS as a subscription area.
✅ Provided by problematically_big_area in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss2_dss (2026-03-03T21:58:04.214826Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:58:04.216879Z)
✅ uss2_dss (2026-03-03T21:58:04.218912Z)
✅ uss2_dss (2026-03-03T21:58:04.221521Z)
✅ uss2_dss (2026-03-03T21:58:04.223636Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
This test case creates multiple subscriptions, goes on to query and search for them, then deletes and searches for them again.
This test step creates multiple subscriptions with different combinations of the optional end and start time parameters.
All subscriptions are left on the DSS when this step ends, as they are expected to be present for the subsequent step.
This test step fragment validates that subscriptions can be created.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:58:04.232633Z)
✅ uss2_dss (2026-03-03T21:58:04.250299Z)
✅ uss2_dss (2026-03-03T21:58:04.268489Z)
✅ uss2_dss (2026-03-03T21:58:04.285537Z)
The response to a successful subscription creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.240025Z)
✅ uss2_dss (2026-03-03T21:58:04.258259Z)
✅ uss2_dss (2026-03-03T21:58:04.275461Z)
✅ uss2_dss (2026-03-03T21:58:04.292890Z)
A successful subscription creation query is expected to return a well-defined body, the content of which reflects the created subscription.
If the content of the response does not correspond to the requested content, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.241396Z)
✅ uss2_dss (2026-03-03T21:58:04.259977Z)
✅ uss2_dss (2026-03-03T21:58:04.276790Z)
✅ uss2_dss (2026-03-03T21:58:04.294216Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.240596Z)
✅ uss2_dss (2026-03-03T21:58:04.259076Z)
✅ uss2_dss (2026-03-03T21:58:04.275976Z)
✅ uss2_dss (2026-03-03T21:58:04.293424Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.240641Z)
✅ uss2_dss (2026-03-03T21:58:04.259147Z)
✅ uss2_dss (2026-03-03T21:58:04.276038Z)
✅ uss2_dss (2026-03-03T21:58:04.293467Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.240677Z)
✅ uss2_dss (2026-03-03T21:58:04.259210Z)
✅ uss2_dss (2026-03-03T21:58:04.276075Z)
✅ uss2_dss (2026-03-03T21:58:04.293502Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.240708Z)
✅ uss2_dss (2026-03-03T21:58:04.259270Z)
✅ uss2_dss (2026-03-03T21:58:04.276107Z)
✅ uss2_dss (2026-03-03T21:58:04.293531Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.276167Z)
✅ uss2_dss (2026-03-03T21:58:04.293590Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.240738Z)
✅ uss2_dss (2026-03-03T21:58:04.259320Z)
✅ uss2_dss (2026-03-03T21:58:04.276136Z)
✅ uss2_dss (2026-03-03T21:58:04.293559Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.259359Z)
✅ uss2_dss (2026-03-03T21:58:04.293620Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.240768Z)
✅ uss2_dss (2026-03-03T21:58:04.259388Z)
✅ uss2_dss (2026-03-03T21:58:04.276195Z)
✅ uss2_dss (2026-03-03T21:58:04.293647Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.240796Z)
✅ uss2_dss (2026-03-03T21:58:04.259423Z)
✅ uss2_dss (2026-03-03T21:58:04.276222Z)
✅ uss2_dss (2026-03-03T21:58:04.293674Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.240823Z)
✅ uss2_dss (2026-03-03T21:58:04.259452Z)
✅ uss2_dss (2026-03-03T21:58:04.276249Z)
✅ uss2_dss (2026-03-03T21:58:04.293701Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.240850Z)
✅ uss2_dss (2026-03-03T21:58:04.259480Z)
✅ uss2_dss (2026-03-03T21:58:04.276276Z)
✅ uss2_dss (2026-03-03T21:58:04.293727Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after the creation of a subscription.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
The notification index of a newly created subscription must be 0, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.241371Z)
✅ uss2_dss (2026-03-03T21:58:04.259954Z)
✅ uss2_dss (2026-03-03T21:58:04.276767Z)
✅ uss2_dss (2026-03-03T21:58:04.294194Z)
Query and search for the created subscription in various ways
If the query to get an existing subscription fails, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.437832Z)
✅ uss2_dss (2026-03-03T21:58:04.448805Z)
✅ uss2_dss (2026-03-03T21:58:04.459897Z)
✅ uss2_dss (2026-03-03T21:58:04.470658Z)
A successful get subscription query is expected to return a well-defined body, the content of which reflects the created subscription. If the format and content of the response are not conforming, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.445226Z)
✅ uss2_dss (2026-03-03T21:58:04.456254Z)
✅ uss2_dss (2026-03-03T21:58:04.467027Z)
✅ uss2_dss (2026-03-03T21:58:04.482040Z)
The response to a successful get subscription query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.444287Z)
✅ uss2_dss (2026-03-03T21:58:04.455326Z)
✅ uss2_dss (2026-03-03T21:58:04.466100Z)
✅ uss2_dss (2026-03-03T21:58:04.481112Z)
If the search query for the area for which the subscription was just created fails, it is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.487082Z)
A successful search query is expected to return a well-defined body, the content of which reflects the created subscription as well as any other subscription in the area. If the format and content of the response are not conforming, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.496776Z)
✅ uss2_dss (2026-03-03T21:58:04.507309Z)
✅ uss2_dss (2026-03-03T21:58:04.516915Z)
✅ uss2_dss (2026-03-03T21:58:04.527132Z)
The response to a successful subscription search query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.496312Z)
✅ uss2_dss (2026-03-03T21:58:04.506811Z)
✅ uss2_dss (2026-03-03T21:58:04.516435Z)
✅ uss2_dss (2026-03-03T21:58:04.526590Z)
If the created subscription is not returned in a search that covers the area it was created for, the DSS is not properly implementing astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.496370Z)
✅ uss2_dss (2026-03-03T21:58:04.506871Z)
✅ uss2_dss (2026-03-03T21:58:04.516493Z)
✅ uss2_dss (2026-03-03T21:58:04.526648Z)
In accordance with astm.f3548.v21.DSS0005,5, the DSS should not allow searches for areas that are too big.
✅ uss2_dss (2026-03-03T21:58:04.529109Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.444794Z)
✅ uss2_dss (2026-03-03T21:58:04.455834Z)
✅ uss2_dss (2026-03-03T21:58:04.466613Z)
✅ uss2_dss (2026-03-03T21:58:04.481620Z)
✅ uss2_dss (2026-03-03T21:58:04.496410Z)
✅ uss2_dss (2026-03-03T21:58:04.506912Z)
✅ uss2_dss (2026-03-03T21:58:04.516534Z)
✅ uss2_dss (2026-03-03T21:58:04.526689Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.444839Z)
✅ uss2_dss (2026-03-03T21:58:04.455878Z)
✅ uss2_dss (2026-03-03T21:58:04.466657Z)
✅ uss2_dss (2026-03-03T21:58:04.481665Z)
✅ uss2_dss (2026-03-03T21:58:04.496444Z)
✅ uss2_dss (2026-03-03T21:58:04.506945Z)
✅ uss2_dss (2026-03-03T21:58:04.516568Z)
✅ uss2_dss (2026-03-03T21:58:04.526722Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.444875Z)
✅ uss2_dss (2026-03-03T21:58:04.455914Z)
✅ uss2_dss (2026-03-03T21:58:04.466693Z)
✅ uss2_dss (2026-03-03T21:58:04.481701Z)
✅ uss2_dss (2026-03-03T21:58:04.496474Z)
✅ uss2_dss (2026-03-03T21:58:04.506977Z)
✅ uss2_dss (2026-03-03T21:58:04.516600Z)
✅ uss2_dss (2026-03-03T21:58:04.526754Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.444908Z)
✅ uss2_dss (2026-03-03T21:58:04.455946Z)
✅ uss2_dss (2026-03-03T21:58:04.466725Z)
✅ uss2_dss (2026-03-03T21:58:04.481733Z)
✅ uss2_dss (2026-03-03T21:58:04.496503Z)
✅ uss2_dss (2026-03-03T21:58:04.507024Z)
✅ uss2_dss (2026-03-03T21:58:04.516631Z)
✅ uss2_dss (2026-03-03T21:58:04.526784Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.444971Z)
✅ uss2_dss (2026-03-03T21:58:04.456030Z)
✅ uss2_dss (2026-03-03T21:58:04.466788Z)
✅ uss2_dss (2026-03-03T21:58:04.481798Z)
✅ uss2_dss (2026-03-03T21:58:04.496564Z)
✅ uss2_dss (2026-03-03T21:58:04.507092Z)
✅ uss2_dss (2026-03-03T21:58:04.516693Z)
✅ uss2_dss (2026-03-03T21:58:04.526846Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.444938Z)
✅ uss2_dss (2026-03-03T21:58:04.455977Z)
✅ uss2_dss (2026-03-03T21:58:04.466755Z)
✅ uss2_dss (2026-03-03T21:58:04.481764Z)
✅ uss2_dss (2026-03-03T21:58:04.496532Z)
✅ uss2_dss (2026-03-03T21:58:04.507057Z)
✅ uss2_dss (2026-03-03T21:58:04.516661Z)
✅ uss2_dss (2026-03-03T21:58:04.526814Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.445021Z)
✅ uss2_dss (2026-03-03T21:58:04.456067Z)
✅ uss2_dss (2026-03-03T21:58:04.466820Z)
✅ uss2_dss (2026-03-03T21:58:04.481831Z)
✅ uss2_dss (2026-03-03T21:58:04.496595Z)
✅ uss2_dss (2026-03-03T21:58:04.507125Z)
✅ uss2_dss (2026-03-03T21:58:04.516725Z)
✅ uss2_dss (2026-03-03T21:58:04.526878Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.445055Z)
✅ uss2_dss (2026-03-03T21:58:04.456097Z)
✅ uss2_dss (2026-03-03T21:58:04.466849Z)
✅ uss2_dss (2026-03-03T21:58:04.481860Z)
✅ uss2_dss (2026-03-03T21:58:04.496623Z)
✅ uss2_dss (2026-03-03T21:58:04.507153Z)
✅ uss2_dss (2026-03-03T21:58:04.516754Z)
✅ uss2_dss (2026-03-03T21:58:04.526907Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.445116Z)
✅ uss2_dss (2026-03-03T21:58:04.456155Z)
✅ uss2_dss (2026-03-03T21:58:04.466906Z)
✅ uss2_dss (2026-03-03T21:58:04.481918Z)
✅ uss2_dss (2026-03-03T21:58:04.496678Z)
✅ uss2_dss (2026-03-03T21:58:04.507210Z)
✅ uss2_dss (2026-03-03T21:58:04.516811Z)
✅ uss2_dss (2026-03-03T21:58:04.526963Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.445146Z)
✅ uss2_dss (2026-03-03T21:58:04.456184Z)
✅ uss2_dss (2026-03-03T21:58:04.466935Z)
✅ uss2_dss (2026-03-03T21:58:04.481947Z)
✅ uss2_dss (2026-03-03T21:58:04.496707Z)
✅ uss2_dss (2026-03-03T21:58:04.507239Z)
✅ uss2_dss (2026-03-03T21:58:04.516841Z)
✅ uss2_dss (2026-03-03T21:58:04.526992Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
Verify that the subscription returned by the DSS via the search is correctly formatted and corresponds to what was created earlier.
✅ uss2_dss (2026-03-03T21:58:04.445176Z)
✅ uss2_dss (2026-03-03T21:58:04.456212Z)
✅ uss2_dss (2026-03-03T21:58:04.466964Z)
✅ uss2_dss (2026-03-03T21:58:04.481976Z)
✅ uss2_dss (2026-03-03T21:58:04.496735Z)
✅ uss2_dss (2026-03-03T21:58:04.507267Z)
✅ uss2_dss (2026-03-03T21:58:04.516871Z)
✅ uss2_dss (2026-03-03T21:58:04.527064Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its creation or mutation.
The code for these checks lives in the subscription_validator.py class.
If the version of the subscription is updated without there having been any mutation of the subscription, the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.445086Z)
✅ uss2_dss (2026-03-03T21:58:04.456126Z)
✅ uss2_dss (2026-03-03T21:58:04.466878Z)
✅ uss2_dss (2026-03-03T21:58:04.481889Z)
✅ uss2_dss (2026-03-03T21:58:04.496651Z)
✅ uss2_dss (2026-03-03T21:58:04.507182Z)
✅ uss2_dss (2026-03-03T21:58:04.516783Z)
✅ uss2_dss (2026-03-03T21:58:04.526935Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
Verify that the version field is as expected.
✅ uss2_dss (2026-03-03T21:58:04.445212Z)
✅ uss2_dss (2026-03-03T21:58:04.456242Z)
✅ uss2_dss (2026-03-03T21:58:04.466995Z)
✅ uss2_dss (2026-03-03T21:58:04.482024Z)
✅ uss2_dss (2026-03-03T21:58:04.496762Z)
✅ uss2_dss (2026-03-03T21:58:04.507295Z)
✅ uss2_dss (2026-03-03T21:58:04.516901Z)
✅ uss2_dss (2026-03-03T21:58:04.527108Z)
This test step attempts to mutate the subscription both with a missing and incorrect OVN, and checks that the DSS reacts properly.
If a request to mutate a subscription is missing the version and succeeds, the DSS is failing to properly implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.298100Z)
If a request to mutate a subscription providing the wrong version succeeds, the DSS is failing to properly implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.301404Z)
This test step mutates the previously created subscription to verify that the DSS reacts properly: notably, it checks that the subscription version is updated, including for changes that are not directly visible, such as changing the subscription's footprint.
If the query to mutate a subscription with valid parameters is not successful, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.309462Z)
✅ uss2_dss (2026-03-03T21:58:04.325986Z)
✅ uss2_dss (2026-03-03T21:58:04.342382Z)
✅ uss2_dss (2026-03-03T21:58:04.358801Z)
✅ uss2_dss (2026-03-03T21:58:04.375513Z)
✅ uss2_dss (2026-03-03T21:58:04.391930Z)
✅ uss2_dss (2026-03-03T21:58:04.409089Z)
✅ uss2_dss (2026-03-03T21:58:04.425652Z)
A successful subscription mutation query is expected to return a well-defined body, the content of which reflects the newly defined subscription. If the format and content of the response are not conforming, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.317228Z)
✅ uss2_dss (2026-03-03T21:58:04.334020Z)
✅ uss2_dss (2026-03-03T21:58:04.350157Z)
✅ uss2_dss (2026-03-03T21:58:04.366772Z)
✅ uss2_dss (2026-03-03T21:58:04.383256Z)
✅ uss2_dss (2026-03-03T21:58:04.399929Z)
✅ uss2_dss (2026-03-03T21:58:04.416751Z)
✅ uss2_dss (2026-03-03T21:58:04.433636Z)
The response to a successful subscription mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.316308Z)
✅ uss2_dss (2026-03-03T21:58:04.333123Z)
✅ uss2_dss (2026-03-03T21:58:04.349176Z)
✅ uss2_dss (2026-03-03T21:58:04.365822Z)
✅ uss2_dss (2026-03-03T21:58:04.382289Z)
✅ uss2_dss (2026-03-03T21:58:04.398994Z)
✅ uss2_dss (2026-03-03T21:58:04.415684Z)
✅ uss2_dss (2026-03-03T21:58:04.432729Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.316817Z)
✅ uss2_dss (2026-03-03T21:58:04.333636Z)
✅ uss2_dss (2026-03-03T21:58:04.349695Z)
✅ uss2_dss (2026-03-03T21:58:04.366393Z)
✅ uss2_dss (2026-03-03T21:58:04.382800Z)
✅ uss2_dss (2026-03-03T21:58:04.399543Z)
✅ uss2_dss (2026-03-03T21:58:04.416241Z)
✅ uss2_dss (2026-03-03T21:58:04.433264Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.316860Z)
✅ uss2_dss (2026-03-03T21:58:04.333678Z)
✅ uss2_dss (2026-03-03T21:58:04.349737Z)
✅ uss2_dss (2026-03-03T21:58:04.366438Z)
✅ uss2_dss (2026-03-03T21:58:04.382842Z)
✅ uss2_dss (2026-03-03T21:58:04.399591Z)
✅ uss2_dss (2026-03-03T21:58:04.416285Z)
✅ uss2_dss (2026-03-03T21:58:04.433308Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.316894Z)
✅ uss2_dss (2026-03-03T21:58:04.333711Z)
✅ uss2_dss (2026-03-03T21:58:04.349772Z)
✅ uss2_dss (2026-03-03T21:58:04.366473Z)
✅ uss2_dss (2026-03-03T21:58:04.382876Z)
✅ uss2_dss (2026-03-03T21:58:04.399627Z)
✅ uss2_dss (2026-03-03T21:58:04.416320Z)
✅ uss2_dss (2026-03-03T21:58:04.433342Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.316925Z)
✅ uss2_dss (2026-03-03T21:58:04.333741Z)
✅ uss2_dss (2026-03-03T21:58:04.349803Z)
✅ uss2_dss (2026-03-03T21:58:04.366502Z)
✅ uss2_dss (2026-03-03T21:58:04.382905Z)
✅ uss2_dss (2026-03-03T21:58:04.399658Z)
✅ uss2_dss (2026-03-03T21:58:04.416350Z)
✅ uss2_dss (2026-03-03T21:58:04.433371Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.316985Z)
✅ uss2_dss (2026-03-03T21:58:04.333799Z)
✅ uss2_dss (2026-03-03T21:58:04.349865Z)
✅ uss2_dss (2026-03-03T21:58:04.366564Z)
✅ uss2_dss (2026-03-03T21:58:04.382965Z)
✅ uss2_dss (2026-03-03T21:58:04.399719Z)
✅ uss2_dss (2026-03-03T21:58:04.416411Z)
✅ uss2_dss (2026-03-03T21:58:04.433430Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.316953Z)
✅ uss2_dss (2026-03-03T21:58:04.333769Z)
✅ uss2_dss (2026-03-03T21:58:04.349832Z)
✅ uss2_dss (2026-03-03T21:58:04.366532Z)
✅ uss2_dss (2026-03-03T21:58:04.382934Z)
✅ uss2_dss (2026-03-03T21:58:04.399688Z)
✅ uss2_dss (2026-03-03T21:58:04.416380Z)
✅ uss2_dss (2026-03-03T21:58:04.433399Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.317036Z)
✅ uss2_dss (2026-03-03T21:58:04.333829Z)
✅ uss2_dss (2026-03-03T21:58:04.349942Z)
✅ uss2_dss (2026-03-03T21:58:04.366594Z)
✅ uss2_dss (2026-03-03T21:58:04.383017Z)
✅ uss2_dss (2026-03-03T21:58:04.399750Z)
✅ uss2_dss (2026-03-03T21:58:04.416441Z)
✅ uss2_dss (2026-03-03T21:58:04.433460Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.317068Z)
✅ uss2_dss (2026-03-03T21:58:04.333855Z)
✅ uss2_dss (2026-03-03T21:58:04.349981Z)
✅ uss2_dss (2026-03-03T21:58:04.366621Z)
✅ uss2_dss (2026-03-03T21:58:04.383052Z)
✅ uss2_dss (2026-03-03T21:58:04.399777Z)
✅ uss2_dss (2026-03-03T21:58:04.416468Z)
✅ uss2_dss (2026-03-03T21:58:04.433487Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.317125Z)
✅ uss2_dss (2026-03-03T21:58:04.333909Z)
✅ uss2_dss (2026-03-03T21:58:04.350058Z)
✅ uss2_dss (2026-03-03T21:58:04.366675Z)
✅ uss2_dss (2026-03-03T21:58:04.383139Z)
✅ uss2_dss (2026-03-03T21:58:04.399830Z)
✅ uss2_dss (2026-03-03T21:58:04.416545Z)
✅ uss2_dss (2026-03-03T21:58:04.433541Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.317152Z)
✅ uss2_dss (2026-03-03T21:58:04.333936Z)
✅ uss2_dss (2026-03-03T21:58:04.350087Z)
✅ uss2_dss (2026-03-03T21:58:04.366702Z)
✅ uss2_dss (2026-03-03T21:58:04.383180Z)
✅ uss2_dss (2026-03-03T21:58:04.399858Z)
✅ uss2_dss (2026-03-03T21:58:04.416620Z)
✅ uss2_dss (2026-03-03T21:58:04.433568Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
Verify that the subscription returned by the DSS via the mutation is properly formatted and contains the correct content.
✅ uss2_dss (2026-03-03T21:58:04.317180Z)
✅ uss2_dss (2026-03-03T21:58:04.333962Z)
✅ uss2_dss (2026-03-03T21:58:04.350114Z)
✅ uss2_dss (2026-03-03T21:58:04.366728Z)
✅ uss2_dss (2026-03-03T21:58:04.383211Z)
✅ uss2_dss (2026-03-03T21:58:04.399885Z)
✅ uss2_dss (2026-03-03T21:58:04.416687Z)
✅ uss2_dss (2026-03-03T21:58:04.433594Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its mutation.
The code for these checks lives in the subscription_validator.py class.
Following a mutation, the DSS needs to update the subscription version, otherwise it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.317097Z)
✅ uss2_dss (2026-03-03T21:58:04.333882Z)
✅ uss2_dss (2026-03-03T21:58:04.350027Z)
✅ uss2_dss (2026-03-03T21:58:04.366648Z)
✅ uss2_dss (2026-03-03T21:58:04.383082Z)
✅ uss2_dss (2026-03-03T21:58:04.399803Z)
✅ uss2_dss (2026-03-03T21:58:04.416495Z)
✅ uss2_dss (2026-03-03T21:58:04.433514Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
Verify that the version field has been mutated.
✅ uss2_dss (2026-03-03T21:58:04.317215Z)
✅ uss2_dss (2026-03-03T21:58:04.333990Z)
✅ uss2_dss (2026-03-03T21:58:04.350143Z)
✅ uss2_dss (2026-03-03T21:58:04.366758Z)
✅ uss2_dss (2026-03-03T21:58:04.383242Z)
✅ uss2_dss (2026-03-03T21:58:04.399915Z)
✅ uss2_dss (2026-03-03T21:58:04.416735Z)
✅ uss2_dss (2026-03-03T21:58:04.433623Z)
Attempt to delete the subscription in various ways and ensure that the DSS reacts properly.
This also checks that the subscription data returned by a successful deletion is correct.
An attempt to delete a subscription without providing a version should fail, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.530238Z)
✅ uss2_dss (2026-03-03T21:58:04.534111Z)
✅ uss2_dss (2026-03-03T21:58:04.537825Z)
✅ uss2_dss (2026-03-03T21:58:04.541613Z)
An attempt to delete a subscription while providing an incorrect version should fail, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.532989Z)
✅ uss2_dss (2026-03-03T21:58:04.536756Z)
✅ uss2_dss (2026-03-03T21:58:04.540529Z)
✅ uss2_dss (2026-03-03T21:58:04.544110Z)
If the query to delete an existing subscription fails, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.550803Z)
✅ uss2_dss (2026-03-03T21:58:04.564572Z)
✅ uss2_dss (2026-03-03T21:58:04.578256Z)
✅ uss2_dss (2026-03-03T21:58:04.591341Z)
A successful delete subscription query is expected to return a well-defined body, the content of which reflects the content of the subscription before deletion. If the format and content of the response are not conforming, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.558310Z)
✅ uss2_dss (2026-03-03T21:58:04.572069Z)
✅ uss2_dss (2026-03-03T21:58:04.585414Z)
✅ uss2_dss (2026-03-03T21:58:04.598793Z)
The response to a successful delete subscription query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.557845Z)
✅ uss2_dss (2026-03-03T21:58:04.571619Z)
✅ uss2_dss (2026-03-03T21:58:04.584950Z)
✅ uss2_dss (2026-03-03T21:58:04.598353Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.557906Z)
✅ uss2_dss (2026-03-03T21:58:04.571677Z)
✅ uss2_dss (2026-03-03T21:58:04.585036Z)
✅ uss2_dss (2026-03-03T21:58:04.598411Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.557946Z)
✅ uss2_dss (2026-03-03T21:58:04.571716Z)
✅ uss2_dss (2026-03-03T21:58:04.585081Z)
✅ uss2_dss (2026-03-03T21:58:04.598449Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.557981Z)
✅ uss2_dss (2026-03-03T21:58:04.571749Z)
✅ uss2_dss (2026-03-03T21:58:04.585115Z)
✅ uss2_dss (2026-03-03T21:58:04.598483Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.558030Z)
✅ uss2_dss (2026-03-03T21:58:04.571780Z)
✅ uss2_dss (2026-03-03T21:58:04.585146Z)
✅ uss2_dss (2026-03-03T21:58:04.598513Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.558096Z)
✅ uss2_dss (2026-03-03T21:58:04.571841Z)
✅ uss2_dss (2026-03-03T21:58:04.585207Z)
✅ uss2_dss (2026-03-03T21:58:04.598575Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.558063Z)
✅ uss2_dss (2026-03-03T21:58:04.571809Z)
✅ uss2_dss (2026-03-03T21:58:04.585175Z)
✅ uss2_dss (2026-03-03T21:58:04.598542Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.558129Z)
✅ uss2_dss (2026-03-03T21:58:04.571872Z)
✅ uss2_dss (2026-03-03T21:58:04.585236Z)
✅ uss2_dss (2026-03-03T21:58:04.598613Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.558157Z)
✅ uss2_dss (2026-03-03T21:58:04.571900Z)
✅ uss2_dss (2026-03-03T21:58:04.585264Z)
✅ uss2_dss (2026-03-03T21:58:04.598643Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.558214Z)
✅ uss2_dss (2026-03-03T21:58:04.571954Z)
✅ uss2_dss (2026-03-03T21:58:04.585319Z)
✅ uss2_dss (2026-03-03T21:58:04.598698Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.558242Z)
✅ uss2_dss (2026-03-03T21:58:04.571982Z)
✅ uss2_dss (2026-03-03T21:58:04.585346Z)
✅ uss2_dss (2026-03-03T21:58:04.598726Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
Verify that the subscription returned by the DSS via the deletion is properly formatted and contains the correct content.
✅ uss2_dss (2026-03-03T21:58:04.558269Z)
✅ uss2_dss (2026-03-03T21:58:04.572025Z)
✅ uss2_dss (2026-03-03T21:58:04.585374Z)
✅ uss2_dss (2026-03-03T21:58:04.598753Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its creation or mutation.
The code for these checks lives in the subscription_validator.py class.
If the version of the subscription is updated without there having been any mutation of the subscription, the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.558186Z)
✅ uss2_dss (2026-03-03T21:58:04.571927Z)
✅ uss2_dss (2026-03-03T21:58:04.585292Z)
✅ uss2_dss (2026-03-03T21:58:04.598670Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
Verify that the version field is as expected.
✅ uss2_dss (2026-03-03T21:58:04.558297Z)
✅ uss2_dss (2026-03-03T21:58:04.572056Z)
✅ uss2_dss (2026-03-03T21:58:04.585401Z)
✅ uss2_dss (2026-03-03T21:58:04.598781Z)
Attempt to query and search for the deleted subscription in various ways
If the DSS provides a successful reply to a direct query for the deleted subscription, it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.600811Z)
✅ uss2_dss (2026-03-03T21:58:04.602863Z)
✅ uss2_dss (2026-03-03T21:58:04.604797Z)
✅ uss2_dss (2026-03-03T21:58:04.606808Z)
If the DSS fails to let us search in the area for which the subscription was just created, it is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.609562Z)
If the DSS returns the deleted subscription in a search that covers the area it was originally created for, the DSS is not properly implementing astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.609646Z)
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:58:04.611676Z)
✅ uss2_dss (2026-03-03T21:58:04.613598Z)
✅ uss2_dss (2026-03-03T21:58:04.615519Z)
✅ uss2_dss (2026-03-03T21:58:04.617489Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created. ∅ This check was not applicable to this test run and is therefore not statused.
Ensures that a DSS properly enforces limitations on created subscriptions
DSSInstanceResource to be tested in this scenario.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
IDGeneratorResource providing the Subscription ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which subscriptions will be created.
✅ Provided by planning_area in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss2_dss (2026-03-03T21:58:04.621317Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:58:04.623481Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
This test attempts to create subscriptions that should be rejected or adapted by the DSS.
This test step attempts to create a subscription that exceeds the maximal subscription duration on the DSS.
It does so directly, by attempting to create a subscription that exceeds the maximal duration of DSSMaxSubscriptionDuration (24 hours),
and indirectly, by first creating a valid subscription and then attempting to mutate it to exceed the maximal duration.
If the DSS under test does not allow the creation of a subscription of the maximal allowed duration of DSSMaxSubscriptionDuration,
it is failing to create a subscription using valid parameters, and is thus failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.635067Z)
If the DSS under test does not reject a subscription that exceeds the maximal allowed duration of DSSMaxSubscriptionDuration,
or fails to truncate the duration of the subscription to this duration, it is in violation of astm.f3548.v21.DSS0015.
✅ uss2_dss (2026-03-03T21:58:04.626641Z)
If the DSS under test does not reject a mutation that would cause a subscription to exceed the maximal allowed duration of DSSMaxSubscriptionDuration,
or fails to truncate the duration of the subscription to this duration, it is in violation of astm.f3548.v21.DSS0015.
✅ uss2_dss (2026-03-03T21:58:04.639282Z)
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:58:04.642862Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
✅ uss2_dss (2026-03-03T21:58:04.649343Z)
This scenario ensures that a DSS will only let the owner of an operational intent reference modify it.
A resources.flight_planning.FlightIntentsResource containing the flight intents to be used in this scenario:
This scenario expects to find at least two separate flight intents in this resource, as it will use their extent to create two operational intents references.
✅ Provided by non_conflicting_flights in top-level resource pool.
A resources.astm.f3548.v21.DSSInstanceResource pointing to the DSS instance to test for this scenario.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
A resources.communications.AuthAdapterResource containing a second set of valid credentials for interacting with the DSS.
This second set of credentials is required to validate that the DSS is properly enforcing access control rules, and properly limits the actions of a client against the resources exposed by the DSS.
The participant under test is responsible for providing this second set of credentials along the primary ones used in most other scenarios.
In general, these test credentials may be in all points equal to the ones used by the AuthAdapterResource that is
provided to the dss resources above, except for the value contained in the sub claim of the token.
For the purpose of this scenario, these credentials must be allowed to create, modify and delete operational intents on the DSS, as well as querying operational intent references.
For the purpose of this scenario, the second_utm_auth resource must provide access to a token with at least the following scope:
utm.strategic_coordinationNote that the subscription (or 'sub' claim) of the token that will be obtained for this resource
MUST be different from the one of the dss resources mentioned above:
this will be verified at runtime, and this scenario will fail if the second set of credentials belong to the same subscription as the main one.
✅ Provided by second_utm_auth in top-level resource pool.
A resources.interuss.IDGeneratorResource that will be used to generate the IDs of the operational intent references created in this scenario.
✅ Provided by id_generator in top-level resource pool.
Makes sure that the DSS is in a clean and expected state before running the test, and that the passed resources work as required.
The setup will create two separate operational intent references: one for each set of the available credentials.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:04.657307Z)
✅ uss2_dss (2026-03-03T21:58:04.661937Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:58:04.665326Z)
✅ uss2_dss (2026-03-03T21:58:04.668576Z)
✅ uss2_dss (2026-03-03T21:58:04.671656Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
If, after cleanup, one or more operational intent reference are still present at the DSS, this scenario cannot proceed.
This scenario is able to remove any operational intent reference that belongs to the configured credentials, but it cannot remove references that belong to other credentials.
A regular failure of this check indicates that other scenarios might not properly clean up their resources, or that the Prepare Flight Planners scenario should be moved in front of the present one.
If this check fails, the rest of the scenario is entirely skipped.
✅ uss2_dss (2026-03-03T21:58:04.671699Z)
This test step ensures that an operation intent reference created with the main credentials is available for the main test case.
To verify that the second credentials are valid, it will also create an operational intent reference with those credentials.
If the DSS does not allow the creation of operation intents when the required parameters and credentials are provided, it is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:04.685395Z)
✅ uss2_dss (2026-03-03T21:58:04.700902Z)
This scenario requires two sets of credentials that have a different 'sub' claim in order to validate that the DSS properly controls access to operational intents.
✅ uss2_dss (2026-03-03T21:58:04.701055Z)
This test case ensures that the DSS does not allow a caller to modify or delete operational intent references that they did not create.
This test step will attempt to modify the operational intent references that was created using the configured dss resource,
using the credentials provided in the second_utm_auth resource, and expect all such attempts to fail.
If an existing operational intent cannot directly be queried by its ID, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:04.717674Z)
If an operational intent reference can be modified by a client which did not create it, the DSS implementation is in violation of astm.f3548.v21.OPIN0035.
✅ uss2_dss (2026-03-03T21:58:04.707482Z)
✅ uss2_dss (2026-03-03T21:58:04.712137Z)
✅ uss2_dss (2026-03-03T21:58:04.717720Z)
If an operational intent reference can be deleted by a client which did not create it, the DSS implementation is in violation of astm.f3548.v21.OPIN0035.
✅ uss2_dss (2026-03-03T21:58:04.714593Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:04.720830Z)
✅ uss2_dss (2026-03-03T21:58:04.734708Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:58:04.731716Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:04.745646Z)
TODO: Complete with details once we check more than the prerequisites.
This scenario currently only checks that all specified DSS instances are publicly addressable and reachable.
A resources.astm.f3548.v21.DSSInstanceResource containing the "primary" DSS instance for this scenario.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
A resources.astm.f3548.v21.DSSInstancesResource containing at least two DSS instances complying with ASTM F3548-21.
✅ Provided by dss_instances in top-level resource pool.
A resources.PlanningAreaResource containing a planning area that covers the area of interest for this
✅ Provided by planning_area in top-level resource pool.
A resources.dev.TestExclusionsResource containing test exclusions parameters like whether private addresses are allowed. This resource is optional.
∅ This resource was not applicable to this test run and was therefore not provided.
As per astm.f3548.v21.DSS0300 the DSS instance should be publicly addressable.
As such, this check will fail if the resolved IP of the DSS host is a private IP address.
This check is skipped if the test exclusion allow_private_addresses is set to True.
❌ uss2_dss (2026-03-03T21:58:04.746618Z)
❌ uss1_dss (2026-03-03T21:58:04.753526Z)
As per astm.f3548.v21.DSS0300 the DSS instance should be publicly addressable. As such, this check will fail if the DSS is not reachable with a dummy query.
✅ uss2_dss (2026-03-03T21:58:04.753063Z)
✅ uss1_dss (2026-03-03T21:58:04.759342Z)
Verifies that all subscription CRUD operations performed on a single DSS instance are properly propagated to every other DSS
DSSInstanceResource the DSS instance through which entities are created, modified and deleted.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
DSSInstancesResource pointing to the DSS instances used to confirm that entities are properly propagated.
✅ Provided by dss_instances in top-level resource pool.
IDGeneratorResource providing the Subscription ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
PlanningAreaResource describes the 3D volume in which subscriptions will be created.
✅ Provided by planning_area in top-level resource pool.
A resources.communications.AuthAdapterResource containing a second set of valid credentials for interacting with the DSS.
This second set of credentials is required to validate that the DSS properly synchronizes the manager of a subscription to other DSS instances.
The test designer should provide this second set of credentials when full testing of manager synchronization behavior is desired.
In general, these test credentials may be in all points equal to the ones used by the AuthAdapterResource that is
provided to the dss resources above, except for the value contained in the sub claim of the token.
Note that most checks in this scenario will work if the second set of credentials is not provided.
For the purpose of this scenario, the second_utm_auth resource must provide access to a token with at least the following scope:
utm.strategic_coordinationNote that the subject (or 'sub' claim) of the token that will be obtained for this resource
MUST be different from the one of the dss resources mentioned above:
this will be verified at runtime, and the depending checks will not be run if this is not the case.
✅ Provided by second_utm_auth in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
✅ uss2_dss (2026-03-03T21:58:04.763201Z)
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:58:04.765269Z)
✅ uss2_dss (2026-03-03T21:58:04.767290Z)
✅ uss2_dss (2026-03-03T21:58:04.769283Z)
✅ uss2_dss (2026-03-03T21:58:04.771677Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
This includes the main test subscription used in this test, as well as the extra subscription
used for testing the manager field sync, if the test is configured to test for it.
∅ This check was not applicable to this test run and is therefore not statused.
This test step queries all secondary instances to confirm that none of the test IDs that are used in the scenario exist.
Ensures that a secondary DSS is ready to be used for testing by confirming that no Subscription bearing an ID used for testing exists on it.
If an existing subscription cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,5 correctly.
✅ uss1_dss (2026-03-03T21:58:04.774113Z)
✅ uss1_dss (2026-03-03T21:58:04.776086Z)
✅ uss1_dss (2026-03-03T21:58:04.778166Z)
✅ uss2_dss (2026-03-03T21:58:04.780603Z)
✅ uss2_dss (2026-03-03T21:58:04.782573Z)
✅ uss2_dss (2026-03-03T21:58:04.784557Z)
If a Subscription that was deleted from the primary DSS can still be found on a secondary DSS, either one of them may be improperly pooled and in violation of astm.f3548.v21.DSS0020.
✅ uss1_dss (2026-03-03T21:58:04.774149Z)
✅ uss1_dss (2026-03-03T21:58:04.776123Z)
✅ uss1_dss (2026-03-03T21:58:04.778199Z)
✅ uss2_dss (2026-03-03T21:58:04.780638Z)
✅ uss2_dss (2026-03-03T21:58:04.782606Z)
✅ uss2_dss (2026-03-03T21:58:04.784590Z)
This test case create a subscription on the main DSS, and verifies that it is properly synchronized to the other DSS instances.
It then goes on to mutate and delete it, each time confirming that all other DSSes return the expected results.
This test step creates multiple subscriptions with different combinations of the optional end and start time parameters.
All subscriptions are left on the DSS when this step ends, as they are expected to be present for the subsequent step.
This test step fragment validates that subscriptions can be created.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:58:04.793279Z)
✅ uss2_dss (2026-03-03T21:58:04.811059Z)
✅ uss2_dss (2026-03-03T21:58:04.828420Z)
The response to a successful subscription creation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.800891Z)
✅ uss2_dss (2026-03-03T21:58:04.817873Z)
✅ uss2_dss (2026-03-03T21:58:04.835589Z)
A successful subscription creation query is expected to return a well-defined body, the content of which reflects the created subscription.
If the content of the response does not correspond to the requested content, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.802239Z)
✅ uss2_dss (2026-03-03T21:58:04.819404Z)
✅ uss2_dss (2026-03-03T21:58:04.837086Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.801438Z)
✅ uss2_dss (2026-03-03T21:58:04.818468Z)
✅ uss2_dss (2026-03-03T21:58:04.836142Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.801481Z)
✅ uss2_dss (2026-03-03T21:58:04.818510Z)
✅ uss2_dss (2026-03-03T21:58:04.836187Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.801515Z)
✅ uss2_dss (2026-03-03T21:58:04.818545Z)
✅ uss2_dss (2026-03-03T21:58:04.836221Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.801546Z)
✅ uss2_dss (2026-03-03T21:58:04.818576Z)
✅ uss2_dss (2026-03-03T21:58:04.836251Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.801612Z)
✅ uss2_dss (2026-03-03T21:58:04.818636Z)
✅ uss2_dss (2026-03-03T21:58:04.836310Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.801574Z)
✅ uss2_dss (2026-03-03T21:58:04.818605Z)
✅ uss2_dss (2026-03-03T21:58:04.836278Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.801643Z)
✅ uss2_dss (2026-03-03T21:58:04.818681Z)
✅ uss2_dss (2026-03-03T21:58:04.836341Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.801671Z)
✅ uss2_dss (2026-03-03T21:58:04.818709Z)
✅ uss2_dss (2026-03-03T21:58:04.836374Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.801698Z)
✅ uss2_dss (2026-03-03T21:58:04.818765Z)
✅ uss2_dss (2026-03-03T21:58:04.836401Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.801725Z)
✅ uss2_dss (2026-03-03T21:58:04.818799Z)
✅ uss2_dss (2026-03-03T21:58:04.836429Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.801752Z)
✅ uss2_dss (2026-03-03T21:58:04.818828Z)
✅ uss2_dss (2026-03-03T21:58:04.836456Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after the creation of a subscription.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
The notification index of a newly created subscription must be 0, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.802216Z)
✅ uss2_dss (2026-03-03T21:58:04.819364Z)
✅ uss2_dss (2026-03-03T21:58:04.837047Z)
Query the created subscription at every DSS provided in dss_instances to confirm that it is properly synchronized across all DSS instances,
and that it can be accessed directly by ID or searched for by area.
This test step fragment validates that subscriptions are properly synchronized across a set of DSS instances.
If the previously created or mutated subscription cannot be found at a DSS, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.841117Z)
✅ uss2_dss (2026-03-03T21:58:04.862932Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct USS base URL, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.841615Z)
✅ uss2_dss (2026-03-03T21:58:04.863463Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct start time, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.841666Z)
✅ uss2_dss (2026-03-03T21:58:04.863514Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct end time, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.841709Z)
✅ uss2_dss (2026-03-03T21:58:04.863556Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct version, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.841747Z)
✅ uss2_dss (2026-03-03T21:58:04.863593Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct notification flags, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1g, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.841785Z)
✅ uss2_dss (2026-03-03T21:58:04.863629Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct implicit flag, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1h, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.841819Z)
✅ uss2_dss (2026-03-03T21:58:04.863662Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the expected notification count, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1i, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.841853Z)
✅ uss2_dss (2026-03-03T21:58:04.863703Z)
The secondary DSS should be aware of the subscription's area: when a search query is issued for an area that encompasses the created subscription, the secondary DSS should return the subscription in its search results.
Otherwise, it is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.856609Z)
✅ uss2_dss (2026-03-03T21:58:04.878387Z)
The secondary DSS should be aware of the subscription's area: when a search query is issued for an area not in the vicinity of the created subscription, the secondary DSS should not return it in its search results.
Otherwise, it is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.859733Z)
✅ uss2_dss (2026-03-03T21:58:04.881409Z)
This test step fragment validates that a known subscriptions can be read, and that its content is correct.
This test step fragment validates that a query to read a subscription succeeds.
If a subscription cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:04.841060Z)
✅ uss2_dss (2026-03-03T21:58:04.862880Z)
The response to a successful get subscription query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:04.849305Z)
✅ uss2_dss (2026-03-03T21:58:04.871309Z)
A successful query for a subscription is expected to return a body, the content of which reflects the created subscription. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.843207Z)
✅ uss2_dss (2026-03-03T21:58:04.865018Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.842747Z)
✅ uss2_dss (2026-03-03T21:58:04.864578Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.842793Z)
✅ uss2_dss (2026-03-03T21:58:04.864623Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.842830Z)
✅ uss2_dss (2026-03-03T21:58:04.864660Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.842865Z)
✅ uss2_dss (2026-03-03T21:58:04.864694Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.842941Z)
✅ uss2_dss (2026-03-03T21:58:04.864763Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.842898Z)
✅ uss2_dss (2026-03-03T21:58:04.864727Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.842977Z)
✅ uss2_dss (2026-03-03T21:58:04.864798Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.843028Z)
✅ uss2_dss (2026-03-03T21:58:04.864830Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.843096Z)
✅ uss2_dss (2026-03-03T21:58:04.864892Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.843128Z)
✅ uss2_dss (2026-03-03T21:58:04.864926Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.843160Z)
✅ uss2_dss (2026-03-03T21:58:04.864957Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its creation or mutation.
The code for these checks lives in the subscription_validator.py class.
If the version of the subscription is updated without there having been any mutation of the subscription, the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.843064Z)
✅ uss2_dss (2026-03-03T21:58:04.864861Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.843193Z)
✅ uss2_dss (2026-03-03T21:58:04.864990Z)
This test step fragment validates that a query to search for subscriptions succeeds.
If the DSS fails to let us search in the area for which the subscription was created, it is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:04.854059Z)
✅ uss1_dss (2026-03-03T21:58:04.859673Z)
✅ uss2_dss (2026-03-03T21:58:04.875973Z)
✅ uss2_dss (2026-03-03T21:58:04.881350Z)
This test step mutates the previously created subscription, by accessing the primary DSS, to verify that the update is propagated to all other DSSes. Notably, it checks that the subscription version is updated, including for changes that are not directly visible, such as changing the subscription's footprint.
This test step fragment validates that subscriptions can be updated.
This test step fragment validates that a query to update a subscription succeeds.
If a subscription cannot be updated with a valid set of parameters, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.889594Z)
This test step fragment validates that subscriptions can be updated but does not contain a check related to the query itself.
This fragment is intended to be used in scenarios that define their own query verification check, usually when more specific requirements are being tested.
The response to a successful subscription mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.896949Z)
A successful subscription mutation query is expected to return a well-defined body, the content of which reflects the mutated subscription.
If the content of the response does correspond to the requested mutation, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.897863Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.897479Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.897521Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.897556Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.897587Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.897649Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.897616Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.897679Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.897706Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.897759Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.897786Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.897813Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its mutation.
The code for these checks lives in the subscription_validator.py class.
Following a mutation, the DSS needs to update the subscription version, otherwise it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.897733Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.897849Z)
Query the updated subscription at every DSS provided in dss_instances to confirm that the mutation is properly synchronized across all DSS instances,
This test step fragment validates that subscriptions are properly synchronized across a set of DSS instances.
If the previously created or mutated subscription cannot be found at a DSS, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.901491Z)
✅ uss2_dss (2026-03-03T21:58:04.923366Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct USS base URL, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.901983Z)
✅ uss2_dss (2026-03-03T21:58:04.923862Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct start time, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.902070Z)
✅ uss2_dss (2026-03-03T21:58:04.923913Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct end time, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.902119Z)
✅ uss2_dss (2026-03-03T21:58:04.923955Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct version, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.902158Z)
✅ uss2_dss (2026-03-03T21:58:04.923994Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct notification flags, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1g, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.902196Z)
✅ uss2_dss (2026-03-03T21:58:04.924072Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct implicit flag, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1h, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.902230Z)
✅ uss2_dss (2026-03-03T21:58:04.924115Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the expected notification count, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1i, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.902264Z)
✅ uss2_dss (2026-03-03T21:58:04.924152Z)
The secondary DSS should be aware of the subscription's area: when a search query is issued for an area that encompasses the created subscription, the secondary DSS should return the subscription in its search results.
Otherwise, it is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.917167Z)
✅ uss2_dss (2026-03-03T21:58:04.938529Z)
The secondary DSS should be aware of the subscription's area: when a search query is issued for an area not in the vicinity of the created subscription, the secondary DSS should not return it in its search results.
Otherwise, it is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.920149Z)
✅ uss2_dss (2026-03-03T21:58:04.941506Z)
This test step fragment validates that a known subscriptions can be read, and that its content is correct.
This test step fragment validates that a query to read a subscription succeeds.
If a subscription cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:04.901439Z)
✅ uss2_dss (2026-03-03T21:58:04.923316Z)
The response to a successful get subscription query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:04.910205Z)
✅ uss2_dss (2026-03-03T21:58:04.931628Z)
A successful query for a subscription is expected to return a body, the content of which reflects the created subscription. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.903723Z)
✅ uss2_dss (2026-03-03T21:58:04.925463Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.903141Z)
✅ uss2_dss (2026-03-03T21:58:04.925028Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.903212Z)
✅ uss2_dss (2026-03-03T21:58:04.925080Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.903271Z)
✅ uss2_dss (2026-03-03T21:58:04.925120Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.903329Z)
✅ uss2_dss (2026-03-03T21:58:04.925154Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.903459Z)
✅ uss2_dss (2026-03-03T21:58:04.925224Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.903398Z)
✅ uss2_dss (2026-03-03T21:58:04.925188Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.903500Z)
✅ uss2_dss (2026-03-03T21:58:04.925260Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.903534Z)
✅ uss2_dss (2026-03-03T21:58:04.925292Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.903607Z)
✅ uss2_dss (2026-03-03T21:58:04.925355Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.903640Z)
✅ uss2_dss (2026-03-03T21:58:04.925387Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.903677Z)
✅ uss2_dss (2026-03-03T21:58:04.925418Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its creation or mutation.
The code for these checks lives in the subscription_validator.py class.
If the version of the subscription is updated without there having been any mutation of the subscription, the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.903574Z)
✅ uss2_dss (2026-03-03T21:58:04.925324Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.903710Z)
✅ uss2_dss (2026-03-03T21:58:04.925451Z)
This test step fragment validates that a query to search for subscriptions succeeds.
If the DSS fails to let us search in the area for which the subscription was created, it is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:04.914764Z)
✅ uss1_dss (2026-03-03T21:58:04.920087Z)
✅ uss2_dss (2026-03-03T21:58:04.936150Z)
✅ uss2_dss (2026-03-03T21:58:04.941446Z)
This test step attempts to mutate the subscription on every secondary DSS instance (that is, instances through which the subscription has not been created) to confirm that such mutations are properly propagated to every DSS.
Note that this step is repeated for every secondary DSS instance.
If the secondary DSS does not allow the subscription to be mutated, either the secondary DSS or the primary DSS are in violation of one or both of the following requirements:
astm.f3548.v21.DSS0210,1b, if the manager of the subscription fails to be taken into account (either because the primary DSS did not propagated it, or because the secondary failed to consider it);
astm.f3548.v21.DSS0005,5, if the secondary DSS fails to properly implement the API to mutate subscriptions.
✅ uss2_dss (2026-03-03T21:58:04.963762Z)
This test step fragment validates that subscriptions can be updated but does not contain a check related to the query itself.
This fragment is intended to be used in scenarios that define their own query verification check, usually when more specific requirements are being tested.
The response to a successful subscription mutation query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.971380Z)
A successful subscription mutation query is expected to return a well-defined body, the content of which reflects the mutated subscription.
If the content of the response does correspond to the requested mutation, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.972311Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.971905Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.971947Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.971981Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.972036Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.972103Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.972069Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.972134Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:04.972162Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.972215Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.972241Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.972269Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its mutation.
The code for these checks lives in the subscription_validator.py class.
Following a mutation, the DSS needs to update the subscription version, otherwise it is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.972189Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:04.972298Z)
This step verifies that the mutation of the subscription on a secondary instance, from the previous step, is properly propagated to every other DSS.
Note that this step is repeated for every secondary DSS instance.
This test step fragment validates that subscriptions are properly synchronized across a set of DSS instances.
If the previously created or mutated subscription cannot be found at a DSS, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.975976Z)
✅ uss2_dss (2026-03-03T21:58:04.997319Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct USS base URL, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1c, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.976513Z)
✅ uss2_dss (2026-03-03T21:58:04.997821Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct start time, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.976564Z)
✅ uss2_dss (2026-03-03T21:58:04.997871Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct end time, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1e, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.976605Z)
✅ uss2_dss (2026-03-03T21:58:04.997912Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct version, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1f, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.976642Z)
✅ uss2_dss (2026-03-03T21:58:04.997956Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct notification flags, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1g, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.976680Z)
✅ uss2_dss (2026-03-03T21:58:04.997996Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the correct implicit flag, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1h, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.976713Z)
✅ uss2_dss (2026-03-03T21:58:04.998052Z)
If the subscription returned by a DSS to which the subscription was synchronized to does not contain the expected notification count, either one of the instances at which the subscription was created or the one that was queried, is failing to implement one of the following requirements:
astm.f3548.v21.DSS0210,1i, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.976746Z)
✅ uss2_dss (2026-03-03T21:58:04.998099Z)
The secondary DSS should be aware of the subscription's area: when a search query is issued for an area that encompasses the created subscription, the secondary DSS should return the subscription in its search results.
Otherwise, it is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.991067Z)
✅ uss2_dss (2026-03-03T21:58:05.013148Z)
The secondary DSS should be aware of the subscription's area: when a search query is issued for an area not in the vicinity of the created subscription, the secondary DSS should not return it in its search results.
Otherwise, it is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1d, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.994196Z)
✅ uss2_dss (2026-03-03T21:58:05.016113Z)
This test step fragment validates that a known subscriptions can be read, and that its content is correct.
This test step fragment validates that a query to read a subscription succeeds.
If a subscription cannot be queried using its ID, the DSS is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:04.975925Z)
✅ uss2_dss (2026-03-03T21:58:04.997268Z)
The response to a successful get subscription query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:04.984021Z)
✅ uss2_dss (2026-03-03T21:58:05.006131Z)
A successful query for a subscription is expected to return a body, the content of which reflects the created subscription. If the content of the response does not correspond to what was requested, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
This check will usually be performing a series of sub-checks from the validate fragments.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.978082Z)
✅ uss2_dss (2026-03-03T21:58:04.999508Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.977626Z)
✅ uss2_dss (2026-03-03T21:58:04.999081Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.977671Z)
✅ uss2_dss (2026-03-03T21:58:04.999129Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.977713Z)
✅ uss2_dss (2026-03-03T21:58:04.999167Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.977748Z)
✅ uss2_dss (2026-03-03T21:58:04.999201Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.977817Z)
✅ uss2_dss (2026-03-03T21:58:04.999270Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.977781Z)
✅ uss2_dss (2026-03-03T21:58:04.999234Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.977852Z)
✅ uss2_dss (2026-03-03T21:58:04.999305Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.977883Z)
✅ uss2_dss (2026-03-03T21:58:04.999337Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.977946Z)
✅ uss2_dss (2026-03-03T21:58:04.999401Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.977976Z)
✅ uss2_dss (2026-03-03T21:58:04.999432Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.978028Z)
✅ uss2_dss (2026-03-03T21:58:04.999463Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its creation or mutation.
The code for these checks lives in the subscription_validator.py class.
If the version of the subscription is updated without there having been any mutation of the subscription, the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.977915Z)
✅ uss2_dss (2026-03-03T21:58:04.999369Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:04.978068Z)
✅ uss2_dss (2026-03-03T21:58:04.999495Z)
This test step fragment validates that a query to search for subscriptions succeeds.
If the DSS fails to let us search in the area for which the subscription was created, it is failing to meet astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:04.988669Z)
✅ uss1_dss (2026-03-03T21:58:04.994135Z)
✅ uss2_dss (2026-03-03T21:58:05.010647Z)
✅ uss2_dss (2026-03-03T21:58:05.016051Z)
If the second set of credentials is provided, this test step will create a subscription using these credentials, in order to prepare the next step that checks manager synchronization.
This test step fragment validates that a query to create a subscription with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,5, the DSS API must allow callers to create a subscription with either one or both of the start and end time missing, provided all the required parameters are valid.
✅ uss2_dss (2026-03-03T21:58:04.949670Z)
If the second set of credentials is provided, checks that the manager of a subscription is properly synchronized across all DSS instances.
This is done by verifying that the main credentials are not able to delete the subscription via any of the secondary DSS instances.
If the subscription can be deleted by a client which did not create it, via a DSS instance to which the subscription was synced following its creation on the primary DSS, either one of the primary DSS or the DSS that accepted the deletion failed to properly broadcast, respectively take into account, the manage of the subscription, and therefore violates astm.f3548.v21.DSS0210,1b.
✅ uss1_dss (2026-03-03T21:58:04.952783Z)
✅ uss2_dss (2026-03-03T21:58:04.955557Z)
Attempt to delete the subscription that was created on the primary DSS through the primary DSS in various ways, and ensure that the DSS reacts properly.
This also checks that the subscription data returned by a successful deletion is correct.
This test step fragment validates that subscriptions can be deleted.
This test step fragment validates that a query to remove a subscription succeeds.
An attempt to delete a subscription when the correct version is provided should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:05.082790Z)
The response to a successful subscription deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:05.093885Z)
A successful subscription deletion query is expected to return a well-defined body, the content of which reflects the deleted subscription.
If the content of the response does not correspond to the subscription at the time of deletion, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:05.094336Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:05.093944Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:05.093983Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:05.094033Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:05.094067Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:05.094131Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:05.094097Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:05.094162Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss2_dss (2026-03-03T21:58:05.094190Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:05.094244Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:05.094270Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:05.094297Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its creation or mutation.
The code for these checks lives in the subscription_validator.py class.
If the version of the subscription is updated without there having been any mutation of the subscription, the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:05.094217Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
✅ uss2_dss (2026-03-03T21:58:05.094323Z)
Attempt to query and search for the deleted subscription in various ways
If a DSS returns a subscription that was previously successfully deleted from the primary DSS, either one of the primary DSS or the DSS that returned the subscription is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS through which the subscription was deleted is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss1_dss, uss2_dss (2026-03-03T21:58:05.096475Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:58:05.098418Z)
Attempt to delete subscriptions that were created through the primary DSS via the secondary DSS instances.
This test step fragment validates that subscriptions can be deleted.
This test step fragment validates that a query to remove a subscription succeeds.
An attempt to delete a subscription when the correct version is provided should succeed, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:05.104270Z)
✅ uss2_dss (2026-03-03T21:58:05.123804Z)
The response to a successful subscription deletion query is expected to conform to the format defined by the OpenAPI specification under the A3.1 Annex of ASTM F3548−21.
If it does not, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:05.111109Z)
✅ uss2_dss (2026-03-03T21:58:05.131255Z)
A successful subscription deletion query is expected to return a well-defined body, the content of which reflects the deleted subscription.
If the content of the response does not correspond to the subscription at the time of deletion, the DSS is failing to implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:05.111713Z)
✅ uss2_dss (2026-03-03T21:58:05.131705Z)
This test step fragment attempts to validate the content of a single subscription returned by the DSS.
The code for these checks lives in the subscription_validator.py class.
If the returned subscription ID does not correspond to the one specified in the creation parameters, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:58:05.111181Z)
✅ uss2_dss (2026-03-03T21:58:05.131314Z)
If the returned subscription has no USS base URL defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:58:05.111250Z)
✅ uss2_dss (2026-03-03T21:58:05.131353Z)
The returned USS base URL must be prefixed with the USS base URL that was provided at subscription creation, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:05.111296Z)
✅ uss2_dss (2026-03-03T21:58:05.131385Z)
If the returned subscription has no start time defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:58:05.111329Z)
✅ uss2_dss (2026-03-03T21:58:05.131416Z)
The returned start time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:05.111432Z)
✅ uss2_dss (2026-03-03T21:58:05.131493Z)
Subscriptions need a defined end time in order to limit their duration: if the DSS omits to set the end time, it will be in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:05.111370Z)
✅ uss2_dss (2026-03-03T21:58:05.131454Z)
The returned end time must be the same as the provided one, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:05.111470Z)
✅ uss2_dss (2026-03-03T21:58:05.131525Z)
If the returned subscription has no version defined, astm.f3548.v21.DSS0005,5 is not respected.
✅ uss1_dss (2026-03-03T21:58:05.111516Z)
✅ uss2_dss (2026-03-03T21:58:05.131553Z)
A subscription that was explicitly created by a client should always have its implicit_subscription flag set to false,
otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:05.111604Z)
✅ uss2_dss (2026-03-03T21:58:05.131608Z)
If the subscription was created with the include_operational_intents flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:05.111642Z)
✅ uss2_dss (2026-03-03T21:58:05.131636Z)
If the subscription was created with the include_constraints flag set to true, the returned subscription must have the same flag set to true, otherwise the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:05.111671Z)
✅ uss2_dss (2026-03-03T21:58:05.131665Z)
This test step fragment attempts to validate a single subscription returned by the DSS after its creation or mutation.
The code for these checks lives in the subscription_validator.py class.
If the version of the subscription is updated without there having been any mutation of the subscription, the DSS is in violation of astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:05.111548Z)
✅ uss2_dss (2026-03-03T21:58:05.131581Z)
This test step fragment attempts to validate a single subscription's notification index returned by the DSS after a mutation, or for any query returning a subscription except for its initial creation.
The index may change for reasons outside of uss_qualifier's control or awareness, therefore the only thing we can reliably verify with regard to the notification index is that:
The code for these checks lives in the subscription_validator.py class.
If the notification index of the subscription is less than 0, the DSS fails to properly implement astm.f3548.v21.DSS0005,5.
✅ uss1_dss (2026-03-03T21:58:05.111700Z)
✅ uss2_dss (2026-03-03T21:58:05.131692Z)
If a DSS returns a subscription that was previously successfully deleted from the primary DSS, either one of the primary DSS or the DSS that returned the subscription is in violation of one of the following requirements:
astm.f3548.v21.DSS0210,1a, if the API is not working as described by the OpenAPI specification; astm.f3548.v21.DSS0215, if the DSS through which the subscription was deleted is returning API calls to the client before having updated its underlying distributed storage.
As a result, the DSS pool under test is failing to meet astm.f3548.v21.DSS0020.
✅ uss2_dss, uss1_dss (2026-03-03T21:58:05.113767Z)
✅ uss1_dss, uss1_dss (2026-03-03T21:58:05.115834Z)
✅ uss2_dss, uss1_dss (2026-03-03T21:58:05.117852Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:58:05.133668Z)
✅ uss1_dss, uss2_dss (2026-03-03T21:58:05.135658Z)
✅ uss2_dss, uss2_dss (2026-03-03T21:58:05.137658Z)
Ensure a clean workspace for testing interactions with a DSS by removing any subscriptions from the DSS that may have been left behind from testing efforts.
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to retrieve the subscriptions they created.
∅ This check was not applicable to this test run and is therefore not statused.
If the DSS cannot be queried for the existing test ID, the DSS is likely not implementing astm.f3548.v21.DSS0005,5 correctly.
✅ uss2_dss (2026-03-03T21:58:05.139747Z)
✅ uss2_dss (2026-03-03T21:58:05.141708Z)
✅ uss2_dss (2026-03-03T21:58:05.143639Z)
✅ uss2_dss (2026-03-03T21:58:05.147352Z)
astm.f3548.v21.DSS0005,5 requires the implementation of the DSS endpoint to allow callers to delete subscriptions they created.
This includes the main test subscription used in this test, as well as the extra subscription
used for testing the manager field sync, if the test is configured to test for it.
✅ uss2_dss (2026-03-03T21:58:05.153330Z)
This instance of this test scenario was skipped in this test run because: Test suite action to run ActionType.TestScenario scenarios.astm.utm.dss.DatastoreAccess could not find required resource ID "dss_datastore_cluster" used to populate child resource ID "datastore_cluster"
This test validates that a DSS correctly implements the OVN Request Optional Extension to ASTM F3548-21.
DSSInstanceResource to be tested in this scenario.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
IDGeneratorResource providing the base entity ID for this scenario.
✅ Provided by id_generator in top-level resource pool.
ClientIdentityResource the client identity that will be used to create and update operational intent references.
✅ Provided by utm_client_identity in top-level resource pool.
PlanningAreaResource describes the 3D volume in which operational intent references will be created.
✅ Provided by planning_area in top-level resource pool.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:05.162109Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
✅ uss2_dss (2026-03-03T21:58:05.159883Z)
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
∅ This check was not applicable to this test run and is therefore not statused.
This case validates the nominal behavior of the OVN request.
This test step fragment validates that a query to create an operational intent reference with valid parameters succeeds
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to create an operational intent reference with either one or both of the start and end time missing, provided all the required parameters are valid. Check that the OIR creation query succeeds.
✅ uss2_dss (2026-03-03T21:58:05.182537Z)
This test step fragment validates that the DSS has set the expected OVN correctly after an USS requested a suffix.
If the DSS has not set the OVN according to the specifications, it will fail this check as per interuss.f3548.ovn_request.ImplementAPI. Check that the DSS has set the expected OVN correctly.
✅ uss2_dss (2026-03-03T21:58:05.182588Z)
This test step fragment validates that a query to update an operational intent reference with valid parameters succeeds.
As per astm.f3548.v21.DSS0005,1, the DSS API must allow callers to mutate an operational intent reference. Check that the OIR update query succeeds.
✅ uss2_dss (2026-03-03T21:58:05.208379Z)
This test step fragment validates that the DSS has set the expected OVN correctly after an USS requested a suffix.
If the DSS has not set the OVN according to the specifications, it will fail this check as per interuss.f3548.ovn_request.ImplementAPI. Check that the DSS has set the expected OVN correctly.
✅ uss2_dss (2026-03-03T21:58:05.208432Z)
This case validates the off-nominal behaviors of the OVN request.
This test step fragment validates that the DSS rejects invalid attempts to request an OVN suffix.
If the DSS accepts the OVN suffix, or fails with an error other than an HTTP code 400, this check will fail as per interuss.f3548.ovn_request.ImplementAPI. Check that the DSS rejects OVN suffix that are not UUIDs. If the DSS accepts the OVN suffix, or fails with an unexpected error, this check will fail.
✅ uss2_dss (2026-03-03T21:58:05.209921Z)
This test step fragment validates that the DSS rejects invalid attempts to request an OVN suffix.
If the DSS accepts the OVN suffix, or fails with an error other than an HTTP code 400, this check will fail as per interuss.f3548.ovn_request.ImplementAPI. Check that the DSS rejects OVN suffix that are empty. If the DSS accepts the OVN suffix, or fails with an unexpected error, this check will fail.
✅ uss2_dss (2026-03-03T21:58:05.211295Z)
This test step fragment validates that the DSS rejects invalid attempts to request an OVN suffix.
If the DSS accepts the OVN suffix, or fails with an error other than an HTTP code 400, this check will fail as per interuss.f3548.ovn_request.ImplementAPI. Check that the DSS rejects OVN suffix that are UUIDs but not v7. If the DSS accepts the OVN suffix, or fails with an unexpected error, this check will fail.
✅ uss2_dss (2026-03-03T21:58:05.212676Z)
This test step fragment validates that the DSS rejects invalid attempts to request an OVN suffix.
If the DSS accepts the OVN suffix, or fails with an error other than an HTTP code 400, this check will fail as per interuss.f3548.ovn_request.ImplementAPI. Check that the DSS rejects OVN suffix that are outdated UUIDv7. If the DSS accepts the OVN suffix, or fails with an unexpected error, this check will fail.
✅ uss2_dss (2026-03-03T21:58:05.214251Z)
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:05.217395Z)
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
∅ This check was not applicable to this test run and is therefore not statused.
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
✅ uss2_dss (2026-03-03T21:58:05.232514Z)
This scenario tests the ability of the DSS to receive DSS reports.
DSSInstanceResource to be tested in this scenario.
✅ Provided by instance 2 in dss_instances in top-level resource pool.
This test attempts to submit to the DSS a report about a communication issue with a DSS that might otherwise go unnoticed.
A dummy getOperationalIntentReference query is made to a non-existent DSS in order to produce a realistic report, as if a DSS was not reachable when trying to retrieve an operational intent reference.
This step makes a report to the DSS.
See make_dss_report in test_steps_fragments.py.
If the submission of the report to the DSS does not succeed, this check will fail per astm.f3548.v21.DSS0100,2.
✅ uss2_dss (2026-03-03T21:58:05.278225Z)
If the ID returned by the DSS is not present or is empty, this check will fail per astm.f3548.v21.DSS0100,2.
✅ uss2_dss (2026-03-03T21:58:05.278274Z)
This test checks that the USS validates correctly the operational intents it creates. Notably the following requirements:
It assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).
FlightIntentsResource that provides the following flight intents:
| Flight intent ID | Flight name | Usage State | UAS State | Invalid details |
|---|---|---|---|---|
valid_flight |
Valid Flight | Planned | Nominal | N/A |
valid_activated |
InUse | |||
valid_conflict_tiny_overlap |
Tiny Overlap Conflict Flight | Planned | Nominal | Conflicts with Flight 1 such that their 3D volumes have an overlap just above IntersectionMinimumPrecision = 1cm |
invalid_too_far_away |
Too Far Away Flight | Has a start time that is more than OiMaxPlanHorizon = 30 days ahead of time |
||
invalid_recently_ended |
Recently Ended Flight | Has an end time that is within 5 to 10 seconds in the past. |
Because the scenario involves activation of intents, all activated intents must be active during the execution of the test scenario. Additionally, their end time must leave sufficient time for the execution of the test scenario. For the sake of simplicity, it is recommended to set the start and end times of all the intents to the same range.
✅ Provided by invalid_flight_intents in top-level resource pool.
FlightPlannerResource that will be tested for its validation of operational intents.
✅ Provided by instance 1 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.
✅ Provided by dss in top-level resource pool.
The user flight intent that the test driver attempts to plan has a start time that is more than OiMaxPlanHorizon = 30 days ahead of time. As such, the attempt should be rejected.
If the USS successfully plans the flight or otherwise fails to indicate a rejection, it means that it failed to validate the intent provided. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per astm.f3548.v21.OPIN0030.
✅ uss1_core (2026-03-03T21:58:05.315442Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:05.315408Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:05.287205Z)
✅ uss1_dss (2026-03-03T21:58:05.318478Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:05.318523Z)
The user flight intent that the test driver attempts to plan has recently ended by just slightly more than TimeSyncMaxDifferentialSeconds = 5 seconds.
As such, if the USS synchronizes its time correctly, the attempt should be rejected.
If the USS successfully plans the flight or otherwise fails to indicate a rejection, it means that it failed to validate that the intent provided was in the past. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per one of the following requirements:
TimeSyncMaxDifferentialSeconds = 5 seconds of an industry-recognized time source as required by astm.f3548.v21.GEN0100; or✅ uss1_core (2026-03-03T21:58:05.334174Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:05.334143Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:05.323752Z)
✅ uss1_dss (2026-03-03T21:58:05.336749Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:05.336792Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:05.409316Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:05.403358Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The valid flight should be successfully planned by the flight planner.
✅ uss1_core (2026-03-03T21:58:05.409285Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:05.341962Z)
✅ uss1_dss (2026-03-03T21:58:05.413406Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:05.413464Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:05.413508Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:05.428349Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:05.437774Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:05.438764Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:05.438804Z)
✅ uss1_core (2026-03-03T21:58:05.438836Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. Validate that the flight was shared correctly and is discoverable.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail. The flight should be successfully transitioned to Ended state by the flight planner.
✅ uss1_core (2026-03-03T21:58:05.475028Z)
This step verifies that ending/removal/cancellation of a flight resulted in the operational intent reference being removed from the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted removal. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_removed() in test_steps.py.
✅ uss1_dss (2026-03-03T21:58:05.443941Z)
✅ uss1_dss (2026-03-03T21:58:05.478422Z)
If the operational intent reference for the flight is still found in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:05.478499Z)
If the operational intent is still discoverable after it was transitioned to Ended, this check will fail per astm.f3548.v21.OPIN0040.
✅ uss1_core (2026-03-03T21:58:05.478499Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:05.529744Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:05.523623Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The valid flight intent should be successfully planned by the flight planner.
✅ uss1_core (2026-03-03T21:58:05.529714Z)
The tested USS is instructed to plan a flight that is constructed in a way that it intersects with Valid Flight by just
over IntersectionMinimumPrecision = 1 cm.
If the tested USS successfully plans the flight or otherwise fails to indicate a rejection, it means that it failed to correctly compute the conflicting intersection. Therefore, this check will fail if the USS indicates success in planning the flight from the user flight intent, per astm.f3548.v21.GEN0500.
✅ uss1_core (2026-03-03T21:58:05.562745Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:05.562716Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:05.536168Z)
✅ uss1_dss (2026-03-03T21:58:05.566569Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:05.566615Z)
interuss.automated_testing.flight_planning.DeleteFlightSuccess
✅ uss1_core (2026-03-03T21:58:05.593651Z)
This test checks that the USS validates correctly the operational intents it creates. Notably the following requirements:
It assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).
FlightIntentsResource that provides the following flight intents:
| Flight intent ID | Flight name | Usage State | UAS State | Invalid details |
|---|---|---|---|---|
valid_flight |
Valid Flight | Planned | Nominal | N/A |
valid_activated |
InUse | |||
valid_conflict_tiny_overlap |
Tiny Overlap Conflict Flight | Planned | Nominal | Conflicts with Flight 1 such that their 3D volumes have an overlap just above IntersectionMinimumPrecision = 1cm |
invalid_too_far_away |
Too Far Away Flight | Has a start time that is more than OiMaxPlanHorizon = 30 days ahead of time |
||
invalid_recently_ended |
Recently Ended Flight | Has an end time that is within 5 to 10 seconds in the past. |
Because the scenario involves activation of intents, all activated intents must be active during the execution of the test scenario. Additionally, their end time must leave sufficient time for the execution of the test scenario. For the sake of simplicity, it is recommended to set the start and end times of all the intents to the same range.
✅ Provided by invalid_flight_intents in top-level resource pool.
FlightPlannerResource that will be tested for its validation of operational intents.
✅ Provided by instance 2 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.
✅ Provided by dss in top-level resource pool.
The user flight intent that the test driver attempts to plan has a start time that is more than OiMaxPlanHorizon = 30 days ahead of time. As such, the attempt should be rejected.
If the USS successfully plans the flight or otherwise fails to indicate a rejection, it means that it failed to validate the intent provided. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per astm.f3548.v21.OPIN0030.
✅ uss2_core (2026-03-03T21:58:05.618208Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:05.618178Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:05.600272Z)
✅ uss1_dss (2026-03-03T21:58:05.620862Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:05.620906Z)
The user flight intent that the test driver attempts to plan has recently ended by just slightly more than TimeSyncMaxDifferentialSeconds = 5 seconds.
As such, if the USS synchronizes its time correctly, the attempt should be rejected.
If the USS successfully plans the flight or otherwise fails to indicate a rejection, it means that it failed to validate that the intent provided was in the past. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per one of the following requirements:
TimeSyncMaxDifferentialSeconds = 5 seconds of an industry-recognized time source as required by astm.f3548.v21.GEN0100; or✅ uss2_core (2026-03-03T21:58:05.637909Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:05.637862Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:05.625789Z)
✅ uss1_dss (2026-03-03T21:58:05.641470Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:05.641537Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:05.722946Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:05.716424Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The valid flight should be successfully planned by the flight planner.
✅ uss2_core (2026-03-03T21:58:05.722905Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:05.648368Z)
✅ uss1_dss (2026-03-03T21:58:05.728695Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:05.728758Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:05.728811Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:05.743803Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:05.757249Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:05.758266Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:05.758310Z)
✅ uss2_core (2026-03-03T21:58:05.758356Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. Validate that the flight was shared correctly and is discoverable.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail. The flight should be successfully transitioned to Ended state by the flight planner.
✅ uss2_core (2026-03-03T21:58:05.804508Z)
This step verifies that ending/removal/cancellation of a flight resulted in the operational intent reference being removed from the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted removal. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_removed() in test_steps.py.
✅ uss1_dss (2026-03-03T21:58:05.764079Z)
✅ uss1_dss (2026-03-03T21:58:05.808158Z)
If the operational intent reference for the flight is still found in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:05.808245Z)
If the operational intent is still discoverable after it was transitioned to Ended, this check will fail per astm.f3548.v21.OPIN0040.
✅ uss2_core (2026-03-03T21:58:05.808245Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:05.867621Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:05.860328Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The valid flight intent should be successfully planned by the flight planner.
✅ uss2_core (2026-03-03T21:58:05.867590Z)
The tested USS is instructed to plan a flight that is constructed in a way that it intersects with Valid Flight by just
over IntersectionMinimumPrecision = 1 cm.
If the tested USS successfully plans the flight or otherwise fails to indicate a rejection, it means that it failed to correctly compute the conflicting intersection. Therefore, this check will fail if the USS indicates success in planning the flight from the user flight intent, per astm.f3548.v21.GEN0500.
✅ uss2_core (2026-03-03T21:58:05.920907Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:05.920846Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:05.878799Z)
✅ uss1_dss (2026-03-03T21:58:05.928501Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:05.928576Z)
interuss.automated_testing.flight_planning.DeleteFlightSuccess
✅ uss2_core (2026-03-03T21:58:05.960730Z)
This test aims to test the strategic coordination requirements that relate to the prioritization scenarios where there exists a conflict with a higher priority flight:
It involves a tested USS and a control USS through which conflicting flights are injected.
It assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).
FlightIntentsResource that provides the following flight intents:
| Flight intent ID | Flight name | Priority | State | Must conflict with | Must not conflict with |
|---|---|---|---|---|---|
flight1_planned |
Flight 1 | Any | Accepted | Flight 2 | Flight 2m |
flight1_activated |
Activated | ||||
flight1m_planned |
Flight 1m | Accepted | Flight 2 | Flight 2m | |
flight1m_activated |
Activated | ||||
flight1c_activated |
Flight 1c | Activated | Flight 2m | N/A | |
flight2_planned |
Flight 2 | Higher than Flight 1* | Accepted | Flight 1 | N/A |
flight2_activated |
Activated | ||||
flight2m_activated |
Flight 2m | Activated | Flight 1c | Flight 1 |
Because the scenario involves activation of intents, the start times of all activated intents must be during the time the test scenario is executed (not before). Additionally, their end times must leave sufficient time for the execution of the test scenario.
✅ Provided by conflicting_flights in top-level resource pool.
FlightPlannerResource that is under test and will manage Flight 1.
✅ Provided by instance 1 in flight_planners in top-level resource pool.
FlightPlannerResource that will manage conflicting Flight 2.
✅ Provided by instance 1 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.
✅ Provided by dss in top-level resource pool.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:06.022239Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.016419Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The higher priority flight should be successfully planned by the control USS as there are no other flights in the area yet.
✅ uss1_core (2026-03-03T21:58:06.022210Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:05.967973Z)
✅ uss1_dss (2026-03-03T21:58:06.027217Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.027296Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.027359Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.041445Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:06.052221Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.053212Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:06.053252Z)
✅ uss1_core (2026-03-03T21:58:06.053284Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied planning because of
a conflict with a higher priority flight intent.
See plan_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully plans the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per astm.f3548.v21.SCD0015.
✅ uss1_core (2026-03-03T21:58:06.088941Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to plan the Flight 1 via the tested USS. However, it conflicts with Flight 2, which is of higher priority. As such it should be rejected per astm.f3548.v21.SCD0015.
✅ uss1_core (2026-03-03T21:58:06.088914Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:06.059983Z)
✅ uss1_dss (2026-03-03T21:58:06.092951Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.092998Z)
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail.
✅ uss1_core (2026-03-03T21:58:06.120415Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:06.174263Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.166995Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The first flight should be successfully planned by the tested USS.
✅ uss1_core (2026-03-03T21:58:06.174221Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:06.125802Z)
✅ uss1_dss (2026-03-03T21:58:06.179855Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.179909Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.179964Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.192147Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:06.204082Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.205541Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:06.205598Z)
✅ uss1_core (2026-03-03T21:58:06.205649Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
Just before directing the planning activity, the test director observes pre-existing notifications which cannot relate to the planning activity that has not yet happened. If these notifications cannot be retrieved, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI.
✅ uss1_core (2026-03-03T21:58:06.216277Z)
✅ uss1_core (2026-03-03T21:58:06.224586Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:06.298895Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.293213Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The second flight should be successfully planned by the control USS. It conflicts with Flight 1, but it has higher priority.
✅ uss1_core (2026-03-03T21:58:06.298865Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:06.232939Z)
✅ uss1_dss (2026-03-03T21:58:06.303537Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.303594Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.303639Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.315837Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:06.323777Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.324745Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:06.324784Z)
✅ uss1_core (2026-03-03T21:58:06.324826Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
The test director checks whether a notification reporting the creation of a conflict by Flight 2 was sent to UAS personnel for the control_uss as is required by SCD0090.
The test director also checks whether a notification reporting the creation of a new conflict with Flight 1 was sent to the UAS personnel for the tested_uss managing Flight 1 as is required by SCD0095.
The timeliness and completeness of these notifications will be checked for compliance with SCD0090 and SCD0095 in aggregate in a later test scenario -- only the raw data is gathered in this test scenario. When eligible notifications are found, they are reported as notes in the test scenario; if a USS does not have a scd0090_notification or scd0095_notification note, then uss_qualifier did not detect a required notification.
Note that these actions will not be performed if the test director was unable to retrieve the notifications before the planning activity.
We fetch the list of notifications. If the USS doesn't return a valid answer, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI and we cannot proceed with notification checks.
✅ uss1_core (2026-03-03T21:58:06.336174Z)
This page describes the content of a common test step where a user flight intent should be denied modification because
of a conflict with a higher priority flight intent.
See modify_planned_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0020.
✅ uss1_core (2026-03-03T21:58:06.382692Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to modify Flight 1 via the tested USS, which is planned. However, it conflicts with Flight 2, which is of higher priority and was planned in the meantime. As such it should be rejected per astm.f3548.v21.SCD0020.
✅ uss1_core (2026-03-03T21:58:06.382662Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:06.345452Z)
✅ uss1_dss (2026-03-03T21:58:06.386935Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.386999Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.387064Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.399026Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:06.407939Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.409296Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:06.409336Z)
✅ uss1_core (2026-03-03T21:58:06.409368Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. Because the modification attempt was invalid, either Flight 1 should not have been modified (because the USS kept the original accepted request), or it should have been removed (because the USS rejected the replacement plan provided).
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied activation because of
a conflict with a higher priority flight intent.
See activate_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully activates the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in activating the flight from the user flight intent, per astm.f3548.v21.SCD0025.
✅ uss1_core (2026-03-03T21:58:06.453756Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to activate Flight 1, however, it conflicts with Flight 2, which is also planned and of higher priority. Note that Flight 1 could be either planned or non-existent before this step. As such it should be rejected per astm.f3548.v21.SCD0025.
✅ uss1_core (2026-03-03T21:58:06.453729Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:06.417848Z)
✅ uss1_dss (2026-03-03T21:58:06.457839Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.457899Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.457940Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.469825Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:06.478075Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.479296Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:06.479335Z)
✅ uss1_core (2026-03-03T21:58:06.479366Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. Because the modification attempt was invalid, either Flight 1 should not have been modified (because the USS kept the original accepted request), or it should have been removed (because the USS rejected the replacement plan provided).
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail.
✅ uss1_core (2026-03-03T21:58:06.509133Z)
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:06.580432Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.574819Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates Flight 1, which should be done successfully given that it is now the highest-priority flight. Note that Flight 1 could be either planned or non-existent before this step. In the latter case, the flight will be directly activated without being planned beforehand.
✅ uss1_core (2026-03-03T21:58:06.580403Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:06.515688Z)
✅ uss1_dss (2026-03-03T21:58:06.584349Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.584450Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:06.584423Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.584516Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.593967Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:06.602183Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.603150Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:06.603188Z)
✅ uss1_core (2026-03-03T21:58:06.603218Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:06.673762Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.668131Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The second flight should be successfully planned by the control USS.
✅ uss1_core (2026-03-03T21:58:06.673733Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:06.609173Z)
✅ uss1_dss (2026-03-03T21:58:06.678325Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.678379Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.678421Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.690112Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:06.698031Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.698964Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:06.699020Z)
✅ uss1_core (2026-03-03T21:58:06.699055Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
Just before directing the planning activity, the test director observes pre-existing notifications which cannot relate to the planning activity that has not yet happened. This list of pre-existing notifications will be used later to determine if a new notification resulted from the planning activity. If these notifications cannot be retrieved, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI.
✅ uss1_core (2026-03-03T21:58:06.710486Z)
✅ uss1_core (2026-03-03T21:58:06.721334Z)
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:06.821645Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.816038Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates Flight 2, which should be done successfully given that it is the highest-priority flight.
✅ uss1_core (2026-03-03T21:58:06.821616Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:06.729354Z)
✅ uss1_dss (2026-03-03T21:58:06.826370Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.826467Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:06.826450Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.826505Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.838310Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:06.846299Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.847268Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:06.847308Z)
✅ uss1_core (2026-03-03T21:58:06.847339Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
The test director checks whether a notification reporting the modification of Flight 2 while in conflict was sent to UAS personnel for the control_uss as required by SCD0090.
The test director also checks whether a notification reporting the modification of a flight conflicting with Flight 1 was sent to the UAS personnel for the tested_uss managing Flight 1 as required by SCD0095.
The timeliness and completeness of these notifications will be checked for compliance with SCD0090 and SCD0095 in aggregate in a later test scenario -- only the raw data is gathered in this test scenario. When eligible notifications are found, they are reported as notes in the test scenario; if a USS does not have a scd0090_notification or scd0095_notification note, then uss_qualifier did not detect a required notification.
Note that these actions will not be performed if the test director was unable to retrieve the notifications before the planning activity.
We fetch the list of notifications. If the USS doesn't return a valid answer, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI and we cannot proceed with notification checks.
✅ uss1_core (2026-03-03T21:58:06.859559Z)
Before execution of this step, flights 1 and 2 are activated and in conflict. Flight 2 is the highest-priority flight. The virtual user attempts to modify Flight 1 in a way that still conflicts with Flight 2, though the conflict is likely reduced.
A practical usage of this workflow might consist of the following sequence of events:
This last action is the virtual user flight planning interaction the USS under test will encounter in this test step.
This page describes the content of a common test case where a valid user flight intent in activated state is tentatively
modified by a flight planned. Multiple outcomes may be valid.
See modify_activated_flight in test_steps.py.
All flight intent data provided is correct and valid. The (already activated) provided flight intent may be in conflict with another activated flight, but only if this conflict already existed before the modification was initiated.
If the provided flight intent is not in conflict with another intent the USS should have successfully modified the flight per astm.f3548.v21.SCD0030. If the USS fails to modify the flight, wrongly indicates a conflict, or wrongly indicates the activated state of the flight, this check will fail.
If the provided flight intent is in conflict with another intent and that a pre-existing conflict was present, the USS may have decided to be more conservative and to not support modification. In such case, the USS may indicate that the operation is not supported instead of modifying the flight per astm.f3548.v21.SCD0030. If the USS fails to modify the flight, or fails to indicate that the modification is not supported, or wrongly indicates the activated state of the flight, this check will fail.
Do take note that if the USS rejects the modification when a pre-existing conflict was present, this check will not fail, but the following Rejected modification check will. Refer to this check for more information.
✅ uss1_core (2026-03-03T21:58:06.956055Z)
If the provided flight intent is in conflict with another intent and that a pre-existing conflict was present, the USS may have rejected the modification instead of modifying it or indicating that the modification is not supported. This could be the case for example if the USS does not support directly update of intents and instead delete the previous one and create a new one. This may or may not be strictly speaking a failure to meet a requirement, but we cannot distinguish between an actual failure to meet the requirement and a reasonable behavior due to implementation limitations.
As such, if the pre-existing conflict was present, and that the USS rejected the modification, this check will produce a low severity finding per astm.f3548.v21.SCD0030.
✅ uss1_core (2026-03-03T21:58:06.956111Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.945547Z)
The requested flight should have been modified essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The virtual user attempts to modify Flight 1 to reduce/mitigate the conflict.
The successful outcomes of the modification attempts:
If the USS rejects the modification, the USS is indicating the modification is "not allowed". This is not correct when judging solely on the rules of F3548-21. However, USSs may (generally) apply any number of additional rules to determine whether or not a flight planning action is accepted by the USS. Because of this, a rejection is not conclusive evidence of SCD0030 non-compliance since the rejection may be due to a different reason. However, rejection in this case would not seem to be justified on the basis of conservatism since rejection is effectively a refusal to communicate relevant information to other USSs and operators in the ecosystem. Therefore, a rejected modification will indicate a low severity failure, producing a finding since we cannot distinguish between an actual failure to meet the requirement and a reasonable behavior due non-F3548-21 constraints. Since this finding is a low severity failure, it does not indicate a failure to comply with a requirement.
In any case, whatever is the outcome of this step, there should not be any impact on the rest of the execution of the scenario. An intent should exist (this is checked in the next step) and it should be either Flight 1 or Flight 1m, both of which can be used in the next step since neither conflicts with Flight 2m.
✅ uss1_core (2026-03-03T21:58:06.955981Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:06.868090Z)
✅ uss1_dss (2026-03-03T21:58:06.960928Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.961042Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:06.961022Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:06.961080Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.973154Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:06.981248Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:06.982203Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:06.982242Z)
✅ uss1_core (2026-03-03T21:58:06.982274Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. If the modification was accepted, Flight 1 should have been modified. If the modification was not supported or the modification was rejected, Flight 1 should not have been modified and should still exist. If it does not exist, it means that there is an active flight without an operational intent, which is a failure to meet interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent in planned state should be
successfully modified by a flight planner. See modify_planned_flight in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been modified by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS fails to modify the flight, wrongly indicates a conflict, or wrongly indicates the planned state of the flight, this check will fail.
✅ uss1_core (2026-03-03T21:58:07.070055Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:07.064466Z)
The requested flight should have been modified essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver modifies (activated) Flight 2 with the control USS so that it is not anymore in conflict with (activated) flight of test USS. This should succeed and leave Flight 1 clear of conflict.
If flight modification is not supported by the USS, the next test step cannot be performed and the test case will end here.
✅ uss1_core (2026-03-03T21:58:07.070026Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:06.988930Z)
✅ uss1_dss (2026-03-03T21:58:07.074487Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.074581Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:07.074563Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:07.074617Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.086275Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:07.094095Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.095027Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:07.095078Z)
✅ uss1_core (2026-03-03T21:58:07.095110Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied modification because
of a conflict with a higher priority flight intent.
See modify_activated_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0030.
✅ uss1_core (2026-03-03T21:58:07.142381Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to modify Flight 1 so that it becomes in conflict with Flight 2. Both flights are activated at that point. However, because the conflict did not exist when the modification was initiated, it should be rejected per astm.f3548.v21.SCD0030. In addition, Flight 1 should not have been removed, because doing so would leave an aircraft in flight without any flight plan.
✅ uss1_core (2026-03-03T21:58:07.142353Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:07.103262Z)
✅ uss1_dss (2026-03-03T21:58:07.146579Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Because the modification attempt was invalid, Flight 1 should not have been modified.
✅ uss1_core (2026-03-03T21:58:07.146627Z)
interuss.automated_testing.flight_planning.DeleteFlightSuccess
✅ uss1_core (2026-03-03T21:58:07.175941Z)
✅ uss1_core (2026-03-03T21:58:07.202727Z)
This test aims to test the strategic coordination requirements that relate to the prioritization scenarios where there exists a conflict with a higher priority flight:
It involves a tested USS and a control USS through which conflicting flights are injected.
It assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).
FlightIntentsResource that provides the following flight intents:
| Flight intent ID | Flight name | Priority | State | Must conflict with | Must not conflict with |
|---|---|---|---|---|---|
flight1_planned |
Flight 1 | Any | Accepted | Flight 2 | Flight 2m |
flight1_activated |
Activated | ||||
flight1m_planned |
Flight 1m | Accepted | Flight 2 | Flight 2m | |
flight1m_activated |
Activated | ||||
flight1c_activated |
Flight 1c | Activated | Flight 2m | N/A | |
flight2_planned |
Flight 2 | Higher than Flight 1* | Accepted | Flight 1 | N/A |
flight2_activated |
Activated | ||||
flight2m_activated |
Flight 2m | Activated | Flight 1c | Flight 1 |
Because the scenario involves activation of intents, the start times of all activated intents must be during the time the test scenario is executed (not before). Additionally, their end times must leave sufficient time for the execution of the test scenario.
✅ Provided by conflicting_flights in top-level resource pool.
FlightPlannerResource that is under test and will manage Flight 1.
✅ Provided by instance 1 in flight_planners in top-level resource pool.
FlightPlannerResource that will manage conflicting Flight 2.
✅ Provided by instance 2 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.
✅ Provided by dss in top-level resource pool.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:07.259410Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:07.253383Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The higher priority flight should be successfully planned by the control USS as there are no other flights in the area yet.
✅ uss2_core (2026-03-03T21:58:07.259378Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:07.210051Z)
✅ uss1_dss (2026-03-03T21:58:07.263569Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:07.263630Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:07.263673Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:07.275114Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:07.283359Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:07.284373Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:07.284413Z)
✅ uss2_core (2026-03-03T21:58:07.284445Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied planning because of
a conflict with a higher priority flight intent.
See plan_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully plans the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per astm.f3548.v21.SCD0015.
✅ uss1_core (2026-03-03T21:58:07.328200Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to plan the Flight 1 via the tested USS. However, it conflicts with Flight 2, which is of higher priority. As such it should be rejected per astm.f3548.v21.SCD0015.
✅ uss1_core (2026-03-03T21:58:07.328169Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:07.291385Z)
✅ uss1_dss (2026-03-03T21:58:07.331991Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:07.332059Z)
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail.
✅ uss2_core (2026-03-03T21:58:07.358960Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:07.423442Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:07.417645Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The first flight should be successfully planned by the tested USS.
✅ uss1_core (2026-03-03T21:58:07.423410Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:07.364459Z)
✅ uss1_dss (2026-03-03T21:58:07.427596Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.427672Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:07.427726Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.439383Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:07.447343Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.448324Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:07.448362Z)
✅ uss1_core (2026-03-03T21:58:07.448393Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
Just before directing the planning activity, the test director observes pre-existing notifications which cannot relate to the planning activity that has not yet happened. If these notifications cannot be retrieved, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI.
✅ uss2_core (2026-03-03T21:58:07.455631Z)
✅ uss1_core (2026-03-03T21:58:07.466539Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:07.567549Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:07.561676Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The second flight should be successfully planned by the control USS. It conflicts with Flight 1, but it has higher priority.
✅ uss2_core (2026-03-03T21:58:07.567519Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:07.472935Z)
✅ uss1_dss (2026-03-03T21:58:07.572790Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:07.572847Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:07.572890Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:07.583421Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:07.591874Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:07.592841Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:07.592880Z)
✅ uss2_core (2026-03-03T21:58:07.592912Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
The test director checks whether a notification reporting the creation of a conflict by Flight 2 was sent to UAS personnel for the control_uss as is required by SCD0090.
The test director also checks whether a notification reporting the creation of a new conflict with Flight 1 was sent to the UAS personnel for the tested_uss managing Flight 1 as is required by SCD0095.
The timeliness and completeness of these notifications will be checked for compliance with SCD0090 and SCD0095 in aggregate in a later test scenario -- only the raw data is gathered in this test scenario. When eligible notifications are found, they are reported as notes in the test scenario; if a USS does not have a scd0090_notification or scd0095_notification note, then uss_qualifier did not detect a required notification.
Note that these actions will not be performed if the test director was unable to retrieve the notifications before the planning activity.
We fetch the list of notifications. If the USS doesn't return a valid answer, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI and we cannot proceed with notification checks.
✅ uss2_core (2026-03-03T21:58:07.602723Z)
✅ uss1_core (2026-03-03T21:58:07.614423Z)
This page describes the content of a common test step where a user flight intent should be denied modification because
of a conflict with a higher priority flight intent.
See modify_planned_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0020.
✅ uss1_core (2026-03-03T21:58:07.672440Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to modify Flight 1 via the tested USS, which is planned. However, it conflicts with Flight 2, which is of higher priority and was planned in the meantime. As such it should be rejected per astm.f3548.v21.SCD0020.
✅ uss1_core (2026-03-03T21:58:07.672412Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:07.623932Z)
✅ uss1_dss (2026-03-03T21:58:07.677181Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.677243Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:07.677285Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.689404Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:07.698218Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.699181Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:07.699220Z)
✅ uss1_core (2026-03-03T21:58:07.699251Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. Because the modification attempt was invalid, either Flight 1 should not have been modified (because the USS kept the original accepted request), or it should have been removed (because the USS rejected the replacement plan provided).
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied activation because of
a conflict with a higher priority flight intent.
See activate_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully activates the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in activating the flight from the user flight intent, per astm.f3548.v21.SCD0025.
✅ uss1_core (2026-03-03T21:58:07.747658Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to activate Flight 1, however, it conflicts with Flight 2, which is also planned and of higher priority. Note that Flight 1 could be either planned or non-existent before this step. As such it should be rejected per astm.f3548.v21.SCD0025.
✅ uss1_core (2026-03-03T21:58:07.747629Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:07.707855Z)
✅ uss1_dss (2026-03-03T21:58:07.752185Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.752243Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:07.752285Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.764414Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:07.772475Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.773429Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:07.773467Z)
✅ uss1_core (2026-03-03T21:58:07.773497Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. Because the modification attempt was invalid, either Flight 1 should not have been modified (because the USS kept the original accepted request), or it should have been removed (because the USS rejected the replacement plan provided).
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail.
✅ uss2_core (2026-03-03T21:58:07.808876Z)
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:07.897741Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:07.891789Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates Flight 1, which should be done successfully given that it is now the highest-priority flight. Note that Flight 1 could be either planned or non-existent before this step. In the latter case, the flight will be directly activated without being planned beforehand.
✅ uss1_core (2026-03-03T21:58:07.897711Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:07.815623Z)
✅ uss1_dss (2026-03-03T21:58:07.901940Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.902074Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:07.902051Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:07.902114Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.914535Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:07.922744Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:07.924114Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:07.924164Z)
✅ uss1_core (2026-03-03T21:58:07.924230Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:08.015327Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:08.009312Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The second flight should be successfully planned by the control USS.
✅ uss2_core (2026-03-03T21:58:08.015294Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:07.930474Z)
✅ uss1_dss (2026-03-03T21:58:08.020458Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:08.020515Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:08.020556Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:08.031798Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:08.039837Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:08.040840Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:08.040879Z)
✅ uss2_core (2026-03-03T21:58:08.040910Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
Just before directing the planning activity, the test director observes pre-existing notifications which cannot relate to the planning activity that has not yet happened. This list of pre-existing notifications will be used later to determine if a new notification resulted from the planning activity. If these notifications cannot be retrieved, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI.
✅ uss2_core (2026-03-03T21:58:08.051343Z)
✅ uss1_core (2026-03-03T21:58:08.064316Z)
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:08.160155Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:08.154565Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates Flight 2, which should be done successfully given that it is the highest-priority flight.
✅ uss2_core (2026-03-03T21:58:08.160127Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:08.071680Z)
✅ uss1_dss (2026-03-03T21:58:08.165256Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:08.165349Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:08.165331Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:08.165386Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:08.176071Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:08.184200Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:08.185159Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:08.185198Z)
✅ uss2_core (2026-03-03T21:58:08.185229Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
The test director checks whether a notification reporting the modification of Flight 2 while in conflict was sent to UAS personnel for the control_uss as required by SCD0090.
The test director also checks whether a notification reporting the modification of a flight conflicting with Flight 1 was sent to the UAS personnel for the tested_uss managing Flight 1 as required by SCD0095.
The timeliness and completeness of these notifications will be checked for compliance with SCD0090 and SCD0095 in aggregate in a later test scenario -- only the raw data is gathered in this test scenario. When eligible notifications are found, they are reported as notes in the test scenario; if a USS does not have a scd0090_notification or scd0095_notification note, then uss_qualifier did not detect a required notification.
Note that these actions will not be performed if the test director was unable to retrieve the notifications before the planning activity.
We fetch the list of notifications. If the USS doesn't return a valid answer, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI and we cannot proceed with notification checks.
✅ uss2_core (2026-03-03T21:58:08.195605Z)
✅ uss1_core (2026-03-03T21:58:08.208875Z)
Before execution of this step, flights 1 and 2 are activated and in conflict. Flight 2 is the highest-priority flight. The virtual user attempts to modify Flight 1 in a way that still conflicts with Flight 2, though the conflict is likely reduced.
A practical usage of this workflow might consist of the following sequence of events:
This last action is the virtual user flight planning interaction the USS under test will encounter in this test step.
This page describes the content of a common test case where a valid user flight intent in activated state is tentatively
modified by a flight planned. Multiple outcomes may be valid.
See modify_activated_flight in test_steps.py.
All flight intent data provided is correct and valid. The (already activated) provided flight intent may be in conflict with another activated flight, but only if this conflict already existed before the modification was initiated.
If the provided flight intent is not in conflict with another intent the USS should have successfully modified the flight per astm.f3548.v21.SCD0030. If the USS fails to modify the flight, wrongly indicates a conflict, or wrongly indicates the activated state of the flight, this check will fail.
If the provided flight intent is in conflict with another intent and that a pre-existing conflict was present, the USS may have decided to be more conservative and to not support modification. In such case, the USS may indicate that the operation is not supported instead of modifying the flight per astm.f3548.v21.SCD0030. If the USS fails to modify the flight, or fails to indicate that the modification is not supported, or wrongly indicates the activated state of the flight, this check will fail.
Do take note that if the USS rejects the modification when a pre-existing conflict was present, this check will not fail, but the following Rejected modification check will. Refer to this check for more information.
✅ uss1_core (2026-03-03T21:58:08.333168Z)
If the provided flight intent is in conflict with another intent and that a pre-existing conflict was present, the USS may have rejected the modification instead of modifying it or indicating that the modification is not supported. This could be the case for example if the USS does not support directly update of intents and instead delete the previous one and create a new one. This may or may not be strictly speaking a failure to meet a requirement, but we cannot distinguish between an actual failure to meet the requirement and a reasonable behavior due to implementation limitations.
As such, if the pre-existing conflict was present, and that the USS rejected the modification, this check will produce a low severity finding per astm.f3548.v21.SCD0030.
✅ uss1_core (2026-03-03T21:58:08.333215Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:08.327503Z)
The requested flight should have been modified essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The virtual user attempts to modify Flight 1 to reduce/mitigate the conflict.
The successful outcomes of the modification attempts:
If the USS rejects the modification, the USS is indicating the modification is "not allowed". This is not correct when judging solely on the rules of F3548-21. However, USSs may (generally) apply any number of additional rules to determine whether or not a flight planning action is accepted by the USS. Because of this, a rejection is not conclusive evidence of SCD0030 non-compliance since the rejection may be due to a different reason. However, rejection in this case would not seem to be justified on the basis of conservatism since rejection is effectively a refusal to communicate relevant information to other USSs and operators in the ecosystem. Therefore, a rejected modification will indicate a low severity failure, producing a finding since we cannot distinguish between an actual failure to meet the requirement and a reasonable behavior due non-F3548-21 constraints. Since this finding is a low severity failure, it does not indicate a failure to comply with a requirement.
In any case, whatever is the outcome of this step, there should not be any impact on the rest of the execution of the scenario. An intent should exist (this is checked in the next step) and it should be either Flight 1 or Flight 1m, both of which can be used in the next step since neither conflicts with Flight 2m.
✅ uss1_core (2026-03-03T21:58:08.333140Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:08.218201Z)
✅ uss1_dss (2026-03-03T21:58:08.338506Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:08.338601Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:08.338582Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:08.338638Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:08.352238Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:08.360204Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:08.361176Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:08.361215Z)
✅ uss1_core (2026-03-03T21:58:08.361247Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. If the modification was accepted, Flight 1 should have been modified. If the modification was not supported or the modification was rejected, Flight 1 should not have been modified and should still exist. If it does not exist, it means that there is an active flight without an operational intent, which is a failure to meet interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent in planned state should be
successfully modified by a flight planner. See modify_planned_flight in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been modified by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS fails to modify the flight, wrongly indicates a conflict, or wrongly indicates the planned state of the flight, this check will fail.
✅ uss2_core (2026-03-03T21:58:08.473488Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:08.467877Z)
The requested flight should have been modified essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver modifies (activated) Flight 2 with the control USS so that it is not anymore in conflict with (activated) flight of test USS. This should succeed and leave Flight 1 clear of conflict.
If flight modification is not supported by the USS, the next test step cannot be performed and the test case will end here.
✅ uss2_core (2026-03-03T21:58:08.473459Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:08.368468Z)
✅ uss1_dss (2026-03-03T21:58:08.478571Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:08.478666Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:08.478648Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:08.478702Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:08.492260Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:08.500828Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:08.501843Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:08.501883Z)
✅ uss2_core (2026-03-03T21:58:08.501914Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied modification because
of a conflict with a higher priority flight intent.
See modify_activated_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0030.
✅ uss1_core (2026-03-03T21:58:08.580900Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to modify Flight 1 so that it becomes in conflict with Flight 2. Both flights are activated at that point. However, because the conflict did not exist when the modification was initiated, it should be rejected per astm.f3548.v21.SCD0030. In addition, Flight 1 should not have been removed, because doing so would leave an aircraft in flight without any flight plan.
✅ uss1_core (2026-03-03T21:58:08.580869Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:08.511613Z)
✅ uss1_dss (2026-03-03T21:58:08.586333Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Because the modification attempt was invalid, Flight 1 should not have been modified.
✅ uss1_core (2026-03-03T21:58:08.586387Z)
interuss.automated_testing.flight_planning.DeleteFlightSuccess
✅ uss2_core (2026-03-03T21:58:08.621990Z)
✅ uss1_core (2026-03-03T21:58:08.654411Z)
This test aims to test the strategic coordination requirements that relate to the prioritization scenarios where there exists a conflict with a higher priority flight:
It involves a tested USS and a control USS through which conflicting flights are injected.
It assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).
FlightIntentsResource that provides the following flight intents:
| Flight intent ID | Flight name | Priority | State | Must conflict with | Must not conflict with |
|---|---|---|---|---|---|
flight1_planned |
Flight 1 | Any | Accepted | Flight 2 | Flight 2m |
flight1_activated |
Activated | ||||
flight1m_planned |
Flight 1m | Accepted | Flight 2 | Flight 2m | |
flight1m_activated |
Activated | ||||
flight1c_activated |
Flight 1c | Activated | Flight 2m | N/A | |
flight2_planned |
Flight 2 | Higher than Flight 1* | Accepted | Flight 1 | N/A |
flight2_activated |
Activated | ||||
flight2m_activated |
Flight 2m | Activated | Flight 1c | Flight 1 |
Because the scenario involves activation of intents, the start times of all activated intents must be during the time the test scenario is executed (not before). Additionally, their end times must leave sufficient time for the execution of the test scenario.
✅ Provided by conflicting_flights in top-level resource pool.
FlightPlannerResource that is under test and will manage Flight 1.
✅ Provided by instance 2 in flight_planners in top-level resource pool.
FlightPlannerResource that will manage conflicting Flight 2.
✅ Provided by instance 1 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.
✅ Provided by dss in top-level resource pool.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:08.745642Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:08.738864Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The higher priority flight should be successfully planned by the control USS as there are no other flights in the area yet.
✅ uss1_core (2026-03-03T21:58:08.745603Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:08.661499Z)
✅ uss1_dss (2026-03-03T21:58:08.750831Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:08.750909Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:08.750984Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:08.769819Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:08.778409Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:08.780095Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:08.780186Z)
✅ uss1_core (2026-03-03T21:58:08.780265Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied planning because of
a conflict with a higher priority flight intent.
See plan_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully plans the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per astm.f3548.v21.SCD0015.
✅ uss2_core (2026-03-03T21:58:08.858310Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to plan the Flight 1 via the tested USS. However, it conflicts with Flight 2, which is of higher priority. As such it should be rejected per astm.f3548.v21.SCD0015.
✅ uss2_core (2026-03-03T21:58:08.858246Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:08.791364Z)
✅ uss1_dss (2026-03-03T21:58:08.865271Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:08.865341Z)
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail.
✅ uss1_core (2026-03-03T21:58:08.906668Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:09.001193Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:08.988714Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The first flight should be successfully planned by the tested USS.
✅ uss2_core (2026-03-03T21:58:09.001162Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:08.912311Z)
✅ uss1_dss (2026-03-03T21:58:09.006853Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:09.006911Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:09.006955Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:09.020242Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:09.028578Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:09.029574Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:09.029613Z)
✅ uss2_core (2026-03-03T21:58:09.029645Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
Just before directing the planning activity, the test director observes pre-existing notifications which cannot relate to the planning activity that has not yet happened. If these notifications cannot be retrieved, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI.
✅ uss1_core (2026-03-03T21:58:09.042038Z)
✅ uss2_core (2026-03-03T21:58:09.055832Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:09.186955Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:09.181105Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The second flight should be successfully planned by the control USS. It conflicts with Flight 1, but it has higher priority.
✅ uss1_core (2026-03-03T21:58:09.186926Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:09.065312Z)
✅ uss1_dss (2026-03-03T21:58:09.192940Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:09.192997Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:09.193060Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:09.207530Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:09.215760Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:09.216782Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:09.216822Z)
✅ uss1_core (2026-03-03T21:58:09.216854Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
The test director checks whether a notification reporting the creation of a conflict by Flight 2 was sent to UAS personnel for the control_uss as is required by SCD0090.
The test director also checks whether a notification reporting the creation of a new conflict with Flight 1 was sent to the UAS personnel for the tested_uss managing Flight 1 as is required by SCD0095.
The timeliness and completeness of these notifications will be checked for compliance with SCD0090 and SCD0095 in aggregate in a later test scenario -- only the raw data is gathered in this test scenario. When eligible notifications are found, they are reported as notes in the test scenario; if a USS does not have a scd0090_notification or scd0095_notification note, then uss_qualifier did not detect a required notification.
Note that these actions will not be performed if the test director was unable to retrieve the notifications before the planning activity.
We fetch the list of notifications. If the USS doesn't return a valid answer, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI and we cannot proceed with notification checks.
✅ uss1_core (2026-03-03T21:58:09.235209Z)
✅ uss2_core (2026-03-03T21:58:09.249673Z)
This page describes the content of a common test step where a user flight intent should be denied modification because
of a conflict with a higher priority flight intent.
See modify_planned_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0020.
✅ uss2_core (2026-03-03T21:58:09.327182Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to modify Flight 1 via the tested USS, which is planned. However, it conflicts with Flight 2, which is of higher priority and was planned in the meantime. As such it should be rejected per astm.f3548.v21.SCD0020.
✅ uss2_core (2026-03-03T21:58:09.327149Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:09.263274Z)
✅ uss1_dss (2026-03-03T21:58:09.332379Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:09.332445Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:09.332487Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:09.345263Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:09.354111Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:09.355210Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:09.355251Z)
✅ uss2_core (2026-03-03T21:58:09.355296Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. Because the modification attempt was invalid, either Flight 1 should not have been modified (because the USS kept the original accepted request), or it should have been removed (because the USS rejected the replacement plan provided).
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied activation because of
a conflict with a higher priority flight intent.
See activate_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully activates the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in activating the flight from the user flight intent, per astm.f3548.v21.SCD0025.
✅ uss2_core (2026-03-03T21:58:09.406471Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to activate Flight 1, however, it conflicts with Flight 2, which is also planned and of higher priority. Note that Flight 1 could be either planned or non-existent before this step. As such it should be rejected per astm.f3548.v21.SCD0025.
✅ uss2_core (2026-03-03T21:58:09.406442Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:09.364276Z)
✅ uss1_dss (2026-03-03T21:58:09.411434Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:09.411493Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:09.411535Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:09.424047Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:09.432347Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:09.433335Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:09.433373Z)
✅ uss2_core (2026-03-03T21:58:09.433403Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. Because the modification attempt was invalid, either Flight 1 should not have been modified (because the USS kept the original accepted request), or it should have been removed (because the USS rejected the replacement plan provided).
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail.
✅ uss1_core (2026-03-03T21:58:09.473186Z)
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:09.566564Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:09.560740Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates Flight 1, which should be done successfully given that it is now the highest-priority flight. Note that Flight 1 could be either planned or non-existent before this step. In the latter case, the flight will be directly activated without being planned beforehand.
✅ uss2_core (2026-03-03T21:58:09.566534Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:09.479888Z)
✅ uss1_dss (2026-03-03T21:58:09.570905Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:09.570996Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:09.570978Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:09.571063Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:09.583502Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:09.591604Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:09.592566Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:09.592604Z)
✅ uss2_core (2026-03-03T21:58:09.592638Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:09.712389Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:09.706487Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The second flight should be successfully planned by the control USS.
✅ uss1_core (2026-03-03T21:58:09.712360Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:09.598730Z)
✅ uss1_dss (2026-03-03T21:58:09.717625Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:09.717682Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:09.717724Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:09.732731Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:09.740783Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:09.741821Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:09.741876Z)
✅ uss1_core (2026-03-03T21:58:09.741912Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
Just before directing the planning activity, the test director observes pre-existing notifications which cannot relate to the planning activity that has not yet happened. This list of pre-existing notifications will be used later to determine if a new notification resulted from the planning activity. If these notifications cannot be retrieved, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI.
✅ uss1_core (2026-03-03T21:58:09.757182Z)
✅ uss2_core (2026-03-03T21:58:09.770998Z)
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:09.906426Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:09.900606Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates Flight 2, which should be done successfully given that it is the highest-priority flight.
✅ uss1_core (2026-03-03T21:58:09.906396Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:09.780268Z)
✅ uss1_dss (2026-03-03T21:58:09.911414Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:09.911515Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:09.911491Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:09.911554Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:09.925986Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:09.934045Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:09.935044Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:09.935084Z)
✅ uss1_core (2026-03-03T21:58:09.935118Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
The test director checks whether a notification reporting the modification of Flight 2 while in conflict was sent to UAS personnel for the control_uss as required by SCD0090.
The test director also checks whether a notification reporting the modification of a flight conflicting with Flight 1 was sent to the UAS personnel for the tested_uss managing Flight 1 as required by SCD0095.
The timeliness and completeness of these notifications will be checked for compliance with SCD0090 and SCD0095 in aggregate in a later test scenario -- only the raw data is gathered in this test scenario. When eligible notifications are found, they are reported as notes in the test scenario; if a USS does not have a scd0090_notification or scd0095_notification note, then uss_qualifier did not detect a required notification.
Note that these actions will not be performed if the test director was unable to retrieve the notifications before the planning activity.
We fetch the list of notifications. If the USS doesn't return a valid answer, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI and we cannot proceed with notification checks.
✅ uss1_core (2026-03-03T21:58:09.950726Z)
✅ uss2_core (2026-03-03T21:58:09.963715Z)
Before execution of this step, flights 1 and 2 are activated and in conflict. Flight 2 is the highest-priority flight. The virtual user attempts to modify Flight 1 in a way that still conflicts with Flight 2, though the conflict is likely reduced.
A practical usage of this workflow might consist of the following sequence of events:
This last action is the virtual user flight planning interaction the USS under test will encounter in this test step.
This page describes the content of a common test case where a valid user flight intent in activated state is tentatively
modified by a flight planned. Multiple outcomes may be valid.
See modify_activated_flight in test_steps.py.
All flight intent data provided is correct and valid. The (already activated) provided flight intent may be in conflict with another activated flight, but only if this conflict already existed before the modification was initiated.
If the provided flight intent is not in conflict with another intent the USS should have successfully modified the flight per astm.f3548.v21.SCD0030. If the USS fails to modify the flight, wrongly indicates a conflict, or wrongly indicates the activated state of the flight, this check will fail.
If the provided flight intent is in conflict with another intent and that a pre-existing conflict was present, the USS may have decided to be more conservative and to not support modification. In such case, the USS may indicate that the operation is not supported instead of modifying the flight per astm.f3548.v21.SCD0030. If the USS fails to modify the flight, or fails to indicate that the modification is not supported, or wrongly indicates the activated state of the flight, this check will fail.
Do take note that if the USS rejects the modification when a pre-existing conflict was present, this check will not fail, but the following Rejected modification check will. Refer to this check for more information.
✅ uss2_core (2026-03-03T21:58:10.097193Z)
If the provided flight intent is in conflict with another intent and that a pre-existing conflict was present, the USS may have rejected the modification instead of modifying it or indicating that the modification is not supported. This could be the case for example if the USS does not support directly update of intents and instead delete the previous one and create a new one. This may or may not be strictly speaking a failure to meet a requirement, but we cannot distinguish between an actual failure to meet the requirement and a reasonable behavior due to implementation limitations.
As such, if the pre-existing conflict was present, and that the USS rejected the modification, this check will produce a low severity finding per astm.f3548.v21.SCD0030.
✅ uss2_core (2026-03-03T21:58:10.097239Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:10.091384Z)
The requested flight should have been modified essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The virtual user attempts to modify Flight 1 to reduce/mitigate the conflict.
The successful outcomes of the modification attempts:
If the USS rejects the modification, the USS is indicating the modification is "not allowed". This is not correct when judging solely on the rules of F3548-21. However, USSs may (generally) apply any number of additional rules to determine whether or not a flight planning action is accepted by the USS. Because of this, a rejection is not conclusive evidence of SCD0030 non-compliance since the rejection may be due to a different reason. However, rejection in this case would not seem to be justified on the basis of conservatism since rejection is effectively a refusal to communicate relevant information to other USSs and operators in the ecosystem. Therefore, a rejected modification will indicate a low severity failure, producing a finding since we cannot distinguish between an actual failure to meet the requirement and a reasonable behavior due non-F3548-21 constraints. Since this finding is a low severity failure, it does not indicate a failure to comply with a requirement.
In any case, whatever is the outcome of this step, there should not be any impact on the rest of the execution of the scenario. An intent should exist (this is checked in the next step) and it should be either Flight 1 or Flight 1m, both of which can be used in the next step since neither conflicts with Flight 2m.
✅ uss2_core (2026-03-03T21:58:10.097164Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:09.972892Z)
✅ uss1_dss (2026-03-03T21:58:10.102484Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:10.102578Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:10.102560Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:10.102620Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:10.116488Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:10.124778Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:10.125730Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:10.125769Z)
✅ uss2_core (2026-03-03T21:58:10.125806Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. If the modification was accepted, Flight 1 should have been modified. If the modification was not supported or the modification was rejected, Flight 1 should not have been modified and should still exist. If it does not exist, it means that there is an active flight without an operational intent, which is a failure to meet interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent in planned state should be
successfully modified by a flight planner. See modify_planned_flight in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been modified by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS fails to modify the flight, wrongly indicates a conflict, or wrongly indicates the planned state of the flight, this check will fail.
✅ uss1_core (2026-03-03T21:58:10.282368Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:10.276341Z)
The requested flight should have been modified essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver modifies (activated) Flight 2 with the control USS so that it is not anymore in conflict with (activated) flight of test USS. This should succeed and leave Flight 1 clear of conflict.
If flight modification is not supported by the USS, the next test step cannot be performed and the test case will end here.
✅ uss1_core (2026-03-03T21:58:10.282337Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:10.132732Z)
✅ uss1_dss (2026-03-03T21:58:10.287765Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:10.287862Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:10.287843Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:10.287898Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:10.304671Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:10.313182Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:10.314141Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:10.314180Z)
✅ uss1_core (2026-03-03T21:58:10.314211Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied modification because
of a conflict with a higher priority flight intent.
See modify_activated_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0030.
✅ uss2_core (2026-03-03T21:58:10.388067Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to modify Flight 1 so that it becomes in conflict with Flight 2. Both flights are activated at that point. However, because the conflict did not exist when the modification was initiated, it should be rejected per astm.f3548.v21.SCD0030. In addition, Flight 1 should not have been removed, because doing so would leave an aircraft in flight without any flight plan.
✅ uss2_core (2026-03-03T21:58:10.387974Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:10.322983Z)
✅ uss1_dss (2026-03-03T21:58:10.392865Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Because the modification attempt was invalid, Flight 1 should not have been modified.
✅ uss2_core (2026-03-03T21:58:10.392912Z)
interuss.automated_testing.flight_planning.DeleteFlightSuccess
✅ uss1_core (2026-03-03T21:58:10.433151Z)
✅ uss2_core (2026-03-03T21:58:10.464507Z)
This test aims to test the strategic coordination requirements that relate to the prioritization scenarios where there exists a conflict with a higher priority flight:
It involves a tested USS and a control USS through which conflicting flights are injected.
It assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).
FlightIntentsResource that provides the following flight intents:
| Flight intent ID | Flight name | Priority | State | Must conflict with | Must not conflict with |
|---|---|---|---|---|---|
flight1_planned |
Flight 1 | Any | Accepted | Flight 2 | Flight 2m |
flight1_activated |
Activated | ||||
flight1m_planned |
Flight 1m | Accepted | Flight 2 | Flight 2m | |
flight1m_activated |
Activated | ||||
flight1c_activated |
Flight 1c | Activated | Flight 2m | N/A | |
flight2_planned |
Flight 2 | Higher than Flight 1* | Accepted | Flight 1 | N/A |
flight2_activated |
Activated | ||||
flight2m_activated |
Flight 2m | Activated | Flight 1c | Flight 1 |
Because the scenario involves activation of intents, the start times of all activated intents must be during the time the test scenario is executed (not before). Additionally, their end times must leave sufficient time for the execution of the test scenario.
✅ Provided by conflicting_flights in top-level resource pool.
FlightPlannerResource that is under test and will manage Flight 1.
✅ Provided by instance 2 in flight_planners in top-level resource pool.
FlightPlannerResource that will manage conflicting Flight 2.
✅ Provided by instance 2 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.
✅ Provided by dss in top-level resource pool.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:10.549406Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:10.543668Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The higher priority flight should be successfully planned by the control USS as there are no other flights in the area yet.
✅ uss2_core (2026-03-03T21:58:10.549377Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:10.471604Z)
✅ uss1_dss (2026-03-03T21:58:10.553621Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:10.553674Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:10.553717Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:10.568814Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:10.578443Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:10.580124Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:10.580187Z)
✅ uss2_core (2026-03-03T21:58:10.580247Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied planning because of
a conflict with a higher priority flight intent.
See plan_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully plans the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per astm.f3548.v21.SCD0015.
✅ uss2_core (2026-03-03T21:58:10.647037Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to plan the Flight 1 via the tested USS. However, it conflicts with Flight 2, which is of higher priority. As such it should be rejected per astm.f3548.v21.SCD0015.
✅ uss2_core (2026-03-03T21:58:10.646969Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:10.588871Z)
✅ uss1_dss (2026-03-03T21:58:10.652112Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:10.652180Z)
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail.
✅ uss2_core (2026-03-03T21:58:10.694354Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:10.810804Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:10.802149Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The first flight should be successfully planned by the tested USS.
✅ uss2_core (2026-03-03T21:58:10.810764Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:10.702320Z)
✅ uss1_dss (2026-03-03T21:58:10.819030Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:10.819108Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:10.819174Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:10.841017Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:10.854046Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:10.855837Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:10.855901Z)
✅ uss2_core (2026-03-03T21:58:10.855956Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
Just before directing the planning activity, the test director observes pre-existing notifications which cannot relate to the planning activity that has not yet happened. If these notifications cannot be retrieved, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI.
✅ uss2_core (2026-03-03T21:58:10.880944Z)
✅ uss2_core (2026-03-03T21:58:10.905148Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:11.036184Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:11.028379Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The second flight should be successfully planned by the control USS. It conflicts with Flight 1, but it has higher priority.
✅ uss2_core (2026-03-03T21:58:11.036142Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:10.913140Z)
✅ uss1_dss (2026-03-03T21:58:11.041161Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.041236Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:11.041280Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.062283Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:11.075151Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.076874Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:11.076941Z)
✅ uss2_core (2026-03-03T21:58:11.077024Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
The test director checks whether a notification reporting the creation of a conflict by Flight 2 was sent to UAS personnel for the control_uss as is required by SCD0090.
The test director also checks whether a notification reporting the creation of a new conflict with Flight 1 was sent to the UAS personnel for the tested_uss managing Flight 1 as is required by SCD0095.
The timeliness and completeness of these notifications will be checked for compliance with SCD0090 and SCD0095 in aggregate in a later test scenario -- only the raw data is gathered in this test scenario. When eligible notifications are found, they are reported as notes in the test scenario; if a USS does not have a scd0090_notification or scd0095_notification note, then uss_qualifier did not detect a required notification.
Note that these actions will not be performed if the test director was unable to retrieve the notifications before the planning activity.
We fetch the list of notifications. If the USS doesn't return a valid answer, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI and we cannot proceed with notification checks.
✅ uss2_core (2026-03-03T21:58:11.098441Z)
This page describes the content of a common test step where a user flight intent should be denied modification because
of a conflict with a higher priority flight intent.
See modify_planned_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0020.
✅ uss2_core (2026-03-03T21:58:11.193594Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to modify Flight 1 via the tested USS, which is planned. However, it conflicts with Flight 2, which is of higher priority and was planned in the meantime. As such it should be rejected per astm.f3548.v21.SCD0020.
✅ uss2_core (2026-03-03T21:58:11.193550Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:11.109724Z)
✅ uss1_dss (2026-03-03T21:58:11.198486Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.198570Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:11.198643Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.224975Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:11.235577Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.236734Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:11.236807Z)
✅ uss2_core (2026-03-03T21:58:11.236872Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. Because the modification attempt was invalid, either Flight 1 should not have been modified (because the USS kept the original accepted request), or it should have been removed (because the USS rejected the replacement plan provided).
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied activation because of
a conflict with a higher priority flight intent.
See activate_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully activates the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in activating the flight from the user flight intent, per astm.f3548.v21.SCD0025.
✅ uss2_core (2026-03-03T21:58:11.329500Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to activate Flight 1, however, it conflicts with Flight 2, which is also planned and of higher priority. Note that Flight 1 could be either planned or non-existent before this step. As such it should be rejected per astm.f3548.v21.SCD0025.
✅ uss2_core (2026-03-03T21:58:11.329468Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:11.247207Z)
✅ uss1_dss (2026-03-03T21:58:11.334968Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.335103Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:11.335154Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.357241Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:11.366723Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.367754Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:11.367816Z)
✅ uss2_core (2026-03-03T21:58:11.367866Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. Because the modification attempt was invalid, either Flight 1 should not have been modified (because the USS kept the original accepted request), or it should have been removed (because the USS rejected the replacement plan provided).
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail.
✅ uss2_core (2026-03-03T21:58:11.415057Z)
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:11.560599Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:11.546794Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates Flight 1, which should be done successfully given that it is now the highest-priority flight. Note that Flight 1 could be either planned or non-existent before this step. In the latter case, the flight will be directly activated without being planned beforehand.
✅ uss2_core (2026-03-03T21:58:11.560546Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:11.423538Z)
✅ uss1_dss (2026-03-03T21:58:11.566373Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.566531Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:11.566497Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:11.566602Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.587828Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:11.602243Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.603941Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:11.603998Z)
✅ uss2_core (2026-03-03T21:58:11.604072Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:11.743758Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:11.734990Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The second flight should be successfully planned by the control USS.
✅ uss2_core (2026-03-03T21:58:11.743715Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:11.612749Z)
✅ uss1_dss (2026-03-03T21:58:11.749196Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.749255Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:11.749300Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.775566Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:11.788091Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:11.789578Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:11.789637Z)
✅ uss2_core (2026-03-03T21:58:11.789687Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
Just before directing the planning activity, the test director observes pre-existing notifications which cannot relate to the planning activity that has not yet happened. This list of pre-existing notifications will be used later to determine if a new notification resulted from the planning activity. If these notifications cannot be retrieved, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI.
✅ uss2_core (2026-03-03T21:58:11.814947Z)
✅ uss2_core (2026-03-03T21:58:11.843741Z)
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:12.053473Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:12.043483Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates Flight 2, which should be done successfully given that it is the highest-priority flight.
✅ uss2_core (2026-03-03T21:58:12.053428Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:11.853093Z)
✅ uss1_dss (2026-03-03T21:58:12.060873Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:12.061102Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:12.061073Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:12.061162Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:12.089517Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:12.100433Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:12.102225Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:12.102299Z)
✅ uss2_core (2026-03-03T21:58:12.102361Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
The test director checks whether a notification reporting the modification of Flight 2 while in conflict was sent to UAS personnel for the control_uss as required by SCD0090.
The test director also checks whether a notification reporting the modification of a flight conflicting with Flight 1 was sent to the UAS personnel for the tested_uss managing Flight 1 as required by SCD0095.
The timeliness and completeness of these notifications will be checked for compliance with SCD0090 and SCD0095 in aggregate in a later test scenario -- only the raw data is gathered in this test scenario. When eligible notifications are found, they are reported as notes in the test scenario; if a USS does not have a scd0090_notification or scd0095_notification note, then uss_qualifier did not detect a required notification.
Note that these actions will not be performed if the test director was unable to retrieve the notifications before the planning activity.
We fetch the list of notifications. If the USS doesn't return a valid answer, the USS has not fully implemented interuss.automated_testing.flight_planning.ImplementAPI and we cannot proceed with notification checks.
✅ uss2_core (2026-03-03T21:58:12.130378Z)
Before execution of this step, flights 1 and 2 are activated and in conflict. Flight 2 is the highest-priority flight. The virtual user attempts to modify Flight 1 in a way that still conflicts with Flight 2, though the conflict is likely reduced.
A practical usage of this workflow might consist of the following sequence of events:
This last action is the virtual user flight planning interaction the USS under test will encounter in this test step.
This page describes the content of a common test case where a valid user flight intent in activated state is tentatively
modified by a flight planned. Multiple outcomes may be valid.
See modify_activated_flight in test_steps.py.
All flight intent data provided is correct and valid. The (already activated) provided flight intent may be in conflict with another activated flight, but only if this conflict already existed before the modification was initiated.
If the provided flight intent is not in conflict with another intent the USS should have successfully modified the flight per astm.f3548.v21.SCD0030. If the USS fails to modify the flight, wrongly indicates a conflict, or wrongly indicates the activated state of the flight, this check will fail.
If the provided flight intent is in conflict with another intent and that a pre-existing conflict was present, the USS may have decided to be more conservative and to not support modification. In such case, the USS may indicate that the operation is not supported instead of modifying the flight per astm.f3548.v21.SCD0030. If the USS fails to modify the flight, or fails to indicate that the modification is not supported, or wrongly indicates the activated state of the flight, this check will fail.
Do take note that if the USS rejects the modification when a pre-existing conflict was present, this check will not fail, but the following Rejected modification check will. Refer to this check for more information.
✅ uss2_core (2026-03-03T21:58:12.308713Z)
If the provided flight intent is in conflict with another intent and that a pre-existing conflict was present, the USS may have rejected the modification instead of modifying it or indicating that the modification is not supported. This could be the case for example if the USS does not support directly update of intents and instead delete the previous one and create a new one. This may or may not be strictly speaking a failure to meet a requirement, but we cannot distinguish between an actual failure to meet the requirement and a reasonable behavior due to implementation limitations.
As such, if the pre-existing conflict was present, and that the USS rejected the modification, this check will produce a low severity finding per astm.f3548.v21.SCD0030.
✅ uss2_core (2026-03-03T21:58:12.308761Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:12.298426Z)
The requested flight should have been modified essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The virtual user attempts to modify Flight 1 to reduce/mitigate the conflict.
The successful outcomes of the modification attempts:
If the USS rejects the modification, the USS is indicating the modification is "not allowed". This is not correct when judging solely on the rules of F3548-21. However, USSs may (generally) apply any number of additional rules to determine whether or not a flight planning action is accepted by the USS. Because of this, a rejection is not conclusive evidence of SCD0030 non-compliance since the rejection may be due to a different reason. However, rejection in this case would not seem to be justified on the basis of conservatism since rejection is effectively a refusal to communicate relevant information to other USSs and operators in the ecosystem. Therefore, a rejected modification will indicate a low severity failure, producing a finding since we cannot distinguish between an actual failure to meet the requirement and a reasonable behavior due non-F3548-21 constraints. Since this finding is a low severity failure, it does not indicate a failure to comply with a requirement.
In any case, whatever is the outcome of this step, there should not be any impact on the rest of the execution of the scenario. An intent should exist (this is checked in the next step) and it should be either Flight 1 or Flight 1m, both of which can be used in the next step since neither conflicts with Flight 2m.
✅ uss2_core (2026-03-03T21:58:12.308681Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:12.144625Z)
✅ uss1_dss (2026-03-03T21:58:12.314434Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:12.314569Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:12.314538Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:12.314630Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:12.341950Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:12.354103Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:12.355516Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:12.355559Z)
✅ uss2_core (2026-03-03T21:58:12.355594Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. If the modification was accepted, Flight 1 should have been modified. If the modification was not supported or the modification was rejected, Flight 1 should not have been modified and should still exist. If it does not exist, it means that there is an active flight without an operational intent, which is a failure to meet interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent in planned state should be
successfully modified by a flight planner. See modify_planned_flight in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been modified by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS fails to modify the flight, wrongly indicates a conflict, or wrongly indicates the planned state of the flight, this check will fail.
✅ uss2_core (2026-03-03T21:58:12.513227Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:12.506394Z)
The requested flight should have been modified essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver modifies (activated) Flight 2 with the control USS so that it is not anymore in conflict with (activated) flight of test USS. This should succeed and leave Flight 1 clear of conflict.
If flight modification is not supported by the USS, the next test step cannot be performed and the test case will end here.
✅ uss2_core (2026-03-03T21:58:12.513196Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:12.366462Z)
✅ uss1_dss (2026-03-03T21:58:12.518424Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:12.518561Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:12.518515Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:12.518617Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:12.541997Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:12.552616Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:12.553638Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:12.553677Z)
✅ uss2_core (2026-03-03T21:58:12.553722Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied modification because
of a conflict with a higher priority flight intent.
See modify_activated_priority_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0030.
✅ uss2_core (2026-03-03T21:58:12.648364Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to modify Flight 1 so that it becomes in conflict with Flight 2. Both flights are activated at that point. However, because the conflict did not exist when the modification was initiated, it should be rejected per astm.f3548.v21.SCD0030. In addition, Flight 1 should not have been removed, because doing so would leave an aircraft in flight without any flight plan.
✅ uss2_core (2026-03-03T21:58:12.648310Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:12.566188Z)
✅ uss1_dss (2026-03-03T21:58:12.654126Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Because the modification attempt was invalid, Flight 1 should not have been modified.
✅ uss2_core (2026-03-03T21:58:12.654210Z)
interuss.automated_testing.flight_planning.DeleteFlightSuccess
✅ uss2_core (2026-03-03T21:58:12.696145Z)
✅ uss2_core (2026-03-03T21:58:12.738249Z)
This test aims at testing the strategic coordination requirements that relate to the prioritization scenarios where there exists a conflict with an equal priority flight that is not permitted by regulation:
It involves a tested USS and a control USS through which conflicting flights are injected.
This scenario skips execution and completes successfully at the setup case if a resource containing equal priority flight intents where conflicts are not allow is not provided, such as if a jurisdiction does not have any priority levels at which conflicts are not allowed.
It assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).
If the jurisdiction in which these tests are being conducted does not have a priority level at which conflicts are not allowed, the FlightIntentsResource must be None to prevent the execution of this test.
Otherwise, the FlightIntentsResource must provide the following flight intents:
| Flight intent ID | Flight name | Priority | State | Must conflict with | Must not conflict with |
|---|---|---|---|---|---|
flight1_planned |
Flight 1 | Any (but all the same) | Accepted | Flight 2 | N/A |
flight1_activated |
Activated | ||||
flight1m_activated |
Flight 1m | Activated | Flight 2 | N/A | |
flight1c_planned |
Flight 1c | Planned | N/A | Flight 2 | |
flight1c_activated |
Activated | ||||
equal_prio_flight2m_planned |
Flight 2m | Planned | N/A | Flight 1 | |
equal_prio_flight2_planned |
Flight 2 | Flight 1, Flight 1m | Flight 1c | ||
equal_prio_flight2_activated |
Activated | ||||
equal_prio_flight2_nonconforming |
Nonconforming |
Because the scenario involves activation of intents, the start times of all activated intents must be during the time the test scenario is executed (not before). Additionally, their end times must leave sufficient time for the execution of the test scenario.
✅ Provided by conflicting_flights in top-level resource pool.
FlightPlannerResource that is under test and will manage Flight 1 and its variants.
✅ Provided by instance 1 in flight_planners in top-level resource pool.
FlightPlannerResource that will be used to inject conflicting Flight 2. Note that this control USS needs to support the
CMSA role in order to transition to the Nonconforming state in order to create a pre-existing conflict among equal-priority operational intents.
✅ Provided by instance 1 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.
✅ Provided by dss in top-level resource pool.
uss_qualifier verifies with the DSS that there are no operational intents remaining in the area.
If the DSS fails to reply to a query concerning operational intent references in a given area, or fails to allow the deletion of an operational intent from its own creator, it is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:12.744747Z)
If operational intents exist in the 4D area(s) that should be clear, then the current state of the test environment is not suitable to conduct tests so this check will fail.
While this scenario assumes that the area used is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario) in order to avoid a large number of area-clearing operations, the scenario will not proceed correctly if the area was left in a dirty state following a previous scenario that was supposed to leave the area clear. This test step verifies that the area is clear.
✅ (2026-03-03T21:58:12.744857Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:12.862443Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:12.853304Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 2 should be successfully planned by the control USS.
✅ uss1_core (2026-03-03T21:58:12.862401Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:12.751236Z)
✅ uss1_dss (2026-03-03T21:58:12.868303Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:12.868363Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:12.868407Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:12.893771Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:12.905632Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:12.907521Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:12.907592Z)
✅ uss1_core (2026-03-03T21:58:12.907653Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:13.043683Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:13.036609Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 2 should be successfully activated by the control USS.
✅ uss1_core (2026-03-03T21:58:13.043652Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:12.916829Z)
✅ uss1_dss (2026-03-03T21:58:13.048338Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:13.048517Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:13.048487Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:13.048591Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:13.067949Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:13.079144Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:13.080379Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:13.080442Z)
✅ uss1_core (2026-03-03T21:58:13.080491Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied planning because of
a non-permitted conflict with an equal priority flight intent.
See plan_conflict_flight in prioritization_test_steps.py.
If the USS successfully plans the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per astm.f3548.v21.SCD0035.
✅ uss1_core (2026-03-03T21:58:13.155540Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to plan the Flight 1 via the tested USS. However, it conflicts with Flight 2 which is of equal priority but came first. As such it should be rejected per astm.f3548.v21.SCD0035.
✅ uss1_core (2026-03-03T21:58:13.155492Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:13.088364Z)
✅ uss1_dss (2026-03-03T21:58:13.159742Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 1 should not have been shared with the interoperability ecosystem since it was rejected.
✅ uss1_core (2026-03-03T21:58:13.159803Z)
This page describes the content of a common test step where a user flight intent should be denied activation because of
a non-permitted conflict with an equal priority flight intent.
See activate_conflict_flight in prioritization_test_steps.py.
If the USS successfully activates the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per astm.f3548.v21.SCD0045.
✅ uss1_core (2026-03-03T21:58:13.235393Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to activate directly Flight 1, i.e. without the flight being planned before. However, this conflicts with activated Flight 2, which is of equal priority. As such it should be rejected per astm.f3548.v21.SCD0045.
✅ uss1_core (2026-03-03T21:58:13.235363Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:13.167179Z)
✅ uss1_dss (2026-03-03T21:58:13.240386Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 1 should not have been shared with the interoperability ecosystem since it was rejected.
✅ uss1_core (2026-03-03T21:58:13.240460Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:13.382781Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:13.375694Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The smaller Flight 1c form (which doesn't conflict with Flight 2) should be successfully planned by the tested USS.
✅ uss1_core (2026-03-03T21:58:13.382748Z)
Because Flight 2 is nearby Flight 1c, successful planning of Flight 1c indicates the tested USS is complying with the portion of astm.f3548.v21.GEN0500 that requires a USS to indicate two 4D volumes are non-intersecting when they are separated by more than 1 cm.
This check is not relevant if the planning is rejected.
✅ uss1_core (2026-03-03T21:58:13.382832Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:13.249676Z)
✅ uss1_dss (2026-03-03T21:58:13.388134Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:13.388212Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:13.388285Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:13.409397Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:13.420926Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:13.422247Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:13.422292Z)
✅ uss1_core (2026-03-03T21:58:13.422325Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied modification because
of a non-permitted conflict with an equal priority flight intent.
See modify_planned_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0040.
✅ uss1_core (2026-03-03T21:58:13.511851Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to enlarge Flight 1c so that it conflicts with Flight 2. However, Flight 2 is of equal priority but was planned first. As such the change to Flight 1c should be rejected per astm.f3548.v21.SCD0040.
✅ uss1_core (2026-03-03T21:58:13.511806Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:13.433378Z)
✅ uss1_dss (2026-03-03T21:58:13.517317Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:13.517382Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:13.517424Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:13.543442Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:13.554237Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:13.555546Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:13.555587Z)
✅ uss1_core (2026-03-03T21:58:13.555620Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. Because the modification attempt was invalid, either Flight 1c should not have been modified (because the USS kept the original accepted request), or it should have been removed (because the USS rejected the replacement plan provided).
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:13.704657Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:13.697947Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates the smaller Flight 1c form, which should be done successfully. Note that Flight 1c could be either planned or non-existent before this step. In the latter case, the "user" will directly activate the flight without planning it beforehand.
✅ uss1_core (2026-03-03T21:58:13.704624Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:13.565040Z)
✅ uss1_dss (2026-03-03T21:58:13.709727Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:13.709823Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:13.709804Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:13.709859Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:13.729767Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:13.739989Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:13.741182Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:13.741222Z)
✅ uss1_core (2026-03-03T21:58:13.741253Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied modification because
of a non-permitted conflict with an equal priority flight intent.
See modify_activated_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0050.
✅ uss1_core (2026-03-03T21:58:13.838113Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to enlarge Flight 1c so that it conflicts with Flight 2. Both flights are activated at the point where that change is requested. However, because the conflict did not exist when the modification was initiated, it should be rejected per astm.f3548.v21.SCD0050. In addition, Flight 1c should not have been removed, because doing so would leave an aircraft in flight without any flight plan.
✅ uss1_core (2026-03-03T21:58:13.838078Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:13.750985Z)
✅ uss1_dss (2026-03-03T21:58:13.842634Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Because the modification attempt was invalid, Flight 1c should not have been modified.
✅ uss1_core (2026-03-03T21:58:13.842685Z)
∅ This test step was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail. If, during the previous step, the USS indicated that it does not support modifications, then it will not be able to modify Flight 1c into Flight 1 during the next test case. As such, the test driver deletes Flight 1c from the system so that Flight 1 can be created directly activated during the next test case.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail. To prepare for the next test case, Flight 2 must be removed from the system.
✅ uss1_core (2026-03-03T21:58:13.887935Z)
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:14.018057Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:14.011095Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates the normal form of Flight 1, which should be done successfully since Flight 2 was removed at the end of the previous step. Note that Flight 1 could be either already activated in the smaller Flight 1c form or non-existent before this step. In the former case, Flight 1c is enlarged to its normal size. In the latter case, the flight will be directly activated without being planned beforehand.
✅ uss1_core (2026-03-03T21:58:14.018025Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:13.895903Z)
✅ uss1_dss (2026-03-03T21:58:14.022733Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:14.022826Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:14.022808Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:14.022863Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:14.044503Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:14.056644Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:14.058134Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:14.058201Z)
✅ uss1_core (2026-03-03T21:58:14.058259Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:14.193669Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:14.186549Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The smaller Flight 2 form should be successfully planned by the control USS because it does not conflict with Flight 1.
✅ uss1_core (2026-03-03T21:58:14.193637Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:14.066364Z)
✅ uss1_dss (2026-03-03T21:58:14.198845Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:14.198928Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:14.198996Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:14.222062Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:14.233386Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:14.235084Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:14.235150Z)
✅ uss1_core (2026-03-03T21:58:14.235213Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
The test driver instructs the control USS to declare Flight 2 as non-conforming. This makes non-conforming Flight 2 conflict with activated Flight 1 -- this same-priority conflict would not be allowed if Flight 2 were in a nominal state.
Do note that executing this test step requires the control USS to support the CMSA role. As such, if the USS rejects the transition to non-conforming state, it will be assumed that the control USS does not support this role and the test execution will stop without failing.
All flight intent data provided is correct, therefore it should have been transitioned to non-conforming state by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS rejects the transition, this check will fail. If the USS indicates that the operation is not supported, the USS does not support the CMSA role, and as such the scenario execution will stop without failing.
✅ uss1_core (2026-03-03T21:58:14.293438Z)
The requested flight should have been updated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
∅ This check was not applicable to this test run and is therefore not statused.
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:14.293390Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:14.247169Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
∅ This check was not applicable to this test run and is therefore not statused.
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
∅ This check was not applicable to this test run and is therefore not statused.
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
∅ This check was not applicable to this test run and is therefore not statused.
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
∅ This check was not applicable to this test run and is therefore not statused.
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
∅ This check was not applicable to this test run and is therefore not statused.
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
∅ This check was not applicable to this test run and is therefore not statused.
∅ This check was not applicable to this test run and is therefore not statused.
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
∅ This test step was not applicable to this test run and is therefore not statused.
Before execution of this step, Flight 1 is activated (onto time range A) and Flight 2 is non-conforming (onto time range A), and both are in conflict. The test driver modifies Flight 1 in a way that still conflicts with Flight 2 by extending its time range A. This modification results in a conflict between the two equal priority flights that already existed before the modification was initiated. While this modification is expected to be accepted by the tested USS in general, the rejection of the modification does not constitute a violation of a requirement. However, the modification request must not result in a failure per interuss.automated_testing.flight_planning.ExpectedBehavior. Nor should Flight 1 have been removed, because doing so would leave an aircraft in flight without any flight plan.
All flight intent data provided is correct and the USS should have either:
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
If:
this check will fail per astm.f3548.v21.USS0105,2. This step validates that the response of the USS is consistent with the flight shared if the USS accepted the modification, i.e. whether Flight 1 was properly modified.
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. This step validates that the response of the USS is consistent with the flight shared if the USS rejected the modification, i.e. whether Flight 1 was not modified.
interuss.automated_testing.flight_planning.DeleteFlightSuccess
✅ uss1_core (2026-03-03T21:58:14.338713Z)
✅ uss1_core (2026-03-03T21:58:14.378220Z)
This test aims at testing the strategic coordination requirements that relate to the prioritization scenarios where there exists a conflict with an equal priority flight that is not permitted by regulation:
It involves a tested USS and a control USS through which conflicting flights are injected.
This scenario skips execution and completes successfully at the setup case if a resource containing equal priority flight intents where conflicts are not allow is not provided, such as if a jurisdiction does not have any priority levels at which conflicts are not allowed.
It assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).
If the jurisdiction in which these tests are being conducted does not have a priority level at which conflicts are not allowed, the FlightIntentsResource must be None to prevent the execution of this test.
Otherwise, the FlightIntentsResource must provide the following flight intents:
| Flight intent ID | Flight name | Priority | State | Must conflict with | Must not conflict with |
|---|---|---|---|---|---|
flight1_planned |
Flight 1 | Any (but all the same) | Accepted | Flight 2 | N/A |
flight1_activated |
Activated | ||||
flight1m_activated |
Flight 1m | Activated | Flight 2 | N/A | |
flight1c_planned |
Flight 1c | Planned | N/A | Flight 2 | |
flight1c_activated |
Activated | ||||
equal_prio_flight2m_planned |
Flight 2m | Planned | N/A | Flight 1 | |
equal_prio_flight2_planned |
Flight 2 | Flight 1, Flight 1m | Flight 1c | ||
equal_prio_flight2_activated |
Activated | ||||
equal_prio_flight2_nonconforming |
Nonconforming |
Because the scenario involves activation of intents, the start times of all activated intents must be during the time the test scenario is executed (not before). Additionally, their end times must leave sufficient time for the execution of the test scenario.
✅ Provided by conflicting_flights in top-level resource pool.
FlightPlannerResource that is under test and will manage Flight 1 and its variants.
✅ Provided by instance 1 in flight_planners in top-level resource pool.
FlightPlannerResource that will be used to inject conflicting Flight 2. Note that this control USS needs to support the
CMSA role in order to transition to the Nonconforming state in order to create a pre-existing conflict among equal-priority operational intents.
✅ Provided by instance 2 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.
✅ Provided by dss in top-level resource pool.
uss_qualifier verifies with the DSS that there are no operational intents remaining in the area.
If the DSS fails to reply to a query concerning operational intent references in a given area, or fails to allow the deletion of an operational intent from its own creator, it is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:14.383604Z)
If operational intents exist in the 4D area(s) that should be clear, then the current state of the test environment is not suitable to conduct tests so this check will fail.
While this scenario assumes that the area used is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario) in order to avoid a large number of area-clearing operations, the scenario will not proceed correctly if the area was left in a dirty state following a previous scenario that was supposed to leave the area clear. This test step verifies that the area is clear.
✅ (2026-03-03T21:58:14.383725Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:14.495585Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:14.489716Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 2 should be successfully planned by the control USS.
✅ uss2_core (2026-03-03T21:58:14.495540Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:14.391208Z)
✅ uss1_dss (2026-03-03T21:58:14.500777Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:14.500849Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:14.500907Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:14.520641Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:14.541291Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:14.542538Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:14.542581Z)
✅ uss2_core (2026-03-03T21:58:14.542630Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:14.696353Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:14.688278Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 2 should be successfully activated by the control USS.
✅ uss2_core (2026-03-03T21:58:14.696319Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:14.551209Z)
✅ uss1_dss (2026-03-03T21:58:14.701712Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:14.701809Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:14.701790Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:14.701846Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:14.723853Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:14.733608Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:14.734616Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:14.734654Z)
✅ uss2_core (2026-03-03T21:58:14.734686Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied planning because of
a non-permitted conflict with an equal priority flight intent.
See plan_conflict_flight in prioritization_test_steps.py.
If the USS successfully plans the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per astm.f3548.v21.SCD0035.
✅ uss1_core (2026-03-03T21:58:14.820893Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to plan the Flight 1 via the tested USS. However, it conflicts with Flight 2 which is of equal priority but came first. As such it should be rejected per astm.f3548.v21.SCD0035.
✅ uss1_core (2026-03-03T21:58:14.820859Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:14.742316Z)
✅ uss1_dss (2026-03-03T21:58:14.827802Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 1 should not have been shared with the interoperability ecosystem since it was rejected.
✅ uss1_core (2026-03-03T21:58:14.827898Z)
This page describes the content of a common test step where a user flight intent should be denied activation because of
a non-permitted conflict with an equal priority flight intent.
See activate_conflict_flight in prioritization_test_steps.py.
If the USS successfully activates the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per astm.f3548.v21.SCD0045.
✅ uss1_core (2026-03-03T21:58:14.910555Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to activate directly Flight 1, i.e. without the flight being planned before. However, this conflicts with activated Flight 2, which is of equal priority. As such it should be rejected per astm.f3548.v21.SCD0045.
✅ uss1_core (2026-03-03T21:58:14.910523Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:14.838786Z)
✅ uss1_dss (2026-03-03T21:58:14.915786Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 1 should not have been shared with the interoperability ecosystem since it was rejected.
✅ uss1_core (2026-03-03T21:58:14.915865Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:15.128506Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:15.119307Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The smaller Flight 1c form (which doesn't conflict with Flight 2) should be successfully planned by the tested USS.
✅ uss1_core (2026-03-03T21:58:15.128460Z)
Because Flight 2 is nearby Flight 1c, successful planning of Flight 1c indicates the tested USS is complying with the portion of astm.f3548.v21.GEN0500 that requires a USS to indicate two 4D volumes are non-intersecting when they are separated by more than 1 cm.
This check is not relevant if the planning is rejected.
✅ uss1_core (2026-03-03T21:58:15.128578Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:14.926830Z)
✅ uss1_dss (2026-03-03T21:58:15.135824Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:15.135909Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:15.135987Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:15.166935Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:15.178632Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:15.180019Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:15.180090Z)
✅ uss1_core (2026-03-03T21:58:15.180152Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied modification because
of a non-permitted conflict with an equal priority flight intent.
See modify_planned_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0040.
✅ uss1_core (2026-03-03T21:58:15.283712Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to enlarge Flight 1c so that it conflicts with Flight 2. However, Flight 2 is of equal priority but was planned first. As such the change to Flight 1c should be rejected per astm.f3548.v21.SCD0040.
✅ uss1_core (2026-03-03T21:58:15.283681Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:15.195429Z)
✅ uss1_dss (2026-03-03T21:58:15.289169Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:15.289263Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:15.289315Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:15.309947Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:15.323278Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:15.325035Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:15.325106Z)
✅ uss1_core (2026-03-03T21:58:15.325168Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. Because the modification attempt was invalid, either Flight 1c should not have been modified (because the USS kept the original accepted request), or it should have been removed (because the USS rejected the replacement plan provided).
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:15.489522Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:15.483488Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates the smaller Flight 1c form, which should be done successfully. Note that Flight 1c could be either planned or non-existent before this step. In the latter case, the "user" will directly activate the flight without planning it beforehand.
✅ uss1_core (2026-03-03T21:58:15.489492Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:15.335609Z)
✅ uss1_dss (2026-03-03T21:58:15.494687Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:15.494785Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:15.494767Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:15.494821Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:15.510726Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:15.518878Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:15.519862Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:15.519900Z)
✅ uss1_core (2026-03-03T21:58:15.519930Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied modification because
of a non-permitted conflict with an equal priority flight intent.
See modify_activated_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0050.
✅ uss1_core (2026-03-03T21:58:15.584844Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to enlarge Flight 1c so that it conflicts with Flight 2. Both flights are activated at the point where that change is requested. However, because the conflict did not exist when the modification was initiated, it should be rejected per astm.f3548.v21.SCD0050. In addition, Flight 1c should not have been removed, because doing so would leave an aircraft in flight without any flight plan.
✅ uss1_core (2026-03-03T21:58:15.584816Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:15.528590Z)
✅ uss1_dss (2026-03-03T21:58:15.589434Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Because the modification attempt was invalid, Flight 1c should not have been modified.
✅ uss1_core (2026-03-03T21:58:15.589481Z)
∅ This test step was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail. If, during the previous step, the USS indicated that it does not support modifications, then it will not be able to modify Flight 1c into Flight 1 during the next test case. As such, the test driver deletes Flight 1c from the system so that Flight 1 can be created directly activated during the next test case.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail. To prepare for the next test case, Flight 2 must be removed from the system.
✅ uss2_core (2026-03-03T21:58:15.629829Z)
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:15.743616Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:15.737633Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates the normal form of Flight 1, which should be done successfully since Flight 2 was removed at the end of the previous step. Note that Flight 1 could be either already activated in the smaller Flight 1c form or non-existent before this step. In the former case, Flight 1c is enlarged to its normal size. In the latter case, the flight will be directly activated without being planned beforehand.
✅ uss1_core (2026-03-03T21:58:15.743587Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:15.636890Z)
✅ uss1_dss (2026-03-03T21:58:15.747777Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:15.747899Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:15.747879Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:15.747937Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:15.764302Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:15.772714Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:15.773751Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:15.773791Z)
✅ uss1_core (2026-03-03T21:58:15.773822Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:15.883644Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:15.876400Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The smaller Flight 2 form should be successfully planned by the control USS because it does not conflict with Flight 1.
✅ uss2_core (2026-03-03T21:58:15.883613Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:15.779192Z)
✅ uss1_dss (2026-03-03T21:58:15.888587Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:15.888644Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:15.888690Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:15.909463Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:15.919979Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:15.920963Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:15.921033Z)
✅ uss2_core (2026-03-03T21:58:15.921075Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
The test driver instructs the control USS to declare Flight 2 as non-conforming. This makes non-conforming Flight 2 conflict with activated Flight 1 -- this same-priority conflict would not be allowed if Flight 2 were in a nominal state.
Do note that executing this test step requires the control USS to support the CMSA role. As such, if the USS rejects the transition to non-conforming state, it will be assumed that the control USS does not support this role and the test execution will stop without failing.
All flight intent data provided is correct, therefore it should have been transitioned to non-conforming state by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS rejects the transition, this check will fail. If the USS indicates that the operation is not supported, the USS does not support the CMSA role, and as such the scenario execution will stop without failing.
✅ uss2_core (2026-03-03T21:58:15.957716Z)
The requested flight should have been updated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
∅ This check was not applicable to this test run and is therefore not statused.
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:15.957688Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:15.930079Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
∅ This check was not applicable to this test run and is therefore not statused.
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
∅ This check was not applicable to this test run and is therefore not statused.
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
∅ This check was not applicable to this test run and is therefore not statused.
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
∅ This check was not applicable to this test run and is therefore not statused.
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
∅ This check was not applicable to this test run and is therefore not statused.
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
∅ This check was not applicable to this test run and is therefore not statused.
∅ This check was not applicable to this test run and is therefore not statused.
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
∅ This test step was not applicable to this test run and is therefore not statused.
Before execution of this step, Flight 1 is activated (onto time range A) and Flight 2 is non-conforming (onto time range A), and both are in conflict. The test driver modifies Flight 1 in a way that still conflicts with Flight 2 by extending its time range A. This modification results in a conflict between the two equal priority flights that already existed before the modification was initiated. While this modification is expected to be accepted by the tested USS in general, the rejection of the modification does not constitute a violation of a requirement. However, the modification request must not result in a failure per interuss.automated_testing.flight_planning.ExpectedBehavior. Nor should Flight 1 have been removed, because doing so would leave an aircraft in flight without any flight plan.
All flight intent data provided is correct and the USS should have either:
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
If:
this check will fail per astm.f3548.v21.USS0105,2. This step validates that the response of the USS is consistent with the flight shared if the USS accepted the modification, i.e. whether Flight 1 was properly modified.
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. This step validates that the response of the USS is consistent with the flight shared if the USS rejected the modification, i.e. whether Flight 1 was not modified.
interuss.automated_testing.flight_planning.DeleteFlightSuccess
✅ uss2_core (2026-03-03T21:58:15.997156Z)
✅ uss1_core (2026-03-03T21:58:16.032541Z)
This test aims at testing the strategic coordination requirements that relate to the prioritization scenarios where there exists a conflict with an equal priority flight that is not permitted by regulation:
It involves a tested USS and a control USS through which conflicting flights are injected.
This scenario skips execution and completes successfully at the setup case if a resource containing equal priority flight intents where conflicts are not allow is not provided, such as if a jurisdiction does not have any priority levels at which conflicts are not allowed.
It assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).
If the jurisdiction in which these tests are being conducted does not have a priority level at which conflicts are not allowed, the FlightIntentsResource must be None to prevent the execution of this test.
Otherwise, the FlightIntentsResource must provide the following flight intents:
| Flight intent ID | Flight name | Priority | State | Must conflict with | Must not conflict with |
|---|---|---|---|---|---|
flight1_planned |
Flight 1 | Any (but all the same) | Accepted | Flight 2 | N/A |
flight1_activated |
Activated | ||||
flight1m_activated |
Flight 1m | Activated | Flight 2 | N/A | |
flight1c_planned |
Flight 1c | Planned | N/A | Flight 2 | |
flight1c_activated |
Activated | ||||
equal_prio_flight2m_planned |
Flight 2m | Planned | N/A | Flight 1 | |
equal_prio_flight2_planned |
Flight 2 | Flight 1, Flight 1m | Flight 1c | ||
equal_prio_flight2_activated |
Activated | ||||
equal_prio_flight2_nonconforming |
Nonconforming |
Because the scenario involves activation of intents, the start times of all activated intents must be during the time the test scenario is executed (not before). Additionally, their end times must leave sufficient time for the execution of the test scenario.
✅ Provided by conflicting_flights in top-level resource pool.
FlightPlannerResource that is under test and will manage Flight 1 and its variants.
✅ Provided by instance 2 in flight_planners in top-level resource pool.
FlightPlannerResource that will be used to inject conflicting Flight 2. Note that this control USS needs to support the
CMSA role in order to transition to the Nonconforming state in order to create a pre-existing conflict among equal-priority operational intents.
✅ Provided by instance 1 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.
✅ Provided by dss in top-level resource pool.
uss_qualifier verifies with the DSS that there are no operational intents remaining in the area.
If the DSS fails to reply to a query concerning operational intent references in a given area, or fails to allow the deletion of an operational intent from its own creator, it is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:16.037436Z)
If operational intents exist in the 4D area(s) that should be clear, then the current state of the test environment is not suitable to conduct tests so this check will fail.
While this scenario assumes that the area used is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario) in order to avoid a large number of area-clearing operations, the scenario will not proceed correctly if the area was left in a dirty state following a previous scenario that was supposed to leave the area clear. This test step verifies that the area is clear.
✅ (2026-03-03T21:58:16.037518Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:16.132552Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:16.126635Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 2 should be successfully planned by the control USS.
✅ uss1_core (2026-03-03T21:58:16.132523Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:16.042698Z)
✅ uss1_dss (2026-03-03T21:58:16.136983Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:16.137059Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:16.137103Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:16.154514Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:16.162536Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:16.163497Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:16.163535Z)
✅ uss1_core (2026-03-03T21:58:16.163565Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:16.276360Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:16.270216Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 2 should be successfully activated by the control USS.
✅ uss1_core (2026-03-03T21:58:16.276330Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:16.169685Z)
✅ uss1_dss (2026-03-03T21:58:16.280446Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:16.280536Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:16.280518Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:16.280571Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:16.296110Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:16.304127Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:16.305161Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:16.305200Z)
✅ uss1_core (2026-03-03T21:58:16.305230Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied planning because of
a non-permitted conflict with an equal priority flight intent.
See plan_conflict_flight in prioritization_test_steps.py.
If the USS successfully plans the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per astm.f3548.v21.SCD0035.
✅ uss2_core (2026-03-03T21:58:16.371333Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to plan the Flight 1 via the tested USS. However, it conflicts with Flight 2 which is of equal priority but came first. As such it should be rejected per astm.f3548.v21.SCD0035.
✅ uss2_core (2026-03-03T21:58:16.371304Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:16.311444Z)
✅ uss1_dss (2026-03-03T21:58:16.375319Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 1 should not have been shared with the interoperability ecosystem since it was rejected.
✅ uss2_core (2026-03-03T21:58:16.375367Z)
This page describes the content of a common test step where a user flight intent should be denied activation because of
a non-permitted conflict with an equal priority flight intent.
See activate_conflict_flight in prioritization_test_steps.py.
If the USS successfully activates the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per astm.f3548.v21.SCD0045.
✅ uss2_core (2026-03-03T21:58:16.426418Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to activate directly Flight 1, i.e. without the flight being planned before. However, this conflicts with activated Flight 2, which is of equal priority. As such it should be rejected per astm.f3548.v21.SCD0045.
✅ uss2_core (2026-03-03T21:58:16.426391Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:16.381487Z)
✅ uss1_dss (2026-03-03T21:58:16.430487Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 1 should not have been shared with the interoperability ecosystem since it was rejected.
✅ uss2_core (2026-03-03T21:58:16.430533Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:16.543974Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:16.538335Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The smaller Flight 1c form (which doesn't conflict with Flight 2) should be successfully planned by the tested USS.
✅ uss2_core (2026-03-03T21:58:16.543944Z)
Because Flight 2 is nearby Flight 1c, successful planning of Flight 1c indicates the tested USS is complying with the portion of astm.f3548.v21.GEN0500 that requires a USS to indicate two 4D volumes are non-intersecting when they are separated by more than 1 cm.
This check is not relevant if the planning is rejected.
✅ uss2_core (2026-03-03T21:58:16.544036Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:16.436643Z)
✅ uss1_dss (2026-03-03T21:58:16.549302Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:16.549357Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:16.549400Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:16.565976Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:16.574444Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:16.575418Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:16.575458Z)
✅ uss2_core (2026-03-03T21:58:16.575490Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied modification because
of a non-permitted conflict with an equal priority flight intent.
See modify_planned_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0040.
✅ uss2_core (2026-03-03T21:58:16.639266Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to enlarge Flight 1c so that it conflicts with Flight 2. However, Flight 2 is of equal priority but was planned first. As such the change to Flight 1c should be rejected per astm.f3548.v21.SCD0040.
✅ uss2_core (2026-03-03T21:58:16.639237Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:16.584269Z)
✅ uss1_dss (2026-03-03T21:58:16.644069Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:16.644128Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:16.644168Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:16.659098Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:16.667312Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:16.668269Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:16.668308Z)
✅ uss2_core (2026-03-03T21:58:16.668338Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. Because the modification attempt was invalid, either Flight 1c should not have been modified (because the USS kept the original accepted request), or it should have been removed (because the USS rejected the replacement plan provided).
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:16.797117Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:16.791828Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates the smaller Flight 1c form, which should be done successfully. Note that Flight 1c could be either planned or non-existent before this step. In the latter case, the "user" will directly activate the flight without planning it beforehand.
✅ uss2_core (2026-03-03T21:58:16.797087Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:16.675233Z)
✅ uss1_dss (2026-03-03T21:58:16.802523Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:16.802619Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:16.802602Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:16.802655Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:16.818573Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:16.827077Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:16.828082Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:16.828124Z)
✅ uss2_core (2026-03-03T21:58:16.828158Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied modification because
of a non-permitted conflict with an equal priority flight intent.
See modify_activated_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0050.
✅ uss2_core (2026-03-03T21:58:16.892542Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to enlarge Flight 1c so that it conflicts with Flight 2. Both flights are activated at the point where that change is requested. However, because the conflict did not exist when the modification was initiated, it should be rejected per astm.f3548.v21.SCD0050. In addition, Flight 1c should not have been removed, because doing so would leave an aircraft in flight without any flight plan.
✅ uss2_core (2026-03-03T21:58:16.892513Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:16.836977Z)
✅ uss1_dss (2026-03-03T21:58:16.897342Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Because the modification attempt was invalid, Flight 1c should not have been modified.
✅ uss2_core (2026-03-03T21:58:16.897389Z)
∅ This test step was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail. If, during the previous step, the USS indicated that it does not support modifications, then it will not be able to modify Flight 1c into Flight 1 during the next test case. As such, the test driver deletes Flight 1c from the system so that Flight 1 can be created directly activated during the next test case.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail. To prepare for the next test case, Flight 2 must be removed from the system.
✅ uss1_core (2026-03-03T21:58:16.938877Z)
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:17.047388Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:17.042101Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates the normal form of Flight 1, which should be done successfully since Flight 2 was removed at the end of the previous step. Note that Flight 1 could be either already activated in the smaller Flight 1c form or non-existent before this step. In the former case, Flight 1c is enlarged to its normal size. In the latter case, the flight will be directly activated without being planned beforehand.
✅ uss2_core (2026-03-03T21:58:17.047359Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:16.945255Z)
✅ uss1_dss (2026-03-03T21:58:17.051546Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:17.051639Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:17.051620Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:17.051675Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:17.072486Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:17.080788Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:17.081766Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:17.081804Z)
✅ uss2_core (2026-03-03T21:58:17.081834Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:17.210313Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:17.204920Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The smaller Flight 2 form should be successfully planned by the control USS because it does not conflict with Flight 1.
✅ uss1_core (2026-03-03T21:58:17.210283Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:17.087302Z)
✅ uss1_dss (2026-03-03T21:58:17.214639Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:17.214704Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:17.214746Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:17.230484Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:17.243743Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:17.244689Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:17.244727Z)
✅ uss1_core (2026-03-03T21:58:17.244756Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
The test driver instructs the control USS to declare Flight 2 as non-conforming. This makes non-conforming Flight 2 conflict with activated Flight 1 -- this same-priority conflict would not be allowed if Flight 2 were in a nominal state.
Do note that executing this test step requires the control USS to support the CMSA role. As such, if the USS rejects the transition to non-conforming state, it will be assumed that the control USS does not support this role and the test execution will stop without failing.
All flight intent data provided is correct, therefore it should have been transitioned to non-conforming state by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS rejects the transition, this check will fail. If the USS indicates that the operation is not supported, the USS does not support the CMSA role, and as such the scenario execution will stop without failing.
✅ uss1_core (2026-03-03T21:58:17.284088Z)
The requested flight should have been updated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
∅ This check was not applicable to this test run and is therefore not statused.
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:17.284053Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:17.253138Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
∅ This check was not applicable to this test run and is therefore not statused.
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
∅ This check was not applicable to this test run and is therefore not statused.
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
∅ This check was not applicable to this test run and is therefore not statused.
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
∅ This check was not applicable to this test run and is therefore not statused.
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
∅ This check was not applicable to this test run and is therefore not statused.
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
∅ This check was not applicable to this test run and is therefore not statused.
∅ This check was not applicable to this test run and is therefore not statused.
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
∅ This test step was not applicable to this test run and is therefore not statused.
Before execution of this step, Flight 1 is activated (onto time range A) and Flight 2 is non-conforming (onto time range A), and both are in conflict. The test driver modifies Flight 1 in a way that still conflicts with Flight 2 by extending its time range A. This modification results in a conflict between the two equal priority flights that already existed before the modification was initiated. While this modification is expected to be accepted by the tested USS in general, the rejection of the modification does not constitute a violation of a requirement. However, the modification request must not result in a failure per interuss.automated_testing.flight_planning.ExpectedBehavior. Nor should Flight 1 have been removed, because doing so would leave an aircraft in flight without any flight plan.
All flight intent data provided is correct and the USS should have either:
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
If:
this check will fail per astm.f3548.v21.USS0105,2. This step validates that the response of the USS is consistent with the flight shared if the USS accepted the modification, i.e. whether Flight 1 was properly modified.
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. This step validates that the response of the USS is consistent with the flight shared if the USS rejected the modification, i.e. whether Flight 1 was not modified.
interuss.automated_testing.flight_planning.DeleteFlightSuccess
✅ uss1_core (2026-03-03T21:58:17.325713Z)
✅ uss2_core (2026-03-03T21:58:17.359030Z)
This test aims at testing the strategic coordination requirements that relate to the prioritization scenarios where there exists a conflict with an equal priority flight that is not permitted by regulation:
It involves a tested USS and a control USS through which conflicting flights are injected.
This scenario skips execution and completes successfully at the setup case if a resource containing equal priority flight intents where conflicts are not allow is not provided, such as if a jurisdiction does not have any priority levels at which conflicts are not allowed.
It assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).
If the jurisdiction in which these tests are being conducted does not have a priority level at which conflicts are not allowed, the FlightIntentsResource must be None to prevent the execution of this test.
Otherwise, the FlightIntentsResource must provide the following flight intents:
| Flight intent ID | Flight name | Priority | State | Must conflict with | Must not conflict with |
|---|---|---|---|---|---|
flight1_planned |
Flight 1 | Any (but all the same) | Accepted | Flight 2 | N/A |
flight1_activated |
Activated | ||||
flight1m_activated |
Flight 1m | Activated | Flight 2 | N/A | |
flight1c_planned |
Flight 1c | Planned | N/A | Flight 2 | |
flight1c_activated |
Activated | ||||
equal_prio_flight2m_planned |
Flight 2m | Planned | N/A | Flight 1 | |
equal_prio_flight2_planned |
Flight 2 | Flight 1, Flight 1m | Flight 1c | ||
equal_prio_flight2_activated |
Activated | ||||
equal_prio_flight2_nonconforming |
Nonconforming |
Because the scenario involves activation of intents, the start times of all activated intents must be during the time the test scenario is executed (not before). Additionally, their end times must leave sufficient time for the execution of the test scenario.
✅ Provided by conflicting_flights in top-level resource pool.
FlightPlannerResource that is under test and will manage Flight 1 and its variants.
✅ Provided by instance 2 in flight_planners in top-level resource pool.
FlightPlannerResource that will be used to inject conflicting Flight 2. Note that this control USS needs to support the
CMSA role in order to transition to the Nonconforming state in order to create a pre-existing conflict among equal-priority operational intents.
✅ Provided by instance 2 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.
✅ Provided by dss in top-level resource pool.
uss_qualifier verifies with the DSS that there are no operational intents remaining in the area.
If the DSS fails to reply to a query concerning operational intent references in a given area, or fails to allow the deletion of an operational intent from its own creator, it is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:17.364053Z)
If operational intents exist in the 4D area(s) that should be clear, then the current state of the test environment is not suitable to conduct tests so this check will fail.
While this scenario assumes that the area used is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario) in order to avoid a large number of area-clearing operations, the scenario will not proceed correctly if the area was left in a dirty state following a previous scenario that was supposed to leave the area clear. This test step verifies that the area is clear.
✅ (2026-03-03T21:58:17.364154Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:17.456057Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:17.450721Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 2 should be successfully planned by the control USS.
✅ uss2_core (2026-03-03T21:58:17.456026Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:17.369813Z)
✅ uss1_dss (2026-03-03T21:58:17.460121Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:17.460175Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:17.460217Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:17.476940Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:17.485479Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:17.486464Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:17.486504Z)
✅ uss2_core (2026-03-03T21:58:17.486537Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:17.598710Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:17.593301Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 2 should be successfully activated by the control USS.
✅ uss2_core (2026-03-03T21:58:17.598680Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:17.492920Z)
✅ uss1_dss (2026-03-03T21:58:17.602985Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:17.603115Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:17.603094Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:17.603153Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:17.618948Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:17.627535Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:17.628594Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:17.628634Z)
✅ uss2_core (2026-03-03T21:58:17.628666Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied planning because of
a non-permitted conflict with an equal priority flight intent.
See plan_conflict_flight in prioritization_test_steps.py.
If the USS successfully plans the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per astm.f3548.v21.SCD0035.
✅ uss2_core (2026-03-03T21:58:17.688847Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to plan the Flight 1 via the tested USS. However, it conflicts with Flight 2 which is of equal priority but came first. As such it should be rejected per astm.f3548.v21.SCD0035.
✅ uss2_core (2026-03-03T21:58:17.688819Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:17.635293Z)
✅ uss1_dss (2026-03-03T21:58:17.692965Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 1 should not have been shared with the interoperability ecosystem since it was rejected.
✅ uss2_core (2026-03-03T21:58:17.693050Z)
This page describes the content of a common test step where a user flight intent should be denied activation because of
a non-permitted conflict with an equal priority flight intent.
See activate_conflict_flight in prioritization_test_steps.py.
If the USS successfully activates the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in creating the flight from the user flight intent, per astm.f3548.v21.SCD0045.
✅ uss2_core (2026-03-03T21:58:17.766074Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to activate directly Flight 1, i.e. without the flight being planned before. However, this conflicts with activated Flight 2, which is of equal priority. As such it should be rejected per astm.f3548.v21.SCD0045.
✅ uss2_core (2026-03-03T21:58:17.766039Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:17.701501Z)
✅ uss1_dss (2026-03-03T21:58:17.770418Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Flight 1 should not have been shared with the interoperability ecosystem since it was rejected.
✅ uss2_core (2026-03-03T21:58:17.770467Z)
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:17.879653Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:17.874216Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The smaller Flight 1c form (which doesn't conflict with Flight 2) should be successfully planned by the tested USS.
✅ uss2_core (2026-03-03T21:58:17.879624Z)
Because Flight 2 is nearby Flight 1c, successful planning of Flight 1c indicates the tested USS is complying with the portion of astm.f3548.v21.GEN0500 that requires a USS to indicate two 4D volumes are non-intersecting when they are separated by more than 1 cm.
This check is not relevant if the planning is rejected.
✅ uss2_core (2026-03-03T21:58:17.879701Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:17.776905Z)
✅ uss1_dss (2026-03-03T21:58:17.885019Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:17.885077Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:17.885121Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:17.904700Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:17.915749Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:17.916765Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:17.916805Z)
✅ uss2_core (2026-03-03T21:58:17.916836Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied modification because
of a non-permitted conflict with an equal priority flight intent.
See modify_planned_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0040.
✅ uss2_core (2026-03-03T21:58:17.996943Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to enlarge Flight 1c so that it conflicts with Flight 2. However, Flight 2 is of equal priority but was planned first. As such the change to Flight 1c should be rejected per astm.f3548.v21.SCD0040.
✅ uss2_core (2026-03-03T21:58:17.996898Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:17.926200Z)
✅ uss1_dss (2026-03-03T21:58:18.002175Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:18.002250Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:18.002309Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:18.022473Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:18.031632Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:18.032900Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:18.032940Z)
✅ uss2_core (2026-03-03T21:58:18.032970Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. Because the modification attempt was invalid, either Flight 1c should not have been modified (because the USS kept the original accepted request), or it should have been removed (because the USS rejected the replacement plan provided).
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:18.198559Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:18.190465Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates the smaller Flight 1c form, which should be done successfully. Note that Flight 1c could be either planned or non-existent before this step. In the latter case, the "user" will directly activate the flight without planning it beforehand.
✅ uss2_core (2026-03-03T21:58:18.198528Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:18.041516Z)
✅ uss1_dss (2026-03-03T21:58:18.206044Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:18.206213Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:18.206170Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:18.206306Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:18.234355Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:18.242896Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:18.243938Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:18.243978Z)
✅ uss2_core (2026-03-03T21:58:18.244039Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a user flight intent should be denied modification because
of a non-permitted conflict with an equal priority flight intent.
See modify_activated_conflict_flight in prioritization_test_steps.py.
If the USS successfully modifies the flight or otherwise fails to indicate a conflict, it means they failed to detect the conflict with the pre-existing flight. Therefore, this check will fail if the USS indicates success in modifying the flight from the user flight intent, per astm.f3548.v21.SCD0050.
✅ uss2_core (2026-03-03T21:58:18.325785Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver attempts to enlarge Flight 1c so that it conflicts with Flight 2. Both flights are activated at the point where that change is requested. However, because the conflict did not exist when the modification was initiated, it should be rejected per astm.f3548.v21.SCD0050. In addition, Flight 1c should not have been removed, because doing so would leave an aircraft in flight without any flight plan.
✅ uss2_core (2026-03-03T21:58:18.325753Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:18.253759Z)
✅ uss1_dss (2026-03-03T21:58:18.330634Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. Because the modification attempt was invalid, Flight 1c should not have been modified.
✅ uss2_core (2026-03-03T21:58:18.330685Z)
∅ This test step was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail. If, during the previous step, the USS indicated that it does not support modifications, then it will not be able to modify Flight 1c into Flight 1 during the next test case. As such, the test driver deletes Flight 1c from the system so that Flight 1 can be created directly activated during the next test case.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail. To prepare for the next test case, Flight 2 must be removed from the system.
✅ uss2_core (2026-03-03T21:58:18.366917Z)
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:18.495427Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:18.486412Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The test driver activates the normal form of Flight 1, which should be done successfully since Flight 2 was removed at the end of the previous step. Note that Flight 1 could be either already activated in the smaller Flight 1c form or non-existent before this step. In the former case, Flight 1c is enlarged to its normal size. In the latter case, the flight will be directly activated without being planned beforehand.
✅ uss2_core (2026-03-03T21:58:18.495396Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:18.373516Z)
✅ uss1_dss (2026-03-03T21:58:18.500533Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:18.500627Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:18.500609Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:18.500663Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:18.516617Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:18.524754Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:18.525719Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:18.525757Z)
✅ uss2_core (2026-03-03T21:58:18.525787Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:18.632961Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:18.627140Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior. The smaller Flight 2 form should be successfully planned by the control USS because it does not conflict with Flight 1.
✅ uss2_core (2026-03-03T21:58:18.632932Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:18.531360Z)
✅ uss1_dss (2026-03-03T21:58:18.637276Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:18.637328Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:18.637370Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:18.654801Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:18.662786Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:18.663750Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:18.663788Z)
✅ uss2_core (2026-03-03T21:58:18.663820Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
The test driver instructs the control USS to declare Flight 2 as non-conforming. This makes non-conforming Flight 2 conflict with activated Flight 1 -- this same-priority conflict would not be allowed if Flight 2 were in a nominal state.
Do note that executing this test step requires the control USS to support the CMSA role. As such, if the USS rejects the transition to non-conforming state, it will be assumed that the control USS does not support this role and the test execution will stop without failing.
All flight intent data provided is correct, therefore it should have been transitioned to non-conforming state by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS rejects the transition, this check will fail. If the USS indicates that the operation is not supported, the USS does not support the CMSA role, and as such the scenario execution will stop without failing.
✅ uss2_core (2026-03-03T21:58:18.706135Z)
The requested flight should have been updated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
∅ This check was not applicable to this test run and is therefore not statused.
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:18.706104Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:18.672196Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
∅ This check was not applicable to this test run and is therefore not statused.
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
∅ This check was not applicable to this test run and is therefore not statused.
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
∅ This check was not applicable to this test run and is therefore not statused.
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
∅ This check was not applicable to this test run and is therefore not statused.
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
∅ This check was not applicable to this test run and is therefore not statused.
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
∅ This check was not applicable to this test run and is therefore not statused.
∅ This check was not applicable to this test run and is therefore not statused.
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
∅ This test step was not applicable to this test run and is therefore not statused.
Before execution of this step, Flight 1 is activated (onto time range A) and Flight 2 is non-conforming (onto time range A), and both are in conflict. The test driver modifies Flight 1 in a way that still conflicts with Flight 2 by extending its time range A. This modification results in a conflict between the two equal priority flights that already existed before the modification was initiated. While this modification is expected to be accepted by the tested USS in general, the rejection of the modification does not constitute a violation of a requirement. However, the modification request must not result in a failure per interuss.automated_testing.flight_planning.ExpectedBehavior. Nor should Flight 1 have been removed, because doing so would leave an aircraft in flight without any flight plan.
All flight intent data provided is correct and the USS should have either:
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
If:
this check will fail per astm.f3548.v21.USS0105,2. This step validates that the response of the USS is consistent with the flight shared if the USS accepted the modification, i.e. whether Flight 1 was properly modified.
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. This step validates that the response of the USS is consistent with the flight shared if the USS rejected the modification, i.e. whether Flight 1 was not modified.
interuss.automated_testing.flight_planning.DeleteFlightSuccess
✅ uss2_core (2026-03-03T21:58:18.741755Z)
✅ uss2_core (2026-03-03T21:58:18.774885Z)
This test checks that the USS being tested validates the operational intents received as response to its GET request from another USS. mock_uss plans an operation designed to be relevant to (but not intersect) the operation tested_uss will plan, and provides the data that tested_uss GETs. tested_uss validates the GET response from mock_uss and accordingly plan its operation.
The primary requirement tested by this scenario is astm.f3548.v21.SCD0035 because a USS cannot verify its operational intent does not conflict when it cannot obtain valid details for that operational intent.
This scenario assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).
FlightIntentsResource provides the two flight intents which must be relevant to each other, but must not intersect. This can generally be accomplished when the convex hulls of the 2D footprints of the two flights intersect, but the polygons do not intersect. There is an overlap in time and altitude of the two flights.
✅ Provided by non_conflicting_flights in top-level resource pool.
MockUSSResource that will be used for planning flights, controlling data shared for validation testing, and gathering interuss interactions from mock_uss.
✅ Provided by mock_uss in top-level resource pool.
FlightPlannerResource that will be used for the USS being tested for its data validation of operational intent.
✅ Provided by instance 1 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.
✅ Provided by dss in top-level resource pool.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ mock_uss (2026-03-03T21:58:18.853779Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ mock_uss (2026-03-03T21:58:18.848001Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
Flight 2 should be successfully planned by mock_uss.
✅ mock_uss (2026-03-03T21:58:18.853750Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:18.782508Z)
✅ uss1_dss (2026-03-03T21:58:18.858108Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:18.858162Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ mock_uss (2026-03-03T21:58:18.858206Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:18.871293Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ mock_uss (2026-03-03T21:58:18.879361Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:18.880368Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ mock_uss (2026-03-03T21:58:18.880407Z)
✅ mock_uss (2026-03-03T21:58:18.880439Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:19.025029Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:19.019253Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
The test driver instructs tested_uss to attempt to plan flight 1. tested_uss checks if any conflicts with flight 2 which is of equal priority and came first.
✅ uss1_core (2026-03-03T21:58:19.024983Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:18.887086Z)
✅ uss1_dss (2026-03-03T21:58:19.030723Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:19.030780Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:19.030822Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:19.048960Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:19.056937Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:19.058113Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:19.058152Z)
✅ uss1_core (2026-03-03T21:58:19.058184Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This step verifies that a USS obtained operational intent details from a Mock USS by means of either a notification from the Mock USS (push), or a GET request (operation getOperationalIntentDetails) to the Mock USS.
This step obtains interactions of interest from mock_uss.
The Mock USSes provide a GET endpoint to retrieve all the interactions that took place between them and other USSes after a particular time. If there is any error retrieving these interactions, this check will fail as per interuss.mock_uss.hosted_instance.ExposeInterface.
✅ mock_uss (2026-03-03T21:58:26.073218Z)
SCD0035 requires a USS to verify before transitioning to Accepted that it does not conflict with another operational intent, and the only way to have verified this is by knowing all operational intent details. As such, if the USS was neither notified of the details by the Mock USS, nor did it retrieve them directly from the Mock USS, this check will fail per astm.f3548.v21.SCD0035 Validate that tested_uss obtained flight2 details from mock_uss, by means of either a notification pushed by mock_uss to tested_uss due to the pre-existing subscription, or direct retrieval by tested_uss from mock_uss.
✅ uss1_core (2026-03-03T21:58:26.073466Z)
This step verifies that, when creating or modifying an operational intent, a USS sent the required notification for a relevant subscription owned by a mock_uss instance by checking the interactions of that mock_uss instance.
This step obtains interactions of interest from mock_uss.
The Mock USSes provide a GET endpoint to retrieve all the interactions that took place between them and other USSes after a particular time. If there is any error retrieving these interactions, this check will fail as per interuss.mock_uss.hosted_instance.ExposeInterface.
✅ mock_uss (2026-03-03T21:58:26.080887Z)
As per astm.f3548.v21.SCD0085, the notification should be sent by a USS about its operational intent to the subscribing USS in no more than MaxRespondToSubscriptionNotification (5) seconds, 95 percent of the time. To verify that notification was indeed sent for this check, waiting up to MaxRespondToSubscriptionNotificationSeconds gets us 95 percent confidence in declaring the USS non-compliant if notification is not received. To ensure the notifications sent are not missed for a test case, we can pick a threshold that gives a very high (e.g., 99 percent per test) confidence of non-compliance. We can make conservative assumptions about the distribution of the delays. If we assume that the notification delays have a normal distribution with 95 percentile at 5 seconds, then with the standard deviation of 3.04, we get the 99 percentile at 7.07 seconds. Hence, for test cases that check notification sent for an operational intent, we will wait for notifications till threshold MaxTimeToWaitForSubscriptionNotificationSeconds (rounding to 7 seconds).
As per astm.f3548.v21.SCD0085, MaxRespondToSubscriptionNotification is measured from time_start - Receipt of subscription notification from DSS - till time_end - Entity details sent to subscribing USS. To make sure the test driver gives enough time for notifications to be received by mock_uss, it marks the time to get interactions from mock_uss as - the time test driver initiates the plan. The sequence of events is -
We know from above that waiting from t_time_start for MaxTimeToWaitForSubscriptionNotificationSeconds would give us 99% confidence that we receive the notifications. But, test_driver doesn't have access to t_time_start. So, it starts waiting from a point of time after the t_time_start that is t1. This ensures that test driver waits for a long enough duration before getting the interactions. Hence, we get a high confidence that the test driver correctly verifies if a notification was sent by tested_uss.
✅ uss1_core (2026-03-03T21:58:26.080956Z)
astm.f3548.v21.SCD0085 tested_uss notifies mock_uss of flight 1, due to mock_uss's subscription covering flight 2 (which is necessarily relevant to flight 1 per test design).
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail.
To prepare for the next test case, tested_uss's flight 1 is closed.
✅ uss1_core (2026-03-03T21:58:26.134492Z)
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail.
To prepare for the next test case, mock_uss's flight 2 is closed.
✅ mock_uss (2026-03-03T21:58:26.164445Z)
In this test case, mock_uss is manipulated to share invalid operational intent details which should prevent tested_uss from planning since it cannot verify the absence of a conflict.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ mock_uss (2026-03-03T21:58:26.221883Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ mock_uss (2026-03-03T21:58:26.216028Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
Flight 2 should be successfully planned by the mock_uss.
✅ mock_uss (2026-03-03T21:58:26.221854Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See expect_shared_with_invalid_data in invalid_op_test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intent references in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:26.170660Z)
✅ uss1_dss (2026-03-03T21:58:26.226497Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:26.226546Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:26.239329Z)
interuss.mock_uss.hosted_instance.ExposeInterface.
Mock USS shares operational intent details with specified invalid data in response for the negative test case as per the GetOperationalIntentDetailsResponse schema of the OpenAPI specification. If the operational intent details from mock_uss does not contain the specified invalid data, this check will fail. It would mean mock_uss is not behaving correctly.
The mock_uss is instructed to share invalid data with other USS, for negative test.
✅ mock_uss (2026-03-03T21:58:26.246454Z)
This page describes the content of a common test case where a valid user flight intent fails in a flight planner, because of invalid data shared for a nearby flight shared by another USS. See plan_flight_intent_expect_failed in invalid_op_test_steps.py.
A USS shouldn't go ahead and plan if it doesn't have accurate information. As per SCD0035 a USS needs to verify a particular conflict status. If flight intent data shared for a nearby flight shared is invalid, the USS can't successfully perform that verification. It couldn't have obtained valid information about the other operational intents it's supposed to verify that conflict status against. Therefore, the USS should fail an attempt to plan. If the plan succeeds, we know they've violated SCD0035 because they failed to verify that particular conflict status.
The test driver instructs tested_uss to plan flight 1. tested_uss should (per SCD0035) check if any conflicts with flight 2 which is of equal priority and came first. The planning attempt should fail because tested_uss will be unable to obtain valid operational intent details for flight 2.
✅ uss1_core (2026-03-03T21:58:26.313678Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:26.253046Z)
✅ uss1_dss (2026-03-03T21:58:26.317842Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
Validate flight 1 is not shared with DSS, as plan failed.
✅ uss1_core (2026-03-03T21:58:26.317892Z)
This step verifies that a USS obtained operational intent details from a Mock USS by means of either a notification from the Mock USS (push), or a GET request (operation getOperationalIntentDetails) to the Mock USS.
This step obtains interactions of interest from mock_uss.
The Mock USSes provide a GET endpoint to retrieve all the interactions that took place between them and other USSes after a particular time. If there is any error retrieving these interactions, this check will fail as per interuss.mock_uss.hosted_instance.ExposeInterface.
✅ mock_uss (2026-03-03T21:58:33.328806Z)
SCD0035 requires a USS to verify before transitioning to Accepted that it does not conflict with another operational intent, and the only way to have verified this is by knowing all operational intent details. As such, if the USS was neither notified of the details by the Mock USS, nor did it retrieve them directly from the Mock USS, this check will fail per astm.f3548.v21.SCD0035 Validate that tested_uss obtained flight2 details from mock_uss, by means of either a notification pushed by mock_uss to tested_uss due to the pre-existing subscription, or direct retrieval by tested_uss from mock_uss.
✅ uss1_core (2026-03-03T21:58:33.329031Z)
This step verifies when a flight is not created, it is also not notified by checking the interuss interactions of mock_uss instance.
This step obtains interactions of interest from mock_uss.
The Mock USSes provide a GET endpoint to retrieve all the interactions that took place between them and other USSes after a particular time. If there is any error retrieving these interactions, this check will fail as per interuss.mock_uss.hosted_instance.ExposeInterface.
✅ mock_uss (2026-03-03T21:58:33.335897Z)
interuss.mock_uss.hosted_instance.ExposeInterface.
∅ This check was not applicable to this test run and is therefore not statused.
interuss.f3548.notification_requirements.NoDssEntityNoNotification
As per the above requirement, the notification should not be sent by a USS about an entity that could not be created in DSS to any USS. To verify that notification was indeed not sent, we need to wait and check up to a threshold to get confidence that USS did not send notification. The max duration for sending a notification in SCD0085 is MaxRespondToSubscriptionNotification(5) seconds. However, this duration is from time start - Receipt of subscription notification from DSS, which does not exist for this check. In this check we use time start when the test driver asked the USS to plan the failed flight. When checking notification not sent, we should wait for the same duration that is used for when checking notification sent. Expect Notification sent. So, we plan to use MaxTimeToWaitForSubscriptionNotificationSeconds (7 seconds).
✅ uss1_core (2026-03-03T21:58:33.335965Z)
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail. Teardown
✅ mock_uss (2026-03-03T21:58:33.413739Z)
This cleanup is for both - after testcase ends and after test scenario ends interuss.automated_testing.flight_planning.DeleteFlightSuccess ∅ This check was not applicable to this test run and is therefore not statused.
This test checks that the USS being tested validates the operational intents received as response to its GET request from another USS. mock_uss plans an operation designed to be relevant to (but not intersect) the operation tested_uss will plan, and provides the data that tested_uss GETs. tested_uss validates the GET response from mock_uss and accordingly plan its operation.
The primary requirement tested by this scenario is astm.f3548.v21.SCD0035 because a USS cannot verify its operational intent does not conflict when it cannot obtain valid details for that operational intent.
This scenario assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).
FlightIntentsResource provides the two flight intents which must be relevant to each other, but must not intersect. This can generally be accomplished when the convex hulls of the 2D footprints of the two flights intersect, but the polygons do not intersect. There is an overlap in time and altitude of the two flights.
✅ Provided by non_conflicting_flights in top-level resource pool.
MockUSSResource that will be used for planning flights, controlling data shared for validation testing, and gathering interuss interactions from mock_uss.
✅ Provided by mock_uss in top-level resource pool.
FlightPlannerResource that will be used for the USS being tested for its data validation of operational intent.
✅ Provided by instance 2 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.
✅ Provided by dss in top-level resource pool.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ mock_uss (2026-03-03T21:58:33.496267Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ mock_uss (2026-03-03T21:58:33.488559Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
Flight 2 should be successfully planned by mock_uss.
✅ mock_uss (2026-03-03T21:58:33.496198Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:33.423919Z)
✅ uss1_dss (2026-03-03T21:58:33.506982Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:33.507085Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ mock_uss (2026-03-03T21:58:33.507160Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:33.528861Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ mock_uss (2026-03-03T21:58:33.540885Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:33.542459Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ mock_uss (2026-03-03T21:58:33.542515Z)
✅ mock_uss (2026-03-03T21:58:33.542563Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:33.685564Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:33.679655Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
The test driver instructs tested_uss to attempt to plan flight 1. tested_uss checks if any conflicts with flight 2 which is of equal priority and came first.
✅ uss2_core (2026-03-03T21:58:33.685534Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:33.551679Z)
✅ uss1_dss (2026-03-03T21:58:33.691115Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:33.691172Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:33.691214Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:33.712855Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:33.722976Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:33.724565Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:33.724624Z)
✅ uss2_core (2026-03-03T21:58:33.724676Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This step verifies that a USS obtained operational intent details from a Mock USS by means of either a notification from the Mock USS (push), or a GET request (operation getOperationalIntentDetails) to the Mock USS.
This step obtains interactions of interest from mock_uss.
The Mock USSes provide a GET endpoint to retrieve all the interactions that took place between them and other USSes after a particular time. If there is any error retrieving these interactions, this check will fail as per interuss.mock_uss.hosted_instance.ExposeInterface.
✅ mock_uss (2026-03-03T21:58:40.744391Z)
SCD0035 requires a USS to verify before transitioning to Accepted that it does not conflict with another operational intent, and the only way to have verified this is by knowing all operational intent details. As such, if the USS was neither notified of the details by the Mock USS, nor did it retrieve them directly from the Mock USS, this check will fail per astm.f3548.v21.SCD0035 Validate that tested_uss obtained flight2 details from mock_uss, by means of either a notification pushed by mock_uss to tested_uss due to the pre-existing subscription, or direct retrieval by tested_uss from mock_uss.
✅ uss2_core (2026-03-03T21:58:40.744595Z)
This step verifies that, when creating or modifying an operational intent, a USS sent the required notification for a relevant subscription owned by a mock_uss instance by checking the interactions of that mock_uss instance.
This step obtains interactions of interest from mock_uss.
The Mock USSes provide a GET endpoint to retrieve all the interactions that took place between them and other USSes after a particular time. If there is any error retrieving these interactions, this check will fail as per interuss.mock_uss.hosted_instance.ExposeInterface.
✅ mock_uss (2026-03-03T21:58:40.752759Z)
As per astm.f3548.v21.SCD0085, the notification should be sent by a USS about its operational intent to the subscribing USS in no more than MaxRespondToSubscriptionNotification (5) seconds, 95 percent of the time. To verify that notification was indeed sent for this check, waiting up to MaxRespondToSubscriptionNotificationSeconds gets us 95 percent confidence in declaring the USS non-compliant if notification is not received. To ensure the notifications sent are not missed for a test case, we can pick a threshold that gives a very high (e.g., 99 percent per test) confidence of non-compliance. We can make conservative assumptions about the distribution of the delays. If we assume that the notification delays have a normal distribution with 95 percentile at 5 seconds, then with the standard deviation of 3.04, we get the 99 percentile at 7.07 seconds. Hence, for test cases that check notification sent for an operational intent, we will wait for notifications till threshold MaxTimeToWaitForSubscriptionNotificationSeconds (rounding to 7 seconds).
As per astm.f3548.v21.SCD0085, MaxRespondToSubscriptionNotification is measured from time_start - Receipt of subscription notification from DSS - till time_end - Entity details sent to subscribing USS. To make sure the test driver gives enough time for notifications to be received by mock_uss, it marks the time to get interactions from mock_uss as - the time test driver initiates the plan. The sequence of events is -
We know from above that waiting from t_time_start for MaxTimeToWaitForSubscriptionNotificationSeconds would give us 99% confidence that we receive the notifications. But, test_driver doesn't have access to t_time_start. So, it starts waiting from a point of time after the t_time_start that is t1. This ensures that test driver waits for a long enough duration before getting the interactions. Hence, we get a high confidence that the test driver correctly verifies if a notification was sent by tested_uss.
✅ uss2_core (2026-03-03T21:58:40.752844Z)
astm.f3548.v21.SCD0085 tested_uss notifies mock_uss of flight 1, due to mock_uss's subscription covering flight 2 (which is necessarily relevant to flight 1 per test design).
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail.
To prepare for the next test case, tested_uss's flight 1 is closed.
✅ uss2_core (2026-03-03T21:58:40.796688Z)
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail.
To prepare for the next test case, mock_uss's flight 2 is closed.
✅ mock_uss (2026-03-03T21:58:40.825768Z)
In this test case, mock_uss is manipulated to share invalid operational intent details which should prevent tested_uss from planning since it cannot verify the absence of a conflict.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ mock_uss (2026-03-03T21:58:40.888442Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ mock_uss (2026-03-03T21:58:40.877411Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
Flight 2 should be successfully planned by the mock_uss.
✅ mock_uss (2026-03-03T21:58:40.888412Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See expect_shared_with_invalid_data in invalid_op_test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intent references in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:40.831604Z)
✅ uss1_dss (2026-03-03T21:58:40.893143Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:40.893198Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:40.906532Z)
interuss.mock_uss.hosted_instance.ExposeInterface.
Mock USS shares operational intent details with specified invalid data in response for the negative test case as per the GetOperationalIntentDetailsResponse schema of the OpenAPI specification. If the operational intent details from mock_uss does not contain the specified invalid data, this check will fail. It would mean mock_uss is not behaving correctly.
The mock_uss is instructed to share invalid data with other USS, for negative test.
✅ mock_uss (2026-03-03T21:58:40.913777Z)
This page describes the content of a common test case where a valid user flight intent fails in a flight planner, because of invalid data shared for a nearby flight shared by another USS. See plan_flight_intent_expect_failed in invalid_op_test_steps.py.
A USS shouldn't go ahead and plan if it doesn't have accurate information. As per SCD0035 a USS needs to verify a particular conflict status. If flight intent data shared for a nearby flight shared is invalid, the USS can't successfully perform that verification. It couldn't have obtained valid information about the other operational intents it's supposed to verify that conflict status against. Therefore, the USS should fail an attempt to plan. If the plan succeeds, we know they've violated SCD0035 because they failed to verify that particular conflict status.
The test driver instructs tested_uss to plan flight 1. tested_uss should (per SCD0035) check if any conflicts with flight 2 which is of equal priority and came first. The planning attempt should fail because tested_uss will be unable to obtain valid operational intent details for flight 2.
✅ uss2_core (2026-03-03T21:58:40.981342Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:40.920789Z)
✅ uss1_dss (2026-03-03T21:58:40.986828Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
Validate flight 1 is not shared with DSS, as plan failed.
✅ uss2_core (2026-03-03T21:58:40.986908Z)
This step verifies that a USS obtained operational intent details from a Mock USS by means of either a notification from the Mock USS (push), or a GET request (operation getOperationalIntentDetails) to the Mock USS.
This step obtains interactions of interest from mock_uss.
The Mock USSes provide a GET endpoint to retrieve all the interactions that took place between them and other USSes after a particular time. If there is any error retrieving these interactions, this check will fail as per interuss.mock_uss.hosted_instance.ExposeInterface.
✅ mock_uss (2026-03-03T21:58:47.998872Z)
SCD0035 requires a USS to verify before transitioning to Accepted that it does not conflict with another operational intent, and the only way to have verified this is by knowing all operational intent details. As such, if the USS was neither notified of the details by the Mock USS, nor did it retrieve them directly from the Mock USS, this check will fail per astm.f3548.v21.SCD0035 Validate that tested_uss obtained flight2 details from mock_uss, by means of either a notification pushed by mock_uss to tested_uss due to the pre-existing subscription, or direct retrieval by tested_uss from mock_uss.
✅ uss2_core (2026-03-03T21:58:47.999081Z)
This step verifies when a flight is not created, it is also not notified by checking the interuss interactions of mock_uss instance.
This step obtains interactions of interest from mock_uss.
The Mock USSes provide a GET endpoint to retrieve all the interactions that took place between them and other USSes after a particular time. If there is any error retrieving these interactions, this check will fail as per interuss.mock_uss.hosted_instance.ExposeInterface.
✅ mock_uss (2026-03-03T21:58:48.005976Z)
interuss.mock_uss.hosted_instance.ExposeInterface.
∅ This check was not applicable to this test run and is therefore not statused.
interuss.f3548.notification_requirements.NoDssEntityNoNotification
As per the above requirement, the notification should not be sent by a USS about an entity that could not be created in DSS to any USS. To verify that notification was indeed not sent, we need to wait and check up to a threshold to get confidence that USS did not send notification. The max duration for sending a notification in SCD0085 is MaxRespondToSubscriptionNotification(5) seconds. However, this duration is from time start - Receipt of subscription notification from DSS, which does not exist for this check. In this check we use time start when the test driver asked the USS to plan the failed flight. When checking notification not sent, we should wait for the same duration that is used for when checking notification sent. Expect Notification sent. So, we plan to use MaxTimeToWaitForSubscriptionNotificationSeconds (7 seconds).
✅ uss2_core (2026-03-03T21:58:48.006046Z)
This page describes the content of a common test case where a flight intent should be successfully deleted by a flight planner.
See delete_flight in test_steps.py.
The flight ID provided is correct and corresponds to an existing flight intent, therefore it should have been deleted by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a failure, this check will fail. Teardown
✅ mock_uss (2026-03-03T21:58:48.036044Z)
This cleanup is for both - after testcase ends and after test scenario ends interuss.automated_testing.flight_planning.DeleteFlightSuccess ∅ This check was not applicable to this test run and is therefore not statused.
When a USS submits an operational intent to DSS, a subscription is associated with that operational intent in DSS. This subscription can be either an implicit or explicit subscription that covers the area of the operational intent. The subscription helps the USS to be notified of new or modified operations in the area, when its operational intent is in Activated, NonConforming and Contingent states. In this scenario, we will verify that USS under test has a subscription to cover the operational intent area, and receives relevant notifications from other USSes.
This scenario assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).
FlightIntentsResource that provides the following flight intents:
| Flight intent ID | Flight name | State | Must be relevant, but not intersecting |
|---|---|---|---|
flight_1_planned |
Flight 1 | Accepted | Flight 2 |
flight_1_activated |
Activated | ||
flight_2_planned |
Flight 2 | Accepted | Flight 1 |
flight_2_planned_modified |
To reach a situation where Flight 1 and Flight 2 do not intersect but are relevant to each other:
Because the scenario involves activation of intents, all activated intents must be active during the execution of the test scenario. Additionally, their end time must leave sufficient time for the execution of the test scenario. For the sake of simplicity, it is recommended to set the start and end times of all the intents to the same range.
✅ Provided by non_conflicting_flights in top-level resource pool.
MockUSSResource will be used for planning flights in order to send notifications to tested_uss, and gathering interuss interactions from mock_uss.
✅ Provided by mock_uss in top-level resource pool.
FlightPlannerResource that will be used for the USS being tested for its ability to maintain awareness of operational intent.
✅ Provided by instance 1 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.
✅ Provided by dss in top-level resource pool.
This test case verifies that relevant notifications for new operational intents are received through subscription of an operational intent in Activated state.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:48.145592Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:48.139694Z)
✅ uss1_core (2026-03-03T21:58:48.298317Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
Flight 1 should be successfully planned by tested_uss.
✅ uss1_core (2026-03-03T21:58:48.145563Z)
✅ uss1_core (2026-03-03T21:58:48.304200Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:48.046862Z)
✅ uss1_dss (2026-03-03T21:58:48.150309Z)
✅ uss1_dss (2026-03-03T21:58:48.181592Z)
✅ uss1_dss (2026-03-03T21:58:48.308732Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:48.150367Z)
✅ uss1_core (2026-03-03T21:58:48.308835Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:48.308817Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:48.150413Z)
✅ uss1_core (2026-03-03T21:58:48.308876Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:48.168344Z)
✅ uss1_core (2026-03-03T21:58:48.325573Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:48.176366Z)
✅ uss1_core (2026-03-03T21:58:48.333721Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:48.177349Z)
✅ uss1_core (2026-03-03T21:58:48.334790Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:48.177393Z)
✅ uss1_core (2026-03-03T21:58:48.334835Z)
✅ uss1_core (2026-03-03T21:58:48.177429Z)
✅ uss1_core (2026-03-03T21:58:48.334873Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss1_core (2026-03-03T21:58:48.304230Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:48.139694Z)
✅ uss1_core (2026-03-03T21:58:48.298317Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
Flight 1 should be successfully activated by the tested USS.
✅ uss1_core (2026-03-03T21:58:48.145563Z)
✅ uss1_core (2026-03-03T21:58:48.304200Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:48.046862Z)
✅ uss1_dss (2026-03-03T21:58:48.150309Z)
✅ uss1_dss (2026-03-03T21:58:48.181592Z)
✅ uss1_dss (2026-03-03T21:58:48.308732Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:48.150367Z)
✅ uss1_core (2026-03-03T21:58:48.308835Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss1_core (2026-03-03T21:58:48.308817Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:48.150413Z)
✅ uss1_core (2026-03-03T21:58:48.308876Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:48.168344Z)
✅ uss1_core (2026-03-03T21:58:48.325573Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:48.176366Z)
✅ uss1_core (2026-03-03T21:58:48.333721Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:48.177349Z)
✅ uss1_core (2026-03-03T21:58:48.334790Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:48.177393Z)
✅ uss1_core (2026-03-03T21:58:48.334835Z)
✅ uss1_core (2026-03-03T21:58:48.177429Z)
✅ uss1_core (2026-03-03T21:58:48.334873Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
While validating that Flight 1 has been shared, we will be able to find the subscription id associated with Flight 1 in DSS. Notifications of relevant flights will be sent to tested_uss using this subscription id.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ mock_uss (2026-03-03T21:58:48.444023Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ mock_uss (2026-03-03T21:58:48.435493Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
The test driver successfully plans Flight 2 via the mock uss, as there is no conflict with Flight 1. However, because they are relevant to each other mock_uss will send Flight 2 notification to tested_uss.
✅ mock_uss (2026-03-03T21:58:48.443965Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:48.338883Z)
✅ uss1_dss (2026-03-03T21:58:48.451570Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:48.451655Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ mock_uss (2026-03-03T21:58:48.451725Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:48.465200Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ mock_uss (2026-03-03T21:58:48.474509Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:48.475583Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ mock_uss (2026-03-03T21:58:48.475622Z)
✅ mock_uss (2026-03-03T21:58:48.475676Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This step verifies that a Tested USS successfully received a notification about a relevant operational intent from a Mock USS instance. This is done by checking the interactions of that Mock USS instance.
This step obtains interactions of interest from mock_uss.
The Mock USSes provide a GET endpoint to retrieve all the interactions that took place between them and other USSes after a particular time. If there is any error retrieving these interactions, this check will fail as per interuss.mock_uss.hosted_instance.ExposeInterface. Mock USS provides a GET endpoint to retrieve all the interactions that took place between Mock USS and other USSes after a particular time. These interactions also include the notifications sent and received by Mock USS.
✅ mock_uss (2026-03-03T21:58:48.486587Z)
There is an assumption here that DSS shared the correct subscriber information with Mock USS in response to planning or modifying its operational intent.
As per astm.f3548.v21.USS0005, Mock USS should send valid notification to USSes subscribed in the area. The validation of notification involves checking that Mock USS included the correct subscription_id in the notification. The check will fail if no or more than one notification is sent to the tested USS, or if the notification does not include the expected subscription_id.
✅ mock_uss (2026-03-03T21:58:48.486668Z)
USSes shall maintain awareness of operational intents relevant to their own ones when they are in the Activated, NonConforming or Contingent states. In DSS, there is a subscription associated with an operational intent managed by a USS. A tested USS should successfully receive a notification of relevant intent from Mock USS based on this subscription.
If the tested USS does not respond with an HTTP status 204 to a valid notification sent by the mock USS, then the tested USS
does not maintain awareness of operational intents relevant to their own ones (astm.f3548.v21.SCD0080), and
does not implement correctly the notifyOperationalIntentDetailsChanged operation (astm.f3548.v21.USS0105,3).
Check a notification was received by tested_uss for Flight 2, with Flight 1's subscription_id.
✅ uss1_core (2026-03-03T21:58:48.486707Z)
This test case verifies that relevant notifications for modified operational intents are received through subscription of an operational intent in Activated state.
This page describes the content of a common test case where a valid user flight intent in planned state should be
successfully modified by a flight planner. See modify_planned_flight in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been modified by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS fails to modify the flight, wrongly indicates a conflict, or wrongly indicates the planned state of the flight, this check will fail.
✅ mock_uss (2026-03-03T21:58:48.598601Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ mock_uss (2026-03-03T21:58:48.592554Z)
The requested flight should have been modified essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
The test driver successfully modifies planned Flight 2 via the mock uss, as there is still no conflict with Flight 1. However, because they are relevant to each other mock_uss will send Flight 2 notification to tested_uss.
✅ mock_uss (2026-03-03T21:58:48.598571Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:48.496211Z)
✅ uss1_dss (2026-03-03T21:58:48.604580Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:48.604648Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ mock_uss (2026-03-03T21:58:48.604690Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:48.617052Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ mock_uss (2026-03-03T21:58:48.627129Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:48.628584Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ mock_uss (2026-03-03T21:58:48.628641Z)
✅ mock_uss (2026-03-03T21:58:48.628691Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This step verifies that a Tested USS successfully received a notification about a relevant operational intent from a Mock USS instance. This is done by checking the interactions of that Mock USS instance.
This step obtains interactions of interest from mock_uss.
The Mock USSes provide a GET endpoint to retrieve all the interactions that took place between them and other USSes after a particular time. If there is any error retrieving these interactions, this check will fail as per interuss.mock_uss.hosted_instance.ExposeInterface. Mock USS provides a GET endpoint to retrieve all the interactions that took place between Mock USS and other USSes after a particular time. These interactions also include the notifications sent and received by Mock USS.
✅ mock_uss (2026-03-03T21:58:48.640093Z)
There is an assumption here that DSS shared the correct subscriber information with Mock USS in response to planning or modifying its operational intent.
As per astm.f3548.v21.USS0005, Mock USS should send valid notification to USSes subscribed in the area. The validation of notification involves checking that Mock USS included the correct subscription_id in the notification. The check will fail if no or more than one notification is sent to the tested USS, or if the notification does not include the expected subscription_id.
✅ mock_uss (2026-03-03T21:58:48.640222Z)
USSes shall maintain awareness of operational intents relevant to their own ones when they are in the Activated, NonConforming or Contingent states. In DSS, there is a subscription associated with an operational intent managed by a USS. A tested USS should successfully receive a notification of relevant intent from Mock USS based on this subscription.
If the tested USS does not respond with an HTTP status 204 to a valid notification sent by the mock USS, then the tested USS
does not maintain awareness of operational intents relevant to their own ones (astm.f3548.v21.SCD0080), and
does not implement correctly the notifyOperationalIntentDetailsChanged operation (astm.f3548.v21.USS0105,3).
Check a notification was received by tested_uss for Flight 2, with Flight 1's subscription_id, after modification of the flight.
✅ uss1_core (2026-03-03T21:58:48.640284Z)
∅ This test case was not applicable to this test run and is therefore not statused.
∅ This test case was not applicable to this test run and is therefore not statused.
The flights are cleaned up at the end of the test scenario. interuss.automated_testing.flight_planning.DeleteFlightSuccess
✅ mock_uss (2026-03-03T21:58:48.693382Z)
✅ uss1_core (2026-03-03T21:58:48.730378Z)
When a USS submits an operational intent to DSS, a subscription is associated with that operational intent in DSS. This subscription can be either an implicit or explicit subscription that covers the area of the operational intent. The subscription helps the USS to be notified of new or modified operations in the area, when its operational intent is in Activated, NonConforming and Contingent states. In this scenario, we will verify that USS under test has a subscription to cover the operational intent area, and receives relevant notifications from other USSes.
This scenario assumes that the area used in the scenario is already clear of any pre-existing flights (using, for instance, PrepareFlightPlanners scenario).
FlightIntentsResource that provides the following flight intents:
| Flight intent ID | Flight name | State | Must be relevant, but not intersecting |
|---|---|---|---|
flight_1_planned |
Flight 1 | Accepted | Flight 2 |
flight_1_activated |
Activated | ||
flight_2_planned |
Flight 2 | Accepted | Flight 1 |
flight_2_planned_modified |
To reach a situation where Flight 1 and Flight 2 do not intersect but are relevant to each other:
Because the scenario involves activation of intents, all activated intents must be active during the execution of the test scenario. Additionally, their end time must leave sufficient time for the execution of the test scenario. For the sake of simplicity, it is recommended to set the start and end times of all the intents to the same range.
✅ Provided by non_conflicting_flights in top-level resource pool.
MockUSSResource will be used for planning flights in order to send notifications to tested_uss, and gathering interuss interactions from mock_uss.
✅ Provided by mock_uss in top-level resource pool.
FlightPlannerResource that will be used for the USS being tested for its ability to maintain awareness of operational intent.
✅ Provided by instance 2 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where flight creation/sharing can be verified.
✅ Provided by dss in top-level resource pool.
This test case verifies that relevant notifications for new operational intents are received through subscription of an operational intent in Activated state.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:48.881983Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:48.876071Z)
✅ uss2_core (2026-03-03T21:58:49.039557Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
Flight 1 should be successfully planned by tested_uss.
✅ uss2_core (2026-03-03T21:58:48.881954Z)
✅ uss2_core (2026-03-03T21:58:49.045440Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:48.741545Z)
✅ uss1_dss (2026-03-03T21:58:48.887411Z)
✅ uss1_dss (2026-03-03T21:58:48.920318Z)
✅ uss1_dss (2026-03-03T21:58:49.050353Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:48.887469Z)
✅ uss2_core (2026-03-03T21:58:49.050456Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:49.050438Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:48.887518Z)
✅ uss2_core (2026-03-03T21:58:49.050497Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:48.906270Z)
✅ uss2_core (2026-03-03T21:58:49.066934Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:48.914408Z)
✅ uss2_core (2026-03-03T21:58:49.074956Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:48.915729Z)
✅ uss2_core (2026-03-03T21:58:49.075954Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:48.915776Z)
✅ uss2_core (2026-03-03T21:58:49.075997Z)
✅ uss2_core (2026-03-03T21:58:48.915813Z)
✅ uss2_core (2026-03-03T21:58:49.076052Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test step where a valid user flight intent should be successfully activated by a flight planner. See activate_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been activated by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ uss2_core (2026-03-03T21:58:49.045470Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:48.876071Z)
✅ uss2_core (2026-03-03T21:58:49.039557Z)
The requested flight should have been activated essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
Flight 1 should be successfully activated by the tested USS.
✅ uss2_core (2026-03-03T21:58:48.881954Z)
✅ uss2_core (2026-03-03T21:58:49.045440Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:48.741545Z)
✅ uss1_dss (2026-03-03T21:58:48.887411Z)
✅ uss1_dss (2026-03-03T21:58:48.920318Z)
✅ uss1_dss (2026-03-03T21:58:49.050353Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:48.887469Z)
✅ uss2_core (2026-03-03T21:58:49.050456Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
✅ uss2_core (2026-03-03T21:58:49.050438Z)
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:48.887518Z)
✅ uss2_core (2026-03-03T21:58:49.050497Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:48.906270Z)
✅ uss2_core (2026-03-03T21:58:49.066934Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:48.914408Z)
✅ uss2_core (2026-03-03T21:58:49.074956Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:48.915729Z)
✅ uss2_core (2026-03-03T21:58:49.075954Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:48.915776Z)
✅ uss2_core (2026-03-03T21:58:49.075997Z)
✅ uss2_core (2026-03-03T21:58:48.915813Z)
✅ uss2_core (2026-03-03T21:58:49.076052Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
While validating that Flight 1 has been shared, we will be able to find the subscription id associated with Flight 1 in DSS. Notifications of relevant flights will be sent to tested_uss using this subscription id.
∅ This check was not applicable to this test run and is therefore not statused.
This page describes the content of a common test case where a valid user flight intent should be successfully planned by a flight planner. See plan_flight_intent in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been planned by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS indicates a conflict, this check will fail. If the USS indicates that the flight was rejected, this check will fail. If the USS indicates that the injection attempt failed, this check will fail.
✅ mock_uss (2026-03-03T21:58:49.185568Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ mock_uss (2026-03-03T21:58:49.179579Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
The test driver successfully plans Flight 2 via the mock uss, as there is no conflict with Flight 1. However, because they are relevant to each other mock_uss will send Flight 2 notification to tested_uss.
✅ mock_uss (2026-03-03T21:58:49.185537Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:49.080584Z)
✅ uss1_dss (2026-03-03T21:58:49.191087Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:49.191144Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ mock_uss (2026-03-03T21:58:49.191187Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:49.203822Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ mock_uss (2026-03-03T21:58:49.212044Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:49.213049Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ mock_uss (2026-03-03T21:58:49.213089Z)
✅ mock_uss (2026-03-03T21:58:49.213120Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This step verifies that a Tested USS successfully received a notification about a relevant operational intent from a Mock USS instance. This is done by checking the interactions of that Mock USS instance.
This step obtains interactions of interest from mock_uss.
The Mock USSes provide a GET endpoint to retrieve all the interactions that took place between them and other USSes after a particular time. If there is any error retrieving these interactions, this check will fail as per interuss.mock_uss.hosted_instance.ExposeInterface. Mock USS provides a GET endpoint to retrieve all the interactions that took place between Mock USS and other USSes after a particular time. These interactions also include the notifications sent and received by Mock USS.
✅ mock_uss (2026-03-03T21:58:49.223769Z)
There is an assumption here that DSS shared the correct subscriber information with Mock USS in response to planning or modifying its operational intent.
As per astm.f3548.v21.USS0005, Mock USS should send valid notification to USSes subscribed in the area. The validation of notification involves checking that Mock USS included the correct subscription_id in the notification. The check will fail if no or more than one notification is sent to the tested USS, or if the notification does not include the expected subscription_id.
✅ mock_uss (2026-03-03T21:58:49.223847Z)
USSes shall maintain awareness of operational intents relevant to their own ones when they are in the Activated, NonConforming or Contingent states. In DSS, there is a subscription associated with an operational intent managed by a USS. A tested USS should successfully receive a notification of relevant intent from Mock USS based on this subscription.
If the tested USS does not respond with an HTTP status 204 to a valid notification sent by the mock USS, then the tested USS
does not maintain awareness of operational intents relevant to their own ones (astm.f3548.v21.SCD0080), and
does not implement correctly the notifyOperationalIntentDetailsChanged operation (astm.f3548.v21.USS0105,3).
Check a notification was received by tested_uss for Flight 2, with Flight 1's subscription_id.
✅ uss2_core (2026-03-03T21:58:49.223884Z)
This test case verifies that relevant notifications for modified operational intents are received through subscription of an operational intent in Activated state.
This page describes the content of a common test case where a valid user flight intent in planned state should be
successfully modified by a flight planner. See modify_planned_flight in test_steps.py.
All flight intent data provided is correct and valid and free of conflict in space and time, therefore it should have been modified by the USS per interuss.automated_testing.flight_planning.ExpectedBehavior. If the USS fails to modify the flight, wrongly indicates a conflict, or wrongly indicates the planned state of the flight, this check will fail.
✅ mock_uss (2026-03-03T21:58:49.338342Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept the flight. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ mock_uss (2026-03-03T21:58:49.332044Z)
The requested flight should have been modified essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
The test driver successfully modifies planned Flight 2 via the mock uss, as there is still no conflict with Flight 1. However, because they are relevant to each other mock_uss will send Flight 2 notification to tested_uss.
✅ mock_uss (2026-03-03T21:58:49.338311Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:49.231880Z)
✅ uss1_dss (2026-03-03T21:58:49.344487Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:49.344546Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ mock_uss (2026-03-03T21:58:49.344587Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:49.358899Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ mock_uss (2026-03-03T21:58:49.367741Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ mock_uss (2026-03-03T21:58:49.368751Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ mock_uss (2026-03-03T21:58:49.368791Z)
✅ mock_uss (2026-03-03T21:58:49.368822Z)
If:
this check will fail per astm.f3548.v21.USS0105,2.
∅ This check was not applicable to this test run and is therefore not statused.
This step verifies that a Tested USS successfully received a notification about a relevant operational intent from a Mock USS instance. This is done by checking the interactions of that Mock USS instance.
This step obtains interactions of interest from mock_uss.
The Mock USSes provide a GET endpoint to retrieve all the interactions that took place between them and other USSes after a particular time. If there is any error retrieving these interactions, this check will fail as per interuss.mock_uss.hosted_instance.ExposeInterface. Mock USS provides a GET endpoint to retrieve all the interactions that took place between Mock USS and other USSes after a particular time. These interactions also include the notifications sent and received by Mock USS.
✅ mock_uss (2026-03-03T21:58:49.379029Z)
There is an assumption here that DSS shared the correct subscriber information with Mock USS in response to planning or modifying its operational intent.
As per astm.f3548.v21.USS0005, Mock USS should send valid notification to USSes subscribed in the area. The validation of notification involves checking that Mock USS included the correct subscription_id in the notification. The check will fail if no or more than one notification is sent to the tested USS, or if the notification does not include the expected subscription_id.
✅ mock_uss (2026-03-03T21:58:49.379103Z)
USSes shall maintain awareness of operational intents relevant to their own ones when they are in the Activated, NonConforming or Contingent states. In DSS, there is a subscription associated with an operational intent managed by a USS. A tested USS should successfully receive a notification of relevant intent from Mock USS based on this subscription.
If the tested USS does not respond with an HTTP status 204 to a valid notification sent by the mock USS, then the tested USS
does not maintain awareness of operational intents relevant to their own ones (astm.f3548.v21.SCD0080), and
does not implement correctly the notifyOperationalIntentDetailsChanged operation (astm.f3548.v21.USS0105,3).
Check a notification was received by tested_uss for Flight 2, with Flight 1's subscription_id, after modification of the flight.
✅ uss2_core (2026-03-03T21:58:49.379140Z)
∅ This test case was not applicable to this test run and is therefore not statused.
∅ This test case was not applicable to this test run and is therefore not statused.
The flights are cleaned up at the end of the test scenario. interuss.automated_testing.flight_planning.DeleteFlightSuccess
✅ mock_uss (2026-03-03T21:58:49.416372Z)
✅ uss2_core (2026-03-03T21:58:49.450119Z)
This test aims to test the strategic coordination requirements that relate to the down USS mechanism in the general case:
It involves a single tested USS. The USS qualifier acts as a virtual USS that may have its availability set to down.
FlightIntentsResource that provides the following flight intents:
| Flight intent ID | Flight name | Usage State | UAS State |
|---|---|---|---|
flight1_planned |
Flight 1 | Planned | Nominal |
✅ Provided by conflicting_flights in top-level resource pool.
FlightPlannerResource that is under test and will manage Flight 1.
✅ Provided by instance 1 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where:
✅ Provided by dss in top-level resource pool.
Make a dummy request to the DSS in order to resolve the USS ID of the virtual USS.
✅ uss1_dss (2026-03-03T21:58:49.455073Z)
This step sets the USS availability to 'Available' at the DSS.
See set_uss_available in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.457702Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.462114Z)
Delete any leftover operational intent references created at DSS by virtual USS.
If the search for operational intent references or their deletion fail, this check fails per astm.f3548.v21.DSS0005,2 or astm.f3548.v21.DSS0005,1, respectively.
✅ uss1_dss (2026-03-03T21:58:49.465262Z)
uss_qualifier verifies with the DSS that there are no operational intents remaining in the area.
If the DSS fails to reply to a query concerning operational intent references in a given area, or fails to allow the deletion of an operational intent from its own creator, it is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:49.468348Z)
If operational intents exist in the 4D area(s) that should be clear, then the current state of the test environment is not suitable to conduct tests so this check will fail.
This scenario requires the area to have been cleared of operational intents. If it has not, this test step will raise a failed check.
✅ (2026-03-03T21:58:49.468421Z)
This test case aims at testing requirement astm.f3548.v21.SCD0005.
The USS qualifier, acting as a virtual USS, creates an operational intent at the DSS with a non-working base URL. The objective is to make the later request by the tested USS to retrieve operational intent details to fail.
If the creation of the operational intent reference at the DSS fails, this check fails per astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:58:49.482058Z)
This step sets the USS availability to 'Down' at the DSS.
See set_uss_down in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.484262Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.488300Z)
Flight 1 of the tested USS conflicts with the operational intent of the virtual USS. However, since:
the tested USS should evaluate the conflicting operational intent as having the lowest bound priority status, i.e. a priority strictly lower than the lowest priority allowed by the local regulation.
As such, the tested USS may either:
All flight intent data provided is correct and astm.f3548.v21.SCD0005 allows the USS to plan an operational intent in conflict with the pre-existing operational intent managed by a down USS by applying the lowest-bound priority to that operational intent. If the USS indicates that the injection attempt failed, this check will fail.
If the USS rejects the requested flight, this check will not fail, but the following Rejected planning check will. Refer to this check for more information.
✅ uss1_core (2026-03-03T21:58:49.601668Z)
ASTM F3548-21 does not require USSs to accept flight requests in all circumstances not prohibited by F3548-21. USSs may (generally) apply any number of additional rules to determine whether or not a flight planning action is accepted by the USS. For instance, a USS may say, "even though we're allowed to plan over unactivated op intents managed by down USSs, we choose not to in order to avoid the small risk the USS may not realize it is down and start that flight any way."
For this reason, a USS may reject the planning request above while still complying with SCD0005 by applying the correct priority to the pre-existing operational intent. Therefore, a rejection of the planning request does not indicate non-compliance with SCD0005. However, because InterUSS uses successful planning as a means to measure whether a USS is in compliance with SCD0005, rejecting the planning attempt means that the primary mechanism for inferring compliance with astm.f3548.v21.SCD0005 is not available. In this case, this check will produce a low-severity finding to note InterUSS's inability to use this primary mechanism for SCD0005 compliance verification.
✅ uss1_core (2026-03-03T21:58:49.601720Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:49.601639Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept Flight 1. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:49.595670Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:49.492528Z)
✅ uss1_dss (2026-03-03T21:58:49.606411Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:49.606466Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:49.606509Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:49.626178Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss1_core (2026-03-03T21:58:49.634248Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss1_core (2026-03-03T21:58:49.635251Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss1_core (2026-03-03T21:58:49.635291Z)
✅ uss1_core (2026-03-03T21:58:49.635323Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. If the planning was accepted, Flight 1 should have been shared.
∅ This check was not applicable to this test run and is therefore not statused.
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:49.492528Z)
✅ uss1_dss (2026-03-03T21:58:49.606411Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. If the planning was rejected, Flight 1 should not have been shared, thus should not exist.
∅ This check was not applicable to this test run and is therefore not statused.
This step sets the USS availability to 'Available' at the DSS.
See set_uss_available in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.637938Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.642495Z)
Delete flights injected at USS through the flight planning interface. interuss.automated_testing.flight_planning.DeleteFlightSuccess
✅ uss1_core (2026-03-03T21:58:49.679807Z)
Delete operational intents created at DSS by virtual USS. If the search for operational intent references or their deletion fail, this check fails per astm.f3548.v21.DSS0005,2 or astm.f3548.v21.DSS0005,1, respectively.
✅ uss1_dss (2026-03-03T21:58:49.694975Z)
This test aims to test the strategic coordination requirements that relate to the down USS mechanism in the general case:
It involves a single tested USS. The USS qualifier acts as a virtual USS that may have its availability set to down.
FlightIntentsResource that provides the following flight intents:
| Flight intent ID | Flight name | Usage State | UAS State |
|---|---|---|---|
flight1_planned |
Flight 1 | Planned | Nominal |
✅ Provided by conflicting_flights in top-level resource pool.
FlightPlannerResource that is under test and will manage Flight 1.
✅ Provided by instance 2 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where:
✅ Provided by dss in top-level resource pool.
Make a dummy request to the DSS in order to resolve the USS ID of the virtual USS.
✅ uss1_dss (2026-03-03T21:58:49.702428Z)
This step sets the USS availability to 'Available' at the DSS.
See set_uss_available in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.704918Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.709114Z)
Delete any leftover operational intent references created at DSS by virtual USS.
If the search for operational intent references or their deletion fail, this check fails per astm.f3548.v21.DSS0005,2 or astm.f3548.v21.DSS0005,1, respectively.
✅ uss1_dss (2026-03-03T21:58:49.712222Z)
uss_qualifier verifies with the DSS that there are no operational intents remaining in the area.
If the DSS fails to reply to a query concerning operational intent references in a given area, or fails to allow the deletion of an operational intent from its own creator, it is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:49.715297Z)
If operational intents exist in the 4D area(s) that should be clear, then the current state of the test environment is not suitable to conduct tests so this check will fail.
This scenario requires the area to have been cleared of operational intents. If it has not, this test step will raise a failed check.
✅ (2026-03-03T21:58:49.715371Z)
This test case aims at testing requirement astm.f3548.v21.SCD0005.
The USS qualifier, acting as a virtual USS, creates an operational intent at the DSS with a non-working base URL. The objective is to make the later request by the tested USS to retrieve operational intent details to fail.
If the creation of the operational intent reference at the DSS fails, this check fails per astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:58:49.728901Z)
This step sets the USS availability to 'Down' at the DSS.
See set_uss_down in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.731157Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.735337Z)
Flight 1 of the tested USS conflicts with the operational intent of the virtual USS. However, since:
the tested USS should evaluate the conflicting operational intent as having the lowest bound priority status, i.e. a priority strictly lower than the lowest priority allowed by the local regulation.
As such, the tested USS may either:
All flight intent data provided is correct and astm.f3548.v21.SCD0005 allows the USS to plan an operational intent in conflict with the pre-existing operational intent managed by a down USS by applying the lowest-bound priority to that operational intent. If the USS indicates that the injection attempt failed, this check will fail.
If the USS rejects the requested flight, this check will not fail, but the following Rejected planning check will. Refer to this check for more information.
✅ uss2_core (2026-03-03T21:58:49.846231Z)
ASTM F3548-21 does not require USSs to accept flight requests in all circumstances not prohibited by F3548-21. USSs may (generally) apply any number of additional rules to determine whether or not a flight planning action is accepted by the USS. For instance, a USS may say, "even though we're allowed to plan over unactivated op intents managed by down USSs, we choose not to in order to avoid the small risk the USS may not realize it is down and start that flight any way."
For this reason, a USS may reject the planning request above while still complying with SCD0005 by applying the correct priority to the pre-existing operational intent. Therefore, a rejection of the planning request does not indicate non-compliance with SCD0005. However, because InterUSS uses successful planning as a means to measure whether a USS is in compliance with SCD0005, rejecting the planning attempt means that the primary mechanism for inferring compliance with astm.f3548.v21.SCD0005 is not available. In this case, this check will produce a low-severity finding to note InterUSS's inability to use this primary mechanism for SCD0005 compliance verification.
✅ uss2_core (2026-03-03T21:58:49.846283Z)
The requested flight should have been planned essentially as requested. The system may adapt requested parameters as necessary, but may not change the test-critical attributes of the flight when fulfilling the planning request per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:49.846202Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept Flight 1. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:49.840446Z)
This step verifies that a created flight is shared properly per ASTM F3548-21 by querying the DSS for flights in the area of the flight intent, and then retrieving the details from the USS if the operational intent reference is found. See OpIntentValidator.expect_shared() in test_steps.py.
If the DSS fails to properly respond to a valid search query for operational intents in an area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:49.739484Z)
✅ uss1_dss (2026-03-03T21:58:49.851144Z)
If a reference to the operational intent for the flight is not found in the DSS, this check will fail per astm.f3548.v21.USS0005 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:49.851201Z)
If an activated operational intent is expected to exist after it has been modified or activated and that it is not found in the DSS, this means that there is an active flight without a corresponding operational intent, then this check will fail per interuss.automated_testing.flight_planning.FlightCoveredByOperationalIntent.
∅ This check was not applicable to this test run and is therefore not statused.
If the state of the operational intent found in the DSS does not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:49.851246Z)
If the operational intent details for the flight cannot be retrieved from the USS, this check will fail per astm.f3548.v21.USS0105,1 and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:49.871056Z)
If the operational intent details response does not validate against the GetOperationalIntentDetailsResponse schema of the OpenAPI specification, this check fill fail per astm.f3548.v21.USS0105,1.
✅ uss2_core (2026-03-03T21:58:49.879438Z)
If the operational intent details reported by the USS do not match the user's flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior and astm.f3548.v21.OPIN0025.
✅ uss2_core (2026-03-03T21:58:49.880466Z)
astm.f3548.v21.OPIN0015 specifies that nominal operational intents (Accepted and Activated) must not include any off-nominal 4D volumes, so this check will fail if an Accepted or Activated operational intent includes off-nominal volumes.
✅ uss2_core (2026-03-03T21:58:49.880507Z)
✅ uss2_core (2026-03-03T21:58:49.880539Z)
If:
this check will fail per astm.f3548.v21.USS0105,2. If the planning was accepted, Flight 1 should have been shared.
∅ This check was not applicable to this test run and is therefore not statused.
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:49.739484Z)
✅ uss1_dss (2026-03-03T21:58:49.851144Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior. If the planning was rejected, Flight 1 should not have been shared, thus should not exist.
∅ This check was not applicable to this test run and is therefore not statused.
This step sets the USS availability to 'Available' at the DSS.
See set_uss_available in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.882829Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.887050Z)
Delete flights injected at USS through the flight planning interface. interuss.automated_testing.flight_planning.DeleteFlightSuccess
✅ uss2_core (2026-03-03T21:58:49.922938Z)
Delete operational intents created at DSS by virtual USS. If the search for operational intent references or their deletion fail, this check fails per astm.f3548.v21.DSS0005,2 or astm.f3548.v21.DSS0005,1, respectively.
✅ uss1_dss (2026-03-03T21:58:49.937355Z)
This test aims to test the strategic coordination requirements that relate to the down USS mechanism in the case where equal priority conflicts are not permitted:
It involves a single tested USS. The USS qualifier acts as a virtual USS that may have its availability set to down.
FlightIntentsResource that provides the following flight intents:
| Flight intent ID | Flight name | Priority | Usage State | UAS State |
|---|---|---|---|---|
flight2_planned |
Flight 2 | Any level where conflicts are not permitted | Planned | Nominal |
✅ Provided by conflicting_flights in top-level resource pool.
FlightPlannerResource that is under test and will manage Flight 2.
✅ Provided by instance 1 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where:
✅ Provided by dss in top-level resource pool.
Make a dummy request to the DSS in order to resolve the USS ID of the virtual USS.
✅ uss1_dss (2026-03-03T21:58:49.944741Z)
This step sets the USS availability to 'Available' at the DSS.
See set_uss_available in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.947241Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.951167Z)
Delete any leftover operational intents created at DSS by virtual USS.
If the search for operational intent references or their deletion fail, this check fails per astm.f3548.v21.DSS0005,2 or astm.f3548.v21.DSS0005,1, respectively.
✅ uss1_dss (2026-03-03T21:58:49.954237Z)
uss_qualifier verifies with the DSS that there are no operational intents remaining in the area.
If the DSS fails to reply to a query concerning operational intent references in a given area, or fails to allow the deletion of an operational intent from its own creator, it is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:49.957251Z)
If operational intents exist in the 4D area(s) that should be clear, then the current state of the test environment is not suitable to conduct tests so this check will fail.
This scenario requires the area to have been cleared of operational intents. If it has not, this test step will raise a failed check.
✅ (2026-03-03T21:58:49.957326Z)
This test case aims at testing requirement astm.f3548.v21.SCD0010 when the pre-existing conflicting flight is in the Activated state.
The USS qualifier, acting as a virtual USS, creates an operational intent with identical characteristics to Flight 2 at the DSS with a non-working base URL. The objective is to make the later request by the tested USS to retrieve operational intent details to fail.
If the creation of the operational intent reference at the DSS fails, this check fails per astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:58:49.971032Z)
The USS qualifier, acting as a virtual USS, activates the operational intent previously created at the DSS with a non-working base URL. The objective is to make the later request by the tested USS to retrieve operational intent details to fail.
If the activation of the operational intent reference at the DSS fails, this check fails per astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:58:49.992997Z)
This step sets the USS availability to 'Down' at the DSS.
See set_uss_down in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.995248Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:49.999086Z)
The same-priority Flight 2 of the tested USS conflicts with the operational intent of the virtual USS. However, since:
All flight intent data provided is correct and the USS should have properly rejected the planning per astm.f3548.v21.SCD0010. If the USS indicates that the injection attempt failed, this check will fail. If the USS successfully plans Flight 2 or otherwise fails to indicate a conflict, this check will fail.
✅ uss1_core (2026-03-03T21:58:50.062966Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept Flight 2. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:50.062936Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:50.003281Z)
✅ uss1_dss (2026-03-03T21:58:50.066958Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss1_core (2026-03-03T21:58:50.067051Z)
This step sets the USS availability to 'Available' at the DSS.
See set_uss_available in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:50.069271Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:50.073492Z)
∅ This test case was not applicable to this test run and is therefore not statused.
This test case aims at testing requirement astm.f3548.v21.SCD0010 when the pre-existing conflicting flight is in the Nonconforming state. This test case will only be executed if uss_qualifier can perform Conformance Monitoring for Situational Awareness operations in the provided DSS instance.
The USS qualifier, acting as a virtual USS, transitions to Nonconforming the operational intent previously created at the DSS with a non-working base URL. The objective is to make the later request by the tested USS to retrieve operational intent details to fail.
If the transition of the operational intent reference at the DSS fails, this check fails per astm.f3548.v21.DSS0005,1.
This step sets the USS availability to 'Down' at the DSS.
See set_uss_down in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
The same-priority Flight 2 of the tested USS conflicts with the operational intent of the virtual USS. However, since:
All flight intent data provided is correct and the USS should have rejected properly the planning per astm.f3548.v21.SCD0010. If the USS indicates that the injection attempt failed, this check will fail. If the USS successfully plans Flight 2 or otherwise fails to indicate a conflict, this check will fail.
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept Flight 2. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
This step sets the USS availability to 'Available' at the DSS.
See set_uss_available in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
∅ This test case was not applicable to this test run and is therefore not statused.
This test case aims at testing requirement astm.f3548.v21.SCD0010 when the pre-existing conflicting flight is in the Contingent state. This test case will only be executed if uss_qualifier can perform Conformance Monitoring for Situational Awareness operations in the provided DSS instance.
The USS qualifier, acting as a virtual USS, transitions to Contingent the operational intent previously created at the DSS with a non-working base URL. The objective is to make the later request by the tested USS to retrieve operational intent details to fail.
If the transition of the operational intent reference at the DSS fails, this check fails per astm.f3548.v21.DSS0005,1.
This step sets the USS availability to 'Down' at the DSS.
See set_uss_down in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
The same-priority Flight 2 of the tested USS conflicts with the operational intent of the virtual USS. However, since:
All flight intent data provided is correct and the USS should have rejected properly the planning per astm.f3548.v21.SCD0010. If the USS indicates that the injection attempt failed, this check will fail. If the USS successfully plans Flight 2 or otherwise fails to indicate a conflict, this check will fail.
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept Flight 2. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
This step sets the USS availability to 'Available' at the DSS.
See set_uss_available in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:50.075717Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:50.079599Z)
Delete flights injected at USS through the flight planning interface. interuss.automated_testing.flight_planning.DeleteFlightSuccess
∅ This check was not applicable to this test run and is therefore not statused.
Delete operational intents created at DSS by virtual USS. If the search for operational intent references or their deletion fail, this check fails per astm.f3548.v21.DSS0005,2 or astm.f3548.v21.DSS0005,1, respectively.
✅ uss1_dss (2026-03-03T21:58:50.094162Z)
This test aims to test the strategic coordination requirements that relate to the down USS mechanism in the case where equal priority conflicts are not permitted:
It involves a single tested USS. The USS qualifier acts as a virtual USS that may have its availability set to down.
FlightIntentsResource that provides the following flight intents:
| Flight intent ID | Flight name | Priority | Usage State | UAS State |
|---|---|---|---|---|
flight2_planned |
Flight 2 | Any level where conflicts are not permitted | Planned | Nominal |
✅ Provided by conflicting_flights in top-level resource pool.
FlightPlannerResource that is under test and will manage Flight 2.
✅ Provided by instance 2 in flight_planners in top-level resource pool.
DSSInstanceResource that provides access to a DSS instance where:
✅ Provided by dss in top-level resource pool.
Make a dummy request to the DSS in order to resolve the USS ID of the virtual USS.
✅ uss1_dss (2026-03-03T21:58:50.100932Z)
This step sets the USS availability to 'Available' at the DSS.
See set_uss_available in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:50.103476Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:50.107566Z)
Delete any leftover operational intents created at DSS by virtual USS.
If the search for operational intent references or their deletion fail, this check fails per astm.f3548.v21.DSS0005,2 or astm.f3548.v21.DSS0005,1, respectively.
✅ uss1_dss (2026-03-03T21:58:50.110623Z)
uss_qualifier verifies with the DSS that there are no operational intents remaining in the area.
If the DSS fails to reply to a query concerning operational intent references in a given area, or fails to allow the deletion of an operational intent from its own creator, it is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:50.113774Z)
If operational intents exist in the 4D area(s) that should be clear, then the current state of the test environment is not suitable to conduct tests so this check will fail.
This scenario requires the area to have been cleared of operational intents. If it has not, this test step will raise a failed check.
✅ (2026-03-03T21:58:50.113847Z)
This test case aims at testing requirement astm.f3548.v21.SCD0010 when the pre-existing conflicting flight is in the Activated state.
The USS qualifier, acting as a virtual USS, creates an operational intent with identical characteristics to Flight 2 at the DSS with a non-working base URL. The objective is to make the later request by the tested USS to retrieve operational intent details to fail.
If the creation of the operational intent reference at the DSS fails, this check fails per astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:58:50.127660Z)
The USS qualifier, acting as a virtual USS, activates the operational intent previously created at the DSS with a non-working base URL. The objective is to make the later request by the tested USS to retrieve operational intent details to fail.
If the activation of the operational intent reference at the DSS fails, this check fails per astm.f3548.v21.DSS0005,1.
✅ uss1_dss (2026-03-03T21:58:50.146803Z)
This step sets the USS availability to 'Down' at the DSS.
See set_uss_down in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:50.149022Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:50.152956Z)
The same-priority Flight 2 of the tested USS conflicts with the operational intent of the virtual USS. However, since:
All flight intent data provided is correct and the USS should have properly rejected the planning per astm.f3548.v21.SCD0010. If the USS indicates that the injection attempt failed, this check will fail. If the USS successfully plans Flight 2 or otherwise fails to indicate a conflict, this check will fail.
✅ uss2_core (2026-03-03T21:58:50.216155Z)
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept Flight 2. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:50.216125Z)
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:50.157119Z)
✅ uss1_dss (2026-03-03T21:58:50.220090Z)
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
✅ uss2_core (2026-03-03T21:58:50.220136Z)
This step sets the USS availability to 'Available' at the DSS.
See set_uss_available in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:50.222337Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:50.226444Z)
∅ This test case was not applicable to this test run and is therefore not statused.
This test case aims at testing requirement astm.f3548.v21.SCD0010 when the pre-existing conflicting flight is in the Nonconforming state. This test case will only be executed if uss_qualifier can perform Conformance Monitoring for Situational Awareness operations in the provided DSS instance.
The USS qualifier, acting as a virtual USS, transitions to Nonconforming the operational intent previously created at the DSS with a non-working base URL. The objective is to make the later request by the tested USS to retrieve operational intent details to fail.
If the transition of the operational intent reference at the DSS fails, this check fails per astm.f3548.v21.DSS0005,1.
This step sets the USS availability to 'Down' at the DSS.
See set_uss_down in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
The same-priority Flight 2 of the tested USS conflicts with the operational intent of the virtual USS. However, since:
All flight intent data provided is correct and the USS should have rejected properly the planning per astm.f3548.v21.SCD0010. If the USS indicates that the injection attempt failed, this check will fail. If the USS successfully plans Flight 2 or otherwise fails to indicate a conflict, this check will fail.
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept Flight 2. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
This step sets the USS availability to 'Available' at the DSS.
See set_uss_available in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
∅ This test case was not applicable to this test run and is therefore not statused.
This test case aims at testing requirement astm.f3548.v21.SCD0010 when the pre-existing conflicting flight is in the Contingent state. This test case will only be executed if uss_qualifier can perform Conformance Monitoring for Situational Awareness operations in the provided DSS instance.
The USS qualifier, acting as a virtual USS, transitions to Contingent the operational intent previously created at the DSS with a non-working base URL. The objective is to make the later request by the tested USS to retrieve operational intent details to fail.
If the transition of the operational intent reference at the DSS fails, this check fails per astm.f3548.v21.DSS0005,1.
This step sets the USS availability to 'Down' at the DSS.
See set_uss_down in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
The same-priority Flight 2 of the tested USS conflicts with the operational intent of the virtual USS. However, since:
All flight intent data provided is correct and the USS should have rejected properly the planning per astm.f3548.v21.SCD0010. If the USS indicates that the injection attempt failed, this check will fail. If the USS successfully plans Flight 2 or otherwise fails to indicate a conflict, this check will fail.
All flight intent data provided was complete and correct. It should have been processed successfully, allowing the USS to reject or accept Flight 2. If the USS indicates that the injection attempt failed, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
This step verifies that a previous attempt to create a flight did not result in a flight being shared with the DSS. It does so by querying the DSS for operational intents in the area of the flight before and after an attempted creation. This assumes an area lock on the extent of the flight intent.
See OpIntentValidator.expect_not_shared() in test_steps.py.
If the DSS fails to reply to a query concerning operational intent references in a given area, it is in violation of astm.f3548.v21.DSS0005,2, and this check will fail.
If there are new operational intent references in the area of the flight intent, this check will fail per interuss.automated_testing.flight_planning.ExpectedBehavior.
This step sets the USS availability to 'Available' at the DSS.
See set_uss_available in test_steps.py.
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when queried for the availability of a USS using valid credentials, the DSS does not return a valid 200 response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:50.228672Z)
This fragment contains the steps for the USS Availability synchronization scenario where we confirm that a USS availability can be correctly read from a DSS instance
If, when presented with a valid query to update the availability state of a USS, a DSS responds with anything else than a 200 OK response, it is in violation of the OpenAPI specification referenced by astm.f3548.v21.DSS0100,1.
✅ uss1_dss (2026-03-03T21:58:50.232928Z)
Delete flights injected at USS through the flight planning interface. interuss.automated_testing.flight_planning.DeleteFlightSuccess
∅ This check was not applicable to this test run and is therefore not statused.
Delete operational intents created at DSS by virtual USS. If the search for operational intent references or their deletion fail, this check fails per astm.f3548.v21.DSS0005,2 or astm.f3548.v21.DSS0005,1, respectively.
✅ uss1_dss (2026-03-03T21:58:50.251528Z)
This scenario prepares flight planner systems for execution of controlled test scenarios by checking planner systems' readiness and having them remove any existing flights that may already be in the test area.
FlightPlannersResource listing all USSs undergoing planning tests so that they can be checked for readiness and instructed to remove any existing flights from the area in this scenario.
✅ Provided by flight_planners in top-level resource pool.
(Optional) MockUSSResource is checked for readiness and instructed to remove any existing flights from the area in this scenario.
✅ Provided by mock_uss in top-level resource pool.
DSSInstanceResource to check for lingering operational intents after the area has been cleared.
✅ Provided by dss in top-level resource pool.
FlightIntentsResource containing flight intents that will be used in subsequent tests, so all planners should be instructed to clear any area involved with any of these intents of flights it manages.
✅ Provided by invalid_flight_intents in top-level resource pool.
(Optional) If more than one FlightIntentsResource will be used in subsequent tests, additional intents may be specified with this resource.
✅ Provided by conflicting_flights in top-level resource pool.
(Optional) If more than one FlightIntentsResource will be used in subsequent tests, additional intents may be specified with this resource.
✅ Provided by conflicting_flights in top-level resource pool.
(Optional) If more than one FlightIntentsResource will be used in subsequent tests, additional intents may be specified with this resource.
✅ Provided by non_conflicting_flights in top-level resource pool.
All USSs are queried for their readiness to ensure later tests can proceed.
interuss.automated_testing.flight_planning.ImplementAPI
✅ uss1_core (2026-03-03T21:58:50.259130Z)
✅ uss2_core (2026-03-03T21:58:50.265157Z)
✅ mock_uss (2026-03-03T21:58:50.271187Z)
This readiness indicates the USS's ability to inject test data, so if this check fails, not only has the USS not met interuss.automated_testing.flight_planning.Readiness, but it also does not meet astm.f3548.v21.GEN0310.
✅ uss1_core (2026-03-03T21:58:50.259188Z)
✅ uss2_core (2026-03-03T21:58:50.265213Z)
✅ mock_uss (2026-03-03T21:58:50.271246Z)
All USSs are requested to remove all flights from the area under test.
interuss.automated_testing.flight_planning.ImplementAPI
✅ uss1_core (2026-03-03T21:58:50.308457Z)
✅ uss2_core (2026-03-03T21:58:50.342476Z)
✅ mock_uss (2026-03-03T21:58:50.360164Z)
✅ uss1_core (2026-03-03T21:58:50.393322Z)
✅ uss2_core (2026-03-03T21:58:50.426339Z)
✅ mock_uss (2026-03-03T21:58:50.443491Z)
✅ uss1_core (2026-03-03T21:58:50.476342Z)
✅ uss2_core (2026-03-03T21:58:50.509784Z)
✅ mock_uss (2026-03-03T21:58:50.526901Z)
✅ uss1_core (2026-03-03T21:58:50.560334Z)
✅ uss2_core (2026-03-03T21:58:50.592973Z)
✅ mock_uss (2026-03-03T21:58:50.610220Z)
interuss.automated_testing.flight_planning.ClearArea
✅ uss1_core (2026-03-03T21:58:50.308513Z)
✅ uss2_core (2026-03-03T21:58:50.342535Z)
✅ mock_uss (2026-03-03T21:58:50.360235Z)
✅ uss1_core (2026-03-03T21:58:50.393388Z)
✅ uss2_core (2026-03-03T21:58:50.426415Z)
✅ mock_uss (2026-03-03T21:58:50.443563Z)
✅ uss1_core (2026-03-03T21:58:50.476415Z)
✅ uss2_core (2026-03-03T21:58:50.509864Z)
✅ mock_uss (2026-03-03T21:58:50.526983Z)
✅ uss1_core (2026-03-03T21:58:50.560420Z)
✅ uss2_core (2026-03-03T21:58:50.593090Z)
✅ mock_uss (2026-03-03T21:58:50.610314Z)
uss_qualifier verifies with the DSS that there are no operational intents remaining in the area.
If the DSS fails to reply to a query concerning operational intent references in a given area, or fails to allow the deletion of an operational intent from its own creator, it is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,2, and this check will fail.
✅ uss1_dss (2026-03-03T21:58:50.621076Z)
✅ uss1_dss (2026-03-03T21:58:50.624261Z)
✅ uss1_dss (2026-03-03T21:58:50.627613Z)
✅ uss1_dss (2026-03-03T21:58:50.630933Z)
If operational intents exist in the 4D area(s) that should be clear, then the current state of the test environment is not suitable to conduct tests so this check will fail.
This step examines whether any operational intents remain. If any foreign (other than uss_qualifier-owned) operational intents remain, then this step's checks will fail. If any uss_qualifier-owned operational intents remain, the checks for this step do not fail but instead we proceed to the next test case. If the area is clear, we skip the next test case.
✅ (2026-03-03T21:58:50.621154Z)
✅ (2026-03-03T21:58:50.624331Z)
✅ (2026-03-03T21:58:50.627682Z)
✅ (2026-03-03T21:58:50.631054Z)
∅ This test case was not applicable to this test run and is therefore not statused.
In addition to foreign flight planners, uss_qualifier may have left operational intents in the DSS from an incomplete previous run. This test case attempts to clean them up if they exist. If there are no operational intents from uss_qualifier in the flight intent areas, this test case will be skipped.
Ensure a clean workspace for testing interactions with a DSS by removing any operational intent references from the DSS that may have been left behind from testing efforts.
If an existing operational intent reference cannot directly be queried by its ID, or if for a non-existing one the DSS replies with a status code different than 404, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
A client with valid credentials should be allowed to search for operational intents in a given area. Otherwise, the DSS is not in compliance with astm.f3548.v21.DSS0005,2.
If an existing operational intent cannot be deleted when providing the proper ID and OVN, the DSS implementation is in violation of astm.f3548.v21.DSS0005,1.
The operational intent references managed by uss_qualifier discovered in the previous test case are removed.
uss_qualifier verifies with the DSS that there are no operational intents remaining in the area.
If the DSS fails to reply to a query concerning operational intent references in a given area, or fails to allow the deletion of an operational intent from its own creator, it is in violation of astm.f3548.v21.DSS0005,1 or astm.f3548.v21.DSS0005,2, and this check will fail.
If operational intents exist in the 4D area(s) that should be clear, then the current state of the test environment is not suitable to conduct tests so this check will fail.
After removing the operational intents of all flight planning participants previously, and just having attempted to remove uss_qualifier-owned operational intents, the area should now be fully clear.
In this scenario, the report of previously executed ASTM F3548 UTM scenario(s) are examined to identify USSs' base URLs so that the makeUssReport endpoint can be called for each of these base URLs.
uss_qualifier uses this authorization is in the test scenario to act as a USS and perform calls to makeUssReport.
✅ Provided by utm_auth in top-level resource pool.
In this test step, the report of all test activities up to this point is examined to identify instances of the Validation of operational intents test scenario in which the Plan Valid Flight test step is inspected to find the base URL of the tested_uss.
If no such executed scenarios are found, the remainder of this scenario will not be performed.
The makeUssReport endpoint is called for each of the USS base URLs identified in the previous step.
If the USS's makeUssReport endpoint does not respond correctly, the USS will have failed to comply with astm.f3548.v21.USS0105,4.
✅ uss1_core (2026-03-03T21:58:50.931036Z)
✅ uss2_core (2026-03-03T21:58:50.939046Z)
ASTM F3548-21 GEN0305 requires that the USS's test system (provided per GEN0300) uses the currently deployed software version except when testing an update. This scenario checks the test and production versions of all participants' systems and ensures that no more than one participant's test system (presumably the participant who is testing an update) has a different version than their production system.
A VersionProvidersResource containing the means by which to query test-environment system versions for each applicable participant.
✅ Provided by test_env_version_providers in top-level resource pool.
A VersionProvidersResource containing the means by which to query production-environment system versions for each applicable participant.
✅ Provided by prod_env_version_providers in top-level resource pool.
A SystemIdentityResource indicating the identity of the system for which to query the version from all providers.
✅ Provided by system_identity in suites.astm.utm.f3548_21.
Each version provider is queried for the version of its system (identified by system_identity) in the test environment.
If a valid response is not received from a version provider, they will have failed to meet versioning.ReportSystemVersion.
✅ uss1_core (2026-03-03T21:58:50.945896Z)
✅ uss2_core (2026-03-03T21:58:50.951889Z)
Each version provider is queried for the version of its system (identified by system_identity) in the production environment.
If a valid response is not received from a version provider, they will have failed to meet versioning.ReportSystemVersion.
✅ uss1_core (2026-03-03T21:58:50.957642Z)
✅ uss2_core (2026-03-03T21:58:50.963498Z)
Per GEN0305, a participant may temporarily have a different software version in the test environment than in production in order to test that new software version. But, as the purpose of testing is to ensure continued compliance and interoperation with other participants' systems that have already been demonstrated functional, if two or more participants have differing software versions between the test and production environments, at least one of these participants will have failed to meet astm.f3548.v21.GEN0305.
✅ uss1_core, uss2_core (2026-03-03T21:58:50.963623Z)
For participants not testing a new software version, their test-environment software version must match their production-environment software version or that participant does not meet astm.f3548.v21.GEN0305.
✅ uss1_core (2026-03-03T21:58:50.963572Z)
✅ uss2_core (2026-03-03T21:58:50.963599Z)
If the system version reported by a participant at one point during the test run is different from the system version reported by that participant at a different point during the test run, that participant cannot meet astm.f3548.v21.GEN0305 because the test environment and production environment system versions cannot be compared because the version in at least one of those environments does not have a consistent value.
✅ uss1_core (2026-03-03T21:58:50.963766Z)
✅ uss2_core (2026-03-03T21:58:50.963864Z)
In this special scenario, the report of previously executed ASTM F3548 UTM scenario(s) are evaluated for the performances of the queries made during their execution.
The flight planners subject to evaluation.
✅ Provided by flight_planners in top-level resource pool.
In this step, all successful requests for operational intent details made to the USSs that are part of the flight planners provided as resource are used to determine and evaluate the 95th percentile of the requests durations.
If the 95th percentile of the requests durations is higher than the threshold MaxRespondToOIDetailsRequest (1 second),
this check will fail per astm.f3548.v21.SCD0075.
✅ uss1_core (2026-03-03T21:58:50.972650Z)
✅ uss2_core (2026-03-03T21:58:50.972972Z)
This step verifies that interactions with the interoperability test instances happened and where at least partly successful.
This check ensures that interactions with the interoperability test instance that each USS must provide are possible.
If all interactions fail, or if no test instance can be reached, the USS is failing to meet astm.f3548.v21.GEN0300.
If no interaction with a test instance was found, this check is skipped.
✅ uss1_core (2026-03-03T21:58:50.973292Z)
✅ uss2_core (2026-03-03T21:58:50.973414Z)
When certain circumstances occur, USSs must notify UAS personnel or the operator's automation system within a fixed amount of time a certain fraction of time. This test case examines notification latency across all tests performed during this test run.
If 95% of the USS's notifications regarding conflicts caused by the operator's flight do not appear in the USS's list of user notifications within ConflictingOIMaxUserNotificationTime (5 seconds) of completing the planning operation, this check will fail per astm.f3548.v21.SCD0090.
To find the notifications considered, review the reports for "Nominal planning: conflict with higher priority" scenarios -- this is where the raw data evaluated by this scenario is gathered.
✅ uss1_core (2026-03-03T21:58:50.974028Z)
✅ uss2_core (2026-03-03T21:58:50.974155Z)
If 95% of the USS's notifications regarding conflicts affecting the operator's flight do not appear in the USS's list of user notifications within ConflictingOIMaxUserNotificationTime (5 seconds) of completing the planning operation, this check will fail per astm.f3548.v21.SCD0095.
To find the notifications considered, review the reports for "Nominal planning: conflict with higher priority" scenarios -- this is where the raw data evaluated by this scenario is gathered.
✅ uss1_core (2026-03-03T21:58:50.974529Z)
✅ uss2_core (2026-03-03T21:58:50.974640Z)