Definitions & Relations
In the EdgeNode engine, geometry alone does not dictate architecture. A flat network of nodes and lines becomes a meaningful digital twin only when elements are given semantic context. This context is established using two mapping structural mechanics: Definitions and Relations.
Both mechanics depend directly on your workspace's active Contours—the structural perimeters that dictate which rules apply to which operational layer.
Node Definitions: Polymorphic Typing
A Definition binds a strict semantic architectural type to a generic node ID inside a targeted contour boundary. This lets a single node change its identity depending on the active vantage point of the analyst.
The platform translates an identifier into one of four domain archetypes:
- Process: Represents functional execution, tasks, or calculations that advance stream artifact states.
- Structural Unit: Represents corporate divisions, hardware boundaries, teams, or organizational departments.
- Location: Maps physical regions, data centers, cloud availability zones, or spatial constraints.
- Artifact Definition: Binds the node to a specific data layout blueprint, model asset, or specification schema.
Relations: Multi-Dimensional Architecture Links
Traditional edges show basic topology. A Relation describes the logical dependencies that dictate how nodes interact inside specific perimeter scopes.
Relations require a valid contour identification string. This ensures that if you switch a contour off or out of viewport scope, its corresponding validation dependencies are completely omitted from engine simulations.
Every Relation object evaluates three binary architectural flags to assess node linkages:
| Structural Flag | Logical Assessment Condition | Simulation Engine Impact |
|---|---|---|
| is_required_by | Strict hard block dependency checking. | The target node cannot execute any internal cycles if the source node fails or runs out of asset capacity. |
| is_extension_of | Inheritance and composition routing. | The source node automatically inherits the baseline latency properties and processing parameters of its parent definition. |
| is_alternative_to | Failover pathways and route splitting. | Instructs the pathfinding engine to compute secondary routing options if primary nodes bottleneck. |
By tracking relationships as separate identity records rather than hardcoding lines into components, your frontend layout remains lightweight. It evaluates complex rules on demand based entirely on your active contour views.