The check-in / PR-review process implements the change-control requirements of the Secure Development Policy and the Operations Security Policy.

​
Requirements

  • At least one approving review from someone other than the author is required before a PR can be merged into a production branch.
  • Reviewers must be qualified — typically a developer or manager familiar with the area of the change.
  • Branch protection enforces the review requirement on master (and any branch matching release/*).
  • CI must pass — tests, lint, security scans, build.
  • No self-merging without an approving review.
Settings live in the Neuroscale GitHub org branch-protection settings.

​
What reviewers check

  • Correctness — does the change do what’s intended?
  • Security — see Secure coding.
  • Tests — adequate unit/integration coverage for the change.
  • Migrations — backward-compatible; safe rollout plan.
  • Logging — no sensitive data; adequate observability.
  • Documentation — public APIs and operational changes documented.
  • Secrets and environment variables. No secret values in .env, config.yaml, values.yaml, container images, Helm charts, Terraform state, static Kubernetes Secret manifests, deployment-tool environment blocks, or CI logs. Every new env var that holds a secret must source from Vault at runtime via a workload-bound auth method (Vault AWS / Kubernetes / AppRole / OIDC) — see Secrets Management → Application configuration and environment variables. .env.example may carry placeholder values only.

​
Sensitive areas

Changes to authentication, IAM/RBAC, billing, customer-data export, and key-management code paths require a second reviewer from the Security team via CODEOWNERS.

​
Emergency changes

Emergency changes (production hotfix) follow the Change Management emergency-change procedure: deploy first, post-deploy review and authorization within 24 hours.

​
Version history

VersionDateDescriptionAuthorApproved by
1.0May 8, 2026Initial versionCameron WolfeIshan Jadhwani