We are developing a generic spatial accessory for Apple Vision Pro using the “Working with generic spatial accessories” sample and a trained .referenceaccessory file. Environment: visionOS: [version/build] Xcode: [version/build] Hardware: Apple Vision Pro + nRF52840-based BLE accessory IMU: 6-axis IMU, 400 Hz HID reports LED constellation: 8 x 850 nm IR LEDs, driven through MOSFETs The BLE/HID and timing path appears to be working: The accessory connects successfully over BLE. ASA/HID enumeration succeeds. The firmware receives continuous LED Output Reports from visionOS. The Accessory Tracking Clock reaches READY. PWM scheduling reports no late events and no queue overflow. In the Accessory Tracking Debug View, multiple independent IR LED blobs are visible and stable at approximately 0.7 m. At least 4 LEDs are visible from normal viewing angles. The app resolves the .referenceaccessory and starts AccessoryTrackingProvider. However, ARKit never produces an AccessoryAnchor. We also have no diagnostic signal indicating whether the failure occurs at: LED candidate-point detection, constellation matching against the .referenceaccessory, or IMU/optical fusion. Questions: Is there a supported diagnostic API, log category, or Debug View indicator that distinguishes candidate-point rejection from constellation-match or fusion rejection? Are there known acquisition prerequisites in the current visionOS beta beyond the published Accessory Design Guidelines? Can Apple recommend a minimal validation procedure using the generic spatial accessory sample to confirm that the LED constellation is accepted by the tracking system? Is this expected to work in a volumetric window, or are there additional lifecycle/session requirements that can prevent initial acquisition? I can provide sanitized HID LED-report logs, timing data, Debug View captures, and a minimal reproducible project if useful.