The short answer: an IDEF0 diagram is ready for review when its purpose and viewpoint are explicit, every function box uses an active verb phrase, every arrow has one defensible Input-Control-Output-Mechanism role, and every decomposed child diagram preserves the boundary promised by its parent. The box layout is the easy part. The review is really about whether the model states what changes, what governs the change, what performs it, and what result leaves the function.
This checklist applies to an IDEF0 function model used to analyze what a system or enterprise does. It is not a flowchart of event order, an organization chart, a data model, or a physical architecture. ISO lists ISO/IEC/IEEE 31320-1:2012 as the current published IDEF0 syntax and semantics standard, last reviewed and confirmed in 2024. The older, freely available FIPS PUB 183 remains useful for its detailed rules and examples, but NIST withdrew it from the federal FIPS series effective September 2, 2008. Do not describe FIPS 183 as a current federal mandate.
Start with A-0: purpose, viewpoint, and boundary
Every IDEF0 model begins with a one-box A-0 context diagram, pronounced “A minus zero.” That box names the whole function. Its boundary arrows define what crosses into and out of the subject. FIPS 183 also requires short purpose and viewpoint statements because the same subject changes when seen by a warehouse manager, software architect, auditor, or customer.
For the worked model:
- Purpose: identify the functional handoffs that must be agreed before an order-fulfillment workflow is automated.
- Viewpoint: operations owner accountable for releasing a correct shipment.
- Top function: Fulfill customer order.
- Boundary: a customer order enters; fulfillment policy controls the work; the order system, warehouse team, and carrier provide mechanisms; a dispatched shipment and dispatch record leave.
That boundary prevents scope drift. Payment authorization could be a control supplied by another system, or it could be a function inside this model. The author must choose. Drawing it both ways creates two incompatible scopes.
The child A0 diagram decomposes the context function. The figure uses four functions: Validate order, Plan fulfillment, Pick and pack order, and Dispatch order. FIPS 183 requires three to six boxes on a non-context diagram. More detail belongs in child diagrams, not a seventh box squeezed onto the same page.
Classify every arrow with the ICOM decision test
An arrow label should be a noun or noun phrase. Its attachment side gives the interface role; color and arrowhead style do not substitute for placement.
| Role | Box edge | Decision test | Worked example |
|---|---|---|---|
| Input | Left | Is this data or object transformed by the function? | Customer order becomes a release decision and fulfillment plan. |
| Control | Top | Does this constrain or govern how the function produces a correct output? | Credit policy and carrier cutoff govern the work but are not consumed. |
| Output | Right | Is this data or object produced by the function? | Approved order, pick plan, packed shipment, and dispatch record. |
| Mechanism | Bottom | What person, system, machine, or means performs the function? | Order system, warehouse team, and carrier service. |
The hardest distinction is usually Input versus Control. Ask whether the function changes the thing. “Customer order” is an input to Validate order because the function establishes its approved or rejected state. “Credit policy” is a control because it governs that decision and normally remains a policy afterward. The same object can play different roles at different boxes or levels, so do not assign one permanent ICOM letter to a noun across the whole model.
A box may have no input or no non-call mechanism, but FIPS 183 requires at least one control and one output for every box. That rule exposes vague functions. If a box produces nothing, it may be a label for a department rather than a function. If nothing governs it, the author may have omitted the requirement, trigger condition, plan, specification, or acceptance rule that determines correct output.
Name functions with verbs and interfaces with nouns
IDEF0 box names state what must be accomplished, so use active verb phrases: Validate order, Plan fulfillment, Pack shipment. Labels such as “Warehouse,” “Order,” or “Approval” name a place, thing, or concept without saying what transformation occurs.
Arrow labels do the opposite. Use noun phrases such as Accepted order, Pick plan, and Carrier cutoff. An arrow named “Validate order” hides whether it carries a request, decision, record, or instruction. A useful reading test is:
The mechanism performs the function, transforming its inputs into outputs under the controls.
For A2, that becomes: “The order system and planner perform Plan fulfillment, transforming the approved order into a pick plan under inventory-allocation rules.” If the sentence is meaningless, one or more roles are probably wrong.
Balance the child diagram with its parent
Decomposition is not permission to redraw the system boundary. A child diagram covers the same scope as its parent box. Unless an arrow is intentionally tunneled, every arrow connected to the parent box must correspond to a boundary arrow on the child diagram. ICOM codes such as I1, C2, O1, and M1 record that correspondence.
Use this procedure before approving a child diagram:
- List every parent-box input, control, output, and mechanism.
- Find the corresponding boundary arrow on the child.
- Confirm that the child functions collectively use or produce it.
- Trace every child boundary arrow back to its parent connection.
- Mark a deliberate tunnel only when the interface is unnecessary at the adjacent level, and record why.
This is a balancing test, not a demand that the role remain identical inside the child. A parent control may become an input to one child function, for example. What must remain traceable is the boundary meaning and correspondence.
Run the 12-point IDEF0 review
| Review question | Pass condition | Typical failure |
|---|---|---|
| 1. Purpose | One sentence says why the model exists. | The model documents everything and supports no decision. |
| 2. Viewpoint | A named role determines what the model can see. | Several audiences silently impose conflicting boundaries. |
| 3. A-0 boundary | One context box and its arrows define the subject. | External functions leak into lower levels without a scope decision. |
| 4. Function names | Every box uses an active verb phrase. | Boxes name departments, objects, or project phases. |
| 5. Arrow labels | Every interface has a precise noun phrase. | Labels repeat the function or use vague words such as “data.” |
| 6. ICOM roles | Each arrow passes the transform, govern, produce, or perform test. | Controls are treated as inputs because both enter a box. |
| 7. Required edges | Every box has at least one control and one output. | A passive activity produces nothing reviewable. |
| 8. Box count | Each non-context diagram has three to six numbered boxes. | One page becomes a miniature wall chart. |
| 9. Flow direction | Orthogonal arrows can be followed without ambiguity. | Crossings, diagonal shortcuts, or unlabeled forks hide meaning. |
| 10. Parent-child balance | Boundary arrows correspond through ICOM codes or explicit tunnels. | A child invents or loses an external interface. |
| 11. Detail references | Every decomposed box points to its child diagram. | Readers cannot navigate the hierarchy or identify the reviewed version. |
| 12. Supporting text | Glossary, notes, and definitions resolve terms the graphic cannot. | A tidy diagram leaves key words open to interpretation. |
Common failure modes
Treating the diagram as a timeline. Left-to-right placement helps reading and often suggests precedence, but IDEF0 models functional relationships, not elapsed time. Use a flowchart, BPMN model, sequence diagram, or schedule when order, branching, waiting, and duration are the decision.
Using departments as mechanisms and functions interchangeably. “Warehouse” can be a mechanism that performs Pick and pack order. It should not also be the function name unless the model explicitly defines what the warehouse accomplishes.
Calling every incoming arrow an input. Policies, specifications, limits, schedules, and acceptance criteria often govern transformation and therefore belong on the control edge. Apply the decision test rather than arranging arrows wherever they fit.
Decomposing without balancing. A child diagram that drops the parent’s carrier cutoff or invents a new customer address changes the interface contract. Either correct the child, revise the parent, or explicitly tunnel the interface.
Confusing a valid diagram with a valid system. Correct IDEF0 syntax does not prove that the process is safe, efficient, authorized, legally compliant, or implemented. Review requirements, controls, evidence, and real operating data separately.
Limits and next step
This checklist covers a readable, structurally reviewable function model. It does not replace the full 106-page ISO standard, project modeling conventions, configuration control, or domain review. The NIST Production in a circular economy model is a current public example of IDEF0 used as a navigable hierarchy, but its subject and choices are not a template for every system.
For your own model, write the purpose, viewpoint, A-0 function, and four boundary lists before opening a drawing tool. Then use ChatDiagram’s IDEF0 diagram maker to draft three to six verb-named child functions. Review the ICOM role of every arrow and balance the child boundary against its parent before adding another level.