Skip to content

Producing an output, examining it and accepting it are three different events. The model needs a clear name for the last one: the moment someone or something with authority decides that an output meets the agreed technical or quality conditions, so that “a test passed” and “we have a budget” are never mistaken for that decision.

A Quality Gate is the decision on technical or quality acceptance, distinct from authorization to spend. It uses evaluation to distinguish producing an output from accepting it. For it to work, three things are needed: a reference of criteria, sufficient information, and authority to decide within that scope. The criteria come from the Stage Contract, and the information is the Evidence the evaluation interpreted.

The decision can be human or automated, according to the authority and the applicable criteria. It does not require a human stop or a meeting at every stage.

Not to be confused with The difference
Evaluation Evaluation examines outputs and evidence against criteria. The Quality Gate is the decision that follows. A completed check is not an acceptance.
Commercial Gate The Commercial Gate decides on the economic commitment to continue. An accepted design may support an offer without authorizing implementation, and an available budget cannot make an inadequate output acceptable.
Permission to change production An accepted implementation may still need authorized deployment. Operational permission belongs to whoever is responsible for the environment.
The whole commitment Accepting an output settles one question defined by the contract. It does not complete the Delivery Unit’s full commitment.

If AI makes outputs cheaper to produce, the decision about which outputs are adequate becomes a larger share of the work. A Quality Gate that can operate as an automated decision within a mandate, with clear criteria and relevant evidence, lets acceptance keep pace with production without a human approval at every step. Its value depends on the quality of that decision, including wrong acceptances and wrong rejections, not on its speed.

The gate needs a reference of criteria to decide against, information sufficient for the decision, and authority for that scope. Automating the gate in bounded conditions does not widen the scope of the criteria and does not remove the need to recognize exceptions. When the evaluation points out limitations, the authority has to recognize whether they are compatible with the contract, call for more information, or require a legitimate revision of the conditions. The mechanism must not hide a limitation to simplify the result.

Acceptance shows that the stage’s conditions were met within the scope of the evaluation. It does not prove that no unknown problem exists. Acceptance can be partial if the contract allows it, and then its scope and pending items stay visible so that the rest is not considered done by association. An earlier acceptance can remain valid in its context and stop supporting the current situation after a relevant change; the Delivery State must show when a new evaluation is needed.

Who evaluates and who accepts can be the same person or system, but that should not be assumed. The Execution Policy and Governance define competence and authority. The Stage Contract indicates the authority that accepts, as well as the criteria, and no executor is presumed able to approve its own output. When the gate is an automated decision, it is exercised under a mandate like any other delegated authority.

Accepting an output gives coordination a reference for deciding what happens next; it does not grant authorization for further consumption. A technical acceptance can support a proposal to continue while budget or scope still await decision. Orchestration receives the decision and works out its consequences for the flow. If the gate does not accept, the reason determines what follows: correction, more evidence, clarification of an ambiguous criterion, or Escalation.

In the barbershop case, each stage has its own acceptance: Q1 accepts the clarified rules, Q2 the design as a basis for continuing, Q3 the implementation within its local scope, Q4 the integrated behaviour, and Q5 the deployment.

Q2 accepts the design for its purpose. It does not authorize implementation: that takes the Commercial Gate, where the barbershop chooses booking at 80. During integrated validation, evaluation finds two overlapping confirmations for the same professional, and Q4 is not granted. The rule is not redefined to accept the defect; the implementation is corrected and evaluated again, and only then is Q4 granted, on evidence covering duration, overlap, the boundary between bookings, different professionals, cancellation, repeated requests and the identified revision and environment. Q4 does not, on its own, grant permission to change production: S5 still needs a valid operational authorization. The criteria are listed in the example Delivery Unit.

Acceptance is not benefit. An accepted booking capability does not show that the barbershop will spend less time coordinating appointments. Business effects are observed later, separately.

A gate that cannot say no is not a gate. If criteria are revised after an unfavourable evaluation just to accept the output, or if a gate records approvals that were never in doubt, it offers little to the decision. Conditions must not be changed only to declare success.

Automation does not make it right. An automated gate is only as good as its criteria and the evidence it receives. Agreement between systems, or a completed automated check, does not automatically establish sufficient evidence.

Software Delivery as a Service is a proposed model by Renan Deves and Marcelo Scheidt, Independent Researchers. See the paper for citation and license.