Stage Contract

What question does this solve?

Work that starts, a result that is expected, and a decision that recognizes whether the result is adequate all need a common reference. Without one, a well-made output can still fail to serve the decision the demand needs, and a question nobody has authority to settle can be quietly settled by whoever happens to be executing.

Definition and role

A Stage Contract is a specification that gathers the required inputs, the execution policy, the expected outputs and the acceptance criteria of a Delivery Stage. It relates those conditions to the purpose of the transformation within the Delivery Unit.

“Contract” here does not mean a legal contract. It names an explicit reference for execution and evaluation. It does not require a separate legal document, and it does not mean there is a new commercial purchase at each stage. The conditions can live in a tool, a document or a set of references available to the participants.

The specification must make it possible to answer what is available, what must be produced, which resources may act, and how the output will be accepted. Its level of detail follows the complexity and risk of the work: a simple fix may need few conditions; an integration may need rules, environments, access and responsibilities in more detail. Making conditions explicit does not remove interpretation or discovery. It makes it possible to recognize when a decision is supported by the current agreement and when it needs clarification or revision.

Why it matters for the hypothesis

The contract lets work done by people and AI keep its purpose and criteria when execution changes hands. A reusable reference can reduce the effort of instructing and evaluating each resource in a pool, provided it is adapted to the context. The mechanism tries to preserve gains in production and coordination; writing specifications does not, by itself, make the service more viable.

How it works

Purpose and link to the demand

The contract should state the stage’s purpose. An output can be well produced and still not serve the decision the demand needs; judging only its format leaves that question unanswered. A feasibility analysis, for example, may aim to establish whether an integration is possible under certain constraints. An adequate result can be a well-founded finding that it is not. It would make no sense to require every analysis to conclude “feasible” in order to accept it.

A reusable specification can be a starting point, but applying it must take account of the demand’s particulars and the decisions already made. The contract specifies one transformation. It does not replace the definition of the demand, and it does not settle economic commitments.

Inputs, preconditions and assumptions

Inputs are the information and artifacts used in the transformation. Preconditions state what must be true to carry out the work as planned. A business rule is an input; having authorized access to the required environment may be a precondition. The distinction explains why a stage cannot start or continue: having a specification available does not mean having the permissions or dependencies needed to implement it.

The contract should make clear how unknown information is handled. An assumption can allow exploration if its use and limits are acknowledged. It must not be presented as a confirmed decision, or silently hand the executor a choice that belongs to another authority. The contract should avoid both demanding unnecessary certainty and authorizing execution without essential conditions.

Execution policy and limits of authority

The contract incorporates or references the applicable Execution Policy, so that execution fits the context of the transformation. This can include required competences, limits on access and situations that call for human evaluation. It need not reproduce the whole policy for every demand, but the applicable rule must be identifiable.

Technical ability is not authority. An agent may produce an alternative without being authorized to accept it or deploy it. The contract also needs to show who can clarify an input, accept the output and authorize an exception. In a small operation these responsibilities may sit with one person; the specification makes them understandable without imposing a particular organization.

Conditions can allow automated acceptance and decisions about continuing within a mandate. The contract then gives people and systems a reference for producing, evaluating and resuming work. It can be simple or structured, and no universal machine format is required. An ambiguity should be related to the purpose and to the authority available to resolve it, rather than always requiring a new human decision.

Outputs, acceptance criteria and evidence

The contract indicates the relevant content of the output and the purpose it must serve. Asking for “a document” does not say which questions it must resolve; asking for “code” does not define the behaviour to implement. Format matters when it affects how the output will be used. Partial or exploratory outputs must be distinguished from the accepted delivery, and when there is partial acceptance its scope must be explicit. See Artifacts.

Acceptance criteria describe the conditions under which the output will be considered adequate. Evidence is the information that supports evaluating those conditions. The Quality Gate uses that evaluation to decide on acceptance. These functions are related but distinct: a criterion is not the test, and it is not the decision that follows. Some criteria allow automated checks; others require judgment about clarity, adequacy or alternatives, in which case the contract should state the purpose of the evaluation, the responsible authority and the information needed.

Acceptance respects the scope of what was evaluated. Checking one scenario does not prove all scenarios, and meeting the stage’s criteria does not demonstrate the business benefit expected from the demand.

Revising conditions and handling exceptions

A contract may need revising when new information appears. The change should preserve the ability to see which conditions guided the work already done and which apply now. An output must not be judged as though it had been produced under conditions defined afterwards. That does not oblige anyone to accept it; it requires recognizing the effect of the change, including rework and a possible revision of the commitment.

An exception needs an understandable scope. Authorizing exploration under an assumption does not waive clarification for good. Conditions must not be changed just to declare success after an unfavourable evaluation. A legitimate revision has a justification, an authority and identifiable effects.

In the running example

At the barbershop, one stage clarifies booking and its dependencies. The table illustrates operational conditions. Price and authorization belong to the commercial commitment, so this specification does not become a legal document.

Component	Illustrative condition
Purpose	Produce a reference for the design and for discussing an offer to build.
Inputs	The intention, services, available rules and authorized information about the existing calendar.
Preconditions	Access to the relevant context and identification of the authority for decisions still open.
Execution	Eligible human resources or systems; choices within the mandate can be delegated.
Output	Booking rules, limits, dependencies and the alternatives identified.
Acceptance	Information sufficient for the agreed purpose, with gaps stated and their consequences acknowledged.
Evidence	References for the rules, results of investigation and a record of the applicable decisions.

A document that merely repeats the request without resolving the essential questions does not meet the purpose. A well-founded analysis showing that one alternative is not viable can meet it. Whether the stage is complete depends on the discovery commitment, not on making the customer buy construction. If the customer has delegated decisions about continuing, acceptance can feed an automated economic decision, but acceptance of the stage remains distinct from economic authorization even when both happen without human intervention.

Boundaries and failure modes

A specification is not a price or an authorization. Making inputs, outputs and evaluation explicit can inform Progressive Estimation. The contract does not turn that into a price or an authorization: Progressive Commitment deals with the committed scope and the Commercial Gate with the economic decision. Technical conditions can be well defined with no authorization to execute yet, and a previously authorized budget can cover several transformations.

Formalization has a cost. AI can help draft and review conditions, but their quality depends on a verifiable relation to the demand and to authorized decisions; generating a long specification quickly does not remove the work of checking that it is relevant. Formalization should be enough to guide the present transformation, without requiring every future alternative to be defined. The economic advantage depends on saving repeated clarification, errors and rework without creating proportionally more bureaucracy.

Explicit is not the same as adequate. Incomplete criteria, mistaken premises or badly bounded outputs can allow acceptance that does not meet the real purpose. A contract should help surface divergences, not prevent them from being discussed because they were not foreseen. The right granularity, the conditions for reuse and how to handle strongly contextual evaluations remain open.

Connected concepts

• Structures overview
• Previous: Delivery Stage, the transformation this contract specifies
• Next: Delivery State, the situation of the demand
• Artifacts and Evidence
• Reference pipeline, the contracts of all five stages of the case side by side
• Glossary