Skip to content

Before comparing who is fastest or cheapest, someone has to know who is allowed to do the work at all, what they may decide on their own, and what has to be checked. Without explicit rules, speed quietly compensates for a missing authorization, and “use the best resource” becomes a choice nobody can explain afterwards.

An Execution Policy gathers the rules for the eligibility, selection, autonomy and supervision of execution, within the authority and scope of decision that have been delegated. It determines under what conditions a resource may take part in the work and which limits guide its action, so that an admissible choice can be recognized before convenience, speed or cost are compared.

A policy can cover competences, access, autonomy, supervision and the evaluation required. It applies in the context of a demand and a stage: a rule suitable for exploration can be insufficient for a change headed to production. It can be written simply and applied by a person, or represented in automated mechanisms; what matters is that its conditions are understandable and actually affect execution. It does not replace the expected result: choosing a resource according to the policy does not show it will produce an adequate output, so evaluation is still needed.

Separating the policy from the definition of the delivery is what lets human, hybrid and autonomous execution be judged against the same expected result, without changing what was contracted.

Because systems can interpret context and carry out cycles of work, it becomes useful to define in advance the scope within which they may act. The policy turns that capability into usable autonomy, reducing the need to reopen every routine decision. That can lower the cost of serving small, recurring commitments. It does not require every demand to be autonomous.

Eligibility covers the conditions a resource must meet to be allowed to do the work. Preference guides the choice between admissible alternatives. A resource without authorized access can be ineligible for an action even if it is technically capable or cheaper. Among eligible resources, availability, context, continuity or expected cost may matter. A speed advantage does not compensate for a missing authorization. When a condition cannot be met, the options are another composition, waiting, or routing an authorized review. The policy should make clear which conditions are mandatory and which allow choice.

Coverage follows the context; not every item applies at every stage.

Dimension Guiding question
Eligibility Which capabilities and conditions are needed to take part?
Access Which information, tools and environments may be used?
Selection Among admissible alternatives, which criteria guide the choice?
Autonomy Which actions and decisions can be taken without new authorization?
Supervision What follow-up or intervention is needed during the work?
Evaluation Which checks and authorities are required to accept the output?
Exceptions When must execution stop or route a question?
Consumption Which limits on effort, attempts or expense apply?

The policy should state its scope and the reference in force. Repeating rules in full in every contract can create divergence; pointing to an undefined policy does not make it applicable either.

Autonomy is described by the actions and decisions permitted, and the limits need not be the same across functions. A resource can carry out implementation and correction without being able to widen the contracted scope. Another can choose a continuation within a ceiling without permission to change the production environment. A policy can allow contextual judgment: a delegated authority can compare alternatives and pick a solution consistent with objectives and conditions, not just execute deterministic rules. The mandate must make it possible to recognize when a choice falls within that scope and when it needs another decision.

A demand can run entirely autonomously: clarifying within the available context, producing, evaluating, correcting, deciding to continue and deploying under the relevant authorizations. That requires the necessary mandates to exist and their conditions to be met, and engineering remains responsible for designing and maintaining those controls. A hybrid configuration can also deliver the service. The policy should represent both explicitly, without imposing universal human approval and without treating technical capability as unrestricted authority. Revocation, revision and the effects of actions in progress must remain manageable.

Technical autonomy is not purchasing authority. A system that can build an alternative has not thereby been authorized to buy it, and a buyer’s authority to spend does not let the provider act in production. How these separate authorities are delegated is covered in Mandates.

Supervision follows execution and may intervene during the work. Evaluation examines the output against the relevant criteria. They can complement each other but are not equivalent. The composition should be justified by the work and the risk, not by the type of executor. Human participation needs a clear purpose: asking someone to approve every output without context or time does not, by itself, establish meaningful evaluation. Where there is automated verification, what it allows one to conclude must be bounded, and the Quality Gate can use that information without extending it to conditions nobody examined.

Relation to contracts, routing and governance

Section titled “Relation to contracts, routing and governance”

The Stage Contract references the applicable policy. Routing uses it to choose and assign concrete resources. Governance establishes who may define, change or make exceptions to the rules. These boundaries locate a divergence: if an eligible resource is unavailable, the problem may be capacity; if the policy excludes every viable composition, conditions may need review by a competent authority. Routing must not resolve that by ignoring the rule. When rules conflict, execution needs a precedence rule or a decision; silently picking the most convenient rule makes the action’s legitimacy impossible to understand.

A policy can change in response to new information, constraints or evaluation results. The change needs an identifiable authority, scope and reference. Work in progress deserves attention of its own: a new rule may call for interruption, adaptation or extra evaluation; it neither affects only future executions nor invalidates everything done before. It must be possible to see which policy guided each relevant execution, or a divergence may be blamed on the resource when it came from a later change. An exception limited to one demand or action stays limited; reusing it needs a new decision or a formal revision.

At the barbershop, booking keeps the same expected behaviour under different policies. The table is illustrative, not a set of universal maturity levels.

Dimension A possible hybrid configuration A possible autonomous configuration
Production and correction Agents execute, with a professional involved in the decisions indicated. Systems carry out attempts and corrections within the contract.
Evaluation and acceptance Automated checks combined with planned human review. Authorized evaluators and acceptance mechanism use the relevant criteria and evidence.
Technical choice A professional decides the alternatives the policy reserved for them. A system chooses alternatives within the delegated objectives and limits.
Economic continuation The customer or a representative decides on the offer. A delegated authority checks offer and mandate, including scope and ceiling.
Deployment The action depends on the defined operational permission. A prior applicable permission allows executing and confirming deployment.
Exception Routed to the competence or authority needed. Another system may resolve it; if it cannot, the planned suspension or routing applies.

The buyer’s policy for authorizing spending does not oblige the provider to accept terms it did not offer. If the integration requires a choice outside the mandate, a system gains no new authority by being able to implement the alternative; it can investigate or propose a review according to its policy.

Following a policy is not the same as succeeding. Rules do not foresee every situation and do not replace evaluation and judgment. Having no eligible alternative is a legitimate outcome: there is no need to pick a resource at any cost to show the system is still running. Waiting, clarifying or stopping can be the right decision.

Policies have their own cost. Restrictions can increase waiting; broad permissions can increase the need to handle unexpected results. Numerous, contradictory or out-of-date rules make execution harder and invite differing interpretations, so governance must allow their usefulness to be reviewed. The operational hypothesis is that explicit conditions allow choices that are easier to understand and control; the advantage over informal agreements depends on context and must be evaluated, including the cost of writing and applying them.

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