Boards

A board is where you model part of your architecture: its nodes and edges, the sources bound to it, and the insights about it.

Boards and the canvas

The canvas is one view of a board. For steps, see the Boards Guide.

The Root Board

Every workspace has exactly one Root Board, the overview at the top of its tree. You can rename it, lay it out, and populate it, but you can't delete it or change its type.

It opens on its canvas until the layers under it include app boards, then on its root hub. The root hub briefs you on the changes that reach beyond their own app, drawn on the root canvas.

Board types and layouts

A board has a type and a layout, and the layout has the bigger effect.

A type is a label you choose in the create sheet. It shows beside the board in the board listing, and as the board's icon in the breadcrumb, whose board switcher groups boards by type. A type controls no features, with one exception: the Context Map.

A Context Map opens in a reading view that leads with the question it answers and links each element to its source board. When the board was drawn as a C4 diagram, the strip also names its level, such as "C4 container". The plugins' /ask-board and /discover commands use this type for a context board.

An ADR board includes no decision template, and a Report board generates no report.

A layout controls canvas behavior. Dashboard is a grid for overviews and presentations. Page is a vertical column for ADRs, knowledge-base articles, and reports.

Where opening a board takes you

An app board opens on its hub. Every other board opens on the canvas, apart from a Root Board with app boards below it. The Board Tree explains the rules.

How layers appear

Boards nest. Any node can hold a child layer, a full board of its own.

Expand

You add layers in three ways:

• By hand. Right-click a node and choose Create Subsystem Layer. The node gets a drill-down indicator; click it to open the child board.
• By adding an app. Click or drag an app type in the canvas Apps palette. It creates a node and a child app board with a repo bound to it.
• From the code plugin. /analyze --drill maps a node's internals as a child board, and /sync pushes each layer in turn. The code plugin covers both.

The code plugin's /ground grounds a board you already authored against your documents, and it builds no hierarchy.

Detached boards

A layer stays in the tree through the node that opens it. Delete that node, or point it at a different layer, and the board becomes detached. It keeps its nodes, its own layers, its bindings and any published page, but no canvas, breadcrumb or board map leads to it any more.

Detached boards collect in a Detached group in the board listing, under the Boards group, with what each one holds. The root hub's Fleet attention strip lists them under a Workspace chip; Review takes you to the group. Each board offers three ways out:

• Open it and look around. Nothing in it has changed.
• Keep as board moves it into the Boards group as a board in its own right. It counts toward your plan's boards from then on.
• Delete permanently… removes it with everything below it, after showing what goes with it. A detached board that is still published is marked Published; deleting it takes the page down.

Reattaching happens from the canvas. When the code plugin or an agent creates a layer with the same slug under a node, the detached board becomes that node's layer again, contents intact. Discarding the working copy that deleted the node restores it, and the board is no longer detached.

Folders, permissions, publishing

Three board topics have pages of their own:

• Boards live in folders inside a workspace. Workspaces & Organizations covers where you create and find them.
• A board has its own access on top of your organization role. Permissions & Access explains the access layers.
• Publishing shares a board with people who have no account. Publishing Boards covers the wizard.

What's next