Delivery Unit

What question does this solve?

A single demand produces many records. A conversation clarifies the intention, a document describes rules, an implementation changes the system, an evaluation finds a divergence. To carry the delivery forward, someone has to understand how all of this relates: which result is being pursued, which conditions are in force, what has already been accepted, and what still prevents progress.

Definition and role

A Delivery Unit is the tracking unit for a bounded demand whose understanding, progress and commitments can be followed individually. It may have dependencies. It relates what someone intends to receive to the work done to produce and evaluate that result.

A unit can represent a new capability, a correction, an integration, or a bounded intermediate delivery such as a feasibility analysis. It has no fixed size and no predetermined number of activities. A vague intention can give rise to a unit, and at that point the commitment may cover nothing more than clarifying it. Recording a demand does not mean its implementation has been authorized, that its scope is complete, or that there is a well-founded estimate for the whole delivery.

Its identity lets everyone recognize that specifications, decisions, code and evaluations refer to the same demand. That link must remain understandable when the understanding changes or when different resources take part in the work.

The model does not require a new system or a new ticket format. Existing tools and records can perform this function. What it requires is that tracking represents the demand and its decisions precisely enough to guide the work.

Why it matters for the hypothesis

If AI makes learning and execution faster, continuity becomes economically important. Speed is worth little if each new participant must reconstruct the intention, the criteria and the commitment. The Delivery Unit is the reference from which usable context is prepared for people, agents and pools. Keeping it up to date must cost less than the reconstruction effort and the errors it is meant to prevent.

How it works

Bounding by result and by the decisions needed

A unit should be bounded so that a result can be discussed and its acceptance conditions recognized. A unit that is too broad bundles commitments that need different decisions. A unit that is too fragmented loses the sense of the delivery and multiplies dependencies.

If AI lowers the effort of clarifying, coordinating and evaluating, smaller advances may come to justify their own tracking and decision. The economically useful size still depends on context. Generating tasks easily does not make every fragment a useful purchase, and it does not remove the cost of integrating the fragment into the result.

Suppose someone asks for a way to follow requests. Showing the current status of each request may be a bounded result. Creating a table, a query and a screen separately may be a useful way to break down execution, without each activity becoming a Delivery Unit. The central question is whether the part can be tracked and decided as a recognizable delivery. It does not need to produce value in isolation or work without dependencies: an integration can be evaluated against its own conditions and still depend on another system before it goes into operation.

A unit is not the same as a project either. A project can group several units; a small demand can be handled as a single unit.

Information that supports tracking

The table below is a conceptual reference, not a form that must be completed before work begins.

Information	What it must make understandable
Identity	Which demand is being tracked and how it is recognized throughout the work.
Intention and context	Why the demand exists, for whom, and in what situation.
Result and limits	What is expected, what is out of scope, and what still needs clarifying.
Acceptance conditions	How the delivery will be judged adequate, and who can accept it.
Constraints and dependencies	Which external or internal conditions limit execution and deployment.
Current situation	What has happened, what is pending, and which decision or work allows progress.
Artifacts and evidence	Which outputs were produced and which information supports evaluations.
Estimates and commitments	Which forecasts are current, and which work has been authorized under which conditions.
Responsibilities and decisions	Who answers for the delivery, who decides, and which changes were agreed.

Information can mature over the stages. An unknown condition should appear as a pending item or an assumption, never as an agreement just because it was written down. The record can point to information kept elsewhere; it does not have to copy code, documents or decisions into one place. It does need references that identify the relevant content and its relation to the current situation.

Continuous identity, revisable understanding

Keeping the identity does not mean freezing the initial description. Work can reveal that the imagined solution does not meet the need, that a rule was misread, or that a constraint calls for another approach. A revision should make it possible to see the previous understanding, the new one, and the effect of the change on what was authorized. Silently rewriting the description removes the reference needed to discuss the commitment.

Not every discovery needs a new unit. A clarification can stay within the agreed result. When deliveries emerge that need separate acceptance or authorization, splitting may be appropriate, and the relation between the original demand and the resulting units must stay visible. The same care applies to merging demands: being technically close does not mean sharing a commitment.

Stages, dependencies and execution

A Delivery Unit can go through several Delivery Stages, each a bounded transformation governed by a Stage Contract. Completing a stage may produce information for the next, require more clarification, or support a decision to stop. It does not complete the unit. Dependencies shape what can move forward without removing the demand’s individual identity. The Delivery State shows these differences.

The unit represents the demand whatever the execution composition. An Execution Resource can take part in some of the work under the Execution Policy without becoming the reference that defines the whole delivery. For a system to execute or decide, the unit’s context must be actionable: it has to distinguish intention, assumption, alternative examined, accepted output and authorized scope. That context is not automatically transferable, because information can be incomplete or need interpretation. Changing resources does not, on its own, change responsibility for the delivery.

In the running example

The barbershop asks for booking, reminders and advance payment. The Delivery Unit starts with that intention and with authorization for discovery only. Requirements, prototype and technical analysis stay linked to the same reference while they widen the understanding of the request.

The provider offers to build booking and to add reminders under their own conditions. The customer authorizes booking only. The unit has to distinguish the contracted scope from the alternatives: a mention in the prototype does not authorize building everything that was discussed.

Reminders can be tracked as a part not yet authorized, or as another linked unit. Either way, their dependency on booking stays explicit. Splitting units does not create technical independence or new transactions. If the customer stops after the accepted discovery, that commitment can be fulfilled, and the option that was never contracted is not presented as a pending obligation. The complete case is in the example Delivery Unit.

Boundaries and failure modes

Not a unit of charge. A Delivery Unit is a tracking unit. An agreement can cover several units, and shared costs can serve more than one demand. Two units do not represent equal amounts of effort, risk or value. Relating resource use and rework to a demand can support economic analysis, provided shared costs and dependencies are considered; counting completed units does not demonstrate productivity, margin or benefit. Unit Economics takes up this distinction.

Existing is not authorized. A unit can exist before any implementation is authorized, and an authorization may cover only part of its route. Progressive Commitment deals with the authorized scope, and the Commercial Gate makes the economic decision explicit when continuing needs a review.

It is only as good as its upkeep. Out-of-date records can produce a wrong understanding of what is authorized. Excessive fragmentation can make coordination harder than execution. Some demands are hard to bound at first; there, the commitment can focus on investigation or clarification without pretending to be certain about later implementation. How best to represent shared dependencies, split demands and allocate common costs remains open.

Connected concepts

• Structures overview
• Next: Delivery Stage, the unit of transformation a demand goes through
• Delivery State, the situation of the unit at any moment
• Example Delivery Unit, the full case
• Glossary