Release · Provenance

Which akson this is.

Documentation that does not name its version documents nothing in particular. This site describes the workspace at v0.0.1-alpha.1 — a prerelease by construction rather than by modesty, for a reason the tooling actually enforces.

v0.0.1-alpha.1 prerelease, gated Apache-2.0 Linux · Rust

What this site documents

The version above is the [workspace.package] version in Cargo.toml, and it is the same string the tag v0.0.1-alpha.1 names. It appears on this page because a generator reads it out of the workspace manifest — so it cannot quietly describe a version the code has moved past.

Everything else on this site is written against that commit: the guide's commands, the internals' architecture, the coordination surface's operation names and envelope members, and the proofs' model list.

What "prerelease" means here

Four gates run before the workflow builds anything, and one of them is the reason this version carries an -alpha. None of them is advisory.

Gate	What it does
Provisional media types	This is the one that makes it a prerelease. While `MEDIA_TYPES_ARE_PROVISIONAL` is `true`, the workflow refuses a stable tag and marks every release it does cut as a prerelease. Akson's payload media types are still in the unregistered `vnd.akson-dev` tree — the contract envelope, the result manifest, and the coordination dispatch envelope among them. Unregistered means the names may change, so anything written against them may have to move.
Tag equals version	The tag must equal the workspace version exactly, so a release asset can never be labelled with a version its binaries were not built from.
`ci` green for this commit	The workflow reads this commit's completed `ci` conclusions and refuses unless they are all `success`. A tag cannot outrun the tests by being pushed at a commit CI never approved.
The active toolchain is the pinned one	`rustc --version` must equal the channel `rust-toolchain.toml` names — asserted at run time rather than assumed, so a runner-image change cannot silently build a release with a different compiler.

The first gate is what the -alpha records: not a guess about maturity, but a fact about the wire types. While it holds, 0.0.1-alpha.1 is the version the tag gate and it both accept. When the media types are registered that gate opens and a stable version becomes possible — and only then.

What a prerelease means for you

Akson runs end to end today, but the wire types may change, key custody is interim — the master secret and the data-encryption key live in a file, and store rollback is undetectable — and the assurance profile is a developer one. Use this release to explore and to build against. Don't protect anything that matters with it yet. The threat model names each residual rather than rounding it away.

What has actually been published

A page about verifying releases should be honest about whether there is anything to verify.

Nothing, yet

The tag has not been pushed, so the release workflow has never run. There are no built artifacts, no SBOMs, no attestation, and no release object — not even a draft. The commands further down have nothing to fetch today; they are here because they are what you should run once there is, and because a verification page written only after assets appear is a page nobody has read by the moment it matters.

v0.0.1-alpha.1 is an annotated tag in the repository, on the commit whose workspace version it names. What tagging establishes is exactly one thing: which commit is the intended prerelease. Everything else waits on a push, which is a deliberate maintainer act rather than an oversight — a tag push publishes to a public repository and starts the workflow.

And when it does run, it stops one step short of publishing: the workflow creates a draft release, so a push builds, SBOMs and attests, while making the assets downloadable stays a second deliberate act after the asset set has been checked. The provenance attestation is public as soon as the workflow runs, though — it binds to the artifacts, not to the release object — so gh attestation verify can succeed on a file before any release page exists.

CI still walks the first steps of the release path on every push and pull request, which is what keeps it from rotting: the same pinned toolchain (asserted at runtime, not assumed), a --locked --release build of one artifact with RUSTFLAGS cleared to mirror the release rather than CI's own -D warnings, and an assertion that the artifact list accounts for every binary the workspace produces — so a new or renamed binary cannot silently fall out of a release.

Verifying an asset

Every release asset is meant to be checked, not trusted. Four checks, in the order that makes each one worth running.

any host

# nothing to download yet — the tag is unpushed, so this fetches nothing today
gh release download v0.0.1-alpha.1 --repo zarbafian/akson --dir akson-release
cd akson-release

# 1. the download is intact
sha256sum --check --ignore-missing SHA256SUMS

# 2. GitHub built these artifacts, from this repo, in this workflow — the trust anchor
gh attestation verify aksond --repo zarbafian/akson \
  --signer-workflow zarbafian/akson/.github/workflows/release.yml

# 3. what is inside the binary you are about to run
jq -r '.components[] | "\(.name) \(.version) \(.licenses[0].expression // "?")"' aksond.cdx.json

# 4. rebuild it yourself, from the commit and lockfile BUILD-INFO.txt names
cat BUILD-INFO.txt                 # tag, commit, toolchain, Cargo.lock digest, build command
git checkout v0.0.1-alpha.1 && sha256sum Cargo.lock
env -u RUSTFLAGS cargo build --locked --release --bins \
  -p aksond -p akson-cli -p akson-mcp \
  -p akson-adapter-openai -p akson-adapter-anthropic -p akson-adapter-gemini
sha256sum target/release/aksond && grep '  aksond$' SHA256SUMS

Step 2 is the trust anchor. Steps 1, 3 and 4 are only as strong as step 2 unless you obtained the assets over a channel you already trust. env -u RUSTFLAGS matters in step 4: the release build sets no RUSTFLAGS at all, unlike CI, which builds with -D warnings — and a different RUSTFLAGS is a different build.

What each check establishes — and what it does not

Check	Establishes	Does not establish
`sha256sum --check`	The download is internally consistent.	Anything about origin — the file is unsigned on its own.
`gh attestation verify`	These exact bytes came out of `release.yml` in this repository, at a named commit.	That the code or its dependencies are safe. And note the trust path: this is GitHub-native Sigstore provenance, not a project-held signing key, so GitHub's OIDC issuer and Sigstore instance are in it.
SBOM inspection	Which crate versions and declared licenses the lockfile resolved, with registry checksums for crates.io crates.	What the linker actually kept — feature-pruned and dead-stripped crates still appear. It is a dependency inventory derived from `Cargo.lock`, not a scan of the binary, and not an audit of those licenses.
Local rebuild	The source and lockfile are the ones described, and usually that the bytes follow from them.	Bit-for-bit reproducibility, which is not claimed: the build does not pin build paths or normalise the environment. If the dependency graphs agree and the attestation verifies, a byte difference is an environment difference.

The full walkthrough

The command-by-command version — offline attestation verification with a bundle and a custom trusted root, the jq recipes over the SBOM, the exact rebuild comparison, and what to do when a check fails — is verifying-a-release.md in the repository, where GitHub renders it. A copy is also served from this site at /verifying-a-release.md — that link is honest rather than pretty: it is Markdown, and this site has no Jekyll layer to render it, so your browser will show it as plain text.

If a check fails, report it through SECURITY.md rather than a public issue, and say which check failed, the tag, the asset, and the digest you computed. A failing gh attestation verify on an asset downloaded from a release page is the serious case — do not run the binary.