Section 2

Foundations: the IDEF0 lineage

Good notation systems don't appear from nowhere. They're built on accumulated insight, tested across domains, refined through application, adapted as the problems they address change. Human-AI Workflow Design builds on one of the most durable notation systems in the history of systems design: IDEF0, a function modelling methodology with roots in the late 1960s. It has traveled from aerospace engineering to software development to service management, and now to the design of human-AI workflows.

Where IDEF0 comes from, and why it has survived, is the foundation of the claim that the Overlap extensions are rigorous. Every addition earns its place by structural necessity. The case for that rigor begins here.

Douglas Ross and the origins of SADT

Douglas T. Ross began developing the ideas behind Structured Analysis at MIT in the 1960s. The methodology itself, SADT, was developed in 1972 at SofTech, the firm Ross founded, and introduced commercially in 1973 (FIPS 183, Annex A; Congram and Epelman, 1995, p. 8). It was built against some of the most demanding design problems of the era: describing the design of a "factory of the future" and the US Air Force Computer-Aided Manufacturing Project. The hard part was representational. How do you describe a complex system, one with people, machines, information, decisions, and constraints, precisely enough to act on, clearly enough to share, and in a structure you can break into manageable parts?

Ross's answer was SADT, Structured Analysis and Design Technique. He described it as a "graphic language for blueprinting systems" that has its roots in "'cell modelling' of human-directed activities" (Ross, 1988, p. xii, quoted in Congram and Epelman, 1995, p. 8). The methodology was built around one powerful idea: that any function in any system can be completely described by four types of relationship: what it transforms, what governs how it transforms, what it produces, and what enables the transformation to happen.

These four relationships, Input, Control, Output, Mechanism, became the ICOM model. Every function in an SADT diagram is represented as a box with arrows entering and exiting on four sides: inputs from the left, controls from the top, outputs to the right, mechanisms from the bottom. The arrows have strictly prescribed meanings. In SADT, unlike most workflow tools, every arrow is a typed relationship. It tells you exactly what role the connected element plays in the function.

"Under control, input is transformed into output by the mechanism." —Congram and Epelman, 1995, p. 10

The US Air Force formalized SADT as IDEF0 (Integration Definition for Function Modelling), publishing it as Federal Information Processing Standard 183 in 1993. The formalization preserved Ross's core insight and added a hierarchical decomposition method: any function box can be decomposed into a child diagram showing its internal sub-functions, each one inheriting the ICOM logic of the parent. A complex system can be described at any level of detail, from the broadest single-box summary to the most granular subprocess, without losing structural consistency. One narrowing happened along the way, and this standard inherits it: Ross's original Structured Analysis modelled every subject in two dual decompositions, things and happenings, data and activities, and held that a model is incomplete without both (Ross, 1977, p. 19). IDEF0 standardized the activity decomposition. HAWD extends IDEF0 and works within that inherited scope.

A methodology that travels

IDEF0 was designed for manufacturing systems. It was adopted by software engineers, applied to enterprise reengineering, extended for cooperative work, and adapted for service management. This travel isn't accidental. The ICOM model's durability comes from a property most workflow tools lack: it forces a distinction between what governs a function and what executes it.

In most flowcharts and process maps, a box is a box. What happens inside it, what rules apply to it, and who or what does the work are all either unlabeled or collapsed into a single description. IDEF0 refuses that collapse. A policy that governs a step is structurally different from the person who carries it out. A document that enters a function and gets transformed is structurally different from the tool that does the transforming. These distinctions matter when you need to govern a system, audit it, or improve it.

The application of SADT to service management is worth a close look. In their 1995 paper in the International Journal of Service Industry Management, Carole Congram and Michael Epelman made an argument that maps precisely onto the one this standard makes, thirty years later, for a different domain.

Services, they observed, lacked a design tradition. Unlike manufactured goods, services were rarely specified before they were produced. As Grönroos (1990, pp. 57-8) observed (quoted by Congram and Epelman, 1995, p. 6), "services are not carefully designed before they are produced", leading to quality problems. The tools available for describing service processes shared a weakness Congram and Epelman named directly: "What does a box mean? An activity, an event, a tool? … What do arrows communicate? Usually they indicate flow, but of what?" (1995, p. 7). The result: service managers couldn't reliably document their processes, transfer them to new employees, or identify where quality problems originated.

Their conclusion was unambiguous: "What is needed, if service managers are to take charge of their services, is a disciplined process for describing them" (1995, p. 7). Their response was to introduce SADT to service management. SADT, they wrote, "is the only methodology that structurally provides for" the two attributes service description needs above all others: "who or what performs the activity ('mechanisms' in SADT terms)" and "what guides or limits the activity ('controls')" (Congram and Epelman, 1995, p. 8). These were exactly the dimensions conventional service process tools couldn't represent.

They demonstrated the methodology through a worked example: individual tax return processing at an accounting firm. The diagrams they produced, from the A0 context diagram showing the whole system down to the decomposed child diagrams showing individual sub-processes, made visible what no flowchart could: the specific policies governing each step, the personnel performing each function, the documents flowing between them, and the library and software resources enabling the work. The result was a model the tax manager could use to answer questions she'd never been able to answer before: where do quality checks happen, who's involved, and how can the process be improved?

The parallel to the present moment is direct. Human-AI workflows share with service processes the same representational problem: the tools we currently use to describe them (standard flowcharts, process maps, narrative documentation) can't adequately capture who or what is doing the work at each step, what governs how it's done, and where human judgment is required and can't be delegated. SADT solved this for services. Extended properly, it solves it for human-AI workflows.

The ICOM model in the human-AI context

IDEF0 is the right foundation for human-AI workflow design because of structural fit. The ICOM model was built to make visible exactly the distinctions these workflows require.

Consider what happens when an AI agent processes a transcript to produce a synthesis. In a standard flowchart, this is a single box: maybe labeled 'AI analysis' with an arrow in and an arrow out. That representation is accurate as far as it goes. But it conceals everything that matters for governance. What prompt governed the analysis? What knowledge assets informed it? What constraints applied? Who or what was the mechanism, which AI system, configured how? What was the output, and what is it for?

The ICOM model makes all of this visible by structural necessity. The transcript is an input: it enters from the left and gets transformed. The prompt that governs the analysis is a control: it enters from the top and shapes the work without being consumed. The AI agent is a mechanism: it enters from the bottom and does the work. The synthesis is an output: it exits to the right and becomes available to the next function. Each element has a defined structural role. Nothing is collapsed. Nothing is assumed.

This is the distinction governance requires. A prompt is not an input. An AI agent is not the same kind of mechanism as a human analyst or a software tool. A knowledge asset built from collective judgment can govern one step and enable another. These differences decide whether a workflow is auditable, and whether a process can be replicated or lives only in the memory of the person who designed it.

The ICOM model sees these differences. Standard notation tools don't. That's why IDEF0 is the right foundation, and why extending it for the human-AI context is the right next step in a lineage of adaptations that began in aerospace, traveled through manufacturing and software, found a home in service design, and now arrives here.

The specific extensions HAWD adds to standard IDEF0 notation, and the gap that makes them necessary, are the subject of the next section.