Section 4
The notation
Human-AI Workflow Design uses eight shapes and two rail taxonomies, in a visual language that reads in black and white, distinguished by shape rather than colour. The shapes define structural roles. The taxonomies define the types of controls and mechanisms that can appear in a workflow.
Everything in the notation follows a single principle: shape tells you the structural role. Label tells you the specific type.
A rectangle tells you this is a function step. The label tells you which function. A tabbed rectangle tells you this is a control. The label tells you whether it's a prompt, a strategy, a policy, or a knowledge asset. This principle holds across all eight shapes and both taxonomies. It's what makes the notation learnable in a single session and consistent across teams and organizations.
The eight shapes divide into two groups: four standard shapes inherited from IDEF0, and four Overlap extensions purpose-built for the human-AI context.
The ICOM model: how every function box connects
Before the shapes, the grammar. Every function box in a HAWD diagram connects to other elements through four types of arrow. Understanding these four types, and the distinctions between them, is the foundation of the notation.
Input enters from the left. It's the thing the function transforms. Inputs are consumed or changed: they aren't the same after the function as before it. A workshop transcript entering an AI analysis step is an input. It'll be transformed into something else.
Control enters from the top. It governs how the function runs. Controls aren't consumed: they shape the work without being changed by it. The prompt that governs an AI analysis step is a control. The board's governance priorities that shape how a package gets prepared are controls. Change a control and you change what the function produces, without changing what enters as input.
Output exits to the right. It's what the function produces. Outputs can become inputs to downstream functions, controls governing later steps, or boundary objects that leave the workflow entirely.
Mechanism enters from the bottom. It's what does the work: the person, agent, tool, or resource that enables the function. Mechanisms aren't consumed. A facilitator who runs a workshop is still a facilitator afterward. An AI agent that processes a transcript is still there for the next step. Ross drew this distinction at the origin: mechanism is support, the means of realizing a function, not an interface that specifies it (Ross, 1977, p. 23).
The complete grammar of SADT, as Congram and Epelman expressed it in their gloss of the generic box: under control, input is transformed into output by the mechanism (1995, p. 10, Figure 2). Every HAWD diagram is an elaboration of that grammar.
Standard shapes
Function / process: rectangle
The core unit of every HAWD diagram. Every activity, transformation, or step in a workflow is represented as a rectangle. All four ICOM arrows connect to this shape: inputs from the left, controls from the top, outputs to the right, mechanisms from the bottom.
Figure 4.1 The ICOM model: the structural grammar of every HAWD diagram. A function box (A0) receives Input from the left, is governed by Control from the top, produces Output to the right, and is enabled by Mechanism from the bottom. Every workflow step in Human-AI Workflow Design is expressed through this four-connection structure.
The label names the function using an active verb phrase: Facilitate workshop. Prepare board package. Analyze transcript. Review draft. The label should use the organization's own language, the terms the people who do the work actually use.
Examples: Run workshop, Draft proposal, Process application, Synthesize transcript, Review findings
Data object: parallelogram
A document, file, transcript, report, or any artifact that moves through the workflow as an input or output. The parallelogram represents things consumed or produced at a step, not things that govern or enable.
Figure 4.2 The data object: a parallelogram representing any document, file, transcript, or report that moves through the workflow as an input or output.
Data objects pass through functions. They're transformed or produced, not preserved. A workshop transcript is a data object. A gap report produced by an AI review step is a data object. A proposal draft handed to a reviewer is a data object.
The label names the specific artifact: Workshop transcript. Grant application. Proposal draft. Analysis summary.
Examples: Transcript, Grant application, Client proposal, Meeting notes, Briefing note
Store / library: cylinder
A repository, archive, or body of reference material that accumulates over time and is drawn from repeatedly. The cylinder represents things that persist: not consumed at a single step, but available across multiple functions and workflows.
Figure 4.3 The store: a cylinder representing any library, archive, or body of reference material that accumulates over time and is drawn from repeatedly as a mechanism.
The store is a mechanism shape: it appears in the bottom rail of a function box, contributing to the work without being transformed by it. An archive of past proposals a team draws on when drafting a new one is a store. A methodology library that practitioners consult in their work is a store. A policy repository that a case worker checks against is a store.
The distinction between a store and a data object matters: a data object passes through a step and is transformed. A store is drawn from at a step and remains intact.
Examples: Transcript archive, Past proposals library, Policy repository, Case record
Boundary object: pill
The pill shape marks the edges of a workflow. It is inherited from the standard IDEF0 terminator shape and given a specific meaning in HAWD: it represents an artifact that crosses a workflow boundary.
Figure 4.4 The boundary object: the pill shape marks the edge of a workflow, appearing as both input arriving from outside and final output leaving to outside.
At the right edge of a diagram, the pill signals a final output: the terminal deliverable of this workflow, produced for use outside it. At the left edge, it signals an input arriving from another workflow, an artifact whose structural role changed as it crossed the boundary.
The same artifact can appear as a pill output in one diagram and a pill input in another. Following the pills across diagrams shows how workflows connect and makes the dependencies of a multi-workflow system visible. In a governance context, the pills show where organizational intelligence flows between processes, and where accountability transfers from one team or function to another.
Examples: Approved proposal, Published report, Case decision of record, Synthesized workshop report
Overlap extensions
Control: tabbed rectangle
Any control governing a function step is represented as a tabbed rectangle, a rectangle with a small tab on its left side. The tab signals the structural role: this element governs the function, it doesn't do the work of it. Controls appear in the top rail of the function box they govern.
Figure 4.5 The control: a tabbed rectangle governing how a function step runs. The left-side tab signals: this governs, it does not do the work. Label by type.
The label names the specific type of control. The control shape is a container for the whole controls taxonomy, (see below for the full list). A prompt, a strategic priority, a knowledge asset, a policy, a template, a role boundary: all appear as tabbed rectangles, told apart by their labels.
This shape was added because standard IDEF0 notation treats all controls as equivalent labeled arrows. In human-AI workflows, a prompt that directly shapes an AI agent's output is structurally different from a policy that constrains which outputs are permissible, and that difference needs to be visible. The tabbed rectangle gives you the visual marker. The label gives you the specificity.
Examples: Analysis prompt, Brand and voice guide, Eligibility policy, Reporting template, Role boundary
Mechanism stack: stacked parallelogram
Any mechanism enabling a function step, other than an AI agent, which has its own shape, is represented as a stacked parallelogram. The stacked form signals that mechanisms layer: a function is usually enabled by a combination of people, tools, resources, and assets working together, not a single element.
Figure 4.6 The mechanism stack: stacked parallelograms representing the team, tools, and resources that enable a function step. Label by type.
The label names the specific type of mechanism. The mechanism stack is a container for the mechanisms taxonomy (see below for the full list). A human role, a software tool, a knowledge asset being actively drawn on, a template scaffolding the work, a curated library of reference material: all appear as stacked parallelograms, told apart by their labels.
Examples: Facilitator, Program officer, Case worker, Report template, Software tool
AI agent: circle
A specific AI system doing the work at a function step is represented as a circle. The circle is the one mechanism type that always gets its own shape, not the generic mechanism stack, because AI needs to be visible in any workflow that uses it.
Figure 4.7 The AI agent: a circle representing a specific AI system doing the work at a step. The only mechanism type with its own shape, because AI must be explicitly visible in any workflow that uses it.
The AI agent shape appears in the bottom rail of the function box it enables, alongside other mechanism elements as needed. It's always paired with a control in the top rail: an AI agent operating without a documented control is a workflow design failure, not just a notation gap.
The label names the specific AI system where possible: Claude. Copilot. A named custom GPT. Where the specific system isn't yet determined, the label names the category: Large language model. AI synthesis agent. Naming the specific system is the governance-ready practice: it creates an audit trail a category label doesn't.
Examples: Claude, Microsoft Copilot, Custom GPT, Gemini, AI synthesis agent
Human judgment checkpoint: hexagon
A step where human interpretation, weighing, and deciding is the primary act gets a hexagon shape. The hexagon signals that human accountability here is explicit, required, and non-delegable.
The hexagon and the circle are the notation's two actor shapes: the circle is where an AI system does the work, the hexagon is where a human decides. Distinguishing them by shape, not colour, is what lets a reader tell the AI step from the human accountability moment at a glance, on screen or on paper.
Figure 4.8 The human judgment checkpoint: a hexagon marking a step where human interpretation, weighing, and deciding is the primary act and the accountability is non-delegable.
Decisions can happen inside any function step, including steps represented as standard rectangles. The hexagon marks the steps where human judgment is the central activity: where a person must interpret findings, weigh options, and take responsibility for the outcome in a way that can't be transferred to an AI mechanism or a software tool.
In governance contexts, the hexagon marks the moments that frameworks like the EU AI Act and ISO/IEC 42001 require to be demonstrably present in high-risk AI workflows. It's the visual answer to the question: where, in this workflow, is a human accountable?
Examples: Approve for release, Accept or decline application, Interpret findings, Sign off on analysis, Authorize decision
Controls taxonomy
The controls taxonomy defines what can appear as a control in a HAWD diagram. All controls use the tabbed rectangle shape. The label identifies the specific type from the taxonomy below. This is likely an incomplete list and will expand and grow through use.
Prompt A designed instruction governing an AI-assisted step. The most specific type of control: it directly shapes what an AI agent does and how it does it at that step. Prompts are written by humans, can be documented and versioned, and should be treated as governance infrastructure. Change a prompt and you change the output. That makes prompt documentation a governance requirement, not a best practice.
Knowledge asset Collective intelligence built from human judgment: governance priorities, strategic frames, risk lenses, oversight questions. A knowledge asset governs a step when it's used as a reference frame that shapes what the function produces. Knowledge assets can appear in both rails: when one governs a step it's a control; when it's actively drawn on to execute a step it's a mechanism. That's the dual-rail property, discussed further below.
Strategy / priorities The organization's stated strategic direction or leadership priorities. Governs which issues get elevated, how outputs are framed, and what the function is solving for. Told apart from a knowledge asset by origin: leadership sets a strategic priority, while a knowledge asset usually gets built through a facilitated collective process.
Policy or standard A formal rule, regulatory requirement, or compliance constraint. Governs what's permissible in the function's output. It changes less often than a prompt and binds harder than a priority. Policies govern by exclusion: they define what outputs can't be, rather than shaping what they are.
Template / format A structural constraint on what the output looks like. Governs form, not just content. A board package template, a reporting format, an agenda structure. Appears in both rails: as a control when it governs the shape of the output, as a mechanism when it scaffolds the work itself.
Role boundary A defined scope constraint: what governance versus management means in this organization, what a board member's role permits, which decisions belong at this step versus elsewhere. Governs what the function may decide, not just what it may produce.
Mechanisms taxonomy
The mechanisms taxonomy defines what can appear as a mechanism in a HAWD diagram. All mechanisms, except AI agents, use the stacked parallelogram shape. The label identifies the specific type from the taxonomy below. AI agents use the circle shape and are listed here for completeness.
Human role A person or group doing the work at this step. Named by role, not individual: Facilitator. Board member. Staff lead. CEO. The primary mechanism in human-led steps. Named by role rather than name so the diagram describes the workflow, not the current personnel.
AI agent Uses the circle shape. Named where possible. Always paired with a prompt or other control in the top rail.
Knowledge asset When a knowledge asset is actively drawn on to execute a step, consulted in the room, used to generate outputs, interpreted to do the work, it functions as a mechanism. The same asset that governs one step as a control may enable another as a mechanism. See the dual-rail property note below.
Software tool A non-AI application enabling the function. Miro, Notion, a transcription service, a scheduling system. It executes deterministically, where an AI agent interprets. Named specifically where possible.
Library / resource A curated body of reference material available to the function at this step. Different from the store shape: a library is accessed at a step for specific reference material, while a store is a persistent repository that accumulates and is drawn from over time.
Template / format A reusable structure that scaffolds how work gets done at this step. As a mechanism it organizes the work itself: the template a facilitator uses to run a session, the format that structures how a report gets drafted. Different from a template as control, which governs what the output looks like.
The dual-rail property: knowledge assets
A knowledge asset is the one element in the HAWD taxonomy that can appear in both rails of a function box: as a control governing the step from the top, and as a mechanism enabling it from the bottom.
This is a structural insight about how organizational intelligence works in human-AI systems. A knowledge asset, built from facilitated human conversation and structured into governance priorities, strategic frames, or risk lenses, relates to a function step in two distinct ways.
When it governs how the step runs, setting the frame the function operates within, determining what the output must address, it's a control. It enters from the top. It shapes the work without being transformed by it.
When it's actively drawn on to execute the step, consulted in the room, used as source material for synthesis, interpreted by a facilitator or an AI agent to do the work, it's a mechanism. It enters from the bottom. It enables the function without governing it.
The same asset, the same document, the same body of collective intelligence. In one position it's a control, in another a mechanism. The notation makes that distinction visible and forces the diagram author to say which relationship is in play at each step.
The property extends behaviour the lineage already permits. FIPS 183 provides that an arrow's ICOM role may change on decomposition: a control on a parent box may arrive as an input for a box on its child diagram (§3.3.2.8). The element persists; its role is re-read at each level. The dual-rail knowledge asset applies the same principle across steps rather than across levels: one asset, two structural relationships, each stated explicitly where it occurs.
Section 5 describes how to build a workflow using this notation: the starting questions, the decomposition process, the authoring discipline, and the glossary every HAWD model requires.