Schema
Define the node types, attributes, and connections that give your graph structure.
A schema is the blueprint for a space. It declares three things:
- Node types — the kinds of things that can exist in your graph.
- Attributes — the fields each type can hold.
- Connections — how types relate to one another.
With a schema in place, every node has a defined shape, and Naumu can tell you when something doesn't fit.
You don't have to design a schema by hand. When you build a space from a conversation or an import, Naumu proposes one for you. Still, understanding the pieces helps you read, refine, and trust the structure.
Node types
A node type is a category — Company, Person, Feature, Document. Every node in your graph is an instance of exactly one type.
Type names use PascalCase: capitalized words with no spaces. Naumu leans toward general types. For example, prefer a single Person type refined by attributes over separate Employee and Contractor types.
Types form a single-rooted hierarchy — a tree with one type at the top. Exactly one type, the root, has no parent. Every other type declares a parent type it nests under, so the schema reads top-down as a tree. A type can also nest under another node of its own type — a Task under a Task — which gives you sub-tasks without inventing a new type.
Each type can carry a one-line description explaining what it represents and how it differs from similar types. When Naumu's agents decide which type a new node belongs to, this description is their strongest signal, so it's worth writing well. Types can also be given a color to tell them apart at a glance in the graph.
Attributes
Attributes are the fields an instance of a type can hold. Each attribute has a name and a type:
| Attribute type | Holds |
|---|---|
string | Free text (with an optional max length and placeholder) |
number | A numeric value (optional min, max, and a unit suffix like h or $) |
date | A date, shown in your chosen format |
boolean | A true/false toggle, with an optional default |
select | One value chosen from a fixed list |
multiselect | Any number of values from a fixed list |
For select and multiselect, you define the list of allowed values. Each value has a label, an optional color, and an optional short description that sets it apart from the others (for example, "closed-won — deal signed and revenue committed"). Any attribute can be marked required, meaning every instance of the type is expected to fill it in.
Reach for a select over free-text string whenever the answers fall into a known set. A fixed value list keeps your data clean and makes filtering and grouping reliable.
Connections
Connections describe how one type relates to another. Each one is declared on the dependent type and points outward. There are three kinds:
- Parent — the structural "belongs under" relationship that builds the hierarchy. A type has at most one parent connection.
- Required — connections every instance is expected to have.
- Suggested — connections that are encouraged but optional.
Every connection has a relation name in UPPER_SNAKE_CASE (WORKS_AT, BELONGS_TO, BUILT_BY) and a target. A target is usually a single concrete type. When a relation legitimately attaches to many different types — think a Comment or a Tag — you can mark it polymorphic instead, meaning it targets anything.
Polymorphic is the escape hatch, not the default. If most of your connections point at "anything," the structure isn't doing its job — pick concrete targets, and add a missing type if you can't.
Viewing the schema
Open the Schema panel for a space to browse its structure. Node types appear as a tree, indented by parent, with polymorphic types listed separately under "attaches to anything." Select any type to open its detail view, where you can read and edit its attributes, connections, color, and description.
The same panel shows the space default visibility — Open, Internal, or Restricted — which applies to new nodes when nothing more specific is set. See Members & sharing for what each level means.
Validation and the Schema Gardener
Because every node has a declared shape, Naumu can check whether your graph actually follows it. The Schema Gardener — one of Naumu's system agents — watches for structural drift and surfaces violations so you can fix them. The same checks also appear inline on a node's detail page. Violations fall into a few kinds:
- Missing parent — the schema expects a parent edge that isn't there.
- Multiple parents — a node has more parent edges than its type allows.
- Parent mismatch — the parent has the wrong type, or the edge uses the wrong relation.
- Unknown relation — an edge uses a relation the schema doesn't define.
- Invalid connection — an edge points at a type the schema doesn't allow for this source.
- Unknown type — a node's type no longer exists in the schema (often because the type was deleted).
These are guidance, not hard blocks — your data stays intact. The catch-all relation RELATES_TO is always allowed, so you can connect anything without tripping a violation when no formal relation fits.
Default visibility per type
Beyond the space default, each type can set its own default visibility — Open, Internal, or Restricted. New nodes of that type inherit it when no explicit visibility is given. A type with no default of its own falls back to the space-level default. See Members & sharing for what each level means.
Changing a type's default does not retroactively change visibility on existing nodes; it only affects nodes created afterward.
Related
- Spaces — how spaces hold your knowledge graph.
- Nodes & edges — working with individual nodes and edges.
- Members & sharing — what Open, Internal, and Restricted mean.