Hi team,
Thanks again for the great work on Basic Memory — following up on a separate point from my earlier note (#1372/#1587) about progress visibility.
I noticed the core note format (frontmatter + free-text Observations with optional [category] tags) has no built-in way to distinguish a durable fact from a point-in-time status, or to mark a note/fact as superseded or expired. In practice, older notes can end up contradicting newer ones, and nothing in the core schema or retrieval flags that.
I see the companion repo basic-memory-skills already addresses this with Memory Defrag (removing stale info, merging conflicts), Memory Reflect (consolidating recent notes into long-term memory), and Memory Lifecycle (folder-based status/archiving, "archive never delete"). That's a solid approach, but it currently lives as an optional workflow layer rather than something the core tool is aware of.
Would it be worth considering a lightweight, optional signal in core, for example a status: or as_of: frontmatter field, or a freshness/recency weighting at search time? That would mean, first, users without the extra skills installed still get some protection against stale or contradicting notes surfacing in search, and second, the lifecycle/defrag conventions in basic-memory-skills would have an underlying primitive to build on, rather than relying purely on file organization.
Happy to share more detail on the specific workflow that surfaced this if useful. Thanks for considering it.
Hi team,
Thanks again for the great work on Basic Memory — following up on a separate point from my earlier note (#1372/#1587) about progress visibility.
I noticed the core note format (frontmatter + free-text Observations with optional [category] tags) has no built-in way to distinguish a durable fact from a point-in-time status, or to mark a note/fact as superseded or expired. In practice, older notes can end up contradicting newer ones, and nothing in the core schema or retrieval flags that.
I see the companion repo basic-memory-skills already addresses this with Memory Defrag (removing stale info, merging conflicts), Memory Reflect (consolidating recent notes into long-term memory), and Memory Lifecycle (folder-based status/archiving, "archive never delete"). That's a solid approach, but it currently lives as an optional workflow layer rather than something the core tool is aware of.
Would it be worth considering a lightweight, optional signal in core, for example a status: or as_of: frontmatter field, or a freshness/recency weighting at search time? That would mean, first, users without the extra skills installed still get some protection against stale or contradicting notes surfacing in search, and second, the lifecycle/defrag conventions in basic-memory-skills would have an underlying primitive to build on, rather than relying purely on file organization.
Happy to share more detail on the specific workflow that surfaced this if useful. Thanks for considering it.