Section 3

The gap: what standard notation doesn't see

Standard IDEF0 notation wasn't designed for a world where some mechanisms are AI agents, some controls are designed prompts, some process steps require explicit non-delegable human accountability, and some artifacts cross workflow boundaries carrying the outputs of one system into the inputs of another. None of this is a flaw in IDEF0. The world it was built for has changed.

The gap between what IDEF0 can represent and what human-AI workflows require is small and precise. Four structural elements appear in human-AI workflows that standard notation can't adequately distinguish. Each one matters for governance. Each one needs a shape of its own, or a defined position in a taxonomy, to show up in a diagram.

This section names each gap, explains why it's structurally significant, and states what the Overlap extension provides in response. The extensions are documented in full in Section 4.

Gap 1: the prompt

In standard IDEF0, controls are represented as labeled arrows entering a function box from the top. A policy, a regulation, a standard operating procedure: all appear as control arrows, told apart only by their labels. That works when controls are all the same structural type: external constraints that govern what a function may produce.

A prompt is a different kind of control. It's a designed instruction, written by a human (likely with AI assistance), that directly shapes what an AI mechanism does and how it does it. The prompt specifies the transformation itself. Change the prompt and you change what the AI produces, fundamentally. A prompt that asks an AI to find risks in a board package produces a different output than one that asks it to find opportunities, even on identical inputs.

So in a human-AI workflow, the prompt is the most consequential control at any AI-assisted step. It's also the most likely to go undocumented: used as a habit by whoever wrote it, invisible to everyone else, ungovernable as a result. Making prompts visible as a distinct type of control is a governance requirement. And it lands on the oldest structure in the notation. In the founding paper, the control is what defines an activity box at all: "at least one control arrow is required to define any activity box," and controls "may never be omitted from activity diagrams" (Ross, 1977, p. 26). HAWD takes the element the lineage treats as constitutive and gives its most consequential modern instance a shape of its own.

Standard IDEF0 has no shape that distinguishes a prompt from any other control. The Overlap extension adds one: a tabbed rectangle whose left-side tab signals that this element governs a function without doing the work of it. The label identifies the specific type. The shape makes the structural role visible at a glance.

Gap 2: the AI agent

In standard IDEF0, mechanisms are the people, tools, and resources that enable a function. They are represented as labeled arrows entering a function box from the bottom. The notation makes no distinction between a human analyst, a software application, and a piece of machinery. All are mechanisms. The label tells you which one.

In a human-AI workflow, that equivalence breaks down. An AI agent is not the same kind of mechanism as a human role or a software tool, and the differences matter. An AI agent interprets. A software tool executes. The agent produces outputs shaped by the prompt that governs it, the model it runs on, and the data it's given, none of which is fully deterministic. Its outputs need human review in ways a deterministic tool's outputs may not. And it changes the accountability structure of the workflow: when an AI agent is the mechanism, who's responsible for the output gets more complex than when a human analyst is.

These differences matter for governance. A board that asks whether AI was involved in a decision needs to be able to see, in the workflow diagram, where AI was the mechanism and what governed it. A regulator auditing a high-risk AI system needs the same visibility. Standard IDEF0 notation, which treats all mechanisms as equivalent, cannot provide it.

The Overlap extension adds a circle shape for AI agents, visually distinct from the mechanism stack used for human roles, software tools, and other resources. It's the one mechanism type that always gets its own shape, because AI needs to be visible in any workflow that uses it. Name it where you can (e.g. Claude, Copilot, a custom GPT) so the specific system is on record, not just the category.

Gap 3: the human judgment checkpoint

Standard IDEF0 represents all function steps as rectangles. The notation makes no visual distinction between a step that could in principle be automated and one that requires non-delegable human judgment. This is appropriate for the domains IDEF0 was designed for: manufacturing systems, software processes, service operations. In those domains, the question of whether a step requires human judgment is typically answered by context, not notation.

In human-AI workflows, that question is the governance question. Major AI governance frameworks all require organizations to define where human oversight is mandatory and to show it's consistently applied. The EU AI Act specifically requires high-risk AI systems to include human oversight measures that enable human intervention. A workflow diagram that draws no visual distinction between steps with human oversight and steps without it can't meet that requirement.

A human judgment checkpoint marks a deliberate moment of accountability: a step where a human must interpret, weigh, and decide, and where that accountability can't be handed to an AI mechanism or a software tool. It isn't the yes/no decision a diamond represents. A process step happens to involve a human. A checkpoint requires one.

The Overlap extension adds a hexagon shape for human judgment checkpoints, visually distinct from the process rectangle and from the circle that marks an AI agent. Two different geometries, two different kinds of actor: the circle is where an AI system does the work, the hexagon is where a human decides. The distinction survives a black-and-white printout and never depends on colour. The hexagon says human accountability here is explicit and non-delegable. Decisions can happen inside any function step. The hexagon marks the steps where human judgment is the primary act.

Gap 4: the boundary object

Standard IDEF0 uses terminator shapes to mark the start and end states of a workflow. In the original notation, these shapes signal the boundaries of the system being modelled: the point where inputs arrive from outside and outputs leave to outside.

In a multi-workflow system, which is the normal condition for any organization using AI at scale, the output of one workflow regularly becomes the input or control of another. The governance knowledge assets from a facilitated board workshop become the controls that govern how board materials get prepared. The synthesized insights from one AI analysis step become the inputs to a human judgment step somewhere else in the organization. These cross-workflow dependencies are the connective tissue of the system.

Standard notation has no shape that makes these connections explicit, no way to mark an artifact as a boundary object whose structural role changes as it crosses from one workflow into another. Without that shape, multi-workflow systems get documented as isolated diagrams with no visible connective logic between them.

The Overlap extension uses the pill shape, inherited from the standard terminator, as the boundary object. At the right edge of a diagram, it signals a final output: the terminal deliverable of this workflow, available to whatever comes next. At the left edge, it signals an input arriving from another workflow. The same shape in two positions. Follow the pills across diagrams and you see how workflows connect, which makes the dependencies of a multi-workflow system visible and auditable.

Related work: extending notation for human-AI collaboration

HAWD is not the only recent attempt to extend an established modelling notation for workflows that combine humans and AI. Ait, Cánovas Izquierdo, and Cabot have proposed a BPMN extension for modelling human-agentic collaborative workflows, addressing how humans and AI agents coordinate through a process: agent profiling, roles, reflection strategies, and the handling of uncertainty in agent outputs.

That work and this one are solving different problems, and the difference follows directly from the notations they extend.

BPMN models flow and sequence. It answers the orchestration question: in what order do things happen, who hands what to whom, how do parallel actors coordinate and converge. Extending BPMN for human-agentic work is a natural response to the rise of multi-agent systems, and the resulting notation is well suited to the engineers building them.

IDEF0 models function and governance. It answers a different question: what governs each step, what enables it, who is accountable, and where that accountability cannot be transferred. This is the question the AI governance frameworks are asking, and it's the question a board, an auditor, or a regulator needs a workflow diagram to answer.

The structural consequence is the control rail. BPMN has no equivalent of ICOM's separation between what governs a transformation and what executes it. There is no place in a BPMN diagram for a prompt as a first-class governing artifact, no dual-rail knowledge asset, no structural distinction between a constraint that shapes an output and a mechanism that produces it. That separation is original to the notation HAWD extends: Ross made the control constitutive of the activity box itself, and defined mechanism as support rather than an interface, the means of realizing a function and not a governor of it (Ross, 1977, pp. 23, 26). It is not a detail of HAWD. It is the whole basis of the governance argument this standard makes.

The two approaches are complementary. An organization designing a multi-agent orchestration might reasonably want both: a BPMN-derived model of how the agents coordinate, and a HAWD model of what governs each step and where human accountability sits. That the same problem is being approached from two established notations at once is a signal the field needs the vocabulary, not a sign that either notation is redundant.

What the extensions preserve

Each of these four extensions adds a shape or a defined taxonomy position to the standard IDEF0 vocabulary. None of them changes the underlying logic of the notation. The ICOM model stays intact. Hierarchical decomposition works exactly as it does in standard IDEF0. The rule that every arrow must be labeled, that controls enter from the top and mechanisms from the bottom, that inputs and outputs are structurally distinct: all of it is unchanged.

The core notation principle of HAWD, shape tells you the structural role and label tells you the specific type, extends logic IDEF0 already embodies. In standard IDEF0, a rectangle tells you this is a function and the label tells you which function. A parallelogram tells you this is a data object and the label tells you which one. The Overlap extensions follow the same logic: a tabbed rectangle tells you this is a control and the label tells you which kind. A circle tells you this is an AI agent and the label names it. A hexagon tells you this is a human judgment checkpoint and the label describes the decision being made.

The extensions add to standard IDEF0; they don't replace it. Standard IDEF0 diagrams stay readable within the HAWD notation system. Practitioners familiar with IDEF0 will recognize the foundation immediately and need only learn four new shapes and two taxonomies to apply the full notation.

Section 4 presents the complete notation: all eight shapes, the controls and mechanisms taxonomies, and the core principle in full.