Workflow inputs and outputs

Your workflow is a function. What are its arguments?

The previous lesson gave you a map of automation opportunities — steps in your workflows that tools can handle so your judgment is reserved for the work that demands it. You assessed each step for definition clarity, judgment independence, and frequency. You may have already automated your first mechanical step. But a question was lurking underneath every assessment you made, and if you did not notice it, you will notice it now: how do you know whether a step's output is correct if you never defined what "correct" means?

This is the question that separates workflows that work from workflows that sort of work. The difference is specification — the explicit, written, unambiguous definition of what goes into each step and what comes out. Without it, you are running a process on implicit assumptions, and implicit assumptions are where errors breed, where rework hides, and where automation becomes impossible.

Every programmer knows this instinctively. A function has a signature: it declares its parameters (what it accepts) and its return type (what it produces). If you call a function with the wrong arguments, the compiler rejects it. If you expect the wrong return type, your program breaks in a visible, diagnosable way. The specification is not documentation layered on top of the function. It is the function. The signature is what makes the code composable — what lets you chain the output of one function into the input of another without ambiguity about what is being passed.

Your workflows are functions. They accept inputs, perform transformations, and produce outputs. But unlike software, they rarely have explicit signatures. The inputs are "whatever I had on hand when I started." The outputs are "whatever felt done when I stopped." And the result is workflows that cannot be reliably chained, cannot be automated, cannot be delegated, and cannot be diagnosed when they produce the wrong result — because "wrong" was never defined relative to a specification.

The IPO model: the simplest useful framework

The Input-Process-Output model is the most foundational framework in systems thinking, and its simplicity is its power. Every system — mechanical, biological, organizational, cognitive — can be described as a transformation: inputs enter, a process acts on them, outputs emerge. A factory takes raw materials (input), applies manufacturing operations (process), and produces finished goods (output). A human body takes food, water, and oxygen (inputs), applies metabolic processes (process), and produces energy, movement, and waste (outputs). A decision takes information and criteria (inputs), applies deliberation (process), and produces a commitment to action (output).

The IPO model is not deep. You did not need this lesson to know that processes have inputs and outputs. But the model's value is not in the concept — it is in the discipline of applying it. When you sit down to specify a workflow's inputs and outputs explicitly, you discover that what you thought was obvious is actually ambiguous, what you thought was simple is actually complex, and what you thought was a single input is actually five inputs, two of which you have been providing inconsistently.

Consider a workflow as common as "write a weekly team update email." In practice, most people experience this as a single undifferentiated task: sit down, write the email, send it. The IPO model forces you to decompose it. What are the inputs? The list of projects your team worked on this week. The status of each project relative to its deadline. Any blockers that need escalation. Decisions that were made and their rationale. Items that require the reader's action. The audience — who is reading this, and what do they need to know versus what do they want to know? The format conventions — is this a formal document or a casual update?

That is at least seven distinct inputs for a task most people think of as "write an email." And each one has its own source, its own reliability, and its own failure mode. If you do not have the project status information, you either omit it (incomplete output) or chase it down at send time (workflow delay). If you do not know your audience's needs, you write either too much (noise) or too little (gaps). The IPO model does not make the email easier to write. It makes visible all the things that make the email hard to write — and most of them are input failures, not writing failures.

SIPOC: the input-output model that includes context

Six Sigma practitioners extended the IPO model into something more useful for real-world process design: the SIPOC diagram. SIPOC stands for Suppliers, Inputs, Process, Outputs, Customers. The extension is not cosmetic. It adds two critical dimensions that the bare IPO model lacks.

Suppliers answer the question: where do your inputs come from? An input does not materialize from nowhere. Someone or something produces it. Your weekly update email requires project status information — that is the input. But where does it come from? From each team member's task tracker, from the project management tool, from the standup meeting notes, from Slack conversations you happened to catch. Each source is a supplier, and each supplier has its own reliability. If the project management tool is updated inconsistently, the input is unreliable regardless of how well-designed the rest of your workflow is. You cannot fix an input problem by improving the process. You can only fix it by addressing the supplier.

Customers answer the question: who receives your outputs, and what do they need? An output that satisfies you may not satisfy its actual recipient. Your weekly update is thorough, detailed, and well-organized — and your VP skips it every week because she needed the three key decisions in the first two sentences, not buried in paragraph four. The output specification was technically complete but did not account for the customer's actual requirements. SIPOC forces you to define the output not in terms of what you produce but in terms of what the recipient needs to receive. The difference is often enormous.

The SIPOC diagram originated in manufacturing, where the consequences of vague specification are immediately visible: parts that do not fit, products that fail quality inspection, assembly lines that halt because a supplier delivered the wrong material. In knowledge work, the consequences are less visible but equally real. A report whose inputs were gathered haphazardly contains errors that nobody catches until a decision based on the report goes wrong. A design document whose output criteria were never defined is revised endlessly because nobody agreed on what "done" means. A handoff between teams fails because the sending team's output does not match the receiving team's input requirements — a gap that would have been obvious if anyone had drawn the SIPOC diagram before starting work.

Garbage in, garbage out: the iron law of input quality

The phrase "garbage in, garbage out" is older than most people realize — it dates to the earliest days of computing in the 1950s and 1960s, attributed variously to early IBM programmers and to the U.S. Army's data processing operations. The principle is as old as systematic work itself, and it remains the single most violated principle in personal workflow design.

The law is simple: the quality of your output is bounded by the quality of your input. No amount of process excellence can transform bad input into good output. A brilliant analysis built on inaccurate data produces confident wrong conclusions. A beautifully designed presentation built on a confused brief produces polished confusion. An automated workflow built on vaguely specified inputs produces efficiently generated garbage.

Most people experience this as frustration with the process ("this workflow isn't working") when the real failure is upstream in the input ("this workflow was given the wrong material"). The distinction matters because the remedies are completely different. If the process is flawed, you redesign the process. If the input is flawed, you fix the input — which often means going back to the supplier, clarifying the specification, or building a validation check that catches bad input before the process begins.

W. Edwards Deming, the quality management pioneer whose work transformed Japanese manufacturing in the post-war era, made this point relentlessly throughout his career. In "Out of the Crisis" (1986), Deming argued that most quality problems are not caused by workers performing poorly. They are caused by systems that deliver inadequate inputs to competent workers. A factory worker who receives metal stock that is out of tolerance will produce parts that are out of tolerance, regardless of their skill. A knowledge worker who receives a project brief that is ambiguous will produce work that misses the mark, regardless of their talent.

Deming's insight extends directly to your personal workflows. When your writing workflow accepts "a topic" as its input, the ambiguity is not laziness — it is a systems failure. The input specification is too loose. Tightening it — from "a topic" to "a specific question, three source references, a target word count, and a deadline" — does not constrain your creativity. It creates the conditions under which creativity can function. Constraints are not the enemy of good work. Vague inputs are.

Operational definitions: making outputs measurable

Deming introduced a concept that bridges the gap between knowing what your output should be and being able to verify that it is: the operational definition. An operational definition specifies a measurement procedure precisely enough that two different people, applying the definition independently, would arrive at the same result.

"The report should be thorough" is not an operational definition. Two people will disagree about what "thorough" means, and neither is wrong — the definition is simply too vague to produce consensus. "The report should cover all five project areas, include week-over-week metrics for each, flag any metric that changed by more than ten percent, and be no longer than two pages" is an operational definition. Two people applying this definition to the same report would agree on whether it meets the criteria.

Operational definitions are what transform output specifications from aspirations into checkable criteria. Without them, "done" is a feeling — you work until it feels done, and the feeling varies by day, by energy level, by how much you care about this particular instance of the workflow. With operational definitions, "done" is a state that can be objectively verified: either the output meets the criteria or it does not. The verification takes seconds. The ambiguity drops to zero.

This is, in essence, what the Agile software development community formalized as the Definition of Done. A user story is not "done" when the developer feels finished. It is done when the code compiles, the tests pass, the feature matches the acceptance criteria, the documentation is updated, and the code has been reviewed by a peer. Each criterion is an operational definition. Together, they constitute an output specification precise enough that anyone on the team can verify completion without asking the developer how they feel about it.

You can apply the Definition of Done pattern to any workflow output. Your weekly update email is done when it contains the five required sections, when each section has been verified against the project tracker, when the action items are highlighted and assigned, and when the total length is under five hundred words. Your research workflow output is done when you have consulted at least three independent sources, when your notes include direct quotes with page numbers, when contradictions between sources are explicitly noted, and when you have written a one-paragraph synthesis in your own words. Each Definition of Done is specific to its workflow. The pattern — explicit, checkable criteria that define the acceptable output — is universal.

The composability benefit: why specification enables chaining

Here is where input-output specification produces its most powerful return, and it is not the return you might expect. The greatest benefit of precise specification is not that individual workflows run better — though they do. The greatest benefit is that precisely specified workflows can be composed. The output of one workflow becomes the input of the next, reliably, without manual translation, without guesswork, without the informal negotiation that currently happens inside your head every time you transition from one process to another.

In software engineering, this is called composability, and it is one of the most valued properties a system can possess. Unix commands are composable because each one reads from standard input and writes to standard output in a predictable text format. The output of grep feeds directly into sort, which feeds into uniq, which feeds into wc. No command needs to know what the others do. Each one simply needs to produce output that matches the next command's expected input format. The specification — plain text, one record per line — is what makes the chain possible.

Your workflows can achieve the same composability, but only if their inputs and outputs are specified clearly enough to chain. Consider a content production pipeline: the research workflow produces a structured set of notes with source citations. The outlining workflow accepts a set of notes and produces a hierarchical document structure. The drafting workflow accepts an outline and produces a rough manuscript. The editing workflow accepts a rough manuscript and produces a polished final document. Each workflow is a self-contained unit with a defined input and a defined output. The chain works because the output of each stage matches the input specification of the next.

Without specification, the chain breaks. The research workflow produces "some notes" — but some are in a notebook, some are in browser tabs, some are in your memory. The outlining workflow needs "a set of notes" but what it actually receives is a partial, scattered collection that requires twenty minutes of gathering before the outlining can begin. That twenty-minute gap is not part of any workflow. It is the cost of vague output specification from the preceding stage. It is the hidden tax on every workflow transition, and it compounds across every stage of every multi-step process you run.

Precise specification eliminates the gap. If the research workflow's output specification says "a single document containing all notes, each tagged with its source, organized by theme, saved to the project folder" — then the outlining workflow's input is a single, findable, structured document. No gathering. No hunting. No twenty-minute tax. The chain flows because the interface between the stages is defined.

Specifying inputs you did not know you needed

One of the most valuable effects of formal input specification is that it reveals hidden inputs — resources, information, or conditions that your workflow requires but that you have never consciously identified. Hidden inputs are the most common cause of unexplained workflow failures, because you cannot troubleshoot a dependency you do not know exists.

A writing session fails not because you lack skill but because you did not realize that your writing workflow has a hidden input: uninterrupted time. You specified the informational inputs (topic, sources, outline) but not the environmental inputs (a quiet room, a closed browser, a phone in another room, a ninety-minute block without meetings). The writing did not happen because an unspecified input was missing.

A decision-making workflow stalls not because the decision is hard but because you did not realize it has a hidden input: the decision criteria. You gathered the options (explicit input) but never specified the criteria by which you would evaluate them (hidden input). So you stare at the options, unable to choose, and blame indecisiveness when the actual failure is an incomplete input specification.

Making hidden inputs explicit transforms your relationship with workflow failure. Instead of "I don't know why this isn't working," you get "the input specification for this workflow requires X, Y, and Z. I have X and Y. Z is missing. That is the problem." Diagnosis becomes mechanical rather than emotional. You are not broken. Your input is incomplete.

The Third Brain as specification partner

Large language models are remarkably effective at one specific task that is directly relevant to input-output specification: making the implicit explicit. When you describe a workflow to an AI, the AI's questions — or the questions you must answer to write a useful prompt — force you to surface assumptions that were previously invisible.

Try this: describe one of your workflows to an LLM and ask it to identify every input the workflow requires and every criterion the output must meet. The AI will generate a list that includes items you had not consciously identified. Some will be obvious in retrospect. Some will surprise you. The AI is not thinking about your workflow more deeply than you can. It is applying a systematic completeness check that you, as the person embedded in the workflow, tend to skip because the hidden inputs feel so natural that they are invisible.

The protocol that works: use AI to draft the input-output specification, then review it against your actual experience. Remove the items that do not apply. Add the items that the AI missed because they are specific to your context. The result is a specification that is more complete than what you would have written alone — because the AI provided breadth and you provided accuracy.

This is the same pattern from the previous lesson — automate the mechanical generation, retain the judgment about what matters. The AI generates candidate inputs and output criteria. You determine which ones are real, which ones are missing, and which ones are noise. The specification that emerges is a collaboration between systematic enumeration and contextual knowledge.

There is a deeper application as well. Once your workflows have explicit input-output specifications, AI can operate on those specifications directly. You can prompt: "Given these inputs, generate the output according to these criteria." The specification becomes the prompt. The more precise the specification, the better the AI output — which is simply "garbage in, garbage out" applied to AI prompting. Vague specifications produce vague AI output. Precise specifications produce AI output that is close enough to useful that your editorial pass is fast rather than frustrating.

From specification to handoff

You now have the tools to define, precisely, what enters each of your workflows and what exits them. You know how to apply the IPO model to decompose the input. You know how to use SIPOC to trace inputs back to their suppliers and outputs forward to their customers. You know how to write operational definitions that make your output criteria checkable. You know how to use the Definition of Done pattern to eliminate ambiguity about completion. And you know that the real payoff of specification is composability — the ability to chain workflows so that the output of one stage feeds cleanly into the input of the next.

But there is a place in every multi-step workflow where specification matters more than anywhere else, and it is the place where failures concentrate with disproportionate frequency: the handoff. When work moves from one person to another, from one system to another, from one stage to another — that transition is where inputs are lost, where output criteria are misunderstood, where the format changes without anyone noticing, where the assumptions of the sender and the assumptions of the receiver diverge silently until the divergence produces a visible failure downstream.

The next lesson examines these handoff points directly. You will discover that nearly every handoff failure is, at its root, an input-output specification failure — a place where the output of the sending stage does not match the input specification of the receiving stage. The tools you built in this lesson — explicit input lists, operational output definitions, composable specifications — are exactly the tools that make handoffs reliable. The specification is not paperwork. It is the contract between stages, and without it, every transition is a gamble.

---

Sources:

1. Deming, W. E. (1986). Out of the Crisis. MIT Center for Advanced Engineering Study. (Operational definitions, system-caused quality failures.)
2. Pyzdek, T., & Keller, P. A. (2014). The Six Sigma Handbook. 4th ed. McGraw-Hill. (SIPOC diagram methodology.)
3. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. (Definition of Done as explicit output criteria.)
4. Flower, L., & Hayes, J. R. (1981). A cognitive process theory of writing. College Composition and Communication, 32(4), 365-387. (Process specification and recursive decomposition.)
5. McConnell, S. (2004). Code Complete. 2nd ed. Microsoft Press. (Function signatures, interface specification, composability in software design.)
6. Raymond, E. S. (2003). The Art of Unix Programming. Addison-Wesley. (Unix philosophy of composable tools through standard I/O.)
7. Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. North River Press. (Systems throughput and constraint specification.)