Thanks Kevin, that clears it up - particularly where the completion timestamp is actually recorded. The underlying goal is to validate safe shutdown of our USB DriverKit driver. We want to check that it stops accepting requests, lets outstanding work finish, and only then releases resources and calls inherited Stop, following your earlier guidance. I think we made the timing question more exacting than it needed to be. We don’t need to identify the precise instant USB activity ends; we need to verify the cleanup ordering and measure how long the sequence takes. We’ll keep the lifecycle ordering checks separate from the timing measurements, then use repeated tests on real machines to establish observed ranges and look for stalls or races. Those measurements won’t establish universal timing guarantees, but they should give us useful practical evidence and we are dealing with a known-set of devices, 10 unique models, so that is a very manageable set. Thanks again for the explanation and your patience - I think we have enough to work from here.

I have one USB timing follow-up while validating the shutdown sequence discussed here. The earlier Stop/lifetime guidance is resolved. For USBDriverKit IOUSBHostPipe::CompleteAsyncIO, is completionTimestamp guaranteed to use the same clock epoch and tick units as mach_absolute_time() on supported macOS releases? The DriverKit 25.5 header and documentation describe it as the absolute time the transfer completed, but I could not find an explicit clock definition. The intended observation is one successfully submitted AsyncIO read. When child Stop closes admission to new requests, we would immediately record mach_absolute_time(), then compare that value with the transfer completionTimestamp. We need to establish whether the transfer was still in progress at that point; a callback delivered later could describe a transfer that had already completed. If that timestamp comparison is unsupported, which documented API or callback observation can establish this ordering without relying on a marker before submission or on callback delivery time? API reference: https://developer.apple.com/documentation/usbdriverkit/iousbhostpipe/completeasyncio

Thank you, Kevin. That fully resolves the remaining ambiguity for us. Your explanation of the single valid termination sequence, the provider’s validity until super::Stop, and the callback-driven cleanup pattern gives us the lifecycle contract we needed to proceed safely. I also appreciate the clarification about abnormal DEXT termination. We will treat that as a failure condition rather than attempting to incorporate it into the normal shutdown protocol. Thank you for taking the time to answer the follow-up so precisely.

Thank you. This resolves the normal Stop path, asynchronous cleanup pattern, Cancel-success expectation, and provider-owned work model. We have a corrected lifecycle, but one blocker remains with one remaining clarification from question 3: Does the public IOService::Stop phase-2/provider-validity guidance also apply when the provider is already inactive or the DriverKit user server has slept? In those cases, is the driver’s public Stop override still guaranteed to be invoked, with the provider remaining valid until the driver’s asynchronous cancellation callback calls super::Stop? I am asking only which public lifecycle guarantee the driver may rely on, not how any private framework entry point is implemented.