What supported public contract should software use for com.apple.provenance when copying an exact expected helper binary into a new, private owner-controlled working directory for separately authorized later use? We want to leave originals unchanged, preserve security protections, and avoid removing, decoding or reconstructing opaque Apple attribute values. Program-byte identity, permissions/custody and code validation are separate from this metadata question; an attribute name or copy success is not treated as a trust decision. Public APIs reviewed: fcopyfile with independent DATA/XATTR selection, and xattr_flags_from_name with xattr_intent_with_flags for COPY intent. A bounded public-constant probe returned zero property flags and the default preserve result for both com.apple.provenance and an invented unknown name. We therefore do not interpret that default as proof of recognition or an exemption. Could you clarify: Which supported metadata postconditions apply to this specific copy use? Is source/destination raw-value equality an appropriate invariant for this opaque attribute, or may the OS legitimately create different destination metadata while preserving the intended security behavior? Which public properties or APIs can establish the intended destination state without parsing/removing private values or weakening OS protections? The xattr manual's named-wrapper return sentence appears inconsistent with its flags-based description/example. What is the supported return-polarity contract, and is using the flags-based function the intended interpretation? This asks for supported semantics, not a bypass or private value format. No paths, binaries, source, attribute values, keys, account data or logs are attached. Public references: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/fcopyfile.3.html https://github.com/apple-oss-distributions/copyfile/blob/main/xattr_name_with_flags.3 https://github.com/apple-oss-distributions/copyfile/blob/main/xattr_flags.h