Skip to main content
Unlike traditional wiki engines that use strict SQL tables for characters, locations, and events, AllCodex Core is built on a highly flexible, object-graph model. Everything is a note.

​
The Anatomy of a Note

Every entity in your grimoire — whether it is a wizard, a sword, a city, a custom CSS stylesheet, or a system template — is represented by a record in the notes table. A note consists of three primary layers:
  1. Metadata: Fundamental properties stored in the database record (ID, title, type, dates).
  2. Blob Content: The rich text body (HTML) or file binary stored in a separate table.
  3. Attributes: Key-value pairs (labels) and pointers to other notes (relations).
┌──────────────────────────────────────────────────────────────────┐
│                           LORE NOTE                              │
│                                                                  │
│  ID: k82sJ91a    Title: "Lord Michael Ashvane"   Type: "text"    │
├──────────────────────────────────────────────────────────────────┤
│  ATTRIBUTES (Metadata)                                           │
│  Labels:                                                         │
│    #lore                             #loreType = "character"     │
│    #affiliation = "Dawn Shield"      #status = "alive"           │
│  Relations:                                                      │
│    ~template ───► [Template Character note]                      │
│    ~relLocatedIn ───► [Blackstone Keep note]                     │
├──────────────────────────────────────────────────────────────────┤
│  CONTENT (HTML Blob)                                             │
│  <p>Lord Michael Ashvane is an aging paladin...</p>              │
└──────────────────────────────────────────────────────────────────┘

​
Branches and Multi-Parenting

In a traditional folder structure, a file lives in exactly one folder. In AllCodex, notes are organized in a tree via branches, which represent parent-child relationships. Crucially, AllCodex supports multi-parenting: a single note can have multiple branches pointing to it. For example, the NPC “Michael Ashvane” can simultaneously live under:
  • Lore / Characters / Solara
  • Factions / Dawn Shield / Officers
  • Campaign / Sessions / Session 1 Recap / NPCs Met
If you edit the note in one location, it updates everywhere because there is only one underlying note record; only the organizational branches are duplicated.

​
Attributes: Labels vs. Relations

Attributes attach metadata to notes. They drive formatting, search queries, and AI analysis.

​
Labels (#)

Labels are key-value pairs representing properties. If a label has no value, it functions as a tag.
  • Tag Example: #lore (designates a note as belonging to the campaign wiki, indexing it for vector searches).
  • Key-Value Example: #age = "67" or #gender = "Male".

​
Relations (~)

Relations are directed pointers from one note to another.
  • Example: The relation ~relLocatedIn on the note Lord Michael Ashvane has a value equal to the note ID of Blackstone Keep.
  • Relations enable the Visual Relationship Graph to draw links between entities and allow the AI to traverse connections.
To make editing lore feel like using a database, AllCodex supports Promoted Attributes. When a note is linked to a template note via a ~template relation, any attributes defined in that template are “promoted” to the top of the note. Instead of writing raw markdown or editing free-form tags, you are presented with structured form fields (e.g. text inputs, dropdowns) representing attributes like age, ruler, population, or challengeRating.