Types & Properties
Define custom schemas to give your thoughts structured data like status, priority, or tags.
What are types?
Types let you define structured schemas for your thoughts. For example, a 'Task' type might have properties like status (todo/doing/done), priority (high/medium/low), and due date. A 'Person' type might have email and role fields. Types turn your free-form canvas into a structured knowledge base.
Assigning types to thoughts
Select a thought and open its properties panel. Use the type selector to assign one or more types. Once a type is assigned, the thought gains that type's properties which you can fill in. Type badges appear on nodes so you can see types at a glance.
Property types
Types support several property kinds: text, number, date, boolean (checkbox), enum (dropdown), reference (link to another thought), color, and icon. Each property has a name and a type that determines its editor widget. Text values that are web addresses render as clickable links when you're just viewing the node, and switch back to a plain editable field when you edit.
Wikilinks inside property values
Text property values support [[ wikilinks just like the body editor — type [[ in a string field, pick an existing thought, or 'Create' to spawn a new one. If the property is linked to a type (see below), creating a new thought through that field automatically stamps the linked type — typing [[New Author]] in Book.author lands a node already typed as Author. Wikilinked values create backlinks the same way body wikilinks do, and the surrounding property name shows up in the backlink context.
Linking a property to another type
When defining a property, type [[ in the property NAME field to link the property to another type. The popup shows existing types — pick one to attach a typed pill to the property, or pick 'Create' to spawn a new type definition on the spot. Properties linked to a type get a colored chip with the type's icon in both view and edit mode. Linked types survive across the publish workflow because the link travels by slug (not local UUID) — admins editing a published type from a fresh garden see the link resolve correctly.
Hidden properties
Mark a property as 'Hidden' in the type editor to keep it out of the way on nodes by default. Hidden properties still store values and still appear in search — they just collapse behind a 'N hidden properties' toggle at the bottom of the node so noisy technical fields (ISRC codes, catalog numbers, sample URLs) don't crowd the visible ones. Useful for types like Track that capture rich metadata but only need a handful of fields visible at a glance.
Type inheritance
Types can inherit from other types using 'subtype of' connections. A 'Bug Report' type that is a subtype of 'Task' inherits all of Task's properties (status, priority) plus adds its own (severity, reproduction steps). Properties flow down the hierarchy.
Types are thoughts
In Neural Garden, type definitions are themselves thoughts in a special system garden. This means you can browse, connect, and organize your types on a canvas just like any other knowledge. Admins manage type definitions through the admin panel.
Naming a new type
Use a short Title Case noun for the name ("Person", "Recipe", "AI Agent") and lowercase kebab-case for the slug ("person", "recipe", "ai-agent"). The slug is locked in once you save — it's how the type is identified across syncs, shared gardens, and updates, so picking the right one upfront matters.
Writing a good description
Keep it to one short sentence under twelve words and end with a period. Skip "A" or "An" at the start ("Human individual." not "A human individual.") and don't restate the type name unless it's an acronym ("Artificial intelligence systems." is fine for AI). Descriptions show up everywhere — pickers, search, AI suggestions — so concise wins.
Aliases that help, not confuse
Aliases are the alternative names someone might naturally call this type — used by AI features when classifying free-form input. Keep them tight: zero to four per type. Drop anything ambiguous ("item", "library", "class") or that already means another type. Quality over quantity prevents your types from competing with each other in the picker.
Color and icon choices
Pick a color distinguishable from sibling types but visually related when they're grouped (e.g. all Time types share a blue family). Hex values (#8b9eff) or design tokens (var(--color-node-resource)) both work. For icons, browse Lucide.dev — each type should have a unique icon, so check existing types first. If the icon you want isn't already available, an admin needs to add it to the project's icon map before you can use it.