Release evidence

Know what you are downloading.

SkyTwin separates a usable alpha, current source capability, and public release support. You can install the app today without pretending the evidence-gated beta is finished.

Current status: v0.7.0-beta is blocked in the authoritative beta claim ledger. This page explains the gate; it does not override it.

What is available today

A downloadable desktop alpha is available for Apple Silicon macOS, x64 Windows, and x86-64 Linux. It is a real packaged SkyTwin app, but it is unsigned and packages current 0.6.106.0 source, including the isolated fictional-data sample and advanced BYO Google setup. It is not represented as a supported public beta or as proof that signing, notarization, updates, or clean-machine behavior are complete.

Desktop alpha: install and use the app

The alpha-0.6.106.0 desktop alpha release packages the current code under an explicitly prerelease tag. Its Electron-compatible application version is derived from the four-part repository version. Open the release page for the available assets:

Platform	Alpha artifact
macOS · Apple Silicon	Current release assets
Windows · x64	Current release assets
Linux · x86-64	AppImage, Debian, and RPM assets

This alpha is not merely the fictional demo. It includes a five-step Connect Gmail wizard in the desktop window. The same page is served at http://localhost:3200/#/connect-gmail for an already authenticated browser session; a fresh browser does not inherit the Electron session-token handoff. The wizard creates and uses your own Google OAuth client for Gmail; a worker can ingest live Gmail and Calendar signals. Follow the real-inbox setup guide and start with a test account; this older capability carries explicit plaintext client-secret/token, provider-warning, and unsupported Gmail/Calendar-mutation limitations.

Unsigned alpha: macOS Gatekeeper and Windows SmartScreen warn on first launch. The release has no current signing/notarization proof, update manifests, checksums/SBOM/provenance bundle, or clean-machine evidence. It also is not the gated beta. Use it to try the packaged application, or use the same release source when you want to inspect and run the code directly.

Source previews: a snapshot you can build on

A public source-preview-YYYY-MM-DD release is a dated snapshot of the source, published as a GitHub prerelease after source CI and documentation checks. Its only downloads are GitHub’s source ZIP and tar archives; it contains no packaged application, updater feed, signing proof, or beta certification. The internal source-candidate packager is not used for public releases.

Use the exact tag or commit from its release notes with the source setup guide. Local development tools are required. Start with the fictional sample; supported managed Google and Microsoft connections remain outside this source snapshot. Advanced users can separately use the current alpha's BYO Gmail wizard or current source's exact experimental operator mode; neither changes the beta evidence state. The desktop beta stays blocked independently. Browse releases →

Claims are machine-checked contracts

The release claim ledger assigns a status, evidence requirement, and owner/boundary to each public claim. The repository command below verifies consistency between release-facing copy and the ledger:

pnpm claims:check

It is necessary but not sufficient. It can validate that a claim is correctly marked blocked; it cannot create a signed artifact, a notarization result, a clean-machine run, a human usability observation, or third-party verification.

Why the public beta remains gated

Gate family	Why it matters	What cannot be substituted
Signing and notarization	Users need an authenticated desktop artifact and platform trust evidence.	A source build, checksum alone, or an unsigned installer.
Clean-machine and packaged sample evidence	The claimed installer path must be proven on the actual artifact and operating system.	Unit tests against a repository checkout.
Release-wide safety/explanation evidence	The public support surface needs bounded, durable proof of its decision behavior.	A polished demo or one correctly handled route.
Release artifact identity	Reports must bind to exact upload bytes, tag, commit, and platform-specific subjects.	A hand-authored report, a branch build, or detached logs.

What the tagged release workflow does

Normalize the repository version to the ready ledger target in a pull request.
On a v* tag, build desktop artifacts and the release evidence material.
Bind reports, checksums, SBOM/provenance material, and platform subject identities to the uploaded assets.
Verify the exact manifest, tag-to-commit relationship, and evidence contract while the release is still an unpublished draft.
Only when the ledger is ready and all checks pass, make the draft release public.

The release workflow is intentionally designed to stop before creating or publishing an eligible public artifact when open stop-ship gates exist.

How to review a candidate honestly

Read the claim ledger first; it is the status source of truth.
Use the evidence deck for public claim-to-mechanism links, then inspect source and test evidence.
For an artifact, verify its release notes, checksums, signing/notarization status, and machine reports—not only a tag name.
For the developer preview, start from source and the fictional sample; do not connect a real account just to force a broader demo.

Canonical detail: release procedure · evidence record template.