Change Management Policy

1. Purpose

This policy governs how changes reach Lever AI's production systems, so that every change is tested before release, deployed through a controlled and recorded path, attributable to the exact source that produced it, and reversible. The controls in this policy are not aspirations: they are the engineering controls the company already operates, stated here as mandatory requirements. This policy expands the change-control summary in the Information Security Policy and is the authoritative statement of Lever AI's change management requirements.

2. Scope

This policy applies to all changes to the production software and infrastructure Lever AI operates: the agent runtime and MCP tool server, the admin-facing web application, deployment and operational tooling, and the supporting cloud configuration on Microsoft Azure. It applies to every person who makes such changes, including contractors.

Changes the agent service makes inside a customer's HRIS tenant at the customer's direction are product operation, not change management; they are governed by the write-safety controls of the AI Governance Policy and the terms of the engagement. Emergency response to a live incident is coordinated under the Incident Response and Business Continuity Policy; any production change it requires is still made under section 3.5 of this policy.

3. Policy

3.1 Change principles

Every production change must be: recorded in version control; tested by the release test suite; deployed through the deploy gate; version-stamped and attributable to an individual and a commit; and reversible by redeploying a prior version. No change path that bypasses these properties is permitted, other than the emergency override in section 3.5, which is itself recorded and reviewed.

3.2 Version control

All production source code, and configuration that is expressible as code, is held in private GitHub repositories. Production changes are made by committing and pushing to version control and deploying from it — never by editing production systems directly. The deploy gate enforces this mechanically: it refuses to deploy from a working tree that is dirty or that has not been pushed, so nothing can reach production that is not recorded in the repository.

3.3 Testing before release

Every release must pass the offline behaviour test suite — approximately 2,800 wire and behaviour tests — before deployment. A failing suite blocks the release. New functionality is accompanied by tests, and defect fixes are made tests-first, as required by the Secure Development (SDLC) Policy; regression tests derived from real incident payloads are added to this suite under the Incident Response and Business Continuity Policy, so the release gate hardens over time.

3.4 The deploy gate

Deployment to production must go through the deploy gate, and the gate's checks are mandatory. The gate refuses to deploy:

• from a dirty working tree (uncommitted changes) or an unpushed branch, so every deployment is traceable to recorded source;
• while customer work is in flight on the service, so a deployment cannot interrupt or corrupt a customer's onboarding run.

Disabling, weakening, or working around the deploy gate is prohibited except through the documented emergency override below.

3.5 Emergency changes and the override

The deploy tooling provides a documented emergency override flag. It may be used only when delay would increase harm — typically an active incident or an urgent security fix — and its use is subject to all of the following:

• the reason for the override must be recorded in the deploy notes at the time of use;
• the Founder must be informed of the override without delay;
• any check that was bypassed, including the test suite, must be run retrospectively as soon as the emergency allows, and any failure treated as a defect to fix immediately;
• every use of the override is reviewed after the fact to confirm it was justified and to decide whether the emergency itself warrants a root-cause analysis under the Incident Response and Business Continuity Policy.

An override with no recorded reason is a policy breach.

3.6 Version stamping and deployment records

Every deployment is version-stamped: the running service reports the commit hash it was built from at a version endpoint, and deployments are logged. What is running in production must always be traceable to the exact source that produced it and to the person who deployed it. Deployment records are retained with operational logs under the Logging and Monitoring Policy.

3.7 Rollback

Rollback is performed by redeploying a prior version-stamped release through the same deploy gate. Because every release is stamped and reproducible from version control, any previously deployed version can be restored. After a rollback, the service's version endpoint and behaviour are verified to confirm the intended version is running. Data-level recovery, where needed, follows the Incident Response and Business Continuity Policy.

3.8 Segregation of duties

Lever AI is a founder-led company of single-digit headcount. Strict segregation of duties between the author of a change, its reviewer, and its deployer is therefore not always possible, and this policy does not pretend otherwise. Where a second engineer is available, substantive changes are reviewed by someone other than the author, as required by the Secure Development (SDLC) Policy. Where one is not, the compensating controls of this policy are mandatory and non-discretionary: the release test suite, the deploy gate's refusal of unrecorded or ill-timed deployments, version-stamped attributable deployments, and engineer monitoring of live onboarding runs. Together these ensure that no change reaches production untested, unrecorded, anonymously, or over in-flight customer work, even when one person performs every step.

3.9 Infrastructure and configuration changes

Changes to cloud infrastructure and service configuration that are not deployed through the pipeline — for example changes made in the Azure portal — are made only by individuals authorised under the Access Control Policy, are kept to a minimum, and, where significant, are recorded with their reason and reflected back into configuration held in version control where practicable. Changes to secrets and credentials follow the Secure Development (SDLC) Policy and the Cryptography and Encryption Policy.

4. Responsibilities

The Founder is accountable for this policy and reviews every use of the emergency override. Every engineer who deploys is responsible for deploying only through the deploy gate, recording override reasons truthfully, and verifying the service after deployment or rollback. Detailed security roles are set out in the Security Roles and Responsibilities document.

5. Exceptions

Exceptions to this policy require the Founder's written approval, a recorded rationale and compensating control, and an expiry date. The emergency override in section 3.5 is the only standing exception mechanism for the deploy gate itself.

6. Review

This policy is reviewed at least annually and after any significant change to the deployment pipeline, the test suite, the team, or the services in scope.