Release integrity means that what reaches users is what the team intended to reach them, in the scope, at the pace, and with the effect the team planned. The term borrows from data integrity, where a system earns trust when the record that comes out matches the record that went in. For a release, the record going in is the intent behind a change, and the record coming out is what users experience after deployment.
A software factory, where AI writes more of the code every day, can produce changes faster than a team can plan each release by hand, and much of the factory's design goes into making sure each change is the right one. Release integrity covers the stretch that follows, from deployment through exposure and validation, when the team needs to know that users received the change as intended.
Factories write intent down early
A well-built factory records intent at nearly every step before deployment. An issue states the goal, the constraints, and what “done” means. A plan describes the approach and the files it will touch, and a person may approve that approach before any code exists. Tests encode expected behavior, and code review confirms that the PR does what the plan said it would. By the time a change merges, the factory has a written record of what the change is supposed to accomplish.
That record describes what the change should do. It says little about who should get the change first, how quickly exposure should grow, what result would show the change is working, or what should happen if it isn't.
Some factories extend past merge with smoke checks or automated reverts, which can catch failures after deployment. But a change can pass those checks without reaching the intended audience or producing the intended result. Someone still has to make the release decisions, and the intent recorded upstream often never reaches the systems that carry them out.
Without a release plan, defaults decide
When a change reaches production without an explicit release plan, the team's existing deployment configuration and operating practices determine what happens next. For many teams, that means the new behavior reaches everyone the deployment serves, service health metrics provide the main measure of success, and reversing the change requires another deployment.
Those defaults suit some changes but erode integrity when they differ from what the team intended. For instance, a feature meant for one market might reach every user the deployment serves, or a change intended to ramp over a week might hit full exposure within minutes. And a change can run without errors but produce the wrong result, since service health metrics can’t show whether it did what it was meant to.
The deployment can pass its checks in all three cases because those checks don't verify whether the release followed the original plan.
Four questions to carry intent forward
A release plan connects the intent recorded during development to the decisions that govern what happens in production. Four questions help establish that connection:
- What is the risk level of the change? Assess what the change touches and how a failure could affect users. A text fix and a change to permission handling can share a deployment pipeline but need different levels of release control.
- How should the change roll out? Decide who should receive the change first and how quickly exposure should expand. Some changes can reach everyone immediately, while others need a narrower audience or a gradual rollout.
- What should the outcome be? Choose metrics that reflect what the change was meant to accomplish for the users exposed to it. Those signals help the team evaluate the change's behavior alongside the service health metrics it already monitors.
- How should the change be reversed, if necessary? Establish what should trigger a pause or rollback and how the team will respond. For behavior controlled by a feature flag, disabling the flag can stop further exposure without another deployment. Changes that can’t be isolated that way need an appropriate rollback or recovery procedure.
The answers to these questions establish what a responsible release looks like for a particular change. The resulting plan may be simple or involved, depending on the risk and intended outcome.
The challenge for a software factory is making sure that assessment happens consistently across the changes it produces.
Make the assessment repeatable
Teams often give their most visible changes careful release plans and close monitoring. Routine changes, by contrast, may get less attention after merge. If release planning depends on someone recognizing which changes deserve special treatment, less visible risks can pass through without the same assessment.
Consistency still leaves room for proportion. A low-risk change may be suitable for immediate exposure, while a change to critical behavior might need a limited rollout and closer monitoring. Both decisions should follow the same risk criteria.
Engineers can define those criteria in policy so routine release decisions follow agreed rules and higher-risk decisions receive additional review. This gives the factory a repeatable way to assess changes without requiring someone to design every release plan from scratch.
For that assessment to become part of the workflow, it needs to happen while the purpose of each change is still available, before the code moves into deployment.
Start the release plan at review
The PR is the last place where a change's intent and implementation sit side by side. That makes it a natural point to decide how the change should reach users.
In this model, each change gets a release plan during review, and engineers define the broader guardrails in policy. Those guardrails establish how changes should be introduced, what production signals matter, and when a rollout should stop.
Our engineering teams at LaunchDarkly have been using Release Autopilot internally for months to put this approach to release planning into practice. We learned a lot from using it ourselves, and that shaped how it works. It will be generally available later this month (select features available in beta).
Integrity extends the factory past deploy
A successful deployment confirms that code reached production. Release integrity asks whether the intended users received the change, whether exposure expanded at the planned pace, and whether the result matched what the team set out to accomplish.
A software factory already captures much of that intent during development. Carrying it into release planning gives teams a way to verify that what happens in production matches those earlier decisions. Every team builds its factory its own way. What release integrity requires underneath it is control in production, at the change level, so the factory stays safe to run however it’s organized. Without that connection, a deployment can succeed while the first evidence of a mismatch comes from the users the change was meant to serve.
