🏷️ Core Types
Six standard types provide a shared vocabulary across all lands. These are conventions, not constraints. Custom types are valid too.
goal
A desired outcome. What you're working toward.
plan
A strategy or sequence of steps toward a goal.
task
A discrete piece of completable work.
knowledge
Stored information or understanding.
resource
A tool, skill, capability, or reference.
identity
Who or what this tree represents, its values, its constraints.
null is always valid. Untyped nodes work exactly as they always have. No node is required to have a type.
💻 Types Are File Extensions
In a traditional OS, a file extension tells programs what to do with a file. .js means "run this with Node." .md means "render this as markdown." The extension is a semantic label. The file contents are the payload. Programs read the extension to decide how to interact.
TreeOS works the same way. The type is the extension. The node itself is the file: its notes, values, schedules, scripts, children, all of it. Agents are the programs.
Traditional OS:
skills.js → extension tells Node.js to execute it
readme.md → extension tells a viewer to render markdown
TreeOS:
API Integration (resource) → type tells agents to load notes as capabilities
Core Values (identity) → type tells agents to read notes as constraints
Just like you can create custom file extensions in a traditional OS and register handlers for them, you can create custom node types in TreeOS and teach agents what they mean through instruction nodes in the tree itself.
🔧 Instructions Live in Nodes
The system does not hardcode behavior per type. Your tree does.
A resource node might carry skill descriptions in its notes, configuration in its values, and dependencies as children. An identity node might hold constraints in its notes and priorities in its values. A task node carries schedules, tracked values, and completion status. The whole node is the payload, not just the notes.
This is what makes TreeOS an operating system, not a database with labels. The tree programs its own agents through its own content. Types are the signal. Notes are the payload. Agents are the runtime.
🎨 Custom Types
The type field is a free-form string. The six core types are a shared vocabulary for interop and UI hints, but nothing stops you from using your own.
ritual, protocol, checkpoint, persona ... whatever fits your domain. Agents treat unrecognized types like null unless the tree itself contains instructions for them.
In federation, nodes with unrecognized types are accepted as-is. The core six are universally understood. Custom types degrade gracefully on foreign lands.
✂️ Naming with Types
Types carry semantic context, so node names should not repeat it. The hierarchy already provides context. Names should compress.
My Workout Plan / Chest Workouts / Morning Chest Routine
Workouts (plan) / Chest (task) / Morning (task)
Drop filler words. Don't echo the type in the name. A node typed "plan" named "Workouts" already says "workout plan." Each node only needs the part its parent doesn't already say.
📡 API
Set type on creation or change it later.
POST /api/v1/node/:nodeId/editType
{ "type": "goal" }
POST /api/v1/node/:nodeId/editType
{ "type": null } // clear type
Type is also accepted on node creation endpoints and in the MCP tool interface. Agents can read and set types through edit-node-type, and types appear in tree overviews and node context automatically.