Reconciling Architect Flow Step Durations with Queue Wait Time in EU-West

What is the standard approach to interpret the ‘In Queue’ duration metric when comparing it against the cumulative execution time of specific nodes in a complex Architect flow within our EU-West tenant?

We have observed a consistent discrepancy in the Conversation Detail view for high-volume inbound queues. The total time spent in the queue, as reported by the Queue Performance dashboard, frequently exceeds the sum of execution times for the routing and IVR nodes preceding the agent assignment. This variance ranges from 150ms to 2.5 seconds per interaction, which aggregates to a significant deviation in our monthly SLA reporting.

The environment is running the latest public release of Genesys Cloud CX. The flow in question utilizes standard conditional logic and transfer nodes without any external API integrations that would introduce network latency. We have verified that the timestamp granularity in the export matches the dashboard view. Is this gap attributable to backend processing overhead for queue position calculation, or is there a specific configuration in the Architect flow that artificially inflates the node execution time metrics? We require a precise method to align these two data sources for accurate capacity planning.