CHANGE CONTROL — RAIN RNG (GLI-19 App. B.8.2; GLI Change Management Program Guide; MGA Directive 3 Art. 24; UKGC Testing Strategy major/minor)

Short, true to the repository as of the commit in lab/FINGERPRINTS.json. Where a control does not yet exist it is marked [TO ESTABLISH].

1. Version identification

• Packages are versioned together (npm version X.Y.Z --workspaces, PUBLISHING.md §1); the certified RNG is identified by (a) the git commit and (b) the SHA-256 digests in lab/FINGERPRINTS.json (files-digest), not by the version string alone. rng-node reports GET / → version, and /healthz.selfTest.fingerprints shows whether the running dist/ matches the manifest.
• Every source module on the certified path carries a header comment describing purpose and design; module edit history is the git log (git log --follow <file>), delivered with the repository (GLI CSR §1.3 accepts a VCS history).

2. What is an "RNG-affecting change" (triggers re-certification / lab notification)

Any change to a file in these FINGERPRINTS.json scopes: source (certified path) (packages/rng-core/src/**, packages/rng-session/src/**, packages/rng-node/src/{house,selftest}.ts, packages/rng-py/rain_rng/**), the toolchain recorded in the manifest (TypeScript major/minor), or the test vectors. Specifically: the hash/HMAC/DRBG/ChaCha implementations; deriveDrawKey (domain prefix RAIN-RNG-v2.1|); drbg() including intBelow, shuffle, uint32/uint53/float, uint64be; outcome(); chain construction (hashChain, chainOk); the ceremony state machines; persist-before-reveal in house.ts; the KAT set. Also: any new N or new scaling method used by a game (GLI CSR §2.2 "generating numbers outside the scope of what was previously tested") and any new game engine consuming the cursor.

Not RNG-affecting (notify, no re-test): rng-node transport/metrics/config/attribution/anchoring code, documentation, lab tools, @rain/channels, @rain/markets, examples. A change is classified at PR time by the RNG owner and recorded in CHANGELOG.md with the tag [RNG] or [non-RNG] [TO ESTABLISH: the tag convention starts with the next release].

3. Procedure for a change (records required)

1. Issue/PR describing reason and components; the PR body carries the classification (§2).
2. Code review by a second maintainer (segregation of duties: author ≠ approver) [TO ESTABLISH — currently a single-maintainer repo; .github/CODEOWNERS + branch protection per docs/GOVERNANCE.md §2 enforce it once a second maintainer team exists and protection is applied; the lab audits compliance from the PR history].
3. CI gate: npm test (build + typecheck + unit incl. KATs + selftest + e2e node), npm run test:py, npm run lab:verify-build (manifest regenerated in the same PR if the change is RNG-affecting) [CI configuration is in the repository: .github/workflows/ci.yml runs exactly these plus a fingerprint-drift check and dependency review; it becomes a required status check when branch protection is applied (docs/GOVERNANCE.md §2) — not yet exercised on GitHub].
4. Merge → CHANGELOG.md entry (date, version, reason, component, author, approver, classification).
5. RNG-affecting → new lab/FINGERPRINTS.json, new lab submission (or "change examination" by the lab per GLI CSR §2.2), regulator notification where required (MGA Art. 24 prior approval; UKGC "major update" external test), before production deployment.
6. Deployment record (who, when, which image digest, which FINGERPRINTS.json) kept by the operator (see HOSTING-HA-DR.md).

Security activities that accompany changes (pen-test after transport/store/key changes, audit per contract deployment) are scheduled in SECURITY-PROGRAM.md §2.

4. Rollback

rng-node workers are stateless; the store is versioned by record type. Rollback = redeploy the previous image whose dist/ matches the previously certified manifest; the node's fingerprint self-check confirms it. A rollback that crosses an RNG-affecting change is itself a change (record it). The WAL/Postgres store must never be rolled back to an older copy (HOUSE-NODE §7).

5. Emergency changes

A security fix on the certified path may be deployed before lab review only if (a) the incident is recorded (INCIDENT-RESPONSE.md), (b) the change is confined to the fix, (c) the lab and regulator are notified within 24 h with the diff and new fingerprints, and (d) the full procedure of §3 is completed afterwards.

Change record — 2026-09-14

• Trigger: lab:verify-build reported FINGERPRINT MISMATCH (15 files) on HEAD 825689ba — FINGERPRINTS.json had been frozen at 22:37Z on Sep 13, before the runtime self-test code (KATs, /selftest) landed.
• Action: lab/tools/refreeze.sh — re-fingerprint on current HEAD, verify twice. 214 files. Both verifications OK.
• Lesson (now policy): FINGERPRINTS.json is regenerated in the SAME commit as any RNG-affecting change, and lab:verify-build runs before every tag/publish. This is the re-certification trigger described above.