What the checksum proves — and what it doesn't
The .sha256 file lets you confirm the ZIP or MSI you have is byte-for-byte what was built — it protects against a corrupted download or a file tampered with in transit. It does not prove who published the file, because anyone could compute a checksum for any file. That's what code signing is for — see Security architecture and Troubleshooting for this release's current unsigned status.
How to verify
certutil -hashfile PlutosTweaker-<version>-Setup.msi SHA256Compare the output against the matching line in the .sha256 file published alongside the artifact. If it doesn't match, do not run the file — get a fresh copy from your order email.
Release manifest
Alongside the checksum, every release ships a machine-readable manifest recording: product name, edition, release label (Public Release vs. Internal/Private Testing), version, the exact git commit it was built from, build configuration, runtime identifier, build timestamp, the ZIP's own SHA-256, whether it's signed, its Authenticode status, the minimum supported Windows version, and a full per-file inventory (path, size, SHA-256) of everything inside the package.
Software Bill of Materials (SBOM)
The SBOM lists every NuGet package (direct and transitive) that ends up in the shipped application, together with its license. The build process that generates it fails closed: any resolved package not present in a known-license table stops the build, so a newly added dependency can never ship without someone consciously recording its license first.
See Third-Party Notices for the human-readable version of the same information.
Why this matters for an unsigned build