Home

Intent Trees and the Canvas

I keep the things I'm chasing, and where each of them came from, as a tree. The material canvas is the other half of the same need. The intent tree was finished on August 19, 2026, the two parts merged in October, and the old canvas entry was archived.

TYPE
Intent log and material canvas
STATUS
The intent tree is done, the two parts are merged, the old canvas entry is archived
WHEN
2020 to now, the intent tree finished in August 2026
BUILT WITH
Unity early on, later the tree is maintained as a document

What this is

I want a record of what I'm chasing, and where a task that branched off came from. I used to keep several conversations open and work on things in parallel, but these relations only lived inside the conversations. To pick something up again after switching away, I first had to remember why I had ended up there. The tree is for this shifting intent; tasks and plans fall out of it. What needs doing changes as the talking goes on, and a line that gets parked has to be pickable back up later.

The canvas idea is older. In December 2020 I already wanted related things sitting on one two-dimensional board, visible and draggable, and in April 2021 I wrote down the need to find the main thread again after an interruption. The same need got built four times. The first three times I built the canvas first, before I had worked out how intents and materials should support the work.

Where a line branches off

One record on the tree is a node. The retrospective's rule for drawing a line is simple: the later thing has to follow from the earlier one. Two sentences said next to each other don't count. The figure invents a "make a small game" thread, which then continues into designing levels and tuning the controls, both with a clear origin. Learning to bake bread came from somewhere else, so it gets its own root node and grows from there.

The old version wrote one node per round of conversation. Later I changed it to one intent per node. Several rounds about the same thing should stay in the same place, and a new node goes down only when a genuinely new intent splits off. What matters is how the things relate.

Where an intent comes fromFICTIONAL EXAMPLEANOTHER ROOTMake a small gameDesign levelsDebug controlsCURRENT FOCUSLearn to bake breadWithout a source link,start a separate treeEdges show origin, not chat order.This was the historical correction, automatic detection was not verified.

FIG. 1 · Where a line comes from

A schematic drawn from the linking rule in the old records. "Make a small game" and "learning to bake bread" are invented examples. A line marks origin; an unrelated topic starts a separate tree.

What the old version left behind

The summary from going through the old records lists 135 trees and 608 nodes. The relations of 534 nodes were filled in with fixed values by the program, 517 have no parent node, and only 7 trees have any parent-child edges. A node missing a parent can also carry a fixed relation, so these two counts don't add up into another batch of nodes.

This comes from how the old program degraded. When it received simplified labels, it wrote the id and the relation as fixed values and left the parent empty, so it produced many records without saying where they came from. The numbers here are from the summary of that retrospective.

After the fix back then, the structure for the program to read listed nodes, roots, and the current node, while people got an indented tree. When no parent could be found it started a new tree; when parsing failed it appended a failure record under the previous node. Links patched in this way don't necessarily mean one thing really followed from the other.

Counts from the old structureHISTORICAL COUNTSReview summary, not recounted here. Original intent data was not read.NODES608totalProgram-fixed relation534 / 608No parent node517 / 608TREES135totalWith parent-child edges7 / 135Each cell is a tree, 7 shaded cells have parent-child edges.The node counts may overlap. Trees have their own denominator.

FIG. 2 · Structural problems in the old records

Numbers from the retrospective summary. Trees and nodes each have their own totals, and the two node problems can't be added together.

How it gets recorded now

When I rebuilt it in July 2026, the tree became one continuously maintained document instead of one entry per message. Starting something new, branching off another line, switching back, finishing or dropping a line: the agent (the program that maintains these records) updates the document.

The document marks which intents are active, which are parked, and which are done or dropped. The conditions for switching states were never written down in full. The old canvas pulled the "what the person is chasing" part out of the tree, and the other agents that carried on the work got the intent document as context. How material cards attach to the tree, though, I haven't written up completely yet.

How the intent document was maintainedHISTORICAL MAINTENANCEPersonstates an intentagentthe maintainerupdates the documentOn a new intent, a branch,a switch, or an endingIntent documentMake a small gameDesign levelsactiveDebug controlson holdFICTIONAL EXAMPLEHISTORICAL STATESactive · on hold · closed · abandonedPast canvasshows what a person seeksSub-agentreads intent contexttwo docs were suppliedThese are historical relationships, the current interface was not checked.Only the state set is shown, full transition rules were not found.

FIG. 3 · How one document gets maintained

A schematic of how the document is maintained, with invented node content. The document fed the old canvas and the other agents. How materials bind to the tree and the full state transitions were never written down, so the figure doesn't draw them.

Where it stands