The abstraction problem

Software delivery today looked at the work of turning a need into usable software. Why AI changes the model set out the enabling hypothesis: AI could change the cost of learning, producing, coordinating and deciding. For that gain to survive the hand-over between activities and executors, the meaning of the demand has to stay usable. This page is about that continuity, and about why today the buyer often has to provide it.

What it means to abstract delivery

An abstraction is a representation that selects what matters for a given decision. “Forty hours of development” highlights effort. “An integration project” highlights an initiative and its scope. “The user will be able to track their requests” highlights a capability expected of the software.

All three can describe the same work, but they answer different questions. Hours help discuss effort or billing. The project groups commitments and activities. The expected capability says what someone intends to receive. A representation can be useful for one decision and insufficient for another.

The abstraction problem appears when one of these representations is used to answer a question it cannot answer alone. Knowing how much time was consumed does not tell you whether the need was met. Knowing a task finished does not tell you whether the software is available for use. Knowing there is a budget does not tell you what is authorized to change.

The model is interested in which information has to stay connected for the transformation of a demand to be understandable from start to delivery. The buyer has to recognize the advance they bought, what they received, what they learned and the conditions for continuing. The provider has to turn those references into work and decisions. That is a choice of representation that comes before any choice of tool or structure.

What remains when execution changes

Take the request “I want to keep track of my requests.” A person can build the solution by hand, use AI as support, or delegate a bounded part of the implementation to a system. In every case, it remains necessary to clarify which requests are recorded, who can access them and which behaviour will be accepted.

Effort, time and checks can change with the execution chosen. The need behind the work is not adequately described by the identity of whoever executes. If the developer changes tools, the requester still needs to know what they will receive and which decisions remain open.

The model therefore separates what is meant to be delivered from the means used to produce it. That makes it possible to analyse a change of execution without losing the reference of the demand, and to notice when the solution itself was changed: if a change of tool led to dropping an important condition, the commitment changed, not just the way of working. The separation is analytical. In practice, the means available influence which solutions are viable; separating the two dimensions makes that influence explicit.

When systems carry out larger parts of the work, these references also have to be usable during execution. An agent that meets a conflict has to relate it to the expected result, the evidence and the scope it may change. If every transition requires a person to reconstruct that whole relation, delegation is limited by that interpretive work.

People, hours, tasks and projects represent different things

A person or team represents capacity and responsibility for execution. Hours measure time. A task describes work to be done. A project can gather deliveries, resources and commitments. These representations remain useful, but they are not interchangeable.

Representation	Question it helps answer	What else is needed to understand the delivery
Person or team	Who can do the work and answer for it?	Which need will be met, under which conditions?
Time or effort	How much work was planned or consumed?	What did that work produce, and how was it evaluated?
Task	Which activity needs to be done?	Which demand does it serve, and what does finishing it let us say?
Project or initiative	Which commitments are grouped together?	How does each delivery progress, and which decisions still prevent its use?
Artifact	What has been produced so far?	For what purpose, with what validity, and with what acceptance?

The problem is not solved by choosing one row and discarding the others. A delivery may need all of these perspectives. The question is how to connect them so that someone can say what is being produced, why, in what condition, and what is missing to continue.

A demand can disappear between its representations

Imagine a piece of work whose request is in a conversation, whose estimate is in a proposal, whose activities are in a list, and whose validation is in an exchange of messages. Each record may do its job. Still, reconstructing the situation of the delivery may require combining information and resolving disagreements between records.

If the request changes, the proposal may no longer represent the current scope. If an activity finishes, the evaluation of the resulting behaviour may be missing. If the software is technically accepted, a decision about its use may still be pending. The difficulty lies in keeping the meaning of these changes connected to the original demand and to later commitments. Today, that connecting work often falls to the buyer, who ends up coordinating the pieces instead of consuming a service.

This is a hypothetical scenario of fragmentation. It can happen in a simple relationship or an operation with many participants, and it is not a universal description of the market: an organization can keep these relations clear with existing practices and tools. The hypothesis is that representing the demand and its progress explicitly reduces the need to reconstruct its meaning from separate records. Its usefulness has to be weighed against the effort of maintaining it; for small work, a conversation and a clear agreement may be enough.

Continuity from intention to commitment

At the barbershop, a purchased discovery produces rules about service duration, the availability of professionals and rescheduling. A prototype lets the choice of time slots be discussed. The technical design identifies the integration needed with the existing calendar. The provider offers to implement booking, with reminders as an option, and the customer chooses booking first. The operation has to preserve the difference between the alternatives examined and the scope actually authorized: an executor cannot treat everything discussed as part of the contracted delivery.

During implementation, a test reveals a conflict between service durations and calendar intervals. For whoever executes, that means examining and correcting the solution. For the buyer, what matters is whether the agreed behaviour can still be delivered under the conditions offered. For the economic decision, what matters is whether this is an included correction or a change of scope.

The representation has to link the intention, the outputs of discovery, the option chosen, the commercial conditions and the evidence from implementation. Simple records or structures in a platform can both do it. What matters is that each decision has the right reference, and that the customer does not have to follow every technical action to understand their delivery.

Representing the demand is not an entirely new idea

Backlog items, change requests, specifications and delivery commitments can each represent aspects of a demand. There is no need to assume these practices ignore intention, acceptance or results to justify the inquiry; an existing approach may already gather the information needed in a given context. The question is one of reach. Does the representation follow only implementation, or also the initial clarification? Can it relate changes of scope to economic decisions? Does it keep the link between what was accepted and what was deployed? Does it stay understandable when the way of executing changes? These questions do not establish the need for a new name. Any contribution will have to be shown by the precision of the relations the model establishes and by their usefulness, not by new vocabulary.

What a representation needs to preserve

To follow the transformation of a demand, a representation should preserve the need that started it, the expected result, the relevant constraints, what has been produced, what has been evaluated, and which decisions condition continuing.

Economic information has to preserve its distinctions too. A forecast for continuing is not a contracted price; an authorization ceiling is not money spent; accepting a prototype does not authorize building every alternative it shows. The buyer must be able to understand these conditions without reconstructing them from internal activities.

Not all of this has to be complete at the start. A request can be vague at first, and clarification can change the understanding of the result and reveal new constraints. Representing the demand means allowing that evolution without confusing an initial assumption with an accepted commitment. It also means recognizing dependencies: tracking a demand individually does not make it independent of shared changes. The level of detail should be proportional to the decisions it supports, since recording information nobody uses adds cost without improving understanding.

From representation to a way of consuming delivery

The proposed abstraction relates what someone intends to receive, the advance they bought, the learning produced and the conditions for continuing. People, hours, tasks and artifacts stay useful inside that relation. The demand provides continuity while the means of production and the understanding change.

That continuity supports an experience in which the buyer can ask, compare conditions, authorize part of the work and follow the result, while the operation coordinates resources and decisions. Self-service is one possible form of interaction; an assisted service can use the same representation. The buyer delegates the organization of production without losing the reference of the commitment. For the operation, usable context lets different resources resume work and lets systems decide within their mandate, which is what allows pools to serve parts of many demands without the customer retelling the intention at every hand-over. AI can help prepare, recover and relate information, but the coherence and currency of these references must remain verifiable.

Maintaining this representation has a cost. If gains in execution are consumed by reconstructing context and correcting interpretations, distributing work may not improve the economics of the service. The abstraction is a mechanism for preserving the gains that AI could enable, and its usefulness depends on reducing the net effort of continuity. The distinctions on this page are analytical proposals; the usefulness of a more explicit representation of the demand remains a hypothesis to evaluate in concrete contexts.

In the model, this representation is the Delivery Unit and its Delivery State. Next: from capacity to outcomes.