Schemas and Memory Decay

Atomic Fact Schema (items.yaml)

- id: entity-001
  fact: "The actual fact"
  category: relationship | milestone | status | preference
  timestamp: "YYYY-MM-DD"
  source: "YYYY-MM-DD"
  status: active # active | superseded
  superseded_by: null # e.g. entity-002
  related_entities:
    - companies/acme
    - people/jeff
  last_accessed: "YYYY-MM-DD"
  access_count: 0

Memory Decay

Facts decay in retrieval priority over time so stale info does not crowd out recent context.

Access tracking: When a fact is used in conversation, bump access_count and set last_accessed to today. During heartbeat extraction, scan the session for referenced entity facts and update their access metadata.

Recency tiers (for summary.md rewriting):

• Hot (accessed in last 7 days) -- include prominently in summary.md.
• Warm (8-30 days ago) -- include at lower priority.
• Cold (30+ days or never accessed) -- omit from summary.md. Still in items.yaml, retrievable on demand.
• High access_count resists decay -- frequently used facts stay warm longer.

Weekly synthesis: Sort by recency tier, then by access_count within tier. Cold facts drop out of the summary but remain in items.yaml. Accessing a cold fact reheats it.

No deletion. Decay only affects retrieval priority via summary.md curation. The full record always lives in items.yaml.