Changes are “live” when enabled and outcomes are confirmed

What this means in practice

Teams separate deploying code from releasing functionality. A change can be deployed safely and repeatedly without making it visible to users until the team explicitly enables it.

This keeps delivery incremental and low risk. It also creates space for controlled rollouts, fast rollback, and learning from real usage before committing to a full release.

Why this matters

Treating deployment and go-live as the same event increases risk and pressure. Decoupling them reduces blast radius, improves predictability, and supports faster iteration without compromising safety.

Practices that meet this principle

• Feature flags used to control exposure and enable quick rollback

• Progressive delivery, such as percentage rollouts and canary releases

• A/B testing and experimentation where appropriate

• Pipelines designed so deployments are routine and repeatable

• Clear feedback loops, including monitoring, user feedback, and metrics

Validation

A project meets this principle when:

• Code can be deployed without immediately changing user-visible behaviour

• A mechanism exists to enable and disable features independently of deployment

• The team can roll out changes gradually and measure impact

• Rollback is possible without requiring emergency changes