Section 5

How to build a workflow

Building a HAWD diagram is a disciplined process. The notation provides the grammar. The process described in this section provides the method for using that grammar to produce a model that's focused, consistent, and useful: one that answers specific questions rather than trying to document everything.

Congram and Epelman (1995, p. 9) stated the foundational discipline of SADT modelling as three steps: formulate the questions the description must answer, state the purpose of the model, determine the viewpoint of the model. Two of those are the methodology's own terms of art. Purpose and viewpoint are what Ross said make a model's structure (Ross, 1977, pp. 17–18), and FIPS 183 defines every IDEF0 model as developed for a specific purpose and from a selected viewpoint (§2.28). The question-first step is Congram and Epelman's contribution, and it earns its place. These three steps apply to HAWD without modification. A diagram built without them turns out either too broad to be useful or too narrow to be shared. The three starting questions are the design decisions that determine everything else.

What questions must this model answer?

Every HAWD model is built to answer a specific set of questions. The questions determine what belongs in the diagram and what doesn't. They set the level of detail required and the scope of the workflow to be modelled.

Formulate the questions before any diagramming begins. They should hang together. As Congram and Epelman observed of the tax manager's questions, they should all pertain to the same process and the same purpose. A question that doesn't connect to the others is a signal: either the model's scope needs rethinking, or that question belongs to a different model.

Well-formed questions look different depending on the sector and the workflow, but they share a shape: each one asks about a specific structural feature of the workflow, and together they point at a single purpose. A private-sector team documenting a client-facing workflow might ask: where does human judgment govern the output before it reaches the client, what controls the AI drafting step and how was that prompt built, and where does brand or quality standard enter as a control? A nonprofit processing applications or reports might ask: what governs how the AI maps incoming information to our fields, where does a program officer's judgment override the automated step, and what has to be documented before this workflow can run without the person who currently holds it in their head? A public-sector or broader-public-service team might ask: where in this workflow is a human accountable for the decision, what makes that accountability auditable after the fact, and what controls ensure the AI step stays within policy?

The pattern holds across all three. Each question asks about a control, a checkpoint, a mechanism, or a boundary, the structural features the notation makes visible, and each connects to the same purpose. Questions that wander outside that purpose, or that could belong to a different workflow entirely, are the signal Congram and Epelman describe: rethink the scope, or move the question to its own model.

What's the purpose of this model?

The purpose statement is a single sentence that says what the model is for. You use it throughout the modelling process as a screening test: any element that doesn't serve the stated purpose doesn't belong in the model.

Congram and Epelman's tax return example states the purpose as: "to identify the sequence of activities to be implemented, and their interrelationships, in order to ensure the smooth flow of work and the timely and accurate processing of individual tax returns" (1995, p. 10). That statement is specific enough to exclude unrelated questions (it would rule out, say, questions about whether the firm's capacity is being used well) while broad enough to cover the full scope of the process being modelled.

A HAWD model for a facilitated workshop workflow might state its purpose as: to document the sequence of activities, controls, and mechanisms that turn participant input into a structured governance output, so the workflow becomes replicable and auditable.

Whose viewpoint does this model represent?

Every HAWD model is built from a specific viewpoint. The viewpoint determines which activities are visible, which controls are relevant, and which mechanisms are named. A model built from the viewpoint of a facilitator will look different from one built from the viewpoint of a board chair or an AI governance auditor, even if they're describing the same workflow.

That's a feature. As Congram and Epelman observe, attempts to combine viewpoints "undoubtedly will diminish the quality of the model, if not render it useless" (1995, p. 10). When a workflow needs describing from multiple viewpoints, build multiple models. Each one holds together. A single model trying to serve all viewpoints serves none of them well.

The viewpoint should be named on the diagram. It's part of the model's metadata, alongside the purpose statement and the node number.

The context diagram: A0

Every HAWD model begins with a context diagram: a single function box, labeled A0, that represents the entire workflow at the highest level of abstraction. The context diagram shows the workflow in relation to its environment, what enters as input, what governs it as control, what produces the outputs, what mechanisms enable it, without showing any internal structure.

The A0 diagram answers one question: what does this workflow do, in the simplest possible terms? It's the frame that holds the detailed model together. Everything in the decomposed diagrams below it must be consistent with what A0 shows entering, governing, and exiting the whole system.

The A0 diagram is also the first governance artifact the model produces. A board or leadership team reviewing an AI-assisted workflow for the first time can read the A0 diagram in minutes. They'll see what inputs the workflow requires, what controls govern it, what outputs it produces, and what mechanisms, human and AI, enable it. That's the governance conversation the diagram is built to support.

Hierarchical decomposition

Once the A0 diagram is complete, any function box can be decomposed into a child diagram that shows its internal sub-functions. The child diagram is labeled with the parent's node number plus a decimal: A0 decomposes into A1, A2, A3, and so on. A1 can itself be decomposed into A1.1, A1.2, A1.3. The hierarchy can go as deep as the purpose and questions require.

The decomposition rule is strict about elements: nothing may appear in a child diagram that wasn't present or implied in the parent. It is deliberately flexible about roles. FIPS 183 provides that arrow roles may differ between parent and child, so a control on a parent box may arrive as an input for a box on its child diagram (§3.3.2.8). The elements persist; their ICOM roles are re-read at each level of decomposition. This rule is what gives HAWD its structural integrity across levels of detail. A reader who understands the A0 diagram won't be surprised by what they find in the child diagrams. They'll recognize the same elements at a finer resolution.

Decomposition continues until the questions posed at the outset are answered. When the diagrams show enough detail to answer them, decomposition stops. The goal is focus, not completeness. As Congram and Epelman note, "it is preferable to develop a library of small models that relate with each other and make the complexities of the process or system comprehensible" (1995, p. 10).

Consistent levels of detail

Within any single diagram, all function boxes should be at a consistent level of detail. A complex sub-process and a simple step shouldn't co-exist as equal elements in the same diagram. When a function box is much more complex than its siblings, that's a signal it needs to be decomposed into its own child diagram.

Consistent levels of detail serve two purposes. They make the diagram readable: a reader can scan the boxes and take them in as one set of activities at the same level of abstraction. And they make the model honest. A diagram where one box hides ten sub-functions and another describes a single simple step misrepresents the relative complexity of the workflow.

The authoring process

HAWD models aren't built alone. The authoring process is collaborative and iterative. The diagram author, usually a consultant, designer, or operations lead, drafts the diagrams from their understanding of the workflow. Then the people who do the work review those drafts: the facilitators, the AI operators, the leaders, the staff who prepare materials.

This review process is called authoring in the SADT tradition, and it is as old as the methodology itself. Ross described a "reader/author cycle" in which authors, experts, and management-level personnel read and critique the efforts of each individual author, and credited that rigorous adherence to quality control with why production models can be relied on (Ross, 1977, p. 20). Congram and Epelman carried the same practice into service modelling: the model-building process "includes a protocol to involve employees, other people who perform activities, management, and customers" (1995, p. 9).

The authoring process serves a governance purpose as well as an accuracy one. When the people who run a workflow have reviewed and validated its HAWD diagram, the diagram carries their authority. It becomes the organization's shared understanding of its own process, documented, reviewed, and agreed, rather than an outside consultant's interpretation of it.

The glossary

Every HAWD model requires a glossary. The glossary defines the terms used in the diagram's labels: the specific language of the organization whose workflow is being modelled.

The glossary is native to the standard itself: FIPS 183 defines an IDEF0 model as a set of diagrams that depict a system "with graphics, text and glossary" (§2.28). Congram and Epelman are explicit about where the terms come from: "All terms used in labels and activities must be from the firm's dialect, with their meaning explained by the diagram author" (1995, p. 14). The glossary is a structural component of the model, as important as the diagrams themselves. A diagram whose terms mean different things to different readers is ambiguity dressed up as precision.

The terms that need defining are the ones an organization uses without thinking, the words that carry a specific local meaning the diagram depends on. A private-sector team might need to define what "qualified lead" means in this workflow, what "client-ready" requires before a draft can pass a checkpoint, or which stage the word "approved" actually refers to. A nonprofit might need to fix the meaning of a field that different program officers phrase differently, "lives impacted" versus "direct beneficiaries", so the AI step maps to it consistently, or define what "eligible" means before an application advances. A public-sector team might need to state exactly where "governance" ends and "management" begins for this model, what counts as a "decision of record," or what "within policy" means at the step where it governs an AI output. In every case the glossary is capturing knowledge that lives in people's heads and making it explicit enough that the diagram means one thing, not several.

The glossary travels with the model. When the model is shared with a new team, used to onboard someone into a role, or reviewed by an auditor, the glossary ensures that the diagram means the same thing to every reader.

A note on purpose and parsimony

The most common failure mode in process modelling is the attempt to build a complete model: one that covers every conceivable situation, every edge case, every variation. Congram and Epelman call this the fallacy of completeness, and note that it always fails, because the variety of situations a workflow can meet is impossible to cover in any one comprehensible model (1995, p. 7).

HAWD models are purposeful, not complete. A HAWD diagram documents the workflow as it's designed to run: the standard path, governed by documented controls, executed by named mechanisms, producing defined outputs. Variations, exceptions, and edge cases are important operational knowledge, but they belong in the glossary, the narrative, or a separate model built for that purpose.

The discipline of purpose and parsimony is what makes HAWD models useful over time. A model that tries to document everything becomes unusable and gets abandoned. A model that documents the designed workflow clearly and precisely becomes the reference point for training, governance, improvement, and audit.

Section 6 applies everything in Sections 4 and 5 to four worked examples, spanning a simple facilitated workshop, a workflow still being designed, a complex multi-day offsite, and one of Overlap's own compounding operating loops, showing how the notation and the building process produce diagrams that reveal what narrative and flowcharts can't.