Organize with nodes

Choose a useful grouping

A decision can belong to more than one node. Start with a few recognizable areas and add more as the record grows. Every decision needs at least one node before confirmation.

Create and use a node

1. Open Nodes and choose New node.
2. Choose the type, enter a name, and describe what belongs there.
3. Choose visibility and groups where your permissions allow it, then select Create node.
4. Choose the node in the decision editor. To browse its records later, open it from Nodes or follow a node chip on a decision.

To change a node, open it and select Edit node. On a phone, the node actions appear below its description and members; group roles and membership are edited in Settings, Groups. Update the fields and select Save changes.

Workspace administrators create nodes and manage the hierarchy. A linked Admin group can manage its nodes, including visibility, linked groups and archive status. Members and Approvers can edit metadata on nodes assigned to their groups. Viewers cannot edit them.

Manage access with groups

Administrators is the only built-in group and gives full administration within its workspace. It cannot be renamed or deleted. The last administrator cannot be removed, including through direct calls.

In Settings → Groups, choose Viewer, Member, Approver or Admin for each custom group, then add users. Every member receives that group’s role on its linked nodes. Select groups in Edit node; there is no separate node-role selector. Roles apply only on directly assigned nodes. Parent access does not inherit to children.

Overlapping groups use the highest role: Admin, Approver, Member, then Viewer. A decision attached to several nodes uses the highest applicable role across those nodes. Whole-workspace visibility grants reading only. Without an applicable group, a person cannot write or approve. Administrators retain full access everywhere in their workspace.

Only the protected Administrators group grants workspace settings and group membership management. An ordinary Admin group applies to its linked nodes. Existing mixed-role memberships are split into groups that preserve their permissions. Remove a group from its nodes before deleting it. Role changes and removals revoke affected assistant grants; permissions are checked on subsequent requests.

Hierarchy and inherited guidance

A workspace admin can choose a parent when creating a node. In Acme Robotics, Catalogue and Fleet console can sit under Product engineering, while Partner portal sits under Commercial.

Each decision attachment defaults to This node only. Enable descendant applicability in the editor to let it guide work below that node. Workspace admins can explicitly mark shared guidance as workspace-wide. Existing decisions keep their original local scope.

AR-041 choosing Postgres over Elasticsearch for Catalogue search does not prescribe Fleet console's search engine. A decision attached to Product engineering flows down only when descendant applicability is enabled.

Applies here includes local, inherited, and visible workspace-wide guidance. Origins appear beside each result. Browse subtree discovers descendant records; they do not all apply to the parent. Upcoming decisions and drafts are separate from current guidance, and reviews due remain applicable.

Workspace admins can open Nodes → Edit hierarchy to see the tree. Drag a node's Move handle onto its new parent, or onto Workspace root to make it top-level. On a keyboard or touch screen, select Move and choose the new parent. Expand or collapse branches to navigate the tree. A node cannot move inside its own descendants.

Choose Preview move, review the guidance gained and lost for every affected node and the number of connected agents, then enter a reason and choose Save move. Cancel leaves the tree unchanged. The whole branch moves together; membership and visibility stay the same. You can also move a branch by editing its parent on the node's edit page. Moves are audited. Active children and bound agent connections must be moved, archived, or revoked before a node can be archived.

External portals and channel notifications keep their explicit audiences. Adding a parent does not publish ancestor decisions to those audiences.

Understand visibility before sharing

Whole workspace makes the node visible to workspace members. Restricted to groups limits the node to users in the selected groups and workspace admins.

A draft with no nodes is visible across the workspace; only Administrators can create or edit it until it has an assigned node. Workspace admins can see all nodes and decisions. Search, Ask AI, and assistant access use the same visibility rules.

Connect a node to a channel

With Slack connected, a node can name a channel for announcements and review notices. Captured decisions from that channel are filed under the linked node. An authorized admin can also enable Suggest drafts from this channel; it is off by default.

Review the capture guide before enabling suggestions so you understand which conversations are read and how the workspace's model is used.