Nodes
Nodes are the building blocks of your architecture model. Each represents something real — a user, a system, an app, a module, a function.
The hierarchy
Section titled “The hierarchy”| Level | What it represents |
|---|---|
| Person | Users and actors |
| System | Software systems |
| ↳ Container | Apps, services, data stores |
| ↳ Component | Logical modules |
| ↳ Operation | Functions & handlers |
| ↳ Process | Multi-step workflows |
| ↳ Model | Data structures |
Each level nests inside the one above it. You drill into a system to see its containers, into a container to see its components, and into a component to see its operations, processes, and models.
Architecture-level nodes
Section titled “Architecture-level nodes”These are the nodes you place on the canvas and connect with edges.
Person
Section titled “Person”An external user or actor that interacts with your systems.
Persons are always top-level — they don’t nest inside anything. They don’t have a technology field or status tracking.
System
Section titled “System”A top-level software system. This is the highest-level boundary for something your team builds and maintains. Systems have a subtle outer border to distinguish them.
Systems can be marked external — these are third-party services you don’t control (like Stripe, AWS, Twilio). External systems appear with a dashed border and cannot contain children.
Container
Section titled “Container”A deployable unit inside a system — a web app, API server, database, message queue, background worker, etc. Select a system and expand it to see its containers.
Containers have a technology field — the framework, language, or platform they run on.
Component
Section titled “Component”A logical module inside a container — an auth service, a repository, a set of API routes. Expand a container to see its components.
Components have a small tab decoration at the top-left. They should correspond to concrete code units — a class, module, package, or folder in your codebase.
Code-level nodes
Section titled “Code-level nodes”Inside a component, you work with three kinds of code-level nodes. These appear in a list view rather than on the canvas.
Operation
Section titled “Operation”A single function, method, or handler — something you can point to in one file. Operations use monospace font and follow your language’s naming convention (camelCase for JS/TS, snake_case for Python/Rust).
Process
Section titled “Process”A multi-step workflow that orchestrates multiple operations — like a saga, pipeline, or scheduled job. If it maps to a single function, it’s an operation, not a process.
A data structure — a type, interface, or schema. Models have a properties list where each field has a name and description.
Shapes
Section titled “Shapes”Every node can have a shape. The default is rectangle, but you can change it in the Properties panel.
Common conventions:
- Rectangle — default for most nodes
- Person — for person nodes
- Cylinder — databases and data stores
- Pipe — message queues and event buses
- Hexagon — external services or gateways
Creating nodes
Section titled “Creating nodes”Three ways to add nodes:
- Right-click the canvas → Add node → pick a kind
- Inside a component, use the + buttons in the list view columns
- AI agents add nodes through the MCP server
Node properties
Section titled “Node properties”Every node has:
- Name — displayed on the node
- Description — what this node is (max 200 characters, shown on canvas)
- Notes — implementation details, deployment context, rationale (not shown on canvas)
Architecture nodes also have:
- Technology — framework, language, or platform (max 28 characters)
- Shape — visual shape on canvas
- Status — proposed, implemented, verified, or vagrant (see Status Tracking)
- External — for system nodes only
Mentions
Section titled “Mentions”In code-level descriptions, use @[Name] to cross-reference sibling nodes. For example: “Validates the @[UserInput] model before calling @[createUser].” These render as clickable pills in the editor.