Part III — Designing the Flow of Work
Designing Production Lines, Work Centers, and Work Rooms
How should the factory structure end-to-end flow, reusable capabilities, and safe working environments?
One public service, many operating contexts
Chapter 7 ended with an authorized Work Order facing three different design needs. Its outcome must move end to end. It may depend on capabilities reused by many lines. It must be performed in contexts with appropriate access, data, tools, controls, and evidence. If those needs are collapsed into a team or reporting line, the authorization can fragment during execution.
The Philippine Identification System, PhilSys, makes the distinction visible. Public records describe a country-owned program adapting the modular open-source MOSIP platform while integrating separately procured registration, biometric, card-production, infrastructure, and systems-integration components. The implementation crossed government institutions, suppliers, partners, hybrid technical environments, local schema and language choices, phased operations, and registration contexts that could function without continuous connectivity.C08-C02
This is not evidence that the program achieved inclusion, reliability, security, cost savings, or any other national outcome. The available records are largely official and program-support accounts. They do establish a topology problem. No platform box could represent the end-to-end public-service outcome. No single supplier owned country accountability. No standard cloud environment described every place where work and service operation occurred.
The reusable platform mattered. So did the flow from policy and enrollment through identity lifecycle and service use. So did the governed contexts in which registration, integration, data handling, support, and operation occurred. These concerns overlapped physically and institutionally, but they were not the same design object.
An organization chart would show agencies, suppliers, teams, and reporting relationships. Those relationships remain real. Employment authority, procurement, budgets, public law, incentives, and accountability cannot be wished away. Yet the chart would not necessarily show how one public outcome travels, which capabilities are reused, or why work under limited connectivity requires a different operating context.
The central question is therefore:
How should the factory structure end-to-end flow, reusable capabilities, and safe working environments?
The answer separates three canonical structures. A Production Line preserves end-to-end outcome flow. A Work Center provides reusable production capability through an explicit interface. A Work Room provides the governed context in which a defined class of work can be performed safely and effectively.
The integrated topology is author synthesis. Modularity, coordination, team-structure, cognitive-load, control, risk, and case evidence constrain and challenge it. No source validates the three labels as an industry standard or proves that separating the concerns improves performance.
The central reframe is:
Design the topology around flow, capability, and context; assign teams to it without mistaking the organization chart for the work.
One public-service outcome can cross shared capability, suppliers, national authority, hybrid infrastructure, and offline local context without proving adoption, inclusion, security, reliability, or cost.
Three structures, three questions
Chapter 5 defined the three structures as part of the Software Factory reference model. This chapter now uses them as design instruments.
A Production Line is an end-to-end, outcome-oriented flow through which a defined class of demand becomes operated software capability and evidence by means of connected Work Centers, Work Rooms, Factory Assets, people, and Digital Workers. It asks: Which recurring outcome must remain continuous across all the work and decisions that produce it?
A Work Center is a reusable production capability serving one or more Production Lines that performs a coherent class of work through defined interfaces, policy, skills, assets, ownership, and service expectations. It asks: Which coherent capability should multiple flows be able to invoke without recreating it?
A Work Room is a governed working environment configured for a defined class of work, containing the access, tools, data, policy, assets, isolation, and evidence capture needed to perform that work safely and effectively. It asks: Under which conditions can this class of work be performed responsibly?
These definitions are logical, not physical. A product team may operate most of a Production Line, provide one Work Center, and use several Work Rooms. A platform team may own several capabilities without each qualifying as a Work Center. One technical environment may host several Work Rooms through distinct policies, identities, data boundaries, and evidence obligations. One Work Room may span on-premise, cloud, supplier, or offline systems.
The structures can also overlap organizationally. A small organization may have one team performing all three functions. Separation does not require restructuring. It requires that the team can distinguish the end-to-end outcome it owns, the capability it offers for reuse, and the contexts in which different work may occur.
The distinction matters because each structure fails differently. A Production Line can fragment at dependencies or optimize local steps while losing the outcome. A Work Center can become an oversubscribed queue, unstable dependency, or mandatory platform that transfers complexity to consumers. A Work Room can obstruct legitimate work, hide unsafe workarounds, or preserve controls that no longer fit the activity.
Calling every product team a line, every platform team a center, and every development environment a room would rename existing structures without improving judgment. A proposed structure earns the name only when it preserves the canonical concern and makes its interfaces governable.
Production Lines preserve outcome continuity
The Production Line begins with a recurring class of authorized demand and ends with operated capability and evidence. Its boundary should remain wide enough to include decisions, work, dependencies, transition, and operation that materially condition the outcome. It should remain narrow enough to guide ownership and flow.
This is not a prescribed lifecycle. Discovery can loop. Work can branch, wait, stop, or reframe. Several increments can proceed in parallel. A Production Line is not a deployment pipeline, project plan, team, value-stream map, or business unit, though any may help represent part of it.
Architecture-description discipline helps frame the boundary. Stakeholders, concerns, viewpoints, elements, relationships, and external interfaces should be visible without assuming that one organizational unit contains them. The line follows accountable outcome continuity across those relationships.
Coordination research adds a caution. Technical dependencies create coordination requirements, and gaps between required and actual coordination have been associated with productivity and failure differences in bounded project settings. These observational findings do not prove that creating a Production Line improves results. They support looking for correspondence between dependencies and the paths through which people decide and communicate.
A useful line test is deletion. Remove the proposed Production Line from the model. If end-to-end ownership, operating outcome, or evidence continuity disappears into local components, the line names a necessary concern. If an existing service, product, or value-flow boundary already preserves the same continuity, keep the local term and avoid creating a duplicate structure.
The line needs an outcome owner, but the owner need not command every participant. Work Centers, suppliers, regulators, users, and operational functions may retain independent authority. The owner is accountable for the continuity of the outcome and for making unresolved interfaces visible, not for absorbing every capability into one hierarchy.
The line also needs a stable relationship to Work Orders. A Work Order carries a bounded unit of demand. The Production Line supplies the end-to-end path and current conditions through which that authorization moves. Several Work Orders may inhabit one line, and one complex Work Order may invoke several lines under explicit ownership. Chapter 17 will govern portfolio choice; this chapter only structures the route.
Work Centers make capability reusable
A Work Center exists when a coherent production capability serves more than one Production Line or has an independent lifecycle that should remain visible. Examples might include identity integration, verification, architecture enablement, release assurance, observability engineering, or specialist data migration. The team name does not decide.
Information hiding provides the design intuition. Parnas argued that modules should hide changeable design decisions behind interfaces rather than merely mirror processing steps. Later analysis connected software design structure to patterns of coupling and change propagation. These studies concern software modules, not organizational design. Their cautious transfer is that a reusable capability should shield consumers from internal decisions while exposing the information necessary to depend on it safely.
A Work Center therefore needs more than an API. It needs a defined capability, consumers, owner, policy, skills, Factory Assets, support expectations, evidence obligations, and change communication. A team offering a service without these relationships may still be valuable, but consumers cannot govern their dependency through the Work Center model.
Reuse can reduce duplicate work, yet it can also concentrate demand. A center that accepts every request through one queue may increase delay across all Production Lines. A mandatory platform can reduce local choices while failing to reduce cognitive load. An unstable interface can push integration work back to consumers. Centralizing specialists can make their expertise visible and simultaneously place it further from outcome context.
Empirical research records several development and infrastructure team structures, including platform teams, but offers a descriptive taxonomy rather than comparative proof.C08-A01 Similarly, research on developer cognitive load confirms a relevant, task- and person-dependent concern measured through heterogeneous methods. It provides no universal threshold, team-size formula, or evidence that a platform reduces load.C08-A02
The Work Center design must therefore be tested from both sides. For consumers: is the capability discoverable, comprehensible, stable enough, supportable, and easier to use than recreate? For the owner: is demand visible, can it be served without chronic overload, are interfaces clear, and does evidence support change? Chapter 10 will address Factory Asset lifecycle and economics. Here the issue is capability topology.
A second deletion test applies. Remove the proposed Work Center. If a reusable capability, its owner, consumer relationship, lifecycle, or evidence duty becomes invisible, the center is useful. If the capability is single-use, local, and has no independent consumers or lifecycle, leave it inside the Production Line rather than manufacturing a shared service.
Work Rooms bind context to work
A Work Room is not just the place software runs. It is the governed context in which a class of work can be performed. Access, privilege, duties, tools, data, policy, assets, isolation, change conditions, and evidence capture form that context together.
Current NIST control guidance makes many of these concerns explicit: access enforcement, separation of duties, least privilege, event records, change impact analysis, restrictions on change, and boundary protection. The catalog does not define a Work Room or prove that implementing controls produces an outcome. It supplies public control anchors that a context may need to select and tailor.C08-S01
A production support room may require operational data and emergency authority unavailable in ordinary development. A safety-consequential integration room may bind specific hardware, versions, simulation, independent evidence, and configuration. An offline public-service room may need local operation, synchronization, protected data handling, and a named local owner. These can be virtual, physical, or hybrid.
The governing word is configured. A generic environment becomes a Work Room only when its conditions correspond to the work. Giving everyone the same locked environment may look consistent while obstructing legitimate tasks. Weak controls can expose data and systems; excessive controls can create workarounds, delay evidence, and move sensitive work into less governed spaces.
The Work Room must also return evidence. Identity, action, configuration, test conditions, change, and operational result may need to be recorded according to consequence. More logging is not automatically better. Evidence must have purpose, protection, retention, and an owner capable of interpreting it.
Risk standards support contextual treatment rather than universal tiers. NASA software requirements likewise use classification and documented tailoring informed by consequence, use, complexity, human dependence, and investment. That is a NASA-specific procedural context, not a universal route taxonomy or an outcome study.C08-S02
The Work Room deletion test is concrete. Remove the room boundary. If materially different access, data, tools, policy, isolation, or evidence conditions disappear, the room is necessary. If ordinary controls already cover the work and no distinct context remains, do not draw one.
The topology and its interfaces
Figure F08.1 shows one Production Line running from bounded demand to operated outcome and evidence. It invokes Work Centers through named request/result interfaces. Selected activities occur inside Work Rooms. Actor tabs show accountable owners without turning teams into topology boundaries. Suppliers, regulators, partners, users, and adjacent systems connect through explicit external interfaces.
Figure F08.1 — Production Line, Work Center, and Work Room topology. A Production Line preserves end-to-end outcome flow, Work Centers expose reusable capability, and Work Rooms provide governed context. Accountable teams and external institutions connect through named interfaces; none of the three structures is automatically a team, department, platform, or environment.
Source: Author synthesis constrained by A02, A16, A18, A24, C08-A01, C08-A02, C08-S01, C08-S02, S03, S06, S17, CS02, C08-CS2, and C08-CS3. Structured specification: figures/F08.1-spec.md.
The interface is where autonomy and coherence meet. A line requesting capability should carry enough Work Order context for the center to understand outcome, consequence, constraints, evidence, and urgency. The center should expose what it provides, which inputs it requires, what evidence it returns, how changes are communicated, and how exceptions or failures are handled.
The Work Room interface is different. It specifies who or what may enter, which data and tools are available, which policy applies, what actions are constrained, how evidence is captured, and who operates the context. A line or center can use several rooms as risk and work change.
External interfaces deserve equal attention. A supplier contract may define service obligations without making the supplier part of the accountable institution. A regulator may constrain a line without performing work. A partner may operate a critical context. The diagram should show responsibility, evidence, and recourse without placing every actor under one hierarchy.
The topology is sufficient only if it makes flow, reusable capability, governed context, actors, evidence, and external interfaces visible. If a case genuinely requires a fourth canonical structure rather than an actor, interface, asset, or control, the model should be reopened. The approved cases do not require one.
The model makes no performance claim. More separation can create more handoffs. Fewer structures can hide shared dependency. Centralization can produce consistency or a constraint. Local control can preserve context or fragment evidence. Design requires a reasoned boundary, not allegiance to a shape.
Interfaces carry the operating model
The topology becomes real in interfaces. A boundary without an interface is only a drawing. A useful interface states the responsibility on each side, the information and evidence exchanged, the authority to change the relationship, expected service conditions, and what happens when the interaction fails.
For a Production Line invoking a Work Center, the request should preserve outcome context without transferring all line complexity. The center needs to understand the class of work, consequence, applicable constraints, required evidence, and timing relationship. The line needs to understand capability limits, prerequisites, expected response, returned evidence, and change policy. If either side relies on personal negotiation to discover these conditions, the interface is not yet governable.
This does not mean every interaction becomes a service-level agreement. A short-lived collaboration may need only a named owner and a shared decision record. A high-consequence shared capability may require formal compatibility, support, recovery, and assurance conditions. The interface should be proportionate to dependency and consequence.
Work Room entry has its own interface. Identity and authorization answer who or what may act. Data and tool conditions answer what is available. Policy and isolation answer what is constrained. Evidence and operation answer what must be recorded and who maintains the context. A room that grants access without making those relationships intelligible can be secure in one sense and unsafe in another.
External interfaces require explicit recourse. A supplier may meet a technical interface while withholding evidence needed for institutional accountability. A partner may depend on local connectivity or training that the central design treats as outside scope. A regulator may require evidence that no internal system currently preserves. Naming an external node without naming responsibility, evidence, and recourse leaves the important boundary unresolved.
Interfaces also change. A Work Center can revise a dependency, a Work Room can strengthen a control, and a Production Line can discover a new operating obligation. Change policy should identify affected consumers, compatibility expectations, migration evidence, and authority to accept or stop. Otherwise modularity merely delays coupling until change occurs.
The interface quality test is counterfactual: could a capable new participant understand the relationship without relying on the people who created it? Complete independence is unrealistic, and tacit knowledge will remain. The aim is to prevent essential authority, constraint, and evidence from existing only in personal memory.
A Production Line preserves end-to-end outcome flow, Work Centers expose reusable capability, and Work Rooms provide governed context. Accountable teams and external institutions connect through named interfaces; none of the three structures is automatically a team, department, platform, or environment.
Shared capability, mission-specific assurance
NASA's core Flight System, cFS, tests the Work Center and Work Room distinction in embedded software. cFS provides a reusable layered framework, while each adopting project has a particular hardware and software configuration, operating system, component versions, reusable applications, mission-specific applications, and risk context.
A NASA technical study examined cFS use, change and configuration patterns, verification and validation practices, tool and process reuse, assurance-evidence reuse, gaps, and risks. The public record indicated that shared process and tooling were more reusable than broadly transferable assurance packages. It also warned that perceived maturity could reduce targeted verification and validation.C08-C01
The evidence is bounded. The study was contractor-authored NASA research, not a randomized outcome evaluation. It does not authorize a safety, cost, schedule, or certification claim. Its value is structural: common code and capability do not erase configuration-specific evidence obligations.
Through the topology, cFS can be viewed as shared capability and related Factory Assets invoked by mission Production Lines. The consuming mission still needs Work Rooms corresponding to its hardware, versions, applications, data, simulation, assurance, and operational conditions. An interface that exposes only code compatibility is incomplete if acceptance depends on mission-specific evidence.
The case prevents an easy platform story. Heritage may reduce development work. Common tools and processes may help. But perceived maturity is not assurance evidence, and one project's evidence may not transfer to a changed configuration. The Work Center should make reusable evidence discoverable while the Work Room and line owner remain responsible for deciding its fitness.
Transfer only the distinction between shared capability and consuming context. Do not transfer NASA classifications, assurance procedures, or institutional roles to ordinary enterprise work.
Regulated enterprise, shared flight capability, and public infrastructure records test topology boundaries without establishing adoption, safety, inclusion, cost, or comparative outcomes.
Public accountability crosses the platform boundary
Return to PhilSys/MOSIP. The reusable platform could be understood as shared capability, but the public-service outcome crossed much more: country law and ownership, procurement, integration, local schema and language, devices, biometric components, hybrid infrastructure, partners, training, connectivity, operations, and service accountability.C08-C02
The Production Line follows the public outcome rather than the platform provider. Work Centers may include reusable identity lifecycle, integration, verification, or infrastructure capabilities. Work Rooms differ across central integration, protected data operations, partner contexts, and sites able to function with constrained connectivity.
The interfaces are institutional as well as technical. The country owner cannot delegate public accountability merely because a supplier integrates components or an open-source program maintains a platform. Conversely, the accountable institution does not control every external contributor. It needs explicit ownership, evidence, change, and recourse at each boundary.
The official records emphasize intended benefit and progress and do not provide evidence for causal inclusion, reliability, security, cost, or superiority. They also do not supply a complete worker or resident perspective. The case supports adaptation and boundary reasoning only.
Its strongest transfer is contextual. A reusable capability must be adapted to law, connectivity, language, operational practice, partner capacity, and public responsibility. Offline or hybrid operation is not a lesser route. It is a different Work Room condition requiring its own integration, synchronization, protection, evidence, and local ownership.
A regulated line cannot end at the team
DBS provides the third stress test. Chapter 5 used its public records to show why a Software Factory boundary can cross architecture, operations, suppliers, governance, and regulation. Here the case tests topology.
The bank's customer journeys crossed applications, infrastructure, third-party systems, operational processes, change controls, monitoring, technology-risk oversight, board accountability, and regulatory conditions. No product team or platform alone could own every relationship, even if local teams had strong end-to-end responsibility.
A Production Line can preserve the customer or service outcome across those dependencies. Work Centers can expose reusable capabilities such as identity, resilience testing, or observability. Work Rooms can provide near-production, operational, or controlled-change contexts. Suppliers and the regulator remain connected through interfaces and authority that the line does not absorb.
The record does not prove that this topology existed, caused an incident, or would have prevented one. It does not justify copying the bank's architecture, response, or governance. It shows why a simple autonomous-team model can hide institution-level accountability and external dependencies.
Across DBS, cFS, and PhilSys, the forms differ. One is a regulated enterprise, one an embedded reusable framework across mission configurations, and one a public digital infrastructure adapted through country institutions and suppliers. The three structures remain explanatory because they preserve different concerns, not because the cases adopted the terms.
Routes vary by context and consequence
One topology can support different routes. Figure F08.2 compares ordinary, constrained-context, and elevated-consequence paths. These are composable examples, not universal risk tiers or a maturity ladder.
Figure F08.2 — Illustrative routing variants by context and consequence. Work may use different access, boundary, evidence, impact-review, and specialist paths while retaining common ownership, policy, interfaces, and outcome concepts. The routes are examples; classification and tailoring remain contextual.
Source: Author synthesis constrained by C08-S01, C08-S02, S06, S07, S17, C08-C01, C08-C02, and CS02. Structured specification: figures/F08.2-spec.md.
The ordinary route may use standard authenticated access, automated and peer evidence, a normal impact check, and an outcome-owner decision. Ordinary does not mean consequence-free. It means existing controls fit the current work.
The constrained-context route may add offline or hybrid operation, partner-controlled interfaces, synchronization evidence, and local operational ownership. The distinction comes from context, not lower maturity.
The elevated-consequence route may add separated duties, stronger isolation, configuration-specific evidence, targeted specialist or independent challenge, and an explicit residual-risk decision. Higher consequence does not require every control to be manual or sequential. Automation and early evidence may reduce both delay and risk.
Every route retains the Work Order, outcome owner, applicable policy, named interfaces, evidence record, and continue, correct, stop, or reframe decision. Routes can combine dimensions, shorten, strengthen, or change after evidence changes.
Classification itself requires review. Understatement can route work through insufficient controls. Overstatement can create delay, unequal access, and ritual. A route that excludes people in constrained environments or makes legitimate work impossible has not become safer merely because it is more restrictive.
Detailed Quality Gate and exception mechanics belong to Chapter 14; governance authority belongs to Chapter 18. The principle here is that differentiated routes preserve shared semantics and accountability while adapting context and evidence.
Work may use different access, boundary, evidence, impact-review, and specialist paths while retaining common ownership, policy, interfaces, and outcome concepts. The routes are examples; classification and tailoring remain contextual.
Designing without topology theater
Leaders can test a proposed topology through six questions.
First, what outcome remains continuous? If the proposed Production Line ends at code completion or a team boundary while operation and evidence sit elsewhere, the line is incomplete.
Second, what capability is genuinely reusable? Name consumers, interface, owner, support, change, and evidence. If none exists independently, keep the capability local.
Third, what context is materially different? Identify access, data, tools, policy, isolation, operation, and evidence conditions. Do not create a Work Room for visual symmetry.
Fourth, where do dependencies require coordination? Compare technical dependencies with decision and communication paths. A boundary that hides permanent negotiation is not modular.
Fifth, what cognitive burden moves to the consumer? A shared capability that exports configuration, policy, or diagnostic complexity may centralize ownership without reducing work.
Sixth, how can the route fail or exclude? Examine queues, misclassification, workarounds, unequal access, unstable interfaces, missing assurance, and external parties without recourse.
Reporting lines remain part of the answer. A logical Production Line cannot override employment authority, budget control, legal accountability, or safety responsibility. The design task is to expose where those authorities support or obstruct the flow, not pretend the topology replaces them.
Topology should be revised when evidence changes. A capability may become broadly reusable and deserve a Work Center. A center may lose independent consumers and return to a line. A distinct Work Room may become unnecessary when ordinary controls improve. A context may require stronger separation after risk changes. The diagram is a current hypothesis about responsibility and interface.
Revisions should follow material change rather than fashion. A reorganization alone does not require new Production Lines if the outcome flows are unchanged. A new platform does not require a new Work Center unless reusable capability and consumer obligations change. A new cloud account does not require a Work Room unless its access, data, policy, isolation, tool, or evidence context differs materially.
The opposite error is to preserve obsolete boundaries because tools and budgets were built around them. If several lines repeatedly bypass a center, the cause may be poor consumer fit rather than resistance. If teams copy data into informal environments, the Work Room may obstruct necessary work. If operation continually discovers dependencies outside the line, the outcome boundary may be too narrow. Workarounds are not always justified, but they are topology evidence.
The three structures should therefore have different health questions. For the line: is the outcome moving end to end, and can evidence change demand or route? For the center: are consumers succeeding without hidden dependency cost, and can the owner sustain capability? For the room: can legitimate work occur with proportionate control and usable evidence? One score cannot answer all three.
Nor should the structures share one lifecycle. A Production Line may persist as long as a recurring outcome remains. A Work Center may emerge, mature, split, combine, or retire as consumer demand changes. A Work Room may be created for a campaign, incident, release class, or continuing operational context. Forcing them into synchronized planning cycles can obscure their different reasons for existence.
These distinctions help leaders locate investment without deciding it here. A line may reveal recurring friction that suggests reusable capability. A center may reveal consumer burden that suggests better assets. A room may reveal control friction that suggests improved environment design. Chapter 17 will compare allocations; the topology makes the objects of investment visible.
The smallest viable topology is usually the best starting hypothesis. Add a structure only when its removal hides an important responsibility, dependency, context, or evidence path. Simplicity is not box count alone: three well-named boxes with informal, unstable interfaces can be harder to operate than a richer map whose responsibilities are explicit. The purpose is not minimal drawing. It is minimal ambiguity about how authorized work reaches an operated outcome.
Executives should be suspicious when every box is green but cross-boundary work remains slow. A well-labeled topology can still contain overloaded centers, long queues, large batches, delayed feedback, and no response capacity. Structure makes those conditions visible; it does not manage them.
Six equal questions test outcome continuity, genuine reuse, distinct context, dependency coordination, consumer burden, and failure or exclusion without producing a score.
What to remember
Production Lines, Work Centers, and Work Rooms separate outcome flow, reusable capability, and governed context. They are logical structures, not automatic synonyms for teams, departments, platforms, environments, or process stages.
The integrated topology is author synthesis. It supports completeness and diagnosis, not a causal claim that structural separation improves performance.
Choose boundaries through flow, reuse, dependencies, cognitive burden, risk, and evidence. Reporting lines remain real and must be connected, but they should not silently define the production system.
Shared capability can reduce duplicate mechanism work while concentrating demand or hiding consumer complexity. Governed context can protect work while obstructing it when controls do not fit.
Routes may vary by context and consequence while retaining common ownership, policy, interfaces, evidence, and decision semantics. More checks are not automatically safer, and lower ceremony is not lower accountability.
Design the topology around flow, capability, and context; assign teams to it without mistaking the organization chart for the work.
From topology to flow under variability
The Work Order now has a route. Production Lines preserve end-to-end outcomes, Work Centers provide reusable capability, and Work Rooms provide governed context. Their interfaces make dependencies, evidence, and authority visible.
But a visible topology can still fail in operation. Several lines can compete for the same Work Center. A constrained Work Room can become a queue. Large batches can delay integration. Urgent work can displace existing commitments. Variability can consume the capacity that a diagram assumes is available.
That is where Chapter 9 begins: How can leaders improve speed and predictability when uncertain work competes for finite capability? The next task is not another structure. It is to manage work in progress, queues, constraints, batch size, buffers, and feedback without equating full utilization with flow.
A visible topology can still overload shared capability and constrained contexts when variable Work Orders compete for finite capacity, creating the Chapter 9 flow question.