How changes reach production.

A change should be understandable before it ships, verifiable after it ships, and reversible if it goes wrong. This is the process we use for the site and the systems we operate.

Version 1.0 · 25 September 2026 · Owned by the directors

Record and assess

Every proposed change has an owner, a reason, an affected system, a verification plan and a way back. Changes to access, personal data, vendors, integrations or production secrets receive director review.

Build and review

Code and infrastructure changes are committed on a branch. The pull request explains the change and another person reviews it before it reaches production. Secrets stay out of source control.

Verify in preview

We run the checks that fit the change: typecheck, build and focused tests for code; desktop and mobile review for pages; and permissions and failure paths for sensitive integrations. Customer data systems use separate non-production credentials and data stores.

Release and observe

An authorised maintainer merges the reviewed change. The deployment is tied to a commit, and the owner checks the affected workflow in production and records the result.

Roll back if needed

If the change causes harm or cannot be verified, we stop rollout and revert it or redeploy the last known good version. We check the restored behaviour and record what happened.

Handle urgent fixes

An emergency fix can take an expedited path with director approval. It still has a recorded reason, source-controlled change, practical check and rollback route, followed by a full review when stable.

The change record is the issue or pull request, review, check results, deployment record and production verification. We update the process when the delivery workflow changes. For the full written process or a security review, email privacy@nomad.sc.