References

This standard follows the convention of separating normative references, the works this standard depends on structurally, from informative references, the works that inform its argument or situate it in a wider field. A reader who wants to understand where the notation comes from should begin with the normative references. A reader who wants to understand why it was built should begin with the informative ones.

Citations in the text follow author-date form, with page numbers where a specific passage is relied on.

Normative references

These works define the methodology HAWD extends. The notation cannot be fully understood, and could not have been built, without them.

Ross, D. T. (1977). "Structured Analysis (SA): A Language for Communicating Ideas." IEEE Transactions on Software Engineering, SE-3(1), 16–34.

The founding paper. Ross had developed, taught, and applied SA at SofTech for almost three years before setting down its design rationale here for the first time. His insight, that any function can be completely described by what it transforms, what governs the transformation, what it produces, and what enables it, is the ICOM model, and it is the foundation of everything in this standard. The paper also states, in Ross's own words, three things this standard depends on: purpose and viewpoint are what make a model's structure (pp. 17–18), at least one control arrow is required to define any activity box (p. 26), and mechanism is support, not an interface (p. 23). The author/reader review cycle that Section 5 builds on appears here too (p. 20).

National Institute of Standards and Technology (1993). Integration Definition for Function Modeling (IDEF0). Federal Information Processing Standards Publication 183. Gaithersburg, MD: U.S. Department of Commerce.

The formalization of SADT as a federal standard. FIPS 183 preserved Ross's ICOM model and specified the hierarchical decomposition method: any function box may be decomposed into a child diagram whose elements must remain consistent with the parent. HAWD's node numbering, decomposition rule, and diagram syntax follow FIPS 183.

Congram, C., and Epelman, M. (1995). "How to describe your service: An invitation to the Structured Analysis and Design Technique." International Journal of Service Industry Management, 6(2), 6–23.

The precedent for what this standard does. Congram and Epelman argued that services lacked a design tradition, that existing process tools could not represent who performs an activity or what governs it, and that SADT supplied exactly those two dimensions. They then demonstrated the methodology on a real workflow. HAWD makes the same argument, thirty years later, for a different domain, and follows the same method: take a methodology built for one class of system, extend it precisely, and prove it on real work. The question-first discipline, the fallacy of completeness, and purpose and parsimony are drawn directly from this paper; purpose and viewpoint themselves are Ross's terms, which Congram and Epelman carried into service design.

Informative references

The SADT tradition

Marca, D. A., and McGowan, C. L. (1988). SADT: Structured Analysis and Design Technique. New York: McGraw-Hill.

The book-length treatment of SADT in practice. Earlier drafts of this standard routed foundational claims through Congram and Epelman's reading of this book. Those claims are now cited to the primary record directly: the author/reader review cycle (Ross 1977, p. 20), purpose and viewpoint (Ross 1977, pp. 17–18; FIPS 183 §2.28), and the glossary requirement (FIPS 183 §2.28). Marca and McGowan remains the fullest account of the method's day-to-day discipline.

AI governance frameworks

Section 7 maps HAWD's structural elements to the requirements these frameworks state. Each of these has been consulted in its primary published form.

International Organization for Standardization / International Electrotechnical Commission (2023). ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. First edition. Geneva: ISO/IEC.

The first international standard for AI management systems, and the only framework discussed in Section 7 against which an organization can be certified. Clause 8 requires documented, controlled processes with retained documentation. Annex A, which is normative, includes control A.9.2: the organization shall define and document the processes for the responsible use of AI systems. Annex B's implementation guidance asks organizations to determine at which life-cycle stages meaningful human oversight is incorporated, and to involve reviewers with authority to override AI decisions. HAWD is a method for producing what these controls require.

ISO text is copyright-protected and is not reproduced in this standard. All requirements are paraphrased and cited by clause.

European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, L series, 12 July 2024. ELI: http://data.europa.eu/eli/reg/2024/1689/oj

The most prescriptive AI regulation yet enacted, and binding law within the EU market. Article 14 requires that high-risk AI systems be designed so that natural persons can effectively oversee them, and specifies that those persons must be able to disregard, override, or reverse the system's output, and must remain aware of the tendency to over-rely on it (automation bias). Article 14(3) distinguishes oversight measures built into the system by its provider from measures the deployer implements. Article 26 obligates deployers to assign oversight to persons with the necessary competence, training, and authority. Annex IV requires technical documentation that includes an assessment of the human oversight measures needed under Article 14.

National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. Gaithersburg, MD: U.S. Department of Commerce.

Organizes AI risk management into four functions: Govern, Map, Measure, and Manage. The Govern function asks organizations to establish accountability structures, documentation practices, and processes for human oversight. The Map function asks them to understand the context in which AI systems operate. HAWD's mechanisms rail, node narratives, human judgment checkpoints, and A0 context diagram respond to these requirements structurally.

Related notation work

Ait, A., Cánovas Izquierdo, J. L., and Cabot, J. (2026). "Towards Modeling Human-Agentic Collaborative Workflows: A BPMN Extension." In Software Engineering and Advanced Applications (SEAA 2025). Lecture Notes in Computer Science. Cham: Springer. Preprint: https://arxiv.org/abs/2412.05958

The closest published work to this standard, and the reason Section 3 addresses it directly. Ait and colleagues extend BPMN to model workflows in which humans and AI agents collaborate, addressing orchestration: agent profiling, roles, reflection strategies, and uncertainty in agent outputs. BPMN models flow and sequence; IDEF0 models function and governance. The two extensions answer different questions, and BPMN has no equivalent of ICOM's separation between what governs a transformation and what executes it. That two established notations are being extended toward this problem at once is a signal the field needs the vocabulary.

Service design and the design tradition

Grönroos, C. (1990). Service Management and Marketing: Managing the Moments of Truth in Service Competition. Lexington, MA: Lexington Books.

Cited by Congram and Epelman for the observation that services are rarely designed carefully before they are produced, and that quality problems follow. The parallel to the current condition of human-AI workflows is the argument this standard opens with.

Works this standard does not cite, and why

Two categories of source are deliberately absent.

Specific AI tools, models, and platforms. The capabilities of AI systems change faster than any standard can track, and a notation that cited them would date immediately. Tool-specific knowledge lives in the companion layer, in the capability map maintained alongside this standard, precisely so that the standard does not have to chase it. Where a tool is named in this document, it is named as an example of a mechanism, not as a recommendation.

Consultancy frameworks and vendor guidance on AI governance. There is a large and growing body of it. Little of it is method, and none of it is notation. Section 7 engages with the governance frameworks that organizations are actually held to, and leaves the rest.