Confirmed resolved — thank you, this diagnosis was exactly right. I captured a sysdiagnose (with the CloudKit logging profile installed) during a fresh Production reproduction, and the real underlying error was hiding under the _pcs_data/BAD_REQUEST noise, exactly as you described: CKError "Invalid Arguments" (12/2006); server message = "Cannot create or modify field 'CD_catalogPlacementsData' in record 'CD_Song' in production schema" I compared the CD_Song record type field-by-field in CloudKit Console between Development and Production, and found two fields present in Development but missing from Production: CD_catalogPlacementsData and CD_submixesData (both added to my Core Data model on 9/12). The "Deploy Schema Changes to Production" diff had been reporting zero pending changes this whole time — but when I re-opened that dialog after finding this, it correctly showed the drift: "Modify 2 fields on CD_Song" plus 4 associated indexes, with the Production schema snapshot dated a day earlier than Development (9/11 vs. 9/12). Deploying that fixed it — Production RecordSave for CD_Song now returns overallStatus: SUCCESS. So the second Apple ID reproducing the same failure wasn't evidence of a broken account or container state after all — it just confirmed the schema mismatch affects every user of the container equally, which makes sense since it's server-side schema, not per-account state. For anyone landing here with this signature: don't trust "0 pending changes" from the Deploy Schema Changes sheet at face value if you're seeing _pcs_data/BAD_REQUEST failures in Production only — compare fields directly between environments in Console, or better, capture a sysdiagnose per TN3163 to see the real error. Re-opening the deploy dialog after confirming the mismatch is what surfaced the correct diff for me. Case-ID: 22179719 — this resolves it. Thanks again for pointing me at the right thread.