Delivery State

What question does this solve?

“In progress” may be enough in a brief conversation, but it does not say whether work remains to be done, an output is awaiting evaluation, a dependency is unresolved or an authorization is missing. Those differences matter to whoever has to act next and to the commitments involved.

Definition and role

The Delivery State is the representation of a Delivery Unit’s current situation. It relates what has already happened to what allows or prevents moving on, and it must be useful for deciding, not only for describing activity.

It does not need to reproduce the whole history or content of the demand. It needs to offer a current view that can be related to the records supporting it. The representation can be simple or made of several pieces of information. The model imposes no universal set of labels, no board and no tool; the choice must preserve the distinctions needed to carry the work forward.

State, stage and history are different things. A Delivery Stage is a transformation; the Delivery State is the situation of the demand. Being in an implementation stage does not say whether execution is active, waiting for access, or finished with an output awaiting evaluation. History records past events and decisions; the state expresses the current understanding derived from them. An output accepted earlier may need re-evaluating after a relevant change, and history makes that evolution understandable without treating the old acceptance as enough. A stage can be complete while the unit waits for authorization to continue, and in parallel work one transformation can be blocked while another is authorized to proceed.

Why it matters for the hypothesis

Persistence and resumption matter when a cycle crosses resources or sessions. Resuming is a condition for taking advantage of faster cycles and capacity shared across demands: if a pool receives part of the work, it has to identify what it can execute without redoing the earlier investigation. AI can help gather and interpret the state, but inferred information does not replace confirmed events or authorizations. The economics of continuity depend on reducing reconstruction and repetition while keeping that reliability.

How it works

Dimensions of the situation

The representation should answer the questions needed to decide the next step. These dimensions guide the reading; they are not mandatory fields or standard states.

Dimension	Question to answer
Understanding	Are the result and its conditions clear enough for the authorized work?
Execution	What work has been done, and which transformation is under way or ready to start?
Evaluation	Which outputs have been evaluated, accepted, or need revision?
Dependencies	What depends on access, information, a decision or an external delivery?
Authorization	Which work can continue within the current commitments?
Closure	Have the conditions of the commitment been met, or was there a decision to stop?

These dimensions can coexist. An output can be technically accepted while continuing still lacks economic authorization. Part of a demand can be under way while another part waits on a dependency. A summary label is useful as long as it does not hide a decisive condition.

Changes backed by events and decisions

A change of state should correspond to something recognizable: an input became available, an execution produced an output, an evaluation finished, or an authority decided about continuing. Recording activity is not enough to justify any transition. Producing code can support the information that an output exists, not that it was accepted. A favourable evaluation can support technical acceptance, not additional spending.

The conditions in the Stage Contract help identify which events are relevant; Evidence supports the conclusion of an evaluation; identifiable decisions establish what was accepted or authorized. The record should also separate an event from its interpretation: a tool can report that a check finished, but concluding that its conditions were met requires considering its result and scope.

Waiting, blocking and who acts next

Waiting can have different causes. Lack of capacity, a missing input, an unavailable environment and a needed authorization are not the same problem. The state should make clear the obstacle, the work it affects and who can deal with it. It need not always forecast a resolution: when the time is unknown, the representation should keep that uncertainty.

A dependency may block only part of the demand. If integration testing is waiting for access, other authorized work may still be possible; the state should suggest neither total stoppage nor unrestricted progress. Identifying who owns the next step does not remove responsibility for the delivery. A provider may depend on a decision by the buyer and still be responsible for explaining its effects on execution and commitment, without the state becoming a way of assigning blame.

Revisions and resuming

A change of context may require revising a situation that was already recognized. The representation should distinguish an error in an earlier evaluation from a later change in the conditions: both may call for rework, but they explain different situations and can affect commitments differently. Resuming work requires checking the conditions in force. An earlier authorization may have a limited scope, an input may be out of date, a dependency may have changed. The state should not assume everything stayed valid during a pause.

Updates by people and systems

People, agents and tools can all produce information relevant to the state. Producing it does not grant authority to declare any state: an execution can report that it finished its work without being able to accept the output or authorize the next transformation. The Execution Policy and Governance establish which updates can be made and under what conditions, and Flow coordination relates events to the situation of the demand.

Conflicting or incomplete information needs explicit treatment. If an evaluation has not been recorded yet, the absence of a record must not be turned into acceptance or rejection automatically. A system that resumes work has to use the recorded references to choose the next step, and must not repeat an action merely because it did not execute it in the current session.

In the running example

For the customer, the same situation should distinguish an advance received, an offer available, a part authorized and an alternative deferred. The economic view can refer to the contracted price, the ceiling and the authorized balance without confusing them with cost or payment, and it need not expose the whole technical history.

Event	Recognizable situation	Limit of the conclusion
Discovery accepted	First advance received; a later offer can be prepared.	Construction not yet authorized.
Booking offer chosen	Scope and conditions of construction assumed.	Reminders and payment remain out unless explicitly decided.
Execution resumed by another resource	Context, revisions and confirmed actions recognized.	Earlier results must not be repeated without examining their effects.
Divergence found	Correction or clarification needed within the relevant scope.	The whole demand is not necessarily blocked.
Evaluation and deployment confirmed	The corresponding conditions have been met.	The benefit of fewer missed appointments still depends on observation.

A delegated decision can produce the authorization to build. The state records its authority and conditions in the same way it records a human decision, and tracking does not wait for an extra confirmation the mandate does not require. If only discovery was contracted and fulfilled, closure should say so; if construction was contracted, an accepted intermediate output is not enough to conclude it.

Boundaries and failure modes

Technical acceptance is not economic authorization. The state should show the scope authorized through Progressive Commitment. The Commercial Gate can produce the decision to continue, revise or stop; that decision stays distinct from the technical acceptance of a Quality Gate. They can happen close together, but they are not the same event.

Closing is not the same as stopping. Closing a unit depends on its commitment. If the authorized result was an analysis, its acceptance can conclude the work. If it included deployment to production, an accepted implementation may still leave conditions pending. An interruption can end execution without a full delivery, so the state must distinguish meeting the commitment, cancellation, and an exploration that concluded with a negative result.

Detail has a cost, and records can be wrong. A detailed representation can become hard to maintain; one that is too simple can hide decisive conditions. A filled-in field does not prove the real situation matches it, and explicit states do not create predictability: knowing about a blockage makes it visible, not quick to resolve. The right granularity, how to aggregate situations in parallel flows and how to handle divergent information remain open. The illustrated situations are not a definitive state machine and assume no specific tool; one concrete possibility for the barbershop case is the reference state machine, itself an illustration rather than a norm.

Connected concepts

• Structures overview
• Previous: Stage Contract, the conditions that make events relevant
• Next: Artifacts, what the work produces
• Evidence, what supports the decisions the state reflects
• State machine, a concrete illustration for the barbershop case
• Glossary