Change Management Procedure

Implements: Information Security Policy Section 7 (Change Management) Owner: ISMS Owner Last Updated: 19 June 2026 Next Review: 21 November 2026

Scope

This procedure governs changes to production systems across both Maelstrom AI platforms — Provii (zero-knowledge age verification) and downpipes (no-custody backup & disaster recovery for the Cloudflare data layer). The change types, approvals and review gates below apply uniformly to both.

Maelstrom builds and maintains the software for both platforms and operates the vendor-side surfaces — the downpipes control-plane (fail-open) and the signature-pinned update channel — through this same process. The downpipes engine and console run in each customer’s own Cloudflare account, under the customer’s keys (no-custody); how a change reaches those customer-operated components is governed by the downpipes Release Channel section below, and the decision to apply an update is a complementary user-entity control (CUEC) of the customer.

Change Types

Standard Change Process

1. Propose

1. Create a branch from main
2. Make changes following repository coding standards
3. Write or update tests as needed

2. Review

• Open a Pull Request with description of what and why
• Automated CI must pass (lint, test, build)
• At least 1 approved review required
• CODEOWNERS rules apply (if file path requires specific reviewer)

3. Merge

• Squash merge to main
• CI deploys automatically to sandbox (where applicable)

4. Deploy to Production

1. For Rust Workers: CI builds WASM, deploys via wrangler deploy
2. For TypeScript Workers: CI deploys via wrangler deploy
3. For mobile: App store review process applies separately

5. Verify

1. Check Cloudflare dashboard for error rates
2. Verify key endpoints return expected responses
3. Monitor for 30 minutes post-deploy

Significant Change Process

All steps from Standard, plus:

• Design review before implementation (brief written description of approach)
• 2 reviewers required on PR, one of whom must be the Security Lead
• Staged rollout where possible (sandbox first, then production)
• Rollback plan documented in PR description
• Post-deploy monitoring for 2 hours

Emergency Change Process

1. Verbal approval from ISMS Owner or Security Lead (Slack, phone, or in-person)
2. Fix applied directly. may bypass standard branch naming
3. Deploy immediately to production
4. Post-hoc PR created within 24 hours documenting the change
5. Post-incident review to determine if the emergency could have been prevented

Rollback Procedure

Cloudflare Workers

# List recent deployments
wrangler deployments list

# Rollback to previous version
wrangler rollback

If Rollback Fails

1. Revert the merge commit on main
2. Push the revert
3. CI will deploy the reverted version
4. Investigate root cause before re-attempting the change

downpipes Release Channel (Update Channel)

The downpipes engine and console do not run in Maelstrom’s account — they run in each customer’s own Cloudflare account, under the customer’s keys, with no standing inbound path (“runs dark”). Maelstrom cannot wrangler deploy into a customer tenant. Changes therefore reach customer-operated components through the signature-pinned update channel rather than the deployment steps above.

Release Pipeline (vendor side)

1. Code change is proposed, reviewed and merged through the Standard/Significant/Emergency process above
2. The release artefact is built and published as a static update to the signature-pinned R2 bucket at updates.downpipes.io
3. The update is signed with the downpipes Update Signer, a key held offline by the operator and never deployed to any Worker
4. The update channel PULLS — updates are never pushed into a tenant. The engine fetches the update on its own schedule and verifies the signature against a pinned public key before applying anything
5. Application is canary-gated (safe-apply) with automatic rollback on failure; there is no phone-home

Vendor-side surfaces (control-plane)

The downpipes control-plane (which mints licence tokens and a content-free advisory beacon, holds no customer keys, data or Cloudflare tokens, and is fail-open — it never gates backup or restore) is vendor-operated and changes through the same Cloudflare Workers process as Provii’s Workers (Standard/Significant/Emergency, CI deploy via wrangler deploy, rollback via wrangler rollback). Because the control-plane is fail-open by design, a failed control-plane change can never block a customer’s backup or restore.

Customer responsibility (CUEC)

Applying an update to a customer’s engine or console is the customer’s decision and is a complementary user-entity control. Maelstrom’s responsibility is limited to building, signing and publishing the update correctly; the offline-held Update Signer and the engine’s pinned-key signature verification protect the integrity of every release before a customer applies it. See the Backup and Recovery Procedure and the ISMS Scope Statement shared-responsibility model.

Maelstrom’s own Cloudflare estate is backed up by our own production instance of downpipes, which receives engine and console updates through this same signature-pinned, pull-only channel — so we operate the release process as a customer of our own product. See Cloudflare Backup Evidence.

Change Log

All changes are tracked via:

• Git commit history (immutable record of all code changes)
• GitHub PR descriptions (what, why, reviewer approvals)
• Cloudflare deployment logs (when each version went live)
• This procedure does not require a separate change log. Git is the source of truth