Last updated April 21, 2026
Nodes & Edges
Nodes and edges are the atoms of your architecture. Nodes represent discrete things — services, databases, APIs, domains — and edges represent the relationships between them. Together, they form the graph that is your architecture model.
Nodes
Every node on a board has a name, a visual representation, an archetype that gives it meaning, and optional tags, attributes, and source references. You drag it onto the canvas, label it, classify it — and it becomes part of your living architecture.
What a node carries
| Property | What it is |
|---|---|
| Name | Display name, 2–100 characters |
| Visual primitive | How the node renders — plain node, container, region, callout, text, axis, or annotation |
| Archetype | Domain meaning — "API Gateway", "PostgreSQL", "Message Queue", etc. |
| Parent | Optional parent node for hierarchical nesting |
| Tags | Labels for filtering and categorization |
| Child layer | Optional link to a nested board for drill-down |
| Source references | Traceability links back to the source documents that justify this node |
Visual primitive types
Every node has a visual primitive that determines its fundamental visual behavior. These fall into three broad families:
Discrete, standalone elements — the things in your architecture.
| Primitive | Description | Example use |
|---|---|---|
| Node | Discrete entity — rectangles, circles, hexagons | Systems, services, decisions, events |
| Callout | Focused annotation attached to an element | Warnings, tips, deprecation notices |
| Text | Freeform text block | Titles, explanations, documentation |
Element archetypes
Archetypes give nodes semantic meaning beyond their visual shape. An archetype defines what kind of architectural element a node represents — "API Gateway", "Message Queue", "PostgreSQL Database" — along with styling, standards, and containment rules.
Archetype groups
| Group | Examples |
|---|---|
| AWS | Lambda, S3, RDS, ECS |
| Azure | Functions, Blob Storage, Cosmos DB |
| GCP | Cloud Run, BigQuery, Pub/Sub |
| Vercel | Edge Functions, KV Store |
| C4 Model | Person, System, Container, Component |
| Common | Generic service, database, API, queue |
| Integrations | GitHub, Slack, Jira connectors |
| Database | PostgreSQL, MongoDB, Redis |
Each archetype specifies which other archetypes it can nest. A Domain container can contain Systems; a System can contain Services. This enforces structural correctness — you can't accidentally put a VPC inside a Lambda function.
Archetypes aren't just cosmetic — they carry containment rules, styling defaults, and semantic meaning. Picking the right archetype means your board stays structurally valid as it grows.
Parent-child hierarchy
Nodes support hierarchical nesting. A node inside a container is visually and logically grouped with its siblings. Combined with child layers, this gives you multi-level zoom: overview → domain → service → internal components.
Edges
Edges connect nodes, representing relationships like dependencies, data flows, or API calls.
What an edge carries
| Property | What it is |
|---|---|
| Source | The originating node |
| Target | The destination node |
| Relation | Label describing the relationship (e.g., "calls", "depends on", "publishes to") |
| Archetype | Optional archetype for edge styling |
| Tags | Labels for filtering |
| Source references | Traceability back to source documents |
Every edge reads naturally: "Payment Service calls User Database." You pick the relation label when you draw the edge — or let a governing source do it for you during sync.
Every node and edge carries source references for traceability — links back to the exact source documents (and even line numbers) that justify its existence. This is how ContextDX keeps your architecture honest.
Verify your node setup
- Nodes have descriptive names (not "Service 1", "Node A")
- Correct visual primitive chosen (node vs container vs region)
- Archetype assigned for semantic meaning
- Parent-child nesting reflects real domain boundaries
- Edges have meaningful relation labels
- Source references attached where applicable