Deployment Is Not Acceptance

A deployment proves that a system reached an environment. It does not prove that the change is correct, useful, safe, understood, or accepted. Software supply-chain guidance distinguishes artifact provenance from the later act of verifying that provenance against expectations.²

This distinction sounds obvious until pressure compresses six states into one sentence: “It is done.” The code exists. The build passed. The deployment succeeded. A verifier returned green. Someone glanced at the page. The organization calls the work complete.

Completion Is a State Machine

A responsible delivery system distinguishes at least these states:

1. Task framed and scoped
2. Implementation reported
3. Source reviewed
4. Committed and pushed
5. Deployed
6. Automated verification completed
7. Product or browser QA completed
8. Production behavior confirmed
9. Human owner accepted the result

These states may occur quickly. They must not become conceptually interchangeable. The NIST Secure Software Development Framework likewise separates preparation, protection, production, and vulnerability response; it does not prescribe this product-acceptance sequence.¹

Why AI Makes The Distinction More Important

AI systems produce fluent reports. An implementation agent may explain what it changed, why the change is correct, and which checks passed. That report is useful evidence; it is not source review.

The reviewing system must inspect the actual files, scope, call paths, generated outputs, tests, runtime behavior, and unintended consequences at a depth appropriate to the task. Otherwise, the organization is accepting the model's description of the artifact instead of the artifact.

Confidence is not evidence. A successful action is not a successful outcome. Deployment is not acceptance.

Every Verification Surface Proves Something Different

• Source review proves that the intended code and scope were inspected.
• Compilation proves that the program satisfies a defined set of language and build constraints.
• Automated tests prove that declared behaviors passed under their test conditions.
• Deployment proves that an artifact reached an environment.
• Runtime verification proves selected behavior in that environment.
• Product QA proves that a human-observable experience meets an explicit checklist.
• Acceptance records that the authorized owner accepts the evidence and residual uncertainty.

Deferred QA Needs An Honest Name

Teams sometimes deploy a batch and intentionally postpone product QA. That may be a reasonable tradeoff. The dangerous act is renaming the batch accepted because it is already live.

CPF uses an explicit deployed and QA-deferred state. The record includes what was deployed, why QA was deferred, what remains to be tested, and what blocks acceptance. Honest state lets leadership choose risk; ambiguous state hides it.

Human Acceptance Must Name The Decision

“Human in the loop” is insufficient. Which human? What are they deciding? Which evidence must they review? What uncertainty remains? What authority do they possess? What happens when they reject the result?

Acceptance is meaningful when the answer to those questions is visible. It becomes ceremonial when a person merely clicks approve after automation has already made the consequential decision. NIST's AI Risk Management Framework calls for documented Human oversight and testing before deployment and during operation; the framework is voluntary and does not require every gate listed here for every change.³

Leaders Protect The Meaning Of Done

A team moves faster when it can trust its states. Engineers know what remains. Product leaders know what has been observed. Executives know which risks are accepted. Customers receive fewer confident surprises.

The purpose is not additional ceremony. The purpose is to prevent an attractive status label from outrunning reality.