Saffron Systems · Method · Published 29 September 2026 · Updated 30 September 2026

How a Saffron release is proven

Page releases of saffronsystems.io and saffronautomations.com are signed with a release attestation: an Ed25519 signature over the exact content of the page files that changed, the commit they were signed at, and hashes of the screenshots that show how they rendered. On saffronsystems.io, a pull request that changes page files cannot merge into main until a required check has verified that signature. The public key and a real attestation are published below, so you can check a signature yourself in under a minute.

Signature

Ed25519, key id saffron-release-2026-09

Applies to

saffronsystems.io and saffronautomations.com page releases

Verified by

saffron-trusted-source-policy, a CI check that uses the verifier, policy and keys from the base commit on main; required on saffronsystems.io

Signing since

28 September 2026

Merge blocked on a failed signature

Since 29 September 2026, on saffronsystems.io

Why a release needs evidence

A pull request tells you that code changed. It does not tell you what a visitor will see, whether the change was checked on a phone, or whether the file that shipped is the file that was reviewed. Those gaps are where production incidents come from: a stale build redeployed over a live site, a page that looked right on one screen and broke on another, a secret pasted into a template.

Saffron narrows those gaps with evidence that is bound to the exact content of each page release, so that someone who was not in the room can confirm which content was signed, by which key, and which screenshot hashes were recorded for it. The deployment step itself is outside that evidence.

The five steps

1. Work happens in an isolated worktree

Each change is made in its own git worktree created from the current origin/main, never in a shared checkout that another engineer or agent might be using. This removes a whole class of accidents in which one person's half-finished work is committed or deployed by someone else.

2. A local gate runs as a pre-commit hook

The repository's enforcement script runs as a versioned pre-commit hook. Before it checks anything, it tests itself: it must reject a set of known-bad fixtures, reject a planted secret, and reject three forged release signatures. If the gate cannot catch its own traps, it refuses to run. Then it checks every changed line:

• Secrets. Private keys, cloud access keys, GitHub, Slack and live Stripe tokens, and generic secret assignments are refused.
• Source policy. In page and style files, hex colour values in colour declarations and design tokens must come from an approved palette list in the repository's policy, most of it drawn from the token files in Saffron's brand library. Arbitrary pixel utilities, inline pixel styling and unfinished-work markers are refused.

3. A visual receipt is captured for every changed page

A headless browser renders each changed page from the staged content, and the receipt records the capture method, for example desktop and mobile widths with reduced motion, beside the current main branch. The receipt records the SHA-256 of the staged source file and of each screenshot, with the capture time. The commit gate refuses a receipt that is older than 24 hours, that has no entry for a changed page, that was captured for different content than the content being committed, or whose screenshot no longer matches its recorded hash. It does not check which widths or comparisons the method used.

4. The release is signed

The signer refuses to run unless the receipt covers every changed page at its exact committed content and every screenshot is present and hash-matched. It then signs a payload that names:

• the repository and the merge base on main;
• the commit being signed;
• each changed page file at its git blob hash, which identifies its content byte for byte;
• the receipt's hash, method, finding and screenshot hashes;
• the signing time and the signer version.

The payload is serialised with sorted keys, so the same content always produces the same bytes, and signed with the Ed25519 release key. The private key never enters the repository.

5. CI verifies from trusted policy, then the change can merge

On saffronsystems.io, repository rulesets on main require every change to arrive through a pull request with its review threads resolved, block force pushes and deletion of the branch, and require two status checks to pass on a branch that is up to date with main. They require no approving review, and they list no bypass actors.

The two checks do different work. saffron-release-gate runs the enforcement tests, fixture self-test and site structure check from the pull request's own code; because that code comes from the branch under review, it does not verify the release attestation. saffron-trusted-source-policy runs the verifier and policy from the pull request's base commit on main and reads the candidate only as data, so a change cannot weaken the rules that judge it. It verifies the signature against a key pinned in main's policy, then checks that the attestation is for this project, that its base commit is already in main's history, that it was signed within the last 30 days, that it covers exactly the page files the pull request changes, and that each of those files at the head of the pull request has exactly the blob hash that was signed. On saffronautomations.com the same check runs on each pull request, but it is not a required check there. Production is then deployed with the Vercel command line from a clean checkout of main; that step is outside what the signature and the checks cover.

Verify one yourself

This is the attestation for the release that corrected the Saffron Systems page copy on 29 September 2026. Download it and the verifier, then run the verifier with Node.js 18 or later. It uses only Node's built-in cryptography.

curl -O https://saffronsystems.io/software/release-proof/attestation-2026-09-29.json
curl -O https://saffronsystems.io/software/release-proof/verify.mjs
node verify.mjs attestation-2026-09-29.json

Expected output begins with VALID signature and lists the repository, the base and signed commits, and the two page files with their blob hashes. Change a single character of any value in the payload and the result becomes INVALID signature.

The published public key, in SubjectPublicKeyInfo form, base64:

saffron-release-2026-09
MCowBQYDK2VwAyEAwGR8Q13t2AxhrrxvpUBtzsJ1qBENuoDiiKO476aqySo=

• attestation-2026-09-29.json: the unedited attestation file from that release
• verify.mjs: the verifier, which checks the signature only, not the attestation's age, project or file list

What this proves

• On saffronsystems.io, since 29 September 2026, the page files that merged are byte for byte the files that were rendered and signed. Editing a page after signing makes the required check fail until the release is signed again.
• The secret and source-policy checks ran on the lines the pull request added, in a gate that first proved it could catch planted failures.
• The release was signed with the Saffron release key, and the saffron-trusted-source-policy check verified the signature against a key pinned in main's policy.

What it does not prove

• That the software is correct. The attestation fixes the content of the page files it lists and records the signer's own account of how they were checked. Logic is covered by tests where a repository has them, not by the signature.
• That the design is good. A screenshot is evidence of how a page rendered, not a judgement of it. That judgement is still human.
• Accessibility conformance. Restricting colour values to an approved palette is not a contrast audit. The repository's rendered checks, run outside CI, cover keyboard use, the skip link and navigation reachability, not full conformance.
• That every secret format is caught. Secret scanning matches known patterns. An unusual format can pass it.
• Independent custody. The key is held on Saffron's release workstation. The signature attests Saffron's own process, not a third party's. There is no public transparency log yet.

Where software agents fit

Some changes on these properties are drafted by software agents working under supervision. They meet exactly the same gate as a person: the same worktree rule, the same commit checks, the same receipt, the same signature and the same CI verification. The release key is a file on Saffron's release workstation, outside the repository, and agents working there run the signer. That is the principle Saffron applies to agentic systems generally: an agent may do the work, but on saffronsystems.io it cannot merge a page change without the evidence. An irreversible move, such as a merge to main or a production deploy, waits for a person's explicit go under Saffron's operating rule; the rulesets themselves require no approving review.