Why release truth starts with the artifact

In software distribution, documentation and marketing copy frequently drift away from the compiled reality. A build configuration might specify an architecture target, a release note might abbreviate the format list, or an installer filename might inherit a legacy naming convention.

When public documentation relies on build scripts or filenames rather than inspectable binaries, inaccuracies accumulate. An abbreviated summary might omit the Standalone application, or a package name might suggest a single architecture when the binaries inside are universal.

At StudioZIO, public capability claims must derive directly from the final, immutable release artifact. Before a release is approved for publication, the signed and notarized package is downloaded and expanded in a clean, read-only inspection environment.

We inventory the exact payloads installed to disk across four capability targets: Audio Unit (.component), VST3 (.vst3), AAX (.aaxplugin), and the Standalone application (.app). If an output does not exist in the expanded payload, it cannot be claimed on any public surface.

Payload presence is only half the verification. Each contained executable is inspected directly using Mach-O analysis tools like lipo and file.

This establishes whether each binary contains arm64 slices, x86_64 slices, or both. We never infer architecture from the installer filename. If the binaries are universal, the release is universal, even if the installer package filename contains an arm64 token for historical reasons.

The results of this inspection are recorded in a permanent, version-controlled Release Truth Manifest. Downstream web pages, product catalogs, and release notes must read their capability claims from this manifest rather than manual transcription.

To see how this applies to our current lineup, read Universal vs Apple Silicon, or review the overall workflow in Inside the StudioZIO release pipeline.