A download button is not enough to establish trust. People need to know which project published a file, which version it belongs to, which system it targets, and whether the bytes they received match the reviewed release.
These checks now protect the v0.4.0 Public Alpha downloads. An unavailable release fails closed instead of sending visitors to a guessed or incomplete file.
Start from the official website#
An Automexia package is official only when automexia.com marks that exact platform and version as available. A familiar logo, repository name, or filename is not enough.
The download route identifies the package format and architecture. It leads to a versioned artifact in the public, binary-only Automexia release archive only after the release record passes the website's activation checks.
The application source remains private. Generated source archives attached by a hosting platform are not Automexia application packages and do not provide a supported source-build path.
Bind the file to a release#
The v0.4.0 Linux release includes SHA-256 checksums, a detached Minisign signature, the public verification key, SPDX and CycloneDX software bills of materials, and a manifest that identifies the release artifacts.
These records serve different purposes. The signature connects the checksum record to the pinned release key. The checksum identifies the exact bytes of a package. The manifest connects the filename, system, architecture, version, and supporting evidence. First-use trust in the key still depends on the publisher's GitHub account; a signature alone does not establish who owns a key.
Verification applies to one exact file. A checksum for an x64 DEB package cannot validate an Arm64 archive. Evidence from one version cannot validate another.
Never replace a published file silently#
The published v0.4.0 release is immutable. If a package needs a correction, it receives a new version and updated release information.
This rule keeps verification meaningful. If a filename could point to different bytes later, an old checksum or review could no longer tell a user what was installed.
If a release must be withdrawn, the website will stop promoting it and the project will publish an advisory for the affected version. Withdrawal does not turn an unsafe file into a different file under the same identity.
Keep the limits visible#
Release verification improves confidence in package identity and handling. It does not prove that software has no defects or that every system configuration is supported.
Release notes will continue to name tested systems, known limitations, installation steps, update guidance, and removal instructions. Early Access users should begin with non-sensitive work and keep another terminal available.
Read the canonical guidance#
The release trust guide is the public source for identifying official files. Installation shows availability for the current version, and Early Access explains the evaluation boundary.
The goal is simple: every active download should lead to a file that a user can identify, verify, and place in the correct release context.