Skip to content

Change Management Policy

Field Value
Status adopted (this reflects current operating practice)
Owner DIR
Applies to All changes to Partile code, infrastructure, configuration, and this data room, across every idea worktree.
Review cadence Per-PR (the upkeep rule is the live review); full pass annually.
Mapped controls OPS-04 (change management via reviewed PRs + version control — implemented), GOV-01 (decision log — operational), GOV-03 (data room kept current — operational).
Evidence Git history across partile-infra / partile-mobile / partile-ops / partile-cloudflare; the Atelier review checkpoint; READINESS.md decision log.
Exception handling Emergency changes are allowed but reconciled into a reviewed PR after the fact (see below).

Purpose

Document the change process Partile already operates, so it is auditable. This is the one policy marked adopted: reviewed-PR-via-version-control is the actual, demonstrable practice (OPS-04 is implemented; GOV-01/GOV-03 are operational).

The change process (as practised)

  1. Idea + spec. Work is scoped as an Atelier idea/PR with a written spec.
  2. Worktree isolation. Each idea has its own Git worktree; changes are developed in isolation and do not cross-contaminate (ops PR-8 was passed via a selected-file commit precisely to preserve commit isolation — evidence the rule is taken seriously).
  3. Reviewed PR. Changes land via PR through the Atelier review checkpoint; main is the integration branch and the audit trail.
  4. Control-register upkeep. Any PR touching privacy/security/data/ML/safety/ availability updates the relevant control row (status, evidence, last-verified) or states why it is unaffected (GOV-03).
  5. Decision log. Material decisions are recorded with date + rationale in the READINESS.md decision log (GOV-01).
  6. Release review. ../procedures/release-review-procedure.md is the pre-merge checklist (tests, secret scan, control-row update).

What every change must satisfy

  • Version-controlled and attributable (no untracked changes to prod-bound code).
  • Reviewed before merge to main.
  • Tested at the level appropriate to the change (smoke tests for safety/retention/ rate-limit paths exist and must stay green).
  • Secret-scanned: no secrets/PII introduced (the rg scan in the release-review procedure).
  • Reflected in the data room when it touches a control.

Production changes

GCP production exists in partile-prod, but no real user data has launched. Production-affecting changes additionally require: the security preflight gates (secure-development-policy.md), a rollback path, a migration plan for schema changes, and an action-register update for any accepted risk or GA/SLA gate. Until staging exists, extra care is required because production is the only cloud runtime; ACT-002 tracks staging-before-GA.

Emergency changes

An urgent fix may bypass the normal pace but not version control: it is committed, then reconciled into a reviewed PR and a decision-log entry promptly after. Emergency changes touching security are also incidents (incident-response-policy.md).

Exceptions

Any deviation from reviewed-PR merge is recorded by DIR with rationale and a reconciliation date.