Thank you, this is really helpful confirmation. I have the same signature on my side, filed as FB23731287 (13 July). Two devices, iPhone and iPad, single iCloud account, Advanced Data Protection on, both on iOS 27 betas. Only failing operations are pcs_data in com.apple.coredata.cloudkit.zone returning BAD_REQUEST. CD record saves are not rejected, import still works, and the schema is fully deployed to Production. A single failed _pcs_data op fails the whole export event and disables the mirroring delegate for the rest of the session. Your fresh-Mac data point is the most useful thing I have seen on this. It lines up with what I am seeing: reinstalling the app on the already-affected devices does not clear it, which fits the idea that a reinstall on the same OS and account re-derives the same PCS material rather than provisioning genuinely fresh. A device that has never joined the account before gets clean PCS state and exports fine to the same zone. That points squarely at a device-side PCS provisioning wedge against a zone that is otherwise healthy, not app or schema data. So we now have at least two developers (FB23731287 and FB24150787), plus the unrelated user you can see in your own Console, with an identical signature. That feels like a CloudKit-side regression rather than anything either of us can fix from the app. For anyone from Apple reading: happy to provide sysdiagnoses, device Console captures of NSCloudKitMirroringDelegate, and CloudKit Console log excerpts. The ask is a way to reset or re-provision the account and zone PCS key state so export can resume, since no device-side or code-side step clears it.