Reference pipeline

Intent to production introduced DU-001, the barbershop’s booking demand. This page details its reference pipeline: five transformations related by inputs, outputs, evaluations and authorizations. The sequence describes a main path, with returns and waiting explicitly allowed. It illustrates the model; it does not prescribe that every demand has five stages. The identifiers are explained in the reference model overview.

Stages and commitments

The pipeline separates clarification, design, implementation, integrated validation and deployment. That decomposition makes it possible to discuss different decisions in the example.

C0 (20) authorizes: S1 Clarification -> S2 Prototype and architecture, in parallel where possible
C0 fulfilled:       authorize C1, ask for adjustment, defer, or close the completed discovery
C1 (80) authorizes: S3 Implementation -> S4 Integrated validation -> S5 Deployment
Return in the case: S4 -> S3 -> S4, a correction under the same rule

Each stage has a Stage Contract. The acceptances Q1 to Q5 are Quality Gate decisions. C0 and C1 are economic commitments, with authorizations of their own. Because C1 covers three stages, there is no forced correspondence between a transformation and a new charge. Permission to deploy in S5 remains an operational condition, separate from the economic commitment.

The same structure in a familiar development flow. The figure groups the five stages of this page into four boxes; commercial decisions follow the scope agreed, not every internal task.

The decomposition shows where AI could change the effort needed: preparing rules and alternatives in S1 and S2, producing and correcting in S3, evaluating in S4, confirming the effects of S5. The chain only supports a new consumption relationship when the cost of the complete cycle, hand-overs included, allows the bounded commitments to be offered. The number of stages does not explain that viability.

The contracts at a glance

Real records would need to state the demand’s rules and references in the detail execution requires.

Stage	Inputs and preconditions	Main output	Acceptance
S1 Clarification	Intention, context and C0 authorized; access to the business authority.	A1: rules for duration, availability, concurrency and cancellation, limits and dependencies.	Q1: the conditions the design needs are clarified and recognized.
S2 Solution design	A1 accepted, constraints available, covered by C0.	A2: prototype, architecture, dependencies and the approach to validation.	Q2: the solution is well enough founded for the implementation decision.
S3 Implementation	A1 and A2 in force, C1 authorized, eligible resources and access.	A3: an identified change, local checks and execution references.	Q3: implementation conditions met to move on to integrated evaluation.
S4 Integrated validation	The relevant revision of A3, Q3 granted, integrated environment available.	A4: results and divergences against the integrated criteria.	Q4: integrated criteria met with sufficient evidence.
S5 Deployment	Q4, an identified revision, the commitment in force and authorization for production.	A5: a record of deployment and the agreed checks.	Q5: deployment and the stage’s final conditions met.

Each contract names the authority that accepts, as well as the criteria. The concrete people or systems are defined for the demand; no executor is presumed able to approve its own output.

S1: clarify without presuming the solution

S1 turns the intention into usable business conditions. The initial need can arrive in informal language, and the stage has to separate the expected behaviour from implementation alternatives not yet chosen. Each appointment lasts 30 minutes and must fit the professional’s registered hours; overlapping intervals for the same professional are forbidden; different professionals can work at the same time; a confirmed cancellation frees the slot. Reminders and advance payment stay out of the main commitment. A business authority, direct or delegated, settles the choices needed before Q1.

Execution can use interviews, reading material and agents, as long as decisions stay with whoever may take them. An automatically produced interpretation only settles a decision when the mechanism has a sufficient mandate and applies its criteria; generating a suggestion confers no authority. If an essential decision is missing, A1 can exist as a partial output but does not receive full acceptance just because it is written down, and the state shows the condition that blocks moving on.

S2: design and ground the continuation

S2 uses the accepted rules to develop prototype and architecture, which can run in parallel: the booking interaction informs technical decisions, and the calendar’s constraints inform the interface. A2 reconciles both, identifies the calendar service that stores bookings and cancellations, and explains how concurrency and availability will be evaluated. Access to the validation environment may not be available yet, as long as that dependency is acknowledged and S2’s purpose does not need it immediately; accepting a design with an explicit dependency does not declare the dependency resolved.

Progressive Estimation relates A2 to the forecasts for implementation. The technical acceptance Q2 supports the discussion, while the Commercial Gate decides on C1. The offer for booking at 80 and the alternative with reminders at 95 come after the discovery at 20; the additional mandate of 90 covers only the first, if its other conditions hold. The choice can be direct or delegated, and it does not happen automatically because Q2 was granted. If no construction is bought, closing the fulfilled C0 records a completed discovery, without treating S3 to S5 as failed work.

S3: produce a change that can be evaluated

S3 implements the behaviour under the conditions in force. The Execution Policy allows a hybrid or autonomous configuration, including planning, production, evaluation and delegated decisions; the contract sets criteria and authority without requiring human confirmation per activity, and Routing confirms who takes on the execution. A3 identifies the revision of the change and the references of rule and design it used, so the output can be evaluated and later revisions recognized. Q3 checks the planned local conditions; it does not declare that integrated behaviour has been shown. If a rule changes during production, its scope must be checked before continuing; the resource can analyse effects but not widen the commitment on its own.

S4: examine the integrated solution

S4 evaluates the relevant behaviour in the agreed integration. At first, missing access prevents the evaluation. The reason and the responsibility for resolving it are recorded. Waiting does not show that the implementation failed, and it does not allow declaring the integration verified on other, non-equivalent evidence.

Once access is available, evaluation finds a concurrency divergence: two overlapping bookings confirmed for the same professional. A4 records it and Q4 is not granted; an evaluation output exists even when the result is unfavourable. The flow returns to S3 to correct the implementation, and the new revision goes through the relevant checks and back to S4. Integrated acceptance must refer to the corrected revision, with the earlier result kept in the history.

S5: deploy what was evaluated

S5 brings the change into the environment of use under the authorized conditions. Its input points to the evaluated and accepted revision, so a later change is not treated as if it had the same basis. The economic authorization C1 does not replace permission to act in production. The environment’s authority grants the relevant operational authorization directly or through a delegated policy, which can be checked automatically without a new human intervention. If execution loses confirmation, the stage keeps a question open, and repeating the action requires checking effects that may already have happened. Q5 recognizes that S5’s contract was met; closing the unit still checks the commitment as a whole.

Returns and changes of scope

The main return in the case is from S4 to S3, for a divergence in the implementation. The rule stays valid and C1 covers its correction, with no automatic extra charge per attempt. If the problem were an ambiguous rule, the return could reach S1; if a constraint changed the solution, S2 might need revising. In both cases coordination identifies the affected outputs and checks the economic coverage of the revision.

Adding reminders does not correct a defect in the contracted booking. It is an extension that needs its own decision. The original demand can continue because booking does not depend on reminders; if a partial selection removed an indispensable dependency, the offer would have to be re-bounded before authorization. The pipeline keeps these differences so that the history does not turn business decisions into technical failures, or a change of scope into an identical attempt.

Parallelism and simplification

The main sequence makes the case easy to trace; activities within stages can run in parallel when dependencies and authorizations allow. Preparing integrated access can start before S4, for example, which is not the same as running the evaluation without an implemented input. In a smaller demand, design and clarification can share a stage, and implementation and verification can be divided differently. That is acceptable if outputs, criteria, authority and commitment stay understandable. A boundary is worth keeping only if it earns its cost; the design should not multiply acceptances just to reproduce this reference.

When the route counts as fulfilled

The unit is not complete because five stages were counted. Acceptances must correspond to the references in force, and the final result must fulfil the authorized commitment; an earlier acceptance can remain valid historically without supporting a later revision. The pipeline also allows different endings: C0 accepted without buying C1 concludes the discovery, and S3 to S5 do not apply to the scope chosen; an active C1 closed without full delivery is recorded as an interruption of that commitment, with its effects and remaining obligations.

Two configurations for the same route

Decision or activity	Hybrid configuration	Autonomous configuration under mandate
Clarify rules	A person decides what they kept for themselves; agents organize alternatives.	A system decides within the delegated business criteria.
Produce prototype and architecture	People and agents share production and review.	Systems produce, compare and correct outputs under explicit criteria.
Form and accept C1	The provider forms the offer; the buyer decides directly.	Delegated authorities of provider and buyer act within their own scopes.
Implement and evaluate	An agreed composition of agents, professionals and checks.	Automated production, evaluation, correction and acceptance when evidence is sufficient.
Deploy	The environment’s authority decides according to its policy.	An operational policy checks and authorizes the ready revision, within its delegation.

Both configurations keep the same rules and contracted result. They are not two different products, and neither requires five human interruptions; a Quality Gate can be a decision built into continuous evaluation. When a delegated condition stops holding, the affected action waits for treatment rather than inventing an authorization. The same demand could also be run entirely by people, with the same criteria, commitments and limits of authority. That configuration is a baseline for comparison: how much it costs to clarify, produce, evaluate and coordinate booking in each arrangement, at comparable scope and quality. Its existence acknowledges operational antecedents; it shows neither economic equivalence nor any presumed superiority of the hybrid or autonomous configuration.

The reference architecture organizes the records and functions that make these checks possible, and the state machine details how events support changes of situation. This pipeline is a reference composition for a fictional case; its stages, codes and acceptances are not a universal sequence and need not correspond to separate contracts or instalments.