How it works

Rules, not a pile of notes

Every guarantee BrainLLM makes is enforced by the server, not requested in a prompt. Here is what that looks like.

The tree

Five areas, built on first run

bootstrap() builds the tree against a fresh Trilium. The root carries a discovery marker, and every container is engraved with its purpose, so any client that connects later finds the same structure and knows what each part is for.

Run it again at any time: it checks an existing root live and only builds a new tree on a confirmed miss, so a network blip can never produce a second brain.

Trilium · BrainLLM5 areas
BrainLLM
├── Master      the user
│   └── Biography · Goals · Preferences
├── LLM         the assistant's self-model
│   ├── Responsibilities · Protocols · Self-correction
│   └── Diary/            one note per day
├── Memory      the operational record
│   ├── Sessions/         one note per day
│   └── Threads/          multi-session work
├── Knowledge   beyond training
│   ├── Master/           facts about the user
│   └── Domains/          Sources + information notes
└── Insights    the brain's record of itself
    ├── Logs/             a change log per day
    ├── Graph             the relation graph
    └── Claims/           checked against the world
Note classes

Three behaviours, sixteen kinds

What a note is decides how writes to it behave. That is what keeps a knowledge base from decaying into a changelog.

Singletons

One note, kept current

Biography, goals, preferences, responsibilities, protocols and self-correction. Writes merge into their sections. They hold what is true now, with no history in them.

Records

One note per day

Sessions, diary entries, logs and dated thread entries. Every write is a timestamped block, because the order of events is the point. Records are never rewritten.

Collections

Titled and deduplicated

Threads, domain notes and knowledge about the user. A second write with the same title updates the first instead of creating a twin.

Lifecycle

Threads age into an archive

A thread untouched for three weeks turns dormant; untouched for longer, it is archived in place. Archived notes keep their content and come back with recover(). Any touch reactivates a thread, and one marked eternal is never aged.

Aging keys off a label, not the modification date: a thread's own body rarely changes once written, so date-based aging would retire a thread worked on daily.

Memory / Threadslifecycle
active  ─────────▶  resolved | superseded   archived, with an outcome
  │ untouched 21 days
  ▼
dormant ─────────▶  archived in place      recover() brings it back
  │ untouched 45 days more
  ▼
archived             content kept, hidden from default reads
The graph

Sixteen verbs, closed vocabulary

relatesTo · extends · contradicts · supports · causes · references · partOf · worksWith · mentors · instanceOf · supersedes · implements · inspiredBy · sourceOf · derivedFrom · corrects.

Why corrects exists: revising a note in place leaves no trace that its old claim was ever believed. A correction edge tells a later reader to check the notes written in the same pass, by the same reasoning.

Insights / Graph16 typed verbs
sourceOfreferencespartOfcorrectssupportssupportsCurrent StateSourcesRelease threadPurpose and DesignSelf-CorrectionSession note
The gate

Ordered, durable, checked by tool call

A session commits only after every closing step has run, in order: session → addendum → maintain → remarks → diary → close. The diary comes after the remarks because it is the closing record and should be written with the reflection prompts in hand.

The gate's state lives on the day's session note, not in memory, so it survives a restart and behaves the same over stdio or behind a load balancer.

claude · BrainLLMclose()
// the work is done. the session tries to close.
> close(summary, identity)
  refused: preclose_incomplete
  missing: remarks, diary

// saying the steps happened doesn't count.
// only the tool calls do.
> remarks()
> diary(body, identity)
> close(summary, identity)
  session logged · daily log regenerated · backup taken
Editing

Surgery, not rewrites

Large notes are edited by heading, by element or by a few words, never by resending the whole body.

section=

Edit one heading

Replace, insert around or remove a section. Reads take the same parameter, so a heading that reads also writes.

within="tr"

Edit one table row

Name a row by a few words inside it and replace it, insert beside it or remove it. Formatting in the stored text doesn't get in the way.

domain=

Rename across a domain

One find and replace over every maintained note in an area, previewed first and written only when you say so. Records are never touched.

See it running.

Minutes to a working brain, once Trilium is up.