A Demand That Retains Its Identity | Software Delivery as a Service

A request begins in a conversation, becomes a prototype, passes through a technical decision, and reaches code. Details change along the way. Some assumptions are abandoned; others become conditions of the solution. When a problem appears, we need to know which intention and decisions the implementation was meant to preserve.

The economic proposal depends on preserving this meaning at a cost each advance can bear. AI may help prepare and recover context, allowing people and agents to perform parts of different demands without repeating the whole investigation. The structures below support that possibility; naming them does not produce the gain.

A Delivery Unit maintains that reference throughout the process. It brings together the demand, its artifacts, dependencies, decisions, and commitments. It can be refined or decomposed. Its purpose is to make progress traceable even as representation and executor change.

It need not coincide with a ticket, feature, or project. Its boundary should make progress and responsibility understandable. A unit that is too large can hide decisions; one that is too small can separate parts that are useful only together.

The Unit Persists; the Transformations Change

At the barbershop, the intention to offer bookings begins with incomplete rules. Discovery produces criteria and a prototype. Implementation produces a software revision. Integrated validation examines its behavior. These are different transformations of the same demand.

Each Delivery Stage is a bounded transformation. Its Stage Contract states required inputs, execution policy, outputs, and acceptance criteria. This contract is an operational specification; it does not require a legal document or a separate purchase for every activity.

Acceptance of a booking implementation might require that appointments for the same professional never overlap. The executor can be a person, an agent, or a combination. The condition remains clear even if the way evidence is obtained must vary.

The Result Must Answer the Question

Existing code is an artifact. A concurrency test run against the correct revision can provide evidence about the overlap rule. A report from another version does not answer the same question. Criteria, outputs, and relevant evidence must be connected.

Suppose local tests pass, but two simultaneous requests can confirm the same slot in the actual integration. The demand has not yet met the criterion. Returning the work should identify that discrepancy, permit correction, and require another relevant evaluation.

If, instead, nobody defined whether two different professionals can work at the same time, there is an ambiguity to clarify. If the calendar is inaccessible, there is a dependency to resolve. Asking the executor to try again does not solve all three problems indiscriminately.

Preserve Meaning Without Freezing the Route

Operational contracts permit returns, investigations, and parallel work. They do not require every demand to follow a rigid sequence. Nor do they justify specifying every movement: formalization should be proportionate to the consequences and the coordination required.

State must distinguish produced, accepted, and authorized work. An accepted prototype may be waiting for a purchasing decision. An authorized implementation may be waiting for access. Confusing those states makes the system treat commercial questions as technical ones, or produce work nobody purchased.

Persistent identity and explicit transformations make it possible to change the means of execution without losing the object of delivery. That continuity makes the abstraction useful: the buyer follows progress while the provider organizes how to achieve it.

For the economic argument this organization supports, see the paper.