Design principles

The model starts from the hypothesis that AI could change the economics of learning, producing, coordinating and deciding. These principles guide how to turn that possibility into a service while keeping the relation between demands, transformations, execution and commitments intact. They give a common basis for discussing implementations, without making the mechanisms the cause of the change.

They are commitments of the proposal. They do not prove that the model produces better results, and they are not a recipe for organizing any context. A small operation and a relationship between companies can respect them with mechanisms of very different complexity.

#	Principle
1	Make the expected result explicit
2	Preserve the identity and context of the demand
3	Make the conditions of each transformation explicit
4	Separate the definition of the delivery from the choice of execution
5	Keep responsibility and authority identifiable
6	Ground evaluations and decisions in relevant evidence
7	Update estimates and commitments as understanding changes
8	Distinguish technical acceptance from economic authorization
9	Allow revision, return and interruption
10	Apply the mechanisms in proportion to the demand

1. Make the expected result explicit

Organizing the work starts from what someone needs to receive. A demand can arrive as a vague intention, but clarifying it should produce a reference of result that the participants can discuss and evaluate. That does not mean specifying the whole software in advance: in an early exploration, the expected result may be to clarify a constraint or assess the feasibility of an alternative. The commitment matches what can be bounded at that moment.

People, hours and tools are still needed to produce the delivery, but providing them does not show that the need was met. The model should let resource use be related to the authorized result. The first commitment can be an advance of learning, such as clarifying requirements, trying out an interaction or examining an integration. Its result should be useful in its own right and produce information for deciding on continuing, and the service should let the buyer recognize what that advance delivers before asking for a commitment to the whole construction.

Where it is realized: Stage Contract, Outcomes, From capacity to outcomes.

2. Preserve the identity and context of the demand

The Delivery Unit should stay recognizable when the people responsible, the artifacts or the understanding of the solution change. Tracking it has to relate the original intention, later decisions and the conditions currently valid. That continuity does not assume the demand stays the same: a discovery may call for splitting it, changing its scope or stopping it. The principle requires being able to understand what changed and how it affects the commitment.

Dependencies are part of that context. A feature can be ready for evaluation and still depend on access to an external system; recording only “in progress” hides a difference that matters for the next step. The depth of the record should follow the need for coordination. This continuity is what lets pools serve parts of different demands without reconstructing the meaning of the request at every hand-over, and the viability of that organization depends on how much it costs to prepare and recover reliable context.

Where it is realized: Delivery Unit, Delivery State, The abstraction problem.

3. Make the conditions of each transformation explicit

A Delivery Stage should make clear what it uses, what it transforms and what it must produce, and the Stage Contract gathers those conditions and the criteria for judging the output. The contract does not remove judgment. Where the adequacy of a solution depends on human evaluation and on context that is hard to formalize, it should be clear who evaluates, for what purpose and on what information. A design stage may need clarified business rules and produce a technical alternative with identified dependencies; its acceptance should consider whether that output allows the next decision, not whether a document with the expected title exists.

Explicit conditions also make gaps discussable. If an essential input is missing, the work may need clarification or a bounded authorization to proceed under a stated assumption. Carrying on without acknowledging the gap moves uncertainty further along.

Where it is realized: Delivery Stage, Stage Contract.

4. Separate the definition of the delivery from the choice of execution

The expected result and its acceptance criteria have to serve as a reference for different compositions of execution. The Execution Policy determines which resources may act, how they are selected, what autonomy they have and what supervision they need. This separation makes it possible to change executor without automatically redefining what must be delivered. It does not mean people, agents and automation are equivalent: competence, context, permissions and risk still limit the choices.

If an agent takes part in implementation, the feature still has to meet the agreed conditions, and its use may call for specific checks; preserving the expected result does not mean keeping every procedure unchanged. Execution Pools can organize shared resources, but they are not the only way to respect the principle; a dedicated resource can also work under explicit conditions.

Where it is realized: Execution Policy, Execution Resources, Execution Pools.

5. Keep responsibility and authority identifiable

Distributing work must not make responsibility for the delivery ambiguous. It is necessary to tell apart who executes, who can accept an output and who has authority to assume or change commitments. These functions can sit with few people; the principle does not require separate roles or multiple approvals for every demand. It requires that authority be understandable when a decision has to be made. Someone can clarify a purchasing approval rule without authority to increase the contracted budget; whoever implements a feature may not be authorized to deploy it.

An automated mechanism can take part in a decision within delegated conditions. That delegation needs recognizable limits and an associated responsibility, and automation alone does not resolve how an exception or an inadequate result is handled.

Where it is realized: Governance, Mandates, Escalation.

6. Ground evaluations and decisions in relevant evidence

Artifacts and evidence are related but different. An artifact is an output of the work; it becomes evidence when it provides information relevant to an evaluation or decision. Code produced does not automatically show that a business rule is met, and an executed test supports a conclusion about one behaviour without showing that the whole solution is adequate. The strength of a conclusion has to respect the scope of the information behind it.

The model must allow evidence to contradict the chosen path. An evaluation that reveals an incompatibility has to be able to trigger revision, clarification or interruption. If every output is accepted whatever the evaluation shows, the mechanism loses its purpose.

Where it is realized: Evidence, Artifacts, Evaluation, Quality Gate.

7. Update estimates and commitments as understanding changes

Estimates express a situated understanding of the work. Progressive Estimation requires relevant changes of context to be reflected in forecasts of effort, cost, time and risk. More information does not guarantee a smaller or narrower forecast; discovering an integration dependency can increase the work expected. What matters is recognizing the change and its basis without artificially preserving the earlier estimate.

Progressive Commitment relates that understanding to what is authorized. Knowing about a difficulty does not automatically authorize consuming more resources or changing the contracted result. The principle does not require renegotiating every activity: one commitment can span several stages with tolerances or conditions for revision. Learning also makes the next offer possible, and the buyer chooses to continue, adjust, select a part or stop. AI enables the hypothesis of making these cycles more affordable and repeatable; being independent of any vendor or tool preserves that causal role rather than reducing AI to an option with no relation to the thesis.

Where it is realized: Progressive Estimation, Progressive Commitment, Pricing.

8. Distinguish technical acceptance from economic authorization

The Quality Gate and the Commercial Gate answer different questions. The first concerns whether an output meets the established conditions; the second concerns authorization to assume, keep or revise an economic commitment. A technical alternative can be clear enough to be accepted as the result of an analysis while its implementation remains unauthorized; an available budget does not show that an output meets the technical criteria.

Both decisions can happen in the same interaction and be taken by people or systems with the relevant delegations, as long as their meaning stays clear. The principle stops the completion of a stage from being read as implicit authorization for everything after it. It applies to internal operations too, where budget, priority and availability can condition continuation without any new commercial transaction, and a Commercial Gate never implies charging separately for each stage.

Where it is realized: Quality Gate, Commercial Gate.

9. Allow revision, return and interruption

The flow has to accommodate discoveries that change the expected path. Bounded stages do not force a linear sequence, and returning to an earlier decision is not an illegitimate deviation. An ambiguous rule found during implementation may call for new clarification, and coordination should relate that return to the artifacts and commitments it affects.

Stopping can also be the right decision. An analysis can show that a solution is not viable under the available conditions; accepting that analysis is not a failure to produce an implementation that was never authorized. Revision is not free: work already done, obligations assumed and dependencies can limit reversibility, and the model promises no unrestricted freedom to undo commitments.

The operation should allow cycles of observation, attempt, evaluation and correction within the commitment. People and systems can run them, and decisions about continuing can be delegated too. Engineering control can be built into criteria, policies and recovery mechanisms; it does not mean human confirmation at every transition. Intervention stays possible according to governance, without becoming a mandatory step.

Where it is realized: Orchestration, Retry, Delivery Stage.

10. Apply the mechanisms in proportion to the demand

Making conditions and decisions explicit has a cost. Records, evaluations and coordination should help understand or carry out the delivery, and the proposal should make it possible to investigate when that cost is justified and when a mechanism has grown beyond what is needed.

Applying the principles must preserve the economic gain that motivates the model. If generating outputs gets cheaper but keeping them coherent, checking them and deciding on them consumes the whole gain, the service may remain unviable. The reference is the complete effort of fulfilling the commitment, including preparation and the buyer’s work. AI does not justify multiplying documents or boundaries that support no decision.

A person building a small solution for someone else can record the expected result, agree acceptance criteria and clarify changes simply. A delivery between companies with integrations and several authorities may need more detailed mechanisms. Proportionality does not mean leaving out a decisive condition because the demand looks small; it means choosing a form sufficient to make it understandable and usable, considering risk, dependencies and the need for coordination as well as apparent size.

Where it is realized: Software Delivery Engine, Unit Economics.

Using the principles

The principles guide the design of a proposed model; their examples are illustrative, and their usefulness and cost have to be assessed in concrete applications. The pages linked above develop each mechanism without assuming a single implementation, and keep the conditions that sustain the model apart from the choices of technology, organizational structure or pricing used to realize it. To see them working together on one demand, follow the reference model.