Change Management Policy

This Change Management Policy defines how Persoon.ai Inc. (“ShipReady Metrics”) controls changes to the production platform so that every change is verified before release, applied in a known order, and traceable afterwards. It covers application code, database schema migrations, runtime configuration, and delivery-pipeline changes.

ShipReady Metrics is operated by a single founder/owner. This policy is honest about that: rather than claiming multi-person approval boards, it relies on machine-enforced verification gates that no change can bypass, plus explicit placeholders for approval controls to be added as the team grows. Engineering standards for how changes are written and tested are defined in the Secure Development Lifecycle Policy.

All standard changes flow through version control into an automated pipeline; there is no manual path that skips verification for application code:

• Every change is a git commit with a Conventional Commits message, enforced locally by commitlint; pre-commit hooks run lint-staged checks before a commit is accepted.
• On every pull request and every push to the production branch (main), two independent CI pipelines run: the verify pipeline (type-check, lint, format check, unit tests, production build, and the SECURITY DEFINER function-grant audit) and the database pipeline (all migrations applied from scratch plus the pgTAP tenant-isolation suite).
• The repository’s CI configuration documents both pipelines as required status checks on main. [Owner to confirm: current branch-protection and review settings on the hosted repository, including whether direct pushes by the owner are permitted.]
• Merging or pushing to main constitutes the release decision (Section 5).

The pipeline gates are the control. A change that fails any of the following does not produce a green run:

• TypeScript compilation (tsc --noEmit) — type errors block the run.
• ESLint and Prettier checks — static-analysis and formatting violations block the run.
• Function-grant audit — a static check that fails if any migration creates or re-creates a guarded SECURITY DEFINER database function without revoking default EXECUTE grants in the same file (a real, previously fixed leak class).
• Unit-test suite (Vitest) — regression failures block the run.
• Production build — the change must build exactly as it will deploy.
• Migration-from-scratch proof — every committed migration must apply cleanly to an empty database.
• pgTAP Row-Level Security suite — tenant isolation must hold after the change; a cross-tenant read that should be denied fails the run.

Production releases are continuous and automated from the main branch:

• Application deploys: every push to main is automatically built and deployed to production by the hosting platform’s git integration (Vercel). CI itself is verify-only and holds no deploy credentials.
• Database migrations: a dedicated migrate-on-deploy workflow runs on every push to main (never from a pull request) and applies any committed migration production has not yet run, so the schema advances in lockstep with the code that depends on it. Applies are serialized so concurrent pushes cannot race the migration ledger, and a migration is recorded as applied in the same query that applies it — a failed migration is never marked as applied.
• The migration workflow authenticates with a scoped management-API access token; it holds no database password and opens no direct database connection.
• Deployment ordering is deliberate: schema first (migrate-on-deploy), application alongside — preventing the incident class where code that reads a new table ships before the table exists.

Database changes carry the highest risk in a multi-tenant platform and have the strictest discipline:

• Append-only migrations: each schema change is a new, sequentially numbered SQL file committed to the repository; existing migrations are never edited or deleted. There are no down-migrations — recovery is roll-forward (Section 8).
• Preventive control: the migrate-on-deploy workflow keeps production’s applied-migration ledger in lockstep with the repository on every push to main.
• Detective control: a scheduled daily drift-alarm workflow runs a read-only comparison of committed migrations against production’s migration ledger; any committed migration not applied in production fails the run, which is the alarm.
• Out-of-band applies (e.g. via administrative tooling during incident response) are permitted only per the production migration runbook committed to the repository, and are reconciled by committing the same SQL as a numbered migration so the ledger, CI proofs, and drift alarm stay truthful.

During an active incident (see the Incident Response Policy), a fix may need to move faster than the standard cadence. Even then, the pipeline is the path: emergency fixes are still commits to main and still pass the automated gates, which run in minutes. Configuration-only mitigations (e.g. disabling a feature flag) may be applied directly in the hosting environment.

• Any out-of-band action taken during an incident is recorded and reconciled into version control afterwards (for schema, per the migration runbook in Section 6).
• [Owner to confirm: whether emergency changes require any additional post-hoc review or record beyond the incident write-up.]

• Application code: deployments are immutable; a bad release is rolled back by reverting the offending commit on main (which redeploys automatically) or by promoting a previous deployment in the hosting platform.
• Database schema: migrations are rolled forward, never down — a corrective migration is committed and flows through the same pipeline. This keeps the append-only ledger truthful.
• Data recovery beyond schema (backups, restore objectives) is governed by the Business Continuity & Disaster Recovery Policy.

In the current single-operator model, the founder/owner authors, verifies, and releases changes. Full segregation of duties between author and approver is not possible with one person, and this policy does not pretend otherwise. The compensating controls are the non-bypassable automated gates (Section 4), the append-only audit trail (Section 10), and independent detective controls (the daily drift alarm) that do not depend on the person who made the change.

• The founder/owner is the only individual authorized to release to production. The company has no employees, and the source repository has a single collaborator, so there is no second releaser today.
• Because there is only one person, pull-request review by a second person is NOT performed today, and a push to the default branch deploys to production. Branch protection exists on the default branch but currently requires zero approving reviews and is not enforced for administrators — stated here as fact rather than implying a review gate that does not operate. Mandatory review by a second person will be introduced when a second person gains repository access.

Every production change is reconstructible after the fact:

• The git history is the change record: who committed what, when, with a structured (Conventional Commits) message describing the intent.
• CI run logs record the verification outcome for every change; deployment history is retained by the hosting platform per deployment.
• The database migration ledger records exactly which schema changes production has applied and when.
• Privileged in-application administrative actions are separately captured in the platform’s audit log.
• These records support the evidence-with-traceability model described in the Information Security Policy.