Team: TS447Y97LA
Please help identify the underlying failure for two automatic Xcode Developer ID submissions:
a904af7c-751d-4e79-9f16-f71f16163ad5— received SHA-256a185ebe3860985d0e5f6a07e00348008687a636731a88033d620e3cb3f9ec6aa, 9,454,788,726 bytes.1f55d5d3-f96f-47d5-ba91-b7372c213ad7— received SHA-256efe2aaa7c3714c68d82d4efc1eab9f14c9cc0751ef78c9b3a0856f1b53757ece, a fresh signing/export attempt.
Both logs return Invalid/4000 and name these arm64 paths:
Pelican.app/Contents/MacOS/PelicanPelican.app/Contents/XPCServices/PelicanInference.xpc/Contents/MacOS/PelicanInference
For the first submission only, we retained the exact Xcode upload ZIP and submitted app. Independent full comparison confirmed the received hash, all 117 ZIP members, and every app resource and metadata entry. There are 115 matching app entries plus two consistent Apple ZIP metadata entries. Python and installed libarchive independently reproduce identical bytes, CRCs, types and permissions. Raw local/central records, ZIP64 values, ranges and footer are consistent; there are no data descriptors or symlinks.
The extracted host and all three XPC services pass deep, strict, all-architecture local codesign verification with exact Apple/Team/Developer-ID requirements. Earlier retained code-page, CMS and timestamp-binding diagnostics also passed. These local checks do not override the notary result. The second submission has not received the first submission's full independent ZIP comparison.
The inference model contains one 5,349,771,222-byte stored member requiring ZIP64 sizes. Later Methods and host metadata also require ZIP64 offsets. We have not established this as a cause, or inferred success for code parts absent from the issue list.
Which exact object and verifier stage failed: the named Mach-O CodeDirectory/CMS, an enclosing resource seal, or archive extraction? Is there a specific error code or documented resource-size limitation relevant to this member? If more evidence is needed, what is the smallest targeted diagnostic? We saw the workflow guidance about excluding huge data from notarization and would like to know whether it applies here before changing the distribution.
The separate inert public carrier job, 9e033029-3914-436d-992b-96bd261637de, is now Accepted. At 2026-09-07 18:32 UTC, its exported app passed strict local verification, stapler validation and Gatekeeper assessment as Notarized Developer ID. This confirms the small control succeeded; it does not establish why the larger app failed. The full product remains Invalid.
The proposed attachment contains the two issue logs, complete member/hash records, four-part size/signature map and a short result summary. No models, apps, profiles, certificates, credentials, account logs or system diagnostic are attached. The original artifacts can be discussed if a specific follow-up is needed.