Does your approval still cover the software you deploy?

Consider a hypothetical release that clears every automated check on Tuesday. The pipeline is green, the rollback is rehearsed, and the on-call schedule covers the rollout window. The change then waits for the fortnightly approval meeting. By Friday, the approval record shows that permission was granted. It says little about what the deployment contained by then, or which safety checks still held when the pipeline ran.

The waiting belongs in the delivery lead time, but the more specific question is what changed during it. If the artifact and its relevant environment remain fixed, the approval may still apply. If they change, a green approval record can conceal a mismatch.

A software change approval process should make clear which artifact and conditions were approved, then verify that deployment still matches them. This is a practical design proposal, not an intervention established by the studies below.

What the evidence supports, and where it stops

Start with the direct observation. Lwakatare et al. (2019) studied five companies with working DevOps practices and reported that deployment speed was affected by context factors, including manual product-owner approval, while deployment toolchain support and shared team ownership went with faster delivery. Read this carefully: it is a multiple case study, not an experiment. Approval appears as one context factor in a cross-case analysis, and the study does not isolate its contribution to delay from everything else happening in those companies. Five companies also means five situations, not five independent replications of an effect.

One plausible explanation is that a manual decision introduces waiting where automated checks otherwise complete quickly. The case study does not establish that particular scheduling explanation across the companies. It gives a reason to inspect the local approval path, not permission to assume that every approval causes avoidable delay.

The systematic reviews describe the other side of the trade. Shahin et al. (2017) synthesized continuous integration, delivery, and deployment research and found recurring benefits: shorter build and test times, better visibility of build and test results, earlier fault detection, and more dependable deployment. Soares et al. (2022) synthesized 101 primary studies on continuous integration and found support for faster feedback and quality benefits, while heterogeneous definitions and methods across studies make universal effect claims unsafe. Neither review hands you a number for your context, and both describe limits: test quality, architecture, skills, and culture still constrain what automation delivers.

An approval attests to a version, not to a release

An approval may examine a specific artifact, configuration, dependency set, or rollout plan. A well-designed process keeps that scope attached to the release. Where it does not, later merges or configuration changes can separate what was reviewed from what gets deployed.

Elapsed time alone does not prove that an approval has become invalid. An immutable artifact may remain unchanged for weeks. A new configuration can change the risk within minutes. The useful question is whether any assumption relevant to the approval has changed, not whether an arbitrary expiry date has passed.

Repeated automated checks can provide updated evidence about the artifact they actually examine. They still have limits: tests may omit important behavior, a staging environment may differ from production, and a passing result does not prove safety. A recorded approval also has value when its scope and conditions remain valid. The proposal is to preserve the connection between these controls, rather than assuming that either can replace the other.

The scope split matters for governance, so let me label it plainly. That approval and deployment are governed by different questions is my framing, not a research finding. The evidence supports a narrower set of ingredients: manual approval appears as a deployment context factor, review votes have social associations, and continuous practices offer feedback benefits with important limits. No study in this set tests evidence-freshness checks at approval gates. What follows is a design proposal built on those mechanisms, offered as something worth testing rather than something proven.

Peer review is useful, and it is not an oracle

Human review has its own record. Thongtanunam and Hassan (2021) examined review dynamics across 83,750 patches in the OpenStack and Qt projects. The amount of prior feedback and how often a reviewer had collaborated with the patch author were strongly associated with positive votes, while patch characteristics and overall review activity were the stronger correlates of defect-proneness. In plain terms, review adds situated judgment, and it also inherits relationships. For approval design, this supports caution about treating a positive vote as a complete account of quality. It does not demonstrate that reviewer memory decays with queue time or that old approvals are necessarily wrong. Those claims would require evidence beyond this study.

Freshness here means checking the continued validity of the reviewed scope. It does not mean replacing informed judgment with a timestamp.

A design proposal: make evidence freshness explicit at the gate

Pick one change class and write three rules for its approval record:

1. Record what the approval covered. Not "approved," but which version, which checks ran, and until when the judgment is intended to hold. 2. Re-verify what changed since. Define a bound: if the diff since approval exceeds it, or a required check no longer passes, the approval re-opens. A freeze window is one option. Another is checking artifact identity and re-running relevant checks at deploy time. Choose based on the risks the control is intended to address. 3. Split the questions. Approval owns whether this change may go out. Deploy-time checks own whether the thing that goes out still matches what was approved.

In a hypothetical database migration, a changed schema assumption could matter even when deployment follows approval within hours. The same artifact deployed later might still meet every condition. Compare the artifact identity, configuration, and relevant check results rather than treating either interval as safe by definition.

Keep what regulation demands. Some regulated settings require documented approval or separation of duties. Preserve the requirements that apply to your system. The freshness question still applies: a signature on a version that did not ship documents less than it appears to.

Measure the queue before you move the gate

Start with a retrospective check of one change class. Compare the artifact and conditions recorded at approval with those present at deployment. Count unexplained mismatches and checks that no longer applied, alongside approval waiting time. This can reveal a control gap without changing production policy.

If you then trial a change, agree the scope, required safeguards, and stop conditions with the responsible owners. A before-and-after comparison of rollbacks and escaped defects is useful monitoring, not proof of causation: workload, release mix, and rare failures can obscure the effect. Investigate adverse outcomes before extending the trial; do not assume that an increase in failures has a single explanation.

The next approval record should let another person answer a concrete question: what exactly was approved, and what evidence shows that the deployment still matches it?

References

Lwakatare, L. E., Kilamo, T., Karvonen, T., Sauvola, T., Heikkilä, V., Itkonen, J., Kuvaja, P., Mikkonen, T., Oivo, M., & Lassenius, C. (2019). DevOps in practice: A multiple case study of five companies. Information and Software Technology, 114, 217–230. https://doi.org/10.1016/j.infsof.2019.06.010

Shahin, M., Ali Babar, M., & Zhu, L. (2017). Continuous integration, delivery and deployment: a systematic review on approaches, tools, challenges and practices. IEEE Access, 5, 3909–3943. https://doi.org/10.1109/access.2017.2685629

Soares, E., Sizilio, G., Santos, J., da Costa, D. A., & Kulesza, U. (2022). The effects of continuous integration on software development: a systematic literature review. Empirical Software Engineering, 27(3), Article 78. https://doi.org/10.1007/s10664-021-10114-1

Thongtanunam, P., & Hassan, A. E. (2021). Review dynamics and their impact on software quality. IEEE Transactions on Software Engineering, 47(12), 2698–2712. https://doi.org/10.1109/tse.2020.2964660

AI disclosure: AI was used to help create this article. Responsibility for the published content remains with Nico Thümler.