Quidne

Build once, promote with proof

One artifact, fingerprinted once and promoted from DEV to UAT to PROD behind approvals, with 39 checks against the live host at every stop. Step through a real run, then change one byte and watch the gate refuse it.

Competency
Release automation and DevOps
Context
Quidne · Release automation
Built with
Azure DevOps Pipelines, Azure Static Web Apps, PowerShell, Pester

Try it

Build

  • Content integrity Passed
  • Config schema Passed
  • ES module syntax Passed
  • Package and fingerprint Published

site-content · 105 files · sha256 22ee0b7b7e47

DEV (Static Web Apps default host)

  • Gate Automatic
  • Deploy Deployed
  • Verify 39 of 39 passed

sha256 22ee0b7b7e47

UAT

  • Approval 29 Approved
  • Deploy Deployed
  • Verify 39 of 39 passed

sha256 22ee0b7b7e47

PROD

  • Approval 30 Approved
  • Deploy Deployed
  • Verify 39 of 39 passed

sha256 22ee0b7b7e47

The 39 checks PROD ran, by group
  • Availability: 6 passed
  • TLS: 4 passed
  • Content identity: 1 passed
  • Security headers: 7 passed
  • Cache headers: 19 passed
  • App config: 2 passed

Simulation of a real run: pipeline run 919 (20260927.5) at commit 59f35ab, released to UAT by approval 29 on 27 September 2026 and to PROD by approval 30 on 28 September. The check results are re-run from that commit's own verifier against its own files; certificate details were read on 1 October 2026.

  1. Validate before anything is built

    Every merge to main runs three validators side by side: content integrity, config schema and ES module syntax. Package starts only when all three pass, so a tree a validator rejected never becomes an artifact.

  2. Fingerprint it once

    Package hashes all 105 files into one manifest and publishes it beside the content. That hash is the artifact's identity from here to PROD. Nothing is rebuilt for another environment.

  3. DEV deploys on its own

    No approval guards DEV. The stage deploys the artifact, then runs the verifier: 39 checks against the live host, from the status code of / to the Cache-Control of every route.

  4. UAT waits for a person

    UAT starts only when someone approves it. Press Approve to release approval 29, as the run did at 17:02 UTC on 27 September. The same artifact deploys and the same 39 checks run against uat.quidne.com.

  5. PROD gets the same bytes

    Approval 30 releases PROD. The token that arrives is the one Build made: the same 105 files and the same hash. Content identity proves it by fetching every file from quidne.com and checking it against the manifest.

  6. What if one byte changed?

    Turn on the what-if and css/base.css on UAT differs from the build by one byte. The content identity check fails with its real message, the stage fails and PROD is never offered the artifact.

What it shows

The release pipeline behind this site, replayed from one run. A merge to main is validated, packaged and fingerprinted once. That single artifact then moves through DEV, UAT and PROD, and nothing is rebuilt on the way. Each environment has its own gate, and each deploy ends with the same verifier checking the live host, so a promotion is never taken on trust.

What you get

  • An artifact: one fingerprinted build, promoted unchanged through every environment.
  • A proof: 39 checks against the live host after every deploy, covering headers, caching, certificates and a byte-for-byte content comparison.
  • A number: 117 checks against live hosts across three environments for one build, and no rebuilds.

After we leave, your team runs it. The pipeline is YAML in your repository, the checks are PowerShell with Pester tests, and the approvals are Azure DevOps environment checks your release owners already understand.

How it is built

The board's data comes from tools/export-verify-run.ps1. The tool extracts the run's commit, proves that every file hashes to the run's own build manifest, then runs that commit's verifier functions against those files with the same routing rules the site is served with. The stage timings and approvals come from the run's timeline. A Pester test fails if a check named here is ever renamed or removed from the verifier, so this page cannot outlive the pipeline it shows.

The board is plain HTML in its final state. The scene module redraws it as a pure function of the data and the step you are on, and the canvas draws only the lane the artifact travels. Every state is carried by a glyph and a word, with colour as reinforcement. Under reduced motion the token jumps between environments instead of travelling.