Skip to content
Developer Codex
Concepts

Understanding the Type System

At some point in any creative project, you find yourself maintaining a list. Characters and their affiliations. Locations and their controlling factions. NPCs and their threat levels. At first the list lives in a document somewhere. Then in a spreadsheet. Then in an increasingly complicated spreadsheet. Then you start thinking about whether there’s a better way.

The type system is the better way. Types let you define structure once and apply it consistently across as many pages as you need. Instead of a spreadsheet beside your notes, the structure lives inside the notes themselves — searchable, linkable, queryable.

The type system has three layers that work together:

Type Definitions are workspace-scoped templates. A TypeDefinition has a name (“Character”), a slug (“character”), an optional icon, and a list of associated property definitions. You define types once and use them across any number of pages.

Property Definitions are the fields attached to a type. A Character type might have properties: allegiance (text), status (select: Active, Deceased, Unknown), threat-level (select). Each property has a name, a value type, and optional configuration (like a list of select options).

Type Assignments are the per-page connections between a page and its types. Assigning the Character type to Magistrate Thorne’s page makes that page a Character — her properties panel shows the Character fields, and she appears in the Characters collection view.

Two types exist in every workspace by default: Page and Folder. These are system types — you can customize their icons, but you can’t rename or delete them. They’re the structural foundation.

Everything beyond Page and Folder is yours to create. Navigate to Settings → Types and click Create Type. Give it a name; the slug is generated automatically. Then define its properties.

A custom type for a worldbuilding project might look like:

TypeProperties
Characterallegiance (text), status (select), occupation (text), arc-phase (select)
Locationcontrolling-faction (text), population (number), political-status (select)
Factionterritory (text), alignment (text), founded (text)
Eventera (text), consequence (text), involved-factions (multi-select)

There are no worldbuilding-specific defaults built in — Inklings ships with Page and Folder, and you create everything else. This sounds like more work than having preloaded types, but it means your type system fits your world rather than someone else’s idea of what a worldbuilding type system should look like.

Each property definition has a value type that determines what kind of data it holds:

Value TypeUse For
textFree-form strings (occupation, notes)
numberNumeric values (population, challenge rating)
yes/noYes/no flags (known-to-players, is-deceased)
dateCalendar dates
selectOne option from a predefined list
multi_selectMultiple options from a predefined list

Value types are immutable after a property definition is created. If you need to change a property’s type, create a new property definition with the correct type and migrate your data. This constraint prevents silent data corruption — a property that was a number stays a number.

A page can have multiple type assignments simultaneously. Magistrate Thorne might be assigned both Character and Political-Figure types, inheriting properties from both. The properties panel merges all typed properties into a single view.

Assign types from the page detail panel (the sidebar panel showing metadata) by clicking the type badge area. Remove an assignment the same way. Assignments can be manual (you added them) or container-scoped (a container rule added them automatically — more on this below).

Deleting a type definition removes all page assignments for that type automatically. The pages themselves remain intact — they lose the type assignment but nothing else.

Container Rules: Automatic Type Assignment

Section titled “Container Rules: Automatic Type Assignment”

A container rule is a rule on a folder page that auto-assigns a type to pages created inside it. Instead of manually assigning “Character” every time you create a new character page, you set a rule on your Characters folder: type = Character, depth = direct children. Now any page created in that folder automatically receives the Character type.

Container rules have two depth settings:

  • Direct children: the rule applies only to pages created immediately inside the folder, not to pages nested deeper
  • Recursive: the rule applies to all descendants, at any depth

You can stack rules. A Characters folder with a recursive Character rule, containing a “Deceased Characters” subfolder with its own direct-children Deceased rule — pages in the subfolder receive both type assignments, one from each rule.

Once pages have types and properties, collection views give you a live table of any type’s pages. From Settings → Types, open any type’s collection view — you see all pages assigned that type, their properties displayed as columns.

A Character collection view shows all characters, their allegiances, statuses, and arc phases in a scannable table. Sorting by status groups living and deceased characters. Filtering by allegiance narrows to a specific faction’s members.

Collection views support three display modes: Table (default, with columns), List (compact), and Gallery. The view configuration — which columns are visible, in what order — persists across sessions.

Collection views don’t replace wiki-links and backlinks. They’re a different navigation mode: type-based querying rather than relationship-based traversal. Use collection views when you need “show me all Characters” or “show me all Locations in descending population order.” Use wiki-links when you’re navigating relationships between specific entities.

Was this page helpful?