In IDEF0, classify an arrow by its relationship to one named function: an Input is transformed, a Control constrains how correct output is produced, a Mechanism performs or enables the work, and an Output is produced. For “Issue purchase order,” the selected quotation is an Input, the approval matrix and budget limit are Controls, the authorized buyer and ERP system are Mechanisms, and the issued purchase order is the Output. The noun itself does not determine the role; the function boundary does.
Scope and status before using the notation
IDEF0 is a functional-modeling method: boxes state what must be accomplished, while arrows name the data or objects that constrain those functions. It is not a flowchart clock. An arrow between boxes says the receiving function needs that interface; it does not by itself prove execution order, duration, responsibility, system permissions, or process compliance.
The primary notation reference here is NIST's FIPS PUB 183, issued in 1993. NIST's official withdrawal index records that FIPS 183 was withdrawn as a Federal Information Processing Standard on September 2, 2008. Therefore this article uses FIPS 183 as the published definition of IDEF0 syntax and semantics—not as a claim that it is a current federal mandate. NIST still publishes a live circular-economy manufacturing model that uses IDEF0 activities, decompositions, and ICOM concepts, which demonstrates current practical use without restoring the withdrawn regulatory status.
The four roles are always relative to a particular function:
| Role and attachment | Question at this box |
|---|---|
| Input · left | What data or object does this function transform into an output? |
| Control · top | What condition, rule, or constraint is required for correct output? |
| Output · right | What data or object does this function produce? |
| Mechanism · bottom | What person, system, tool, or other means performs or supports the function? |
FIPS 183 also separates grammar by part of speech: function boxes use active verbs or verb phrases; interface arrows use nouns or noun phrases. “Select supplier” is a function. “Approved supplier list” is an interface. Naming a box “Supplier selection” hides the action, while naming an arrow “Check supplier” turns an interface into an undocumented activity.
Worked classification: issue a controlled purchase order
Assume a fictional procurement process whose purpose is to turn an authorized business request and supplier information into an issued purchase order. The model viewpoint is the internal procurement team. It deliberately stops before goods receipt, invoice matching, payment, legal terms review, and supplier performance management.
The three functions are:
- Validate requisition — establish that the request contains usable requirements under the procurement policy.
- Select supplier — evaluate quotations against the validated requirements and approved supplier constraints.
- Issue purchase order — create the controlled commitment from the selected quotation under approval and budget constraints.
Now test the disputed nouns one at a time.
Purchase requisition is an Input to “Validate requisition.” That function transforms the original request into validated requirements. Calling it a Control merely because it authorizes work would obscure the modeled transformation.
Procurement policy is a Control. The function does not turn the policy into a new product. The policy constrains what counts as a valid requisition and therefore enters from the top.
Buyer is a Mechanism for validation; buyer and ERP are Mechanisms for issuance. They are means used to perform the functions. The model does not consume the buyer or transform the ERP into an issued purchase order.
Supplier quotations are Inputs to “Select supplier.” They are evaluated and transformed, together with validated requirements, into a selected quotation. The approved supplier list is a Control because it limits which candidate can be accepted.
Selected quotation changes role at the next boundary. It is the Output of “Select supplier” and the Input to “Issue purchase order.” This is expected: ICOM is not a permanent label attached to a document everywhere in the model.
Approval matrix and budget limit are Controls on “Issue purchase order.” They define conditions for a correctly authorized commitment. The authorized buyer and ERP are Mechanisms. The issued purchase order is the Output.
Reproducible Schematex source
idef0 "Issue a controlled purchase order"
node A0
function A1 "Validate requisition"
function A2 "Select supplier"
function A3 "Issue purchase order"
input A1 "Requisition"
control A1 "Procurement policy"
mechanism A1 "Buyer"
A1 -> A2 "Requirements"
input A2 "Quotes"
control A2 "Approved supplier list"
mechanism A2 "Buyer + records"
A2 -> A3 "Selected quote"
control A3 "Approval matrix + budget"
mechanism A3 "Buyer + ERP"
output A3 "Issued PO"Schematex 1.0.13 strictly parsed and rendered this source on September 4, 2026. It returned no diagnostics. The SVG contains three function boxes numbered contiguously A1 through A3 and eleven interface arrows: four with an Input role, three Controls, three Mechanisms, and one final boundary Output. Two of the four Input-role arrows are internal flows whose source is the preceding function's output. No arrow targets a function through its output side. The current Schematex IDEF0 syntax reference documents ICOM placement, reference resolution, decomposition numbering, boundary coding, and the three-to-six-box structural check.
That validation is structural. It proves that the declared interfaces obey the supported grammar and attach to allowed sides. It cannot prove that the procurement policy is current, that a buyer has authority, that a budget exists, that supplier data is accurate, or that the model boundary matches a real organization.
The two ambiguity tests that matter
First ask whether the function transforms the item. A supplier quotation is transformed by “Select supplier” into a selected quotation, so it is an Input there. The same document might be a Control for a different function, such as “Audit supplier selection,” where it constrains what evidence the audit must examine but is not itself transformed into the audit conclusion.
Second ask whether the item constrains correct output or provides the means of execution. An approval matrix constrains who may approve a commitment, so it is a Control. The authorized buyer performs the work, so the buyer is a Mechanism. Writing both above the box as generic “resources” would erase the difference the model is meant to expose.
FIPS 183 gives a conservative tie-break: when one interface genuinely combines Input and Control meaning, show it as a Control; it also advises revisiting uncertain arrows instead of crowding a high-level diagram. Use that rule after defining the function precisely, not as a shortcut for putting every document on top.
Checks and invariants
- Every box is an action. “Validate requisition,” “Select supplier,” and “Issue purchase order” are active verb phrases.
- Every arrow is a thing. Labels are nouns or noun phrases, not hidden process steps.
- Every function has a Control. Removing policy or authorization constraints would make “correct output” undefined in this example.
- Inputs are transformed. The model can state what becomes different because each Input was used.
- Mechanisms remain means. People and systems enable the function; they are not mislabeled as the material being transformed.
- Outputs have a producer. Validated requirements, selected quotation, and issued purchase order originate from named functions.
- Roles may change by boundary. Selected quotation is an Output from A2 and an Input to A3 without contradiction.
- The diagram has one viewpoint and boundary. It does not silently mix the requester's, supplier's, accounts-payable team's, and procurement team's models.
- Three boxes are enough at this level. More detail belongs in child decompositions rather than extra arrows and micro-steps on one page.
Failure modes and review boundary
The most common error is treating IDEF0 as a left-to-right timeline. The picture may be read left to right, but the arrows describe interface constraints, not elapsed sequence. Use BPMN, a flowchart, or a schedule when waiting states, branching, concurrency, handoffs, or timing are the claim.
Other failures include putting all documents above the boxes because “documents are controls,” putting every software system below every box without checking actual use, naming boxes with departments instead of functions, making an arrow carry both a task and a noun, and decomposing the model until the page becomes an operating procedure. A valid IDEF0 diagram can also be factually wrong because it omitted a control, misidentified the transforming function, or adopted the wrong viewpoint.
Take one disputed arrow from a real model and write four sentences: what the function transforms, what constrains correct output, what performs the work, and what the function produces. Keep the noun only in the role supported by those sentences. Then paste the revised three-to-six-box source into the Schematex playground, inspect the attachment sides, and have the process owner review the semantics rather than only the layout.