I would like to identify a supported, minimally scoped diagnostic method for a code-signature verification failure, without changing certificates, trust settings, or system protections. The command execution environment reported macOS 27.0.1, build 26A434. The following command was run against the standard system executable: /usr/bin/codesign --verify --strict --verbose=6 -R '=anchor apple' /usr/bin/printf It returned exit status 1 with: CSSMERR_TP_NOT_TRUSTED In architecture: arm64e.x1 The designated requirement displayed for the file was: identifier "com.apple.printf" and anchor apple The signature display reported Authority=(unavailable). Following TN3161, the CMS data was inspected structurally: it contained three certificate structures, whose recorded validity periods included the observation date. This was not a cryptographic or trust validation, and I do not treat the file as authenticated. My question is how to distinguish a certificate/trust rejection from inability to complete evaluation in the command's execution context. The documentation for SecStaticCodeCheckValidityWithErrors describes detailed errors, and kSecCodeInfoTrust describes access to the trust object used in code-signature evaluation. Is either a supported diagnostic route for this system executable and architecture? If so, please identify the required flags, prerequisites and minimum non-sensitive result fields. In particular, I do not want to change the strict or architecture coverage merely to obtain a passing result. No diagnostic using those APIs has been implemented or run. I am not asking to re-sign the system file, install certificates, reset trust settings, disable protections, or bypass validation. I would prefer an initial diagnostic that does not require private Keychain contents, broad system logs, or a full diagnostic archive. I understand that a diagnostic result or a successful information query would not by itself authorize execution or prove that the environment is safe.