Memories

The atom of wadachi. A memory = one markdown file + one index row.

Anatomy

field meaning
content markdown body — the knowledge itself. Supports wikilinks
title short and descriptive — it's what search results show
project scope; global for cross-project knowledge (Projects & scoping)
tags keywords for retrieval
category one of the seven below

The seven categories

category use for
architecture system design, structure, high-level patterns
bugfix bugs found and their solutions
config setup, environment, infrastructure details
pattern conventions, recurring code patterns, style rules
context project background, goals, constraints
reference API details, library usage, external docs
note everything else

Storing well

store_memory(
  content  = "Gemini 504 in the fix loop → resume from checkpoint. See [[#63]].",
  title    = "Gemini 504 recovery in convert loop",
  project  = "pipeline",
  tags     = ["gemini", "504", "resume"],
  category = "bugfix")

Habits that pay off:

Updating: nothing is ever lost

update_memory replaces content and/or tags — but first it snapshots the previous version into memory_versions. Retrieve the history with memory_history(id); this also powers Provenance & time-travel.

Deleting vs retiring

delete_memory is permanent (file + row). It's almost never what you want: for knowledge that stopped being true, prefer flag_stale — the memory stays, recoverable, annotated in every recall (Beliefs, staleness & decay). Delete is for noise, stale is for history.

Access tracking

Reading a memory (get_memory, expand_memory) bumps its access counter and timestamp. This feeds decay (Beliefs, staleness & decay): knowledge you actually use stays on top.