An invitation
to design.

A lot of people are figuring out remarkable things with AI right now.

Some are becoming genuinely more capable: working faster, thinking further, offloading the parts of their work that don't need them. The more technical among them are automating whole steps, building their own small software, replacing tools they used to pay for. Others are at the very start, learning what this thing even is. The range is enormous, and almost all of it is happening the same way: individually, by doing the work.

That's actually a good way to design a workflow. You build it by running it, you feel where it's strong, you notice what's missing. The problem isn't the method. The problem is what comes after. There's no way to take what you worked out and hand it to someone else so they get the same result. We see it on our own team. Even when you sit beside someone and show them exactly what you did, something doesn't carry.

Part of why is that we often can't say precisely what we've built. We know it works. We can't always name what governs the AI step, where our own judgment is doing the real work, or what we had to put in place before any of it held together. We're reaching for something we don't fully have language for yet.

A shared language is what lets one organization learn from another.

That's what a notation is for. It makes an answer transferable: not a story about what an organization did, but a description precise enough for someone else to run. Here is the workflow. Here is what governs each step. Here is where a human has to decide, and why. Here is what had to be built before it would work at all.

That is a thing another organization can actually pick up. It is also, not incidentally, the thing a regulator, an auditor, or a board is going to ask for.

And it opens something up. If a hospital works out a genuinely good way to combine clinical judgment with AI, it should be able to hand that to every other hospital, in a form they can read and adapt to their own context. A field could build a shared library of how it actually works, contributed by the institutions figuring it out, disseminated in a language everyone in that field can read. That barely exists right now. This is a way to do it.

Because the possibilities are not really about efficiency. Efficiency is the first thing people reach for and the least interesting thing available. The workflows worth designing are the ones that solve harder problems: how an organization thinks, how it decides, how it communicates, how it puts human judgment and machine capability together on purpose rather than by accident. Section 8 of the standard is largely a list of those open questions. We would like company in working on them.

Why this is open

A proprietary notation creates a dependency. An open one creates infrastructure.

The standard is licensed under Creative Commons Attribution 4.0. Read it, use it, adapt it, teach it, build on it, extend it for a context we never imagined. Credit the studio that originated it so the lineage stays visible. That is the whole ask.

A notation only becomes a shared language if it's genuinely shared. One that lives behind a gate is a product. One that anyone can pick up, apply, and improve is a commons, and a commons is what this is for.

What v0.9 means, and what the year is for

The standard is released as version 0.9. It's rigorous enough to use now, and it's early enough that the people who use it can still shape what it becomes.

The year that follows this release is an open development period. It is not a comment window. A comment window says: we are finishing this, tell us what is wrong. An open year says: we are building this in the open, come build it with us. Version 1.0 will be what the year produces.

Two kinds of contribution are wanted, and they are deliberately different in weight.

1. Propose something to the standard

A shape the notation is missing. A taxonomy entry that should exist. An extension for a context the original work never imagined. These are reviewed by Overlap as steward, and accepted changes are credited and carried into the next version.

2. Contribute a worked example

Apply the notation to a real workflow. Diagram it. See what it reveals, including what it reveals is missing. Then contribute the result, and the gaps it surfaced, so someone else can learn from work they will never see up close. A notation proves itself by being applied to problems its author never imagined.

Contributors are named. Authorship of the standard stays singular and Overlap remains its steward, because a standard without an editor becomes incoherent. But the people who apply this notation, test it against real work, and improve it will be visible in it.

Interested in this part? We’re developing this section next, but if you’d like to get in touch, please do!

Who this is for

Anyone who designs work that combines human judgment with AI, and who has to be able to explain how it works.

That includes the obvious audiences: consultants and designers building these workflows for clients, operations leads building them inside their own organizations, governance functions who have to sign off on them.

It also includes a set of readers this standard was written with particular care for. Public sector organizations that will have to show a regulator how a decision got made. Health and social service organizations where a human judgment is not a preference but a requirement. Nonprofits and foundations doing genuinely inventive work with very little capacity to document it. Networks of organizations that could learn enormously from each other and currently have no way to.

And boards, who are being told by every framework they read that they must define where human oversight is non-negotiable, and are given no method whatsoever for doing it.

Where the notation comes from

Human-AI Workflow Design extends IDEF0, a function modelling methodology formalized as a United States federal standard and built on Structured Analysis and Design Technique, developed by Douglas Ross. It has been used for fifty years to describe complex systems in aerospace, manufacturing, software, and service design. It survived that long because of one property most process tools lack: it forces a distinction between what governs a step and what performs it.

That distinction is the entire reason it works for AI. When an AI agent does a step, the question that matters is not only what it did but what governed it, and whether a human was accountable for the result. IDEF0 already had a structural place for that question. It just needed four additions to answer it in this context.

Extending IDEF0 for a new domain is also not new. It has been done before for cooperative work, for enterprise reengineering, and, closest to this, for service design, when Carole Congram and Michael Epelman argued in 1995 that services were being produced without ever being designed, and that a notation could fix it. This standard makes their argument again, thirty years later, about a different kind of work.