Purpose and scope
This process applies to material changes to Kylian application code, configuration, infrastructure, dependencies, data models, deployment workflows, and third-party integrations. Its goal is to make production changes attributable, tested, observable, and reversible in proportion to risk.
Change classes
- Standard change: low-risk, repeatable work with a known implementation and recovery path.
- Normal change: a feature, fix, integration, configuration update, or migration that receives the full review and validation appropriate to its risk.
- Emergency change: urgent work needed to contain an incident, restore service, or address a critical vulnerability. Review may be expedited, but testing and retrospective documentation are still required.
Required change record
A material change record should identify the owner, reason, affected service, security and privacy impact, test evidence, release plan, monitoring plan, and rollback path. Source control, deployment records, and linked issue tracking provide the audit trail.
Review and approval
Changes are reviewed and approved according to risk. Review covers correctness, authorization, data handling, migration safety, dependency risk, secrets, observability, and recovery. High-impact changes require independent review or explicit approval before production release.
Quality and security gates
A failing required gate blocks release unless an authorized owner documents the reason, compensating control, and follow-up.
- Build, type, lint, and automated test checks relevant to the change.
- Dependency, vulnerability, and secret checks where supported by the repository and deployment workflow.
- Targeted verification of permissions, data boundaries, failure handling, and customer-visible behavior.
- Migration and rollback validation for changes that affect persistent data or integrations.
Release and observation
Production releases use an attributable deployment path. The owner confirms required checks, watches health and error signals, and validates the customer-facing result. Riskier changes may use staged exposure, limited rollout, or additional observation before broad availability.
Emergency changes
Emergency work is limited to the smallest safe change needed to reduce harm or restore service. The owner records the incident, validation, decision maker, release, and recovery plan. A retrospective review follows after stabilization, and any temporary control is removed or formalized.
Rollback and recovery
Every material release has a recovery approach appropriate to the change. Options include reverting source, redeploying a known-good build, disabling a feature, restoring configuration, or applying a tested data recovery procedure. Customer impact and data integrity take priority over preserving a release.
Evidence, exceptions, and review
Change evidence is retained in the systems that record source, review, tests, deployment, and incidents. Exceptions must identify an owner, reason, risk, compensating control, and expiration. This process is reviewed after significant incidents and as engineering practices change.