We are qualifying a production WidgetKit extension on an iPhone 17 running iOS 26.6.1. both use App Group group.com....app.widgets. The extension reads small snapshots from the App Group. Precise personal Home data uses NSFileProtectionComplete; a separate book-only Lock projection uses NSFileProtectionCompleteUntilFirstUserAuthentication. Public Daily and non-personal control state are stored separately. Does Apple provide a supported deterministic mechanism to cause or observe the actual system-hosted WidgetKit provider performing a fresh App Group read during each phase below? Locked after first unlock. Rebooted, before the first passcode unlock. Relocked after first unlock. We need to attribute the read to the exact extension executable/process, establish the lock phase without unlocking or opening the protected data through the observation mechanism, and distinguish “the provider did not run” from “it ran but observation was unavailable.” Cached widget pixels, file attributes and later recovery cannot establish whether a fresh provider read was allowed or denied. WidgetCenter reload requests and timeline dates are opportunistic and have not produced deterministic invocations in these phases. Direct provider invocation, XCTest helper processes, debugger-controlled lifecycle substitution and manually reading files from the host do not establish the required system WidgetKit lifecycle. We cannot weaken file protection or add artificial production AppIntent/background capabilities solely to force this test. Please clarify which applies: A. A supported deterministic XCTest, CoreDevice, Xcode or WidgetKit test mechanism exists. If so, what setup, trigger and logging method should we use? B. WidgetKit scheduling in these states is intentionally opportunistic and no deterministic public test mechanism is provided. If so, what supported evidence does Apple recommend for verifying this protected-file contract? This request concerns test methodology; we are not claiming locked/BFU protection has passed.