Node A1

IDEF0 Diagram Builder

Draw a standards-correct IDEF0 diagram: activities on the diagonal, ICOM arrows on the right sides of the box, six activities maximum. Click anything to inspect it, drag the paper to pan, Ctrl+scroll to zoom, go full screen to present. Export SVG or PNG.

What IDEF0 arrows mean

Every arrow role is encoded by which side of the box it touches. Inputs enter the left and are transformed by the activity. Controls enter the top and govern how the activity runs — standards, plans, doctrine. Outputs leave the right. Mechanisms enter the bottom: the people, tools, and systems that perform the activity. That's why the arrow builder only asks which side of the destination an arrow enters — a box-to-box arrow always departs from its source's output side, and an arrow to the sheet boundary is by definition an output.

IDEF0 caps each diagram at six activities. When you run out of room, you do not add a seventh box — you decompose: any activity becomes its own child diagram carrying its node number (A2 decomposes into A21, A22, ...). That discipline is the entire reason IDEF0 models stay readable at any scale. In this builder, double-click any box — or select it and press Decompose — to open its child sheet; the breadcrumb above the canvas tracks where you are, and saving to a .idef0 file captures every sheet at once.

The model check: IDEF0 the way the classic tools did it

The great dedicated IDEF0 tools of the 90s — Design/IDEF, AI0Win — understood something most drawing tools never did: the model is the artifact, and the diagram is just its projection. You couldn't draw an illegal model quietly. An activity with no control, an output going nowhere, a child diagram whose boundary invented arrows its parent box never had — all of it was marked, and the model didn't pass until the marks were cleared. That enforcement is what made a validated IDEF0 model trustworthy enough to hand a development team.

This builder carries that discipline forward. The live model check below the canvas continuously audits every sheet against the method's rules: every activity must have at least one control (nothing happens without governance) and at least one output (an activity that produces nothing isn't an activity); the convention of 3–6 boxes per decomposition; and — the rule that matters most — boundary consistency. When you decompose a box, the arrows touching it on the parent diagram become the child sheet's boundary contract: the boundary strip above the canvas shows each inherited arrow and whether you've placed it yet (click an unplaced one to pre-fill the arrow builder), and the model check flags anything the child sheet invents from thin air or lets vanish. In-work states are legal — they're flagged as cautions, not blocked — but a clean model check means the decomposition actually agrees with itself, level to level.

Validate models in CI

An .idef0 file is plain JSON — it diffs cleanly, reviews well in a pull request, and belongs in version control next to the work it describes. The same validation engine that powers the live model check is available as a self-contained, zero-dependency script: download idef0-lint.mjs and run it anywhere Node 18+ exists:

node idef0-lint.mjs model.idef0            # exit 1 on redlines
node idef0-lint.mjs --strict model.idef0   # exit 1 on any finding

Wire it into a pre-commit hook or a pipeline step and a decomposition that stops agreeing with itself fails the build — the same way a broken test would. No account, no service, nothing phones home: it's the validator from this page, packaged to run offline.

Wondering whether IDEF0 is even the right notation for your problem? Read the guide: IDEF0 vs SysML activity diagrams — which one you actually need.