Predictive Routing Queue Time Aggregation Issues in Legal Export Metadata

Need some help troubleshooting the metadata aggregation logic when exporting conversations that utilized predictive routing. We are running bulk export jobs via POST /api/v2/analytics/conversations/export to satisfy strict legal discovery requirements. The manifest.json file is generated correctly, but the time metrics are causing significant issues with our chain of custody validation.

The problem is that the wait_time and handle_time fields appear to be aggregated incorrectly for predictive routing scenarios. In our Architect flow, agents are selected from a queue based on predictive availability, yet the export metadata shows a zero wait_time even though the agent was idle in the queue for over three minutes. This discrepancy breaks our audit trail because the legal team requires precise timestamps for when an agent actually became available versus when they accepted the interaction.

We have verified that the S3 bucket permissions are correct and the audio files are present. However, the metadata mismatch suggests the export engine is not capturing the queue entry timestamp accurately for predictive routing events. Is there a specific filter or additional metric we need to include in the export request to isolate the predictive queue dwell time from the general wait time?