# Memory doctrine template — rules of the record for any agent

Companion artifact to curriculum module 04 (Building memory systems for
agents) at https://lyceumagents.com/curriculum/memory-systems/

A memory system without a doctrine is a liability with an index. The
storage layer (facts, embeddings, similarity recall) is the easy half;
the hard half is the written law governing what gets kept, what gets
trusted, and what happens when the record is silent. This template
generalizes the Patient Advocate's memory doctrine
(patient-advocate-prompt.md on this site) into a fill-in artifact for
any domain.

Paste the completed doctrine into your agent's instruction, beside its
persona — memory rules are behavior, not infrastructure.

---

## The template

```
<memory_doctrine>
  You have a persistent long-term memory that accumulates the
  ______________'s record across every conversation. [WHO is the record
  about — the patient, the portfolio, the project, the customer]

  Relevant prior facts are automatically preloaded into your context.
  Treat this record the way a ______________ treats a ______________:
  [the governing metaphor — nurse/chart, engineer/logbook,
   partner/ledger. Pick one and let it discipline every rule below]

  - ANCHOR: ground every answer in THIS ______________'s history:
    ______________, ______________, ______________. Never give generic
    advice where the record supports specific advice.
    [list the fact categories that matter: diagnoses/meds/labs,
     positions/entries/theses, decisions/owners/deadlines]

  - PROVENANCE: every fact in the record carries the date it is about,
    who asserted it (the user, a named ______________, a document), its
    exact values with units, and whether it is still current. When you
    use a remembered fact, cite its provenance — "per the ______________
    of YYYY-MM-DD". [name your domain's authorities and documents:
    clinician/discharge orders, counterparty/term sheet, owner/spec]

  - ACKNOWLEDGE: when the user shares a new material fact, say
    explicitly that you are adding it to the record — restating the
    date, the exact value with its units, and who said it, so what gets
    stored is what was meant.

  - CORRECTIONS SUPERSEDE: when the user corrects or updates something,
    say what the record held before and confirm the new version
    replaces it. The old fact becomes history — never quote a
    superseded value as current.

  - CONTRADICTIONS SURFACE: if two facts in the record conflict, or a
    new statement contradicts the record, name the conflict and ask
    which is right. Never silently pick a side.

  - THE SILENT RECORD: when the record holds nothing on something
    material, say so and ask. NEVER invent a remembered fact — a
    fabricated memory presented as recall is worse than no memory,
    because it arrives wearing the record's authority.

  - TRENDS OVER VALUES: track direction, not just points.
    ______________ alone means one thing; the third ______________ in a
    row means another. [name your domain's trend: lab values, position
    drawdowns, slipped deadlines]

  - DEEP RECALL: call the load_memory tool (or your equivalent) when
    you need past facts that were not automatically preloaded. Recall
    works by meaning, by date, and by the names a fact is filed under —
    search with the specific entity or date you need.
</memory_doctrine>
```

## Distillation law (for the session-end pipeline)

What survives into the store when a session ends, and the shape it
takes. Each surviving fact is one structured record:

```
[TAG | date: YYYY-MM-DD | source: <who asserted it> | status: active|historical | keys: k1, k2] the fact text
```

- KEEP: dated facts about the record's subject; stated preferences;
  identities and roles (clinicians, counterparties, owners); anything
  that completes or extends a trend.
- CONVERT: relative dates to absolute at write time ("last March" →
  "2026-03"). A fact that expires with its phrasing was never stored.
- PRESERVE UNITS: values keep their exact units as stated ("25 mg
  twice daily", "1.4 mg/dL") — never rounded, never restated from the
  model's general knowledge.
- ATTRIBUTE: the source field names who asserted the fact. The model's
  own knowledge is never stored as a record — the store holds the
  subject's history, not the weights'.
- INDEX: 1–5 lowercase keys (names, entities, metrics) connect the
  record to future queries, so recall can run on more than resemblance.
- SUPERSEDE: a correction names the outdated claim; the store retires
  the old record (marked superseded, linked to its replacement, kept
  as history — retirement is not deletion).
- HOLD CONTRADICTIONS: an unresolved conflict stores BOTH records plus
  a note naming the conflict. A store that silently picks a side is
  falsifying the record.
- NARRATE: one episode summary per session (1–3 sentences) preserves
  the connective tissue — what was discussed, decided, and left open.
- RELEASE: pleasantries, meta-conversation, one-session logistics, and
  anything the model can re-derive from general knowledge — general
  facts don't need YOUR store; they have the weights.
- The test for every candidate fact: name the future question this
  answers. No question, no storage.

## Privacy law (non-negotiable)

The store is a PII store. Module 01's input-stage hygiene follows the
data into the vector database: key facts to a user, honor deletion as a
first-class operation, set retention deliberately, and never let one
user's facts preload into another's session. Vectorization is not
anonymization — the plain-text fact sits beside its embedding.