[uss_qualifier] Remove participant verifiable capabilities

AGENTS.md

@@ -33,6 +33,7 @@ This document contains key context, nuances, and troubleshooting tips specifical
 ## 4. Local Testing constraints
 - **Unit-test working directory**: Run `uss_qualifier` unit tests from `monitoring/uss_qualifier/` with the repository root on `PYTHONPATH` (for example, `PYTHONPATH=../.. ../../.venv/bin/python -m pytest scenarios/scenario_test resources/flight_planning`). Some resource fixtures resolve test-data paths relative to the working directory and fail when run from the repository root.
 - **Qualifier Working Directory**: Run resource-construction checks and qualifier resource tests from `monitoring/uss_qualifier` with the repository root on `PYTHONPATH`. External resource paths such as `file://./test_data/...` resolve relative to the current working directory, as they do in `run_locally.sh`.
+- **Local Python 3.14 artifact generation**: Python 3.14 defaults to `forkserver` on Linux, which cannot pickle the local worker functions in `reports/artifacts.py`. If a local qualifier run fails there with `PicklingError`, use the project's Docker runtime or a local launcher that calls `multiprocessing.set_start_method("fork")` before running `monitoring.uss_qualifier.main`.
 - **Docker Dependency**: Mock USS and DSS environments require active Docker containers. Standard testing commands are typically structured via bash scripts like `./monitoring/uss_qualifier/run_locally.sh <config>`. If container-building fails due to `Authentication` or package registry issues in the agent's environment, gracefully halt and ask the human user to run the script instead.
 
 ## 5. Continuous Improvement of this Guide

github_pages/static/index.md

@@ -11,7 +11,6 @@ These reports were generated during continuous integration for the most recent P
 * [Sequence view](./artifacts/uss_qualifier/reports/uspace/sequence)
 * [Tested requirements](./artifacts/uss_qualifier/reports/uspace/requirements)
 * [Timing report](./artifacts/uss_qualifier/reports/uspace/timing)
-* [Demonstrated capabilities](./artifacts/uss_qualifier/reports/uspace/capabilities.html)
 * [Raw report](./artifacts/uss_qualifier/reports/uspace/report.json) (large)
 
 ### [No-op test configuration](https://github.com/interuss/monitoring/blob/main/monitoring/uss_qualifier/configurations/dev/noop.yaml)

monitoring/uss_qualifier/README.md

@@ -130,11 +130,3 @@ Any artifacts specified in test configuration are generated.
 #### Validate test report
 
 Test report is evaluated in order to return the appropriate "success or error" execution code (if specified in test configuration).
-
-### Verifiable capabilities
-
-A test suite may define one or more verifiable "capabilities" and the criteria necessary to verify them for a participant.  These verifiable capabilities are intended to be used to indicate whether a participant has satisfied the requirements for an optional capability.
-
-For instance, ASTM F3411-22a network remote identification includes the concept of an "intent-based network participant" who provides information about their overall flight intent, but not real-time telemetry.  A NetRID Service Provider is not required to support intent-based network participants, but if they do choose to support them, then they must follow a few requirements.  In this case, an "intent-based network participant support" capability may be defined to be verified only if uss_qualifier confirms compliance with the requirements regarding intent-based network participants.  If compliance to the intent-based network participants cannot be confirmed, the NetRID Service Provider under test may still be fully compliant with the standard; they just elected not to support this particular optional capability and would therefore be standard-compliant without verifying the "intent-based network participant support" capability.
-
-As another example, ASTM F3411-22a does not require a NetRID Display Provider to provide Display Application clients with the serial number of an identified aircraft.  However, a particular jurisdiction may accept F3411-22a remote identification as a means of compliance only if Display Applications are capable of providing the viewer with the aircraft serial number.  In this case, the ASTM F3411-22a test suite could define a "serial number" capability indicating that a Display Provider provides the correct aircraft serial number to its Display Application clients, and then the test suite for the jurisdiction may define a "qualified in jurisdiction" capability which is not verified unless the ASTM F3411-22a test suite's "serial number" capability is verified (among other criteria).

monitoring/uss_qualifier/configurations/dev/uspace.yaml

@@ -130,9 +130,6 @@ v1:
       stop_fast: true
   artifacts:
     raw_report: {}
-    templated_reports:
-      - template_url: https://github.com/Orbitalize/reports/releases/download/v0.0.18/app-v0.0.18.zip
-        report_name: capabilities
     tested_requirements:
       - report_name: requirements
         requirement_collections: