EdgeNode projects computable execution plans into the official IDEF (Integrated DEFinition) modeling family. The platform compiles functional ICOM architecture models via IDEF0 (modeling what governs, supplies, and performs each function) and structured operational pathways via IDEF3 (modeling sequential order, logic junctions, and process units of behavior).
The Complementary IDEF Lens
IDEF0 and IDEF3 operate as official siblings, providing two synchronized viewpoints over the same computable plan:
| Diagram Standard | Modeling Domain | Core Question Answered | Target Scope | Primary Unit |
|---|---|---|---|---|
| IDEF0 | Function (Transformations) | What governs, supplies, and performs each function? | Apex / Primary Artifact | ICOM Activity Box |
| IDEF3 | Process (Flow & Sequencing) | In what order does work proceed, and where does it branch? | All Plan Artifacts | Unit of Behavior (UOB) |
Part I: IDEF0 Functional Modeling & ICOM Ports
IDEF0 scopes exclusively to the plan's apex artifact (identified via the highest trigger convergence or lowest unit volume, identical to VSM) and models each operational cycle as an ICOM function box.
1. ICOM Port Anatomy
Every activity box is bounded by four distinct functional interfaces corresponding to the cardinal sides of the box:
- Input (West / Left Port)
- Material, data, or resources transformed or consumed by the function. Sourced from supplying relationship flows.
- Control (North / Top Port)
- Rules, conditions, standards, or constraints governing when and how the transformation occurs.
- Output (East / Right Port)
- The primary product or resulting state of the activity. Serves as the origin for all outgoing arrows.
- Mechanism (South / Bottom Port)
- The operational role or system entity executing the function. Sourced from the cycle's
responsible_id.
2. Relational Edge-to-Port Mapping
Arrows in IDEF0 always depart from the source activity's Output (East) port. The port they enter on the downstream activity is determined by the dominant relation type resolved in the computable view:
| Dominant Relation Type | Target ICOM Port | Functional Semantics |
|---|---|---|
constraints, influences, aligns |
Control (North) | Governs or constrains execution |
characterizes |
Control (North) | Qualifies functional criteria |
couples, composes, requires |
Input (West) | Supplies material or prerequisite data |
| (Unresolved / Default Edge) | Input (West) | Standard operational flow |
alternates |
(Dropped) | Excluded (no direct ICOM equivalent) |
Mech: Assembler).
3. Strict Diagonal Staircase Layout
IDEF0 activities are ranked topologically, serialized into a strict sequential order, and positioned at coordinate pairs . This produces the classic IDEF0 diagonal layout where flows step downward and to the right.
[Control: Spec]
|
v
[Input] ---> +-------------------------+
| Assemble Subunit [A1] | ---> [Output: Subunit]
+-------------------------+ |
^ v
| +-------------------------+
[Mech: Assembler] | Final QA [A2] | ---> [Finished Part]
+-------------------------+
^
|
[Mech: QA Lead]
Part II: IDEF3 Process Flow & Junction Logic
While IDEF0 isolates the primary function, IDEF3 captures chronological process sequencing across all plan artifacts. IDEF3 decomposes work into Units of Behavior (UOBs) connected by precedence links and logic junctions.
1. Anatomy of a Unit of Behavior (UOB)
Each root cycle is rendered as a standardized rectangular UOB box. Duration, roles, and states are omitted to emphasize structural workflow:
+------------------------------------+
| Cut Material | <-- Activity / Node Name
+------------------+-----------------+
| 1.1 | A1 | <-- UOB Number (Left) | IDEF0 Ref (Right)
+------------------+-----------------+
- Activity Title
- The primary display name of the process node.
- UOB Number (Bottom Left)
- The unique process step identifier within the flow hierarchy (e.g.,
1.1,1.2). - IDEF0 Reference (Bottom Right)
- The cross-standard reference code (
A1,A2) linking this behavioral step back to its functional definition in IDEF0.
2. Logic Junctions (Forks & Joins)
Path divergence and convergence are managed by standardized logic junctions placed on intermediate layout columns:
| Junction Type | Detection Rule | Layout Placement | Visual Symbol |
|---|---|---|---|
| Fan-Out Fork | Node with > 1 outgoing edges | One column after source UOB (2 × level + 1) |
Square box with & (AND) |
| Fan-In Join | Node with > 1 incoming edges | One column before target UOB (2 × level - 1) |
Square box with & (AND) |
3. Precedence Links vs. Inter-Stream Triggers
IDEF3 distinguishes between internal process progression and external stream synchronization:
- Material / Precedence Links: Solid directional arrows carrying the artifact name between UOBs, anchored directly through junctions.
- Trigger Links (Signals): Synthesized from plan pipelines. Rendered as dashed arrows linking the triggering UOB directly to the initial UOB of the spawned stream.
Comparison: IDEF0 vs. IDEF3 vs. BPMN 2.0
| Dimension | IDEF0 | IDEF3 | BPMN 2.0 |
|---|---|---|---|
| Primary Lens | Functional Transformation (ICOM) | Process Precedence & Junctions | Executable Choreography |
| Artifact Scope | Apex artifact only | All plan artifacts | All plan artifacts |
| Time Modeling | Time-free (durations stripped) | Time-free (order only) | Durations & Latencies |
| Visual Layout | Strict diagonal staircase | Alternating columns & tracks | Horizontal swimlanes by role |
| Signature Element | ICOM Ports & A-Codes | UOB Boxes & Junctions | Gateways & Boundary Events |