A module is a domain's practice encoded as a walkable tree: an entry block that teaches the WALK, aspect blocks that hold the domain's knowledge, and leaf blocks that ground out in real APIs. Every engagement composes three layers: the customer's own AI plus their private Lattris graph, this public tree (the provider's practice), and the provider's own domain system (the data the leaves point to).
Recon before writing a word. Map the domain's real data layer: routes, request shapes, auth, and its own vocabulary — a system's words can trap the unwary (a field named like something familiar that means something else here). Verify access works end to end, one real call, before any block promises it.
Author the entry. It teaches the walk, not the domain — domain knowledge lives in the aspect and leaf blocks it points to. State ordering as mechanism, never tradition: say WHY a step comes first, not just that it does. Every leaf must earn its own fetch from title, summary and edge reason alone; a summary that can't justify the fetch gets fixed, never propped up with extra machinery.
Split what Lattris holds from what the domain system holds. Lattris carries the journey — decisions (the why) and sessions (the how-it-went). The domain system carries current state. Never keep either only in the module's head. One decision becomes one note, written the day it's made; undecided things stay unwritten — the decisions, read together, are the plan's current state.
Always include a recall leaf: the exact order a returning AI rebuilds context — decisions first, then the person's own graph, then the domain system's current state, then what's new today — and instructs the AI to keep growing that person's graph as it learns (people, relationships, context, written when learned, titled to be found).
Always include a self-memory leaf: read the account before speaking on return; save the session (lattris capture session) when one closes. State, why, and how-it-went, together, are what "knowing this person" means.
Only operational facts cross into the domain system — names, contacts, amounts, dates, answers. The reasoning behind them (why a decision was hard, who someone really is to the person) stays in the person's own private graph. The domain system's fields simply have no place to hold it — that split is what keeps the person's real thinking off a system built to extract value from it.
Seed it. Draft the whole tree as one seed batch (blocks + edges together) so a later pass has one artifact to work from. Create each block with POST /memories/notes, set its summary after with PATCH. Link with POST /memories/{id}/edges, verb references, reason always required and aimed at a real fetch decision — never at an obligation (obligations belong in the block body, not the link).
New relationship verbs may be added without asking first, but only when all three hold: the verb is actually needed by a real engagement (not anticipated), no existing verb already covers it, and it is the plain-language name of the real relationship — a name that needs a legend has failed.