Part III — Designing the Flow of Work
From Demand to Work Order
How can uncertain demand become authorized, traceable work without freezing discovery too early?
When inherited certainty left the ground
Chapter 6 defined the Factory Operating System as the coordination layer that makes policy, decision rights, work state, orchestration, controls, evidence, measures, and learning explicit and operable. That layer still needs an object on which those relationships can act. Demand rarely arrives as one. It arrives as a concern, obligation, hypothesis, failure, request, or ambition whose meaning changes as people investigate it.
On 4 June 1996, the first Ariane 5 launcher began its maiden flight. Roughly 40 seconds after the flight sequence began, the vehicle failed. The independent inquiry traced the sequence through both inertial reference systems, reused software, an alignment function that was no longer needed after lift-off, a conversion exception, diagnostic output interpreted as flight data, and extreme nozzle commands. The technical sequence was rapid. The assumptions behind it had travelled much further.C07-C01
The inertial software came from Ariane 4. Its earlier operating context had shaped the values the software was expected to encounter. The Ariane 5 trajectory differed. Protections reflected inherited assumptions, and the relevant trajectory was not represented adequately in equipment and system simulation. Redundant hardware did not provide independence because both units carried the same software and encountered the same condition.C07-C01
Formal reviews and extensive testing had occurred. Thousands of corrections had been made during the wider program. The case cannot responsibly be reduced to absent process, careless reuse, one conversion, or one individual decision. System requirements, inherited assumptions, protection choices, common-mode software, test representativeness, and review scope interacted.
The inquiry matters to demand authorization because the work was not simply “reuse the inertial reference software.” Reuse was a choice carrying assumptions about context, qualification, operational need, protection, and evidence. When the context changed, the authorization needed to keep those assumptions and evidence obligations visible. A component could satisfy its inherited specification while the intended system outcome became unsafe.
This is the pressure created by Chapter 6's closing question. If uncertain demand enters a Software Factory as an unqualified ticket, important context can disappear. If it enters as a fixed specification, learning may appear as deviation. If it remains an open-ended discovery effort, accountability can disappear in the other direction. The factory needs authorization that can change without losing its reason, boundaries, or history.
The central question is:
How can uncertain demand become authorized, traceable work without freezing discovery too early?
The answer is the Work Order: the traceable and progressively elaborated authorization for a unit of demand, recording its intended outcome, constraints, ownership, risk, acceptance evidence, current production state, and material decision history.
The Work Order is author synthesis. Standards, requirements research, public guidance, audits, and failure inquiries support its functions and boundaries. No source validates the name, mandates one schema, or proves that a richer record improves an outcome.
The central reframe is:
A Work Order authorizes the next justified commitment, not a fictional certainty about the whole journey.
Inherited software assumptions crossed into a changed operating context while representative evidence did not cover the new condition; the inquiry supports no one-artifact prevention claim.
Authorization is not specification
Organizations often treat authorization as a moment. A budget is approved, a contract is signed, a ticket enters a backlog, or a leader asks a team to begin. Each act may carry legitimate authority, but each can leave the production system with a different understanding of what was authorized.
A ticket may name a requested feature without naming the outcome or the authority to accept risk. A requirements document may be detailed while hiding which assumptions are uncertain. A contract may create enforceable obligations without representing how user evidence changes a solution. A product backlog may order work without preserving why a prior choice was abandoned. None is inherently defective. None is automatically a Work Order.
The distinction is functional. A Work Order connects a unit of demand to the Factory Operating System. It gives policy something to constrain, decision rights an object to authorize, work state a durable meaning, orchestration a current boundary, controls an evidence obligation, and learning a record that can change later action. The physical representation can remain distributed across established tools.
This is why “one record” does not require one database. A contract, risk record, backlog item, architecture decision, test result, and operational acceptance may remain in their appropriate systems. The Work Order needs durable correspondence among them. An authorized actor should be able to determine the intended outcome, current scope, relevant constraints, evidence expected at the next decision, unresolved risk, and material history without reconstructing the project from institutional memory.
The distinction also prevents the Work Order from becoming a richer intake form. More fields can create the appearance of discipline while moving uncertainty into vague answers. A field called “business value” does not establish an outcome. A red risk rating does not show the condition or decision it represents. A completion percentage does not reveal whether acceptance evidence exists. The test is not record density. It is decision fitness.
ISO/IEC/IEEE 12207 treats requirements, risk, decisions, verification, validation, operation, maintenance, and change as lifecycle concerns. ISO/IEC/IEEE 16085 makes risk identification, analysis, treatment, and monitoring explicit. These standards do not define the Work Order or prove that documentation improves delivery. They support a narrower proposition: authorization and evidence remain relevant as work and conditions change.
Requirements research reinforces the point. A systematic review of requirements change management examined causes, processes, techniques, and organizational decisions across heterogeneous studies. The accessible record supports the continuing need to identify, analyze, decide, cost, and control change. It does not support a pooled effect, a universal technique, or the Work Order construct.C07-A01
Authorization is therefore a continuing relationship. It begins by bounding an outcome, but it persists through changed evidence, constrained choices, acceptance, operation, reframe, and stop. The record evolves. The authority to evolve it remains explicit.
What the Work Order must preserve
The canonical definition names seven functions. They do not constitute a universal field list. Different consequences, legal systems, contracts, and technical contexts require different records. The functions identify what must remain answerable.
Intended outcome
The outcome states the change sought in the world, service, operation, or risk condition. It is not the requested feature. “Add an export button” is a solution instruction. “Allow authorized users to provide an auditable case record to an external reviewer within the required period” is closer to an outcome because it names a capability, user, and consequence while leaving implementation open.
An outcome can still change. Discovery may show that the problem is informational, contractual, operational, or already solved by an existing capability. The record preserves why investigation began and who may decide that a reframe remains legitimate.
Constraints
Constraints bound viable action. They may arise from law, safety, architecture, privacy, accessibility, interoperability, contracts, budgets, time, physical systems, or operational continuity. A constraint is not merely a preference with stronger language. Its source, scope, interpretation owner, and consequence should be visible.
Some constraints must be fixed early. A hazardous physical interface, statutory deadline, protected-data boundary, or contractual authority may sharply limit discovery. Progressive commitment does not mean deferring every choice. It means committing when evidence and consequence justify commitment and preserving the reason.
Ownership
Ownership identifies who is accountable for the outcome and who holds the relevant decisions. Demand can have many stakeholders, but ambiguity about final authority becomes production delay. The outcome owner may authorize discovery. A technical owner may decide among bounded designs. An acceptance owner may determine whether evidence is sufficient. An operational owner may assume responsibility after transition.
These roles may belong to one person in a small context or several institutions in a regulated one. Chapter 18 will define governance allocation. Here the Work Order must make the authority relevant to its current state discoverable.
Risk
Risk records uncertainty that matters to the decision: the condition, possible consequence, affected parties, current evidence, treatment, owner, and review trigger. A generic rating is insufficient when it detaches severity from reasoning.
Risk also shapes how quickly choices can remain open. Low-consequence user-interface details may be explored through inexpensive feedback. Safety-critical assumptions may need early qualification and representative testing. Progressive commitment is proportional, not uniformly permissive.
Acceptance evidence
Acceptance evidence states what would justify the next decision. It may include observed user behavior, verified system behavior, safety evidence, compatibility results, operational readiness, a legal interpretation, or confirmation that a non-software intervention resolved the need. The evidence should be named before the work makes it expensive to change the question.
Acceptance criteria alone can be too narrow if they only restate features. Evidence connects the intended outcome and constraints to an inspectable result. It does not eliminate judgment. A named owner still decides whether the evidence is sufficient within the accepted uncertainty.
Current production state
Current state tells participants what has been authorized now. Demand recognized, discovery authorized, options evaluated, scope authorized, acceptance decided, and operated outcome are different conditions. None is a completion percentage or maturity level.
State should reveal the next decision and allowed exits. It should also prevent activity from outrunning authority. Recognition of a problem does not authorize a build. Authorization to investigate does not authorize deployment. Acceptance of an increment does not settle every later operating obligation.
Material decision history
History preserves decisions that changed outcome, constraint, risk, scope, evidence, authority, or exit. It need not retain every conversation or draft. Excessive retention can create privacy, security, cost, and discoverability burdens. The requirement is proportionate memory.
The record should explain why the current authorization differs from the original one. It should show which option was rejected, what evidence changed a boundary, who accepted a residual risk, why work stopped, or how a replacement inherited unresolved obligations. Chapter 15 will address detailed Traceability and retention. Chapter 7 establishes only the need for material continuity.
A Work Order keeps seven functions answerable without prescribing a universal field list, form, schema, or completion score.
Progressive commitment
Progressive commitment narrows choices as evidence grows. It is not an excuse to avoid decisions. Every discovery interval needs a named owner, time or cost boundary, risk boundary, evidence expectation, and an explicit continue, authorize, reframe, or stop decision.
The tension resembles the organizational problem of exploration and exploitation. Exploration searches for better understanding and alternatives. Exploitation applies what is already known. An organization that commits too early can optimize the wrong solution. One that explores indefinitely can avoid accountability while consuming scarce capacity.
The final GAO Agile Assessment Guide connects iterative delivery with eliciting, prioritizing, refining, testing, validating, managing, and tracing requirements. It also discusses contracting, role clarity, oversight, and retrospectives aligned with delivery cadence. The guide is public implementation guidance synthesized from cases and specialists, not controlled evidence of a performance effect and not a Work Order design.C07-R01
GOV.UK discovery guidance makes the exit logic concrete. Discovery may lead to building, reusing an existing capability, partnering, providing information, making a non-software intervention, or deciding not to build. This is practitioner guidance, not comparative proof. Its value is to preserve alternatives that a feature request or funded project can erase.C07-R03
Progressive commitment changes the question at each decision. Early on, the question is whether a problem merits bounded investigation. Later, it is whether evidence supports one option and what scope can be responsibly authorized. At acceptance, it is whether the produced result and residual risk justify operation, correction, reframe, or stop.
The model preserves uncertainty rather than pretending to drive it to zero. Evidence can eliminate some alternatives and expose new uncertainty. A representative test may disprove an inherited assumption. User research may show that the intended outcome is real but the proposed interface is unusable. A legal interpretation may close an option. An operational incident may reopen a decision believed settled.
The discipline lies in changing authorization with the evidence. A team does not silently expand scope because discovery was useful. A sponsor does not insist on the original solution because funding exists. A control owner does not treat every baseline change as failure. Each material change reaches the authority that can decide it, and the reason remains attached to the Work Order.
Progressive commitment is easiest to misuse when a state label becomes a substitute for a decision. “In discovery” can conceal an effort whose owner, horizon, and evidence obligation are unknown. “Approved” can hide whether approval covered investigation, a current increment, a contract, or operation. “Done” can hide unresolved acceptance, transition, or monitoring duties. State is useful only when it changes what actors are authorized to do and makes the next decision visible.
The approach also separates reversibility from importance. A consequential decision may be technically reversible but institutionally expensive because users, suppliers, policy, or dependent systems adapt around it. A small technical change may be difficult to reverse once data or external commitments accumulate. The Work Order records the decision horizon and expected cost of change without pretending to calculate every option precisely.
Evidence expectations should be capable of failure. If every result can be interpreted as support for continuing, the discovery is not testing the path. A useful expectation identifies what would increase confidence, what would weaken it, and which authority decides whether residual uncertainty is acceptable. This is especially important when sunk effort and public commitment make stopping emotionally or politically difficult.
At the same time, a stop rule should not become automatic judgment detached from context. Evidence can be incomplete or delayed. A missed target may reveal a defective measure rather than a defective outcome. A control owner may need to distinguish a temporary dependency from a fundamental barrier. Progressive commitment requires accountable interpretation, not mechanical stage advancement.
The Work Order lifecycle
Figure F07.1 shows six current states linked by accountable decisions. A dotted evidence rail accumulates beneath them. An uncertainty band narrows but never disappears. Stop and reframe remain available after every material decision. Contract, baseline, legal, and hazard obligations can constrain choices earlier.
Figure F07.1 — Work Order lifecycle with progressive commitment. A Work Order can accumulate evidence and narrow authorized choices while preserving outcome, constraints, ownership, risk, acceptance evidence, current production state, and material decisions. Reframe and stop remain explicit exits; uncertainty never disappears.
Source: Author synthesis constrained by A07, C07-A01, C07-R01–C07-R04, S01, S17, CS01, and C07-CS2. Structured specification: figures/F07.1-spec.md.
The first transition moves from recognized demand to a bounded outcome. A demand owner identifies the source, affected users or system, initial problem evidence, and obvious legal or safety constraints. If no accountable outcome or lawful path exists, the work can stop before a build becomes an institutional commitment.
The second transition authorizes discovery. The outcome owner records material constraints, initial risk, dependencies, evidence expectations, and a decision horizon. High-consequence work may establish baselines or qualification duties now. The state authorizes investigation within limits, not an indefinite research program.
The third transition evaluates options. Build, reuse, partnership, information, process change, and no-build choices remain legitimate. Changed assumptions and affected interfaces become visible. The owner decides to continue, reframe, stop, or request a bounded delivery commitment.
The fourth transition authorizes current scope. The chosen option, current constraints, risks, dependencies, acceptance evidence, and applicable funding or contract authority define what may proceed. The commitment is real. Later change requires another material decision; progressive does not mean informal.
The fifth transition evaluates acceptance. Produced capability and evidence appropriate to consequence are examined. The acceptance owner may accept, require correction, reframe, stop, or seek a separately governed exception. Chapter 14 owns Quality Gate mechanics and Chapter 18 owns institutional exception authority.
The final transition moves to operated outcome and retained record. An operational owner accepts responsibility, monitoring and evidence obligations, and the next review or retirement trigger. Reframe, replacement, and retirement can open new bounded decisions without erasing the path by which the current state was reached.
This figure is not a universal process. States may overlap, repeat, combine, or use different labels. A small change may move through them rapidly. A regulated system may require several distinct authorities and formal baselines. The invariant is not sequence. It is the correspondence among outcome, authority, evidence, current state, and material change.
The lifecycle can be compressed without being omitted. A routine, low-risk correction may bound the outcome, identify applicable constraints, authorize the known option, test acceptance, and transition to operation within one working session. Its Work Order may be a small record linking an incident, change, evidence, and release. Proportionality removes ceremony; it does not remove authorization.
Conversely, a complex Work Order may contain nested decisions without becoming a portfolio plan. A multi-increment capability can authorize one evidence-bearing slice while retaining an outcome and dependency view across slices. Each increment should clarify what has been learned, what remains open, and whether the next commitment is still justified. Chapter 9 will address how such work moves under variability; this chapter only preserves the integrity of authorization.
The lifecycle also accommodates non-build outcomes. If discovery shows that guidance, training, a contract change, process repair, or retirement addresses the outcome more responsibly than new software, the Work Order can reframe without being declared a software failure. The production system has converted uncertain demand into evidence and a decision. Code volume is not the measure of completion.
Cancellation deserves the same discipline. Stop does not mean delete the record or erase the obligation. The owner records what ended, why, what commitments remain, which users or suppliers are affected, what assets or data require disposition, and whether a replacement decision begins. A clean stop can preserve more institutional value than continued delivery of a solution whose justification has disappeared.
A Work Order can accumulate evidence and narrow authorized choices while preserving outcome, constraints, ownership, risk, acceptance evidence, current production state, and material decisions. Reframe and stop remain explicit exits; uncertainty never disappears.
The FBI record as authorization history
The FBI's Trilogy modernization, Virtual Case File, and later Sentinel system appeared in Chapter 2 as a test of fragmented delivery. Here the same public record serves a different editorial job: it shows why authorization, component dependency, requirements change, termination, replacement, and verification history must remain connected.
Trilogy combined infrastructure, workplace technology, and investigative case-management application work. After the attacks of 11 September 2001, the FBI's mission and information needs changed. Requirements changed, commitments were accelerated, and multiple components progressed under interacting management, architecture, contracting, skill, supplier, and oversight conditions.
The infrastructure components eventually operated. The Virtual Case File did not. In March 2005, the FBI terminated VCF and moved toward Sentinel. The authorized outcome did not disappear when one effort stopped. It passed into a replacement decision carrying prior requirements, unresolved constraints, institutional learning, and new management choices.
Sentinel later changed management and delivery approach and became available to users in 2012. The inspector general also recorded changing requirements, cost-scope qualifications, and limits in verifying some completion claims. The case therefore resists two simple stories: a fixed specification would have prevented change, or iteration alone created success.
Through a Work Order lens, the important questions are longitudinal. Which outcome persisted across program names? Which requirements and assumptions changed? Which component dependencies conditioned acceptance? Who could terminate one path and authorize another? Which evidence supported claims of completion? What history did the replacement need in order not to begin as if no prior decision existed?
The public record cannot show that one artifact would have answered every question. Nor can it isolate a method from leadership, capability, oversight, architecture, time, and accumulated learning. It shows why “cancelled” and “delivered” are insufficient production states when the institutional outcome, obligations, and evidence continue across them.
The transfer is not a recommendation to make every backlog item carry a program archive. It is to keep a proportionate authorization thread when demand survives a change in contract, supplier, team, architecture, or named initiative. Without that thread, replacement can erase the reasons for prior choices while retaining their consequences.
The FBI authorization thread crosses component dependencies, VCF termination, replacement, and Sentinel operation while preserving qualifications; it makes no method-causality or outcome-comparison claim.
Ariane 501 as a boundary test
Return to Ariane 501. The case challenges any reading of progressive commitment as late constraint or informal change. In safety- and mission-consequential work, operational assumptions, inherited qualification, protection decisions, and representative evidence may need to be fixed and reviewed early.
NASA systems guidance offers a compatible principle. Baselines can change under control with bidirectional Traceability, risk analysis, and decision analysis. Rigor can be tailored to complexity, cost, and criticality.C07-R02 A baseline is therefore not the opposite of learning. It is a declared condition whose change requires visible authority and evidence.
The Ariane inquiry found that reused software carried assumptions from a different flight context and that testing did not adequately represent the Ariane 5 trajectory. The lesson is not “never reuse.” Reuse may be entirely rational. The Work Order question is whether the authorization exposes which assumptions are inherited, which context has changed, what qualification remains valid, and what evidence must be renewed.C07-C01
The same reasoning applies to redundancy. Duplicate components do not provide independent protection when they share the same software and assumptions. A Work Order for a safety-consequential capability should not record “redundancy present” as sufficient evidence. It should connect the intended protection to failure independence, test conditions, and the authority that judged the evidence sufficient.
The case also limits the framework. A Work Order would not have prevented the failure by its existence. Documents can preserve incorrect assumptions. Reviews can approve incomplete evidence. Teams can misunderstand a recorded constraint. The construct improves the questions a production system can ask; it does not guarantee the answers or the behavior of the institution.
Transfer only the need to keep changed context, inherited assumptions, evidence sufficiency, protections, and material decisions attached to authorization. Do not transfer launch-assurance procedure to ordinary software work. Proportionality remains essential.
Three demands, different commitments
The Work Order becomes practical when it changes shape with consequence without changing its function. Consider three common demand classes: a regulatory change, a customer-facing experiment, and reliability remediation. These are illustrative applications of the framework, not empirical cases.
A regulatory change may begin with a legal obligation whose interpretation, jurisdiction, effective date, affected systems, records, and accountable authority require early clarification. Discovery can remain open about implementation while the obligation and deadline constrain options. Acceptance evidence may require legal confirmation, system behavior, records, and operational readiness. An exception may not be available, or may require authority outside the Product Line.
A customer-facing experiment begins with greater uncertainty about the problem and solution. The Work Order may authorize a small evidence-gathering intervention with explicit population, duration, privacy conditions, success and harm indicators, and a stop rule. The next commitment may be scale, revise, abandon, or replace with a non-software response. A roadmap promise should not silently convert the experiment into predetermined delivery.
Reliability remediation may begin with an incident, recurring error, or service evidence. The initial Work Order preserves the affected outcome, current risk, operational owner, evidence, and immediate containment. Discovery may distinguish a local defect from a capacity, dependency, architecture, or policy condition. Acceptance evidence should address the observed failure mode and any changed operating assumption, not only completion of a corrective task.
The three demands may use different records and authorities. The regulatory item may rely on formal interpretation and deadline control. The experiment may emphasize bounded exposure and learning. The reliability item may prioritize containment, recurrence evidence, and operational ownership. The common requirement is a traceable authorization that can explain the current decision without pretending the future is fixed.
These examples also expose a portfolio boundary. Deciding which Work Order deserves funding or scarce capacity belongs to Chapter 17. Chapter 7 does not rank demand. It ensures that when an institution compares or authorizes demand, it is comparing intelligible commitments rather than labels whose uncertainty and obligations are hidden.
Different demand types require different early constraints, evidence, and exits while preserving the same authorization functions; the examples are illustrative, not empirical cases.
What leaders should require
Leaders should not respond by mandating a larger form. They should require that five questions remain answerable throughout work.
First, what outcome and affected parties justify this authorization? If the answer is a feature, project name, or deadline, the demand may still be solution-shaped rather than outcome-bounded.
Second, what is fixed now, what remains open, and why? This reveals whether uncertainty is being managed or concealed. It also protects necessary baselines from casual reinterpretation.
Third, who can make the next material decision? Discovery, scope, acceptance, risk, operation, reframe, and stop may require different authorities. The current owner must be visible before the decision arrives.
Fourth, what evidence would justify the next commitment? The question should name the evidence, its relationship to outcome and constraint, and the boundary of what it can establish.
Fifth, what will happen if the evidence does not support the current path? Reframe and stop must be genuine outcomes. If cancellation is institutionally impossible, discovery is theater and the solution was authorized earlier than the record admits.
Practitioners should be able to answer the same questions without becoming document custodians. The Work Order should reduce reconstruction and translation. It should connect existing engineering, product, risk, contract, and operational records through stable identifiers and decision relationships. Automation may help maintain correspondence, but it cannot decide which uncertainty is acceptable without assigned authority.
The failure modes are symmetrical. A thin ticket can hide outcome, risk, and evidence. A large dossier can create bureaucracy and false certainty. The appropriate record is the least structure that preserves accountable learning across the boundaries the work will cross.
Leaders should also resist converting the Work Order lifecycle into a stage-gate funding model. The states report the condition of authorization, not a sequence of executive approvals. Decision authority should sit at the lowest level able to own the consequence. Some transitions may be automated when policy and evidence make the decision routine. Others require independent challenge. The design question is who can responsibly decide, not how many checkpoints can be added.
A healthy Work Order should become more useful as work progresses. It should reduce repeated explanation, reveal changed assumptions, and make acceptance easier to assess. If participants maintain it only for reporting, copy the same information into several systems, or avoid recording material change because approval is expensive, the implementation has failed its purpose. Those behaviors are evidence about the Factory Operating System around the record.
The Work Order should also survive organizational movement. People change roles, suppliers change, teams reorganize, and platforms evolve. Durable identifiers and explicit ownership allow the decision thread to move without claiming that history is complete. The goal is continuity of authority and evidence, not an immutable archive of every interaction.
Privacy and retention are part of that judgment. Material history may contain user evidence, security information, commercial terms, or personal attribution. Preserve what future decisions require, protect it according to consequence, and retire it under lawful policy. Traceability is not indiscriminate memory.
What to remember
A Work Order is the traceable and progressively elaborated authorization for a unit of demand. It preserves intended outcome, constraints, ownership, risk, acceptance evidence, current production state, and material decision history.
It is author synthesis, not a standard document, universal schema, or proven intervention. Existing tickets, contracts, backlogs, risk systems, and decision records may carry the functions if their relationships remain durable.
Progressive commitment narrows choices as evidence grows. It requires bounded discovery, named authority, evidence expectations, and continue, authorize, reframe, or stop decisions. It does not weaken lawful contracts, baselines, hazard controls, or operational accountability.
Reframe and cancellation are legitimate production outcomes. They must preserve current state and material history so that replacement work inherits obligations and evidence rather than only a new name.
The record must be proportionate. More fields do not create understanding, and more retention does not create Traceability. The test is whether the current authorization and next decision remain explainable.
A Work Order authorizes the next justified commitment, not a fictional certainty about the whole journey.
From authorized demand to production topology
The Work Order makes uncertain demand governable. It identifies the outcome, constraints, authority, evidence, current state, and decisions that the Factory Operating System must coordinate. But authorization does not determine where work should travel.
The same Work Order may need end-to-end outcome ownership, reusable specialist capability, and a context with the right access, data, tools, isolation, and evidence capture. If those design problems are collapsed into one team or reporting line, dependencies and risk can remain hidden. If they are split without explicit interfaces, authorization fragments during execution.
The next question is therefore: How should the factory structure end-to-end flow, reusable capabilities, and safe working environments? Chapter 8 will separate Production Lines, Work Centers, and Work Rooms so that authorized demand can move through coherent interfaces rather than organization-chart assumptions.
An authorized Work Order still needs end-to-end outcome flow, reusable capability, and governed working context; Chapter 7 does not prescribe their topology or route.