Reference architecture

The reference pipeline describes the transformations of DU-001. This page organizes the responsibilities and information needed to carry them out. It is a logical architecture: its parts can be realized by people, existing tools or software components, and it requires no specific product or infrastructure. It is not a platform design, an infrastructure specification or a product recommendation.

Functions that have to relate

The Software Delivery Engine brings together coordination, execution, evaluation and decisions within the conditions of the service, and the architecture has to preserve those relations when different participants act on the same demand. The unit keeps a recognizable identity, and its artifacts, contracts, commitments and decisions must be relatable without depending only on the memory of whoever did the work.

That continuity is what lets AI prepare relevant information and carry out parts of the route without a full manual reconstruction at every hand-over. Persistent references, bounded access and usable evaluation make it possible to call on prepared capacity across projects. The economic expansion depends on the effort actually avoided and the quality actually kept.

Not everything has to live in one place: code, documents and environment information can stay in their own systems, as long as the relevant content and the conditions in force can be identified. Nor does each function have to be a separate technical service; logical separation clarifies responsibilities, and physical composition depends on context and cost.

Logical view

Consumption interface: conversation, dashboard or assisted interaction
    shows intention, outputs received, offers, choices and delegated decisions
Delivery Unit record
    relates persistent context, contracts, state and references
Commercial information
    separates price, commitment, available authorization and payments
Orchestrator
    coordinates next steps under the conditions and authorizations in force
Execution Policy + Routing
    bound and route work to Execution Resources
Execution
    produces artifacts and information about their result
Evaluation + Quality Gate
    examine evidence and record acceptance or the need for revision
Governance and Commercial Gate
    define authority and the economic decisions that condition the flow

This describes relations, not a single sequence of calls. Governance guides the whole operation, economic decisions may be needed at different moments, and evaluation can send work back to execution or clarification. The Orchestrator uses this information to coordinate, but it gains no technical, business or economic authority just by having access to the records.

Records of the demand and its conditions

The form of each record can vary, as long as the relations and the current situation stay understandable.

Logical record	Content and function
Demand DU-001	Intention, result, limits, dependencies and responsible parties.
Contracts S1 to S5	Inputs, permitted execution, outputs and criteria for each transformation.
Commitments C0 and C1	Authorized economic scope, conditions, revisions and the corresponding decisions.
Artifacts A1 to A5	References to outputs and their revisions, without copying their content.
Evaluations	Criteria examined, evidence, results and limitations, per revision.
Acceptances Q1 to Q5	Acceptance decisions, authority, scope and the evaluation referred to.
Executions	Resources assigned, start conditions, results and relevant attempts.
State and history	The current situation and the events that support its changes.

The codes are local to the example. What must not disappear is the distinction between an output produced, information evaluated and a decision taken.

References in force and history

An update must make both the previous and the new content recognizable. Correcting A3 produces another revision of the implementation; the earlier acceptance stays in the history but does not transfer automatically to the new revision. The state indicates which reference supports continuing, so a change made after evaluation may need checking again before S5, and deploying what was accepted requires identifying that correspondence. The same discipline applies to policies and contracts: an execution is understood against the conditions that guided it. The history does not need every irrelevant action, only the events and decisions needed to understand responsibilities, acceptance and commitment.

Coordination and consistent updates

Participants can report events at different moments. The architecture has to prevent a decision from being applied without considering the reference it belongs to: before changing the situation, coordination checks the demand, the execution or revision affected, and the conditions in force. An old result can be recorded historically without authorizing current progress. Conflicting information needs resolving; if one resource reports completion and another finds a constraint, the operation must not silently pick the more convenient report. The logical requirement is to keep the correspondence between event, basis and change of situation, including when messages are repeated or arrive out of order. The technical mechanism is an implementation choice.

Resources and routing

The description of Execution Resources provides capability, access, availability and limits; an Execution Pool can organize some of them, and dedicated resources are also allowed. Routing uses the Execution Policy and the stage’s conditions to produce an assignment, confirmed against the unit and the work actually taken on. Recording an assignment grants no new permissions over data or environments, and shared resources keep the boundaries between clients’ or units’ contexts. In a hybrid composition, the architecture preserves who produced, who evaluated and who decided, even when one tool presents all of it in a single interface.

Evaluation and decisions

Evaluation receives a reference to an output and the relevant criteria and produces information about fulfilment, divergence or insufficiency; the Quality Gate records the acceptance decision within its authorized scope. Evaluation does not change the economic commitment directly: a finding can support a new estimate or a proposed revision, but the Commercial Gate remains responsible for that decision. In the case, Q2 allows the design to be the basis of the offer for C1 but does not authorize implementation; Q4 supports technical readiness for deployment but does not replace permission to act in production. Authorities can be people or mechanisms with explicit delegation, and the architecture keeps the scope of the delegation verifiable.

External systems and the effects of execution

The integration and the production environment are outside the full control of coordination. In the example, the environment’s authority provides authorized access to the calendar service for validation and deployment; that role may sit with the barbershop or another operator, depending on the agreement, and is not presumed to be unrestricted power of the buyer or the provider. Recording a request for access does not show that access can be used yet. External actions can also have effects without immediate confirmation: if deployment loses its response, the state of the environment must be checked before repeating it, because no confirmation is not the same as a failure with no effects.

Exceptions and interruption

The architecture needs destinations for Retry and Escalation. A new attempt must relate to the previous one, its reason and the conditions that justify continuing. An ambiguous rule is resolved within the existing mandate or routed to the business authority; an extension of commitment to the economic authority; a technical constraint to the competence needed. Requests to pause or cancel have to reach active work, and a unit must not be declared closed while relevant actions have an unknown situation. After an operational interruption of coordination itself, it must be possible to tell what is still active, what finished and which decisions are pending, without assuming all work has to be redone.

Economic information and visibility

Consumption and commitments are related to the demand and the relevant period, with preparation, production, evaluation and correction recorded in the detail economic analysis needs. That does not turn every record into a charge: Unit Economics and Pricing have different purposes, and the cost scenarios of Unit Economics have their own scope, not transferred to this demand. A higher forecast of consumption must reach the right decision when it affects the commitment, without turning an updated calculation into automatic authorization.

The consumption interface

The buyer needs to recognize what has been received and what is still an option. For DU-001, the interface shows the discovery accepted at 20, the booking offer at 80 and the alternative with reminders at 95, and lets the buyer accept the feasible option, ask for adjustment, defer, or close the fulfilled discovery. After accepting 80 under an additional mandate of 90, the record shows an aggregate contracted price of 100, an aggregate authorized ceiling of 110 and an uncommitted balance of 10. Payments, invoices and the provider’s cost are kept in separate fields, and a repeated acceptance message must not increase the commitment or create a duplicate charge.

The interface does not need to expose the composition of each pool. It must make accessible the conditions that affect the buyer’s choice, including dependencies, responsibilities, the possibility of delegating, and the effects of interrupting an active commitment. Self-service requires clarity for decisions and preserved context, not just a screen.

One operation for many demands

The engine keeps the capacity to receive new intentions, form offers and fulfil simultaneous commitments. While DU-001 waits for access in S4, other authorized work can use the available resources, provided reservations, the cost of resuming and promised conditions are recognized. High utilization is not accepted delivery, and resources are not interchangeable without preparation. Resources for discovery can serve a new intention while implementation resources carry out a unit already authorized and evaluation resources examine another; the gain depends on preparing and transferring context at a cost below the benefit of sharing, and AI cycles are the enabling change investigated for widening those situations. Resuming recovers rules, prototype, architecture, revisions, decisions, unfavourable evidence and the commitment in force, but persistent context does not mean handing the whole history to any executor, and clients’ data stay separate even when models, tools and general criteria are shared.

Scale requires watching waiting, quality, interventions, the cost of context and acceptance by class of demand. Generating artifacts quickly can move the constraint to evaluation or external decisions.

Separate authorities

Scope	Example of delegated power	What that power does not grant
Buyer	Choose the offer at 80 within the additional ceiling and stated conditions.	Set the provider’s capacity, price or obligations unilaterally.
Provider	Form the offer, allocate resources, evaluate and fulfil the delivery.	Increase the budget or accept conditions on the buyer’s behalf.
Environment	Authorize action on the accepted revision in the production calendar.	Change the economic commitment or accept any functional result.

A fully autonomous route can combine delegations from all three scopes. Engineering sets references, criteria, access, failure handling and recovery; control does not have to mean a person at every transition. See Mandates.

Proportion and limits

A small operation can perform these functions with documents, decision records and the execution tools it already has; a larger one may need automation and more separation of responsibilities. These relations can also describe human operations that predate AI. The transformation being investigated adds cycles of interpretation, production, evaluation and decision carried out by systems, which could change the cost of providing the service repeatedly. The architecture is independent of vendors but recognizes the enabling role of AI in that hypothesis. Keeping records, integrations and rules costs something, and the logical representation proves neither viability nor adoption.

The state machine develops a concrete slice of the transitions using these references, without requiring them to be tables, services or messages of any particular technology.