Plain EnglishSafety first
AIUpdateWatch.com
Search
Menu

AIUpdateWatch Daily Intelligence

Verify an AIUpdateWatch release

This page explains the release-integrity controls and the evidence that must exist before a build can be described as signed, deployed or rollback-ready.

Morning edition: Saturday, July 25, 2026 · Data cutoff Jul 25, 2026, 4:00 AM (America/New_York)

Current Stage 31 status

Controls are ready; no production release is claimed here

The current repository contains the deterministic packaging, verification, keyless-signing, deployment-attestation and rollback-staging controls. Remote deployment remains disabled, and this page does not claim that the current edition has already been signed or deployed.

Archive
deterministic-ustar
Digest
SHA256
Signing
Sigstore keyless signing through GitHub OIDC
Provenance
SLSA provenance v1
Protected environment
signed-release
Remote deployment
Not authorized

Verification evidence

What a signed release must contain

Release envelope

Binds the edition, source commit, authorization, browser evidence, build root, archive digest and rollback reference.

Sigstore bundle

Contains the keyless signature, short-lived certificate, timestamp and transparency-log proof for the release envelope.

SLSA provenance

Describes the build type, source material, builder identity, invocation and release archive subject digest.

Build-file manifest

Lists every deployable file with its exact SHA-256 digest and byte size.

Bundle manifest

Lists every file inside the deterministic release archive.

Deployment attestation

Records whether the checked local or remote deployment matches the approved build files.

Rollback descriptor

Identifies the preceding verified release without automatically changing the live site.

Fail-closed sequence

How a release becomes verifiable

  1. Approve the exact edition.The release authorization binds a named manager or a protected GitHub Environment to the source commit.
  2. Build and test the site.Astro validation, the production build and functional browser acceptance must pass first.
  3. Hash every deployable file.The build manifest records the exact path, byte size and SHA-256 digest of every file.
  4. Create the release twice.Both deterministic archives must be byte-for-byte identical or the release stops.
  5. Sign the envelope and provenance.GitHub OIDC obtains an ephemeral identity for Sigstore keyless signing; no long-lived private key is stored in the repository.
  6. Verify the deployment.The deployment attestation checks the release identity and every expected file before the deployment can be described as verified.
  7. Keep a verified rollback package.Rollback stages a previously verified release for review and never changes the live site automatically.

Public machine-readable policy

The stable policy endpoint describes the archive, digest, signature, provenance, environment and rollback requirements.

Open the release policy JSON →

How to verify a future signed envelope

Use the release archive, release envelope, Sigstore bundle and expected GitHub workflow identity together. A digest without its signed identity and provenance is not enough.

cosign verify-blob release-envelope.json \
  --bundle release-envelope.sigstore.json \
  --certificate-identity-regexp='^https://github.com/oraktas/aiupdatewatch_beginner_complete_site/.github/workflows/manual-signed-release.yml@' \
  --certificate-oidc-issuer='https://token.actions.githubusercontent.com'

Important distinction

Signed, deployed and attested are different states

Signed

The release envelope and provenance have valid identity-bound signatures.

Deployed

The files have been copied to a hosting environment. Deployment alone does not prove integrity.

Attested

The deployment has been checked against the approved build manifest and release identity.