Software Delivery Engine

The question this section answers: how are the units, conditions and information of the structures put to work, so that a provider can receive new intentions, carry out purchased advances and produce information for later offers, again and again?

Definition and role

The Software Delivery Engine is the coordinated set of functions, resources and mechanisms that carries Delivery Units through transformations with explicit conditions. It keeps the relation between the work done, the outputs produced, the evidence available and the commitments that allow work to continue. The model does not claim to coin the term.

“Delivery operating system” here means the organization of how the service runs. It does not mean a computer operating system, and it does not require a single software product. An implementation can combine people, procedures and different tools. One person developing for another can perform many of these functions directly; in an operation with many demands they may be distributed. Scale changes the complexity of the implementation, not the definition.

The engine is not limited to routing the tasks of an isolated project. It links recurring service with the commitments of each demand: it keeps capacity to receive new intentions, carry out the advances that were bought, and produce the information that supports the next offer.

Why it matters for the hypothesis

The enabling change is that AI could reduce the effort of interpreting an intention, trying alternatives, preparing context, producing, evaluating and deciding. The engine organizes that capability into reusable cycles, so that preparing a small delivery and its next offer need not consume an economically prohibitive share of the service. The operational change supports the commercial one: offering frequent choices requires being able to produce and fulfil them at a compatible cost.

The same general architecture also describes a human operation. What is being investigated is the economic boundary these cycles could shift, including varied demands that would otherwise need costly preparation of their own. Engineering brings context, tools, criteria and recovery together to make that capability usable. Hybrid operation and full autonomy within a mandate are both possible configurations; either must sustain the whole route.

What goes in and what can come out

The input is a demand tracked as a Delivery Unit, with the understanding available and the scope authorized. The whole solution need not be defined before starting; a first commitment can cover only clarification or analysis.

Outputs depend on that commitment. They can be a deployed change, an accepted specification, or a well-founded conclusion that something is not viable. The engine must tell these apart and never present a concluded exploration as software in production. Waiting, revision or interruption are also outcomes of coordination: they are not accepted deliveries, but they are part of the operation, and a service that cannot continue under the available conditions has to represent that and route the decision needed.

The external boundary includes the person asking, the provider and the relevant dependencies. The engine coordinates what is within its reach and recognizes what depends on other authorities or systems. Representing a dependency does not mean controlling it.

Capabilities it needs

The table organizes the main functions without imposing software modules or departments.

Capability	Operational responsibility
Keep the demand’s context	Relate intention, constraints, commitments and current decisions.
Carry out transformations	Recognize available inputs and apply the conditions of the stages.
Mobilize execution	Identify eligible, available resources and route work to them.
Evaluate outputs	Produce and interpret information relevant to the acceptance criteria.
Coordinate continuity	Recognize returns, dependencies, authorizations and conditions for closing.
Handle exceptions	Tell correction, a new attempt, clarification and a decision beyond the available authority apart.
Preserve responsibility	Keep identifiable who answers and who can decide.

Functions can be concentrated or distributed. What must be verifiable is how they fit together. If a resource finishes its work, someone or something has to recognize the result and have it evaluated, without assuming that finishing execution already means acceptance.

How the parts fit

The pages in this section each develop one responsibility:

• Orchestration coordinates the flow. The Orchestrator relates state, conditions and events to route the next permitted step. The engine includes that function, and also the resources, evaluations and mechanisms that do the work, so coordinating is never the same as producing everything or holding every authority.
• Execution Resources describe the usable capacity: people, agents and arrangements.
• The Execution Policy sets the rules for eligibility, selection, autonomy and supervision.
• Execution Pools organize capacity shared across demands. They are optional; dedicated resources remain valid.
• Routing applies the policy to concrete resources. It cannot make exceptions to the policy on its own.
• Evaluation examines outputs, and the Quality Gate makes the acceptance decision.
• Retry and Escalation handle exceptions.
• Governance defines authorities and responsibilities, and Mandates looks at delegated authority across all of them.

The reference architecture shows one logical composition of these functions for a concrete case.

The Stage Contract defines the conditions of a transformation and references the Execution Policy. The Commercial Gate remains a separate economic decision. Orchestration coordinates all of these within the limits of Governance.

Separating conditions, choices and execution

Keeping the stage’s conditions, the choice of executor and the execution itself apart makes it possible to change how work is done without silently changing the expected result, and to recognize when a change needs a new evaluation or authorization. Choosing a different resource does not remove the demand’s constraints. Being able to call a tool does not show that it suits the work or is authorized to act on the systems involved.

Acceptance and commitment are distinct decisions too. A Quality Gate decides on technical or quality acceptance; a Commercial Gate decides on the economic commitment to continue. An accepted alternative may still await authorization for implementation. The engine must respect commitments that span several stages: it does not need to charge or renegotiate at every transformation, but it must recognize when work stays covered by the current agreement and when it needs another decision. The information it produces feeds Progressive Estimation and Progressive Commitment.

Working under change and failure

The route need not be linear. An evaluation can reveal an incompatibility, a dependency can become unavailable, a rule can change during implementation. The engine relates these events to the outputs and commitments they affect. A failure does not automatically call for a new attempt: it may need correction, clarification, or a decision by a different authority. If an execution ends without its result being confirmed, repeating it at once can duplicate work or cause unwanted effects, so the engine must establish what happened before assuming nothing was done.

In the running example

The barbershop buys discovery. The engine keeps the intention and mobilizes resources to clarify the rules, produce a prototype and examine the integration. The accepted outputs support an offer to build, which the customer chooses directly or through a delegated decision, and the operation recognizes the authorized scope before mobilizing the corresponding production. During construction an executor prepares the implementation, evaluation finds a conflict between times, and the correction is evaluated again. That cycle can be human, hybrid or autonomous. A valid automatic decision does not need extra human confirmation by definition of the model.

While one request is in discovery, another can be in construction and a third in evaluation. The service uses resources and configurations kept for these functions across projects, and AI can prepare part of the context so that each hand-over needs less manual reconstruction. Context and access for each demand are still prepared separately: shared capacity does not authorize mixing data or commitments. If the barbershop stops after discovery, the engine concludes that commitment and preserves the outputs as agreed. That is not a failure, and its cost stays in the analysis of the operation.

Boundaries and cost

The engine consumes resources to coordinate, record, evaluate and handle exceptions, and these costs have to be counted alongside productive execution. Automating an activity can reduce its effort and still increase the cost of preparation or review. An implementation can also concentrate waiting in evaluation or authorization: more capacity to produce outputs does not guarantee more accepted deliveries.

This organization is meant to make those relations analysable. It does not show that total cost will be lower. It does not require its own platform, a fixed price list or full autonomy; those are implementation choices, not hidden conditions of the definition. Its viability depends on sufficient context, useful evaluations, recognizable authority and sustainable costs, which remain questions of application and research.