Mind models

A long research output, a decision record or what you know about a customer becomes unreadable as plain text. The sentence you need sits in the middle of thirty pages, the reason a path was ruled out was never written down, and what is still open is invisible. A mind model solves all three at once: the subject is a tree, every node says what it is, and what is unknown is visible in colour.

Mind models live on the Files screen. They sit next to the documents you upload and the outputs agents produce, they are referenced with @file, and every save leaves a new version.

#What it is for

The same structure works across very different jobs, and in all of them it answers one question: what do we know here, what did we choose and why, what is still open.

Use	What the tree holds
Decision record	The question, the options, why each was ruled out, and the verdict
Research output	Topic headings with findings and their sources underneath
Learning map	What you know and what you don't; the open ones stay marked
Customer memory	Decision makers, objections, past conversations, things to do

#The parts of the tree

A node says two things. Its type says what it is; its state says where it stands. The two are independent, so a question can be open and so can a fact.

Type	When
Topic	A grouping heading that holds things together
Question	A branching point; the options below are its answers
Option	A path; its state says whether it was chosen or why it was ruled out
Decision	A verdict; the reasoning sits in its body
Fact	An observation or a note. Assumptions and risks live here too
Constraint	A rule that has to be met: a policy, an acceptance criterion, an obligation
Action	Work to be done; put who takes it on in the Owner field and its due day in the Due field

State is the hardest-working part of the tree. Open is where there is no answer yet, chosen and rejected tell what became of a path, verified and refuted tell what became of an assumption, stale marks what used to be true, and resolved closes an answered question, a finished task or a cleared obstacle. Rejected and refuted nodes are dimmed and struck through, but never deleted: why a path was ruled out is as valuable as the path you took.

For meeting and work tracking every node has three more fields. Owner is the person who will answer the question or do the work, kept apart from the people in the Related field. Due is the day it is due; when it has passed and the node is not resolved, the card shows it in red. Came from says where the content came from: a meeting, a document, a person or an agent inference. Something the agent noticed on its own carries a dashed agent inference badge on the card, so it is not mistaken for something said in the meeting.

Nodes connect in two ways. The tree edge is the parent-child link and you can put a label on it ("yes", "no", "because"). Beyond that you can link two nodes sideways: one can be related to another, supersede it, or serve as evidence for it. Sideways links are drawn dashed, so it is obvious at a glance that they are not branches.

#Building the tree

A mind model opens in the file window in read mode: clicking a card only shows its detail, so nothing changes by accident. To edit, press Edit at the top or the E key; Done goes back to reading. The README button on the same row shows the tree as a plain page (with type, state, owner and date on each line), and Download gives it to you as a Markdown file.

You can build the tree with the mouse or the keyboard. In edit mode the + on the right of the selected card adds a child and the + below it adds a sibling. Double-click empty canvas and a free note without a state opens there. It starts as a fact; change its type in the detail panel. It is not attached to the tree, and dragging it onto a card makes it join that branch. The keyboard is faster; with a node selected:

Key	What it does
Tab	Opens a new node underneath and puts the cursor in its title
Enter	Opens a sibling next to it
⌘Backspace (Ctrl+Backspace)	Deletes the node; if it has children, it asks how many will go
← / →	Collapses and expands the branch
⌘Z / ⇧⌘Z (Ctrl+Z / Ctrl+Y)	Undoes what you did, redoes what you undid
⌘S (Ctrl+S)	Saves the tree
Esc	Clears the selection

A new node is born as a fact in the open state; you change its type and state from the selectors on the card. We don't ask for the type at the moment you add it, because stopping to pick a type breaks the flow of writing.

The tree arranges itself, but you can move a card wherever you like. Pick it up and drop it on empty space and it is pinned there; its branch comes along and the position is saved in the file. Drop it on another card instead and you change its parent, saying "this branch actually belongs under that one"; the card you hover is highlighted. The Put cards back into the tree layout button at the top right removes every pin. Pins apply to the horizontal tree; on the radial layout the tree always arranges itself.

You do choose the shape of that arrangement. In the controls at the top right of the canvas, next to the zoom buttons, there are two layout buttons: horizontal tree puts the root on the left and opens the branches to the right; radial puts the root in the middle and spreads the branches around it. Radial suits a map with a few main subjects of equal weight, because no branch looks like it sits "above" or "below" the others. The buttons stay in place in full screen too. The choice is written into the document: once you save, everyone who opens the tree sees it the same way. The cards are identical in both layouts; only their places and the side the connectors leave from change.

Changes are written when you press Save (or ⌘S), and every save leaves a new version. Until then an "unsaved changes" note stays at the top; if you try to close the file or leave the page without saving, the app asks first — what you wrote is never dropped silently.

The History list in the file window gathers one person's consecutive saves, each less than ten minutes after the one before, into a single row; each save still stays its own version and can be restored. Going back to an earlier version shows as its own row. The row's Changes button shows what that session changed in the tree, node by node: nodes added, removed, changed in state or content, and moved under another branch. Changed fields show their old and new values, and a moved node shows where it was before.

When the tree grows, the Full screen button in the top right opens the canvas to the whole screen. The same button or Esc leaves it.

#Finding your way in a large tree

The tree opens collapsed: the roots and one level below them are visible, the rest is folded. A folded card shows how many nodes sit underneath it; clicking that number opens one level and − closes it again. On the keyboard ← collapses and → expands. Which branches you leave open is yours alone and stays in your browser — it does not change the document, and your teammate sees the tree the way they left it.

The … button on a card opens that node's note on the card; it stays open, a click elsewhere doesn't close it. The full note is read in the node detail panel on the right: the selected node's note, source, related items, cross-links and child nodes live there. On the card the note is clipped to four lines, because a long note turns the card into a wall and the tree becomes unreadable.

The same panel is where you write these fields. With editing on, the title, note, related items, source and the label of the incoming wire appear as boxes; write the title on the card or in the panel, it is the same field. In the related box @ adds one or more things: the person who owns an action, an agent, a linked task or a file. Each shows as its own chip on the card and is clickable: a person chip opens the person card, a task chip the task, a file chip the file. The @ links in the note work the same way. The source can be an address, a file or a meeting name. The wire label is written on the wire coming from the parent to this card ("yes", "no", "because"); under the box it says which card it comes from, because a card has one incoming wire but many outgoing ones. The root has no incoming wire, so that box is not shown on the root. What you write is applied to the tree when you leave the panel, and emptying a box removes the field; saving is still the Save button. The bar on the card holds only the title, type and state: structure is edited on the card, content in the panel.

The controls in the top right also carry collapse all and expand all: folding twenty branches one by one is twenty clicks. Collapsing everything closes every branch, roots included; only the roots stay on screen, each showing how many nodes sit under it.

When you click a card it is marked with a blue ground, and the path back to the root is marked too — a lighter blue with thicker wires. You see where you are and how you got there in one look.

Clicking a dashed cross link does the same job: the line turns blue, the cards at both ends are marked, and the link's kind and note are written above the line. In a tall tree a dashed line runs between other cards and you cannot follow where it goes by eye. Click it again, or click an empty spot, to let it go.

The search box in the top left searches the tree: if your word appears in a node's title, note, source or related field, that node is highlighted and its path opens automatically. Cards that don't match are dimmed rather than removed — so you can see where the node you found sits in the tree. Emptying the box returns the tree to how it was.

The filters under the search box give the lists text cannot: by type (say, question), by state (say, open), by kind of source (say, agent inference) and by owner. They combine with each other and with the search box; that is how you find "open questions" or "Selin's work". Each list offers only the values present in the tree, with the number of cards that carry them. Picking a filter moves the view onto the matching cards.

#Pointing at a node

The number on a card (1.2.2) shifts when the tree changes, so to point at a node in a chat or on a card use its node address. Click the node, choose Copy address in the detail panel and paste it: you get something like @file.pilot-takip#3f9c2a71. The address keeps pointing at the same node when the tree changes. Clicking it opens the mind model with the node selected, its branch unfolded and the view centred on it. Agents write the same address when they refer to a node. To share outside Orbi (in an email or another tool), the Link button in the same panel copies a web link; it opens the latest version of the file on that node.

#How agents read the tree

When you give an agent work on a branch, what reaches it is not that node's text. The whole chain from the root down to the node goes with full bodies, the rest of the tree goes as titles only, and sideways-linked nodes go in full. That way the agent doesn't start in the middle of the subject, but doesn't have to read the whole tree either.

Agents can read a tree, build one from scratch and change it. You can refer to a node by the number you see on the canvas ("update 1.2.2"); for a lasting pointer the node address is better, because numbers shift when the tree changes.

#How agents keep the tree

When you have an agent work a meeting, an e-mail or a document into a tree, it follows the same rules. They are written into the mind model tools themselves, so Orbi's own agents and clients that connect to Orbi from outside see the same rules.

1. It finds what exists first. If the topic already has a mind model, it reads that one instead of building a new one. On a large tree it goes only to the branch it needs, and it reads separately what changed since the version it saw last.
2. One event, one version. All the changes from one meeting are written at once and show in the version history with that meeting's summary.
3. Every node says where it came from. The source (the file and its minute or section) and the kind of source are written. Things the agent noticed on its own are marked as agent inference.
4. It closes things. An answered question, finished work and a cleared obstacle become resolved, with the reason added as a note. A changed decision is updated in one step: its old form is not deleted but stays under it as a rejected option, linked to the new decision with a "supersedes" link and the reason for the change. So you can still see later which decision changed and why.
5. It writes people correctly. In the Owner and Related fields a workspace member is written as @user.<name>, and anyone who is not a member, such as someone on the customer's side, as plain text. A @user name that is not a member is refused, so the tree never shows a stranger as a teammate or the wrong teammate.
6. Topic knowledge stays in the tree. Decisions, questions and work live in the mind model. The workspace memory only gets rules and lessons that hold beyond this topic.

If an agent changes the tree while you have it open, the new version lands on your canvas at once: the changed cards are highlighted in yellow and a strip at the top says how many nodes changed. Changes in the strip shows the difference node by node, and Undo goes back to how the tree was before the agent's version (saved as a new version too). If you have unsaved changes, the canvas does not change on its own; the strip tells you a new version arrived, and you can drop your changes and open it if you want.

If you connected an agent tool such as Claude Code or Cursor to Orbi with your own account, the versions it writes are saved under your name. The History list shows "via Claude Code" next to your name and keeps those versions on a separate line from the ones you saved by hand. They land on an open canvas at once, like an agent's version.

Search also sees inside the tree. When you search for a sentence, the result points at the branch it appears in, not at the file. A file is listed once even when the word appears in many branches: the result shows the branch that matches best and opens the file on it. Many matching branches do not push cards, records and other files out of the list.

#What we deliberately left out

A mind model is not a table. Comparing three providers across five criteria is what collections are for; the tree holds "why we chose this", the collection holds "how much each costs". More: Collections.

The tree does not calculate. You can write numbers into it, but it will not add them up; a tree that did the arithmetic could quietly show a wrong total, so it was left out on purpose.

Nodes do not run anything. Drawing a decision tree is not the same as executing it; if you want the steps of a job carried out automatically, flows are the right place. More: Flows.

A tree that grows too large can be split: write another mind model's @file link into a node's body. The agent opens that file when it needs it and leaves it alone when it doesn't.

#Diagrams agents draw use the same canvas

When an agent explains a flow or a structure to you, it can draw a diagram. Those diagrams now appear on the same canvas: in chat, on a task card and in the docs you can drag a diagram around and open it full screen to zoom in. The mouse wheel scrolls the page, not the diagram — reading never gets stuck on it. Groups in a diagram — steps drawn inside a box — appear as labelled frames. Diagrams that are neither a tree nor a flow — a timeline, a calendar, a pie chart — stay as plain drawings, because there is nothing for the canvas to do with them.

Decision boxes are drawn on a yellow background and each branch goes down in its own column, so "yes" and "no" separate side by side and the branch labels sit right below the decision. In a crowded diagram you can grab a box and drag it somewhere else. That only rearranges your own screen: it is not saved to the diagram, and the boxes return to their places when the page reloads.

Such a diagram is not a file; it lives inside the message. If you want to work on it, move its content into a mind model, where you can edit the nodes and keep the versions.