A node type describes one kind of thing in your context graph — Account, Contract, Ticket — and every record of that kind shares its properties, appearance, and rules.
Overview
The Nodes tab lists every node type: name, category, property and edge counts, owner, and last updated. Search or sort by name, use the row menu for Edit or Delete, or click a row for its detail page. Node types fall into three categories, chosen at creation: Core entity (a first-class object like Account), Secondary entity (a supporting record like Ticket), or Derived entity (computed, like Risk Score). Core is pre-selected but changeable.
Creating a node type
New Node opens a three-step flow. Identity sets a singular, capitalised name (name and category required) plus an optional description and tags. Properties lets you start From template, Define manually, or Skip for now — switching resets what you've built, so decide first. Data & Storage sets a record title format (defaulting to the primary key) and two toggles: Enable SCD Type 2 keeps version history and locks permanently once created; Enable Auditable tracks record activity and can change later. You can't finish while a default value doesn't fit its property type, and a node with properties needs exactly one primary key. Skipping properties saves the node right away, but the first property you add afterward must be the primary key.
Choosing a colour and icon
Node types are coloured automatically by default, so every node of a type looks consistent across the schema canvas, node lists, and the record relationship graph. Open the appearance picker — the round preview beside the Name field on Identity — for curated colours, a custom swatch for any hex value, and a searchable icon grid. A colour you pick overrides the automatic one and is remembered until changed; types you never customise keep their automatic colour.
Properties, flags, and defaults
A property's Key must start with a letter or underscore, use only letters, digits, and underscores, and be unique within the node — some reserved words get quietly aliased rather than rejected, so avoid common terms as keys. Adding or editing a property steps through Basics (key, display name, type, default value, nesting), Behaviour, and Review. Marking Primary key forces Required, Unique, and Graph queryable on and locks them — only one per node, and it can never carry a default. Other flags cover Required, Indexed, Unique, PII, and optional hashing, secure field, search, sorting, and filtering. Changing a property's type, or turning on Primary key, silently clears any default already set. From template offers dozens of pre-built schemas — Account, Contact, Invoice, Ticket — searchable by name or field; applying one copies field names, types, and key flags as an editable starting point, though defaults don't come across.
The node detail page
Opening a node shows its icon, name, category, description, an Edit/Delete menu, and five tabs: Properties, Edges, Survivorship, Data quality, and Data matching. Properties lists every field with its name, key, type, and flags, and supports adding, editing, or deleting — deleting one removes anything nested under it too. Edges is a read-only view of relationships touching the node. Until backed by real data, the last three tabs show a placeholder.
Survivorship and data rules at the node level
The Survivorship tab decides which value wins when multiple sources supply the same field. Turn on Use Custom Strategy for a default strategy, then override it per field with rules built from Source System priority, Recency, Minimum Value, or Maximum Value, plus fallbacks and filters — object and list fields can't be customised this way, and the rules are shared with the node's underlying data model. Data quality and Data matching are read-only summaries of rules already attached to the node — quality shows each rule's type, its conditions, and the outcome on failure; matching shows conditions, filters, and how matches resolve. Creating or editing these rules happens from the underlying data model, not the node page.
Deleting a node
Deleting a node type is significant and permanent: it removes the node, every connected edge, and the underlying records — taking their survivorship, quality, and matching rules with them. The confirmation prompt calls out connected edges, but the impact goes further than what's shown, so check what's linked before confirming. This can't be undone.
Notes
Deleting a property breaks any mapping or edge join that used it; changing a key effectively replaces the property, so recheck mappings either way.
Moving the primary key to a different property is a major identity change — do it before real data flows.
Node edits use a version check: if someone else changed the node first, your save is rejected rather than overwriting theirs.