The ACT-R vitality model reads access_count and last_accessed from note frontmatter to compute vitality scores (computeVitalityACTR and computeAccessSaturation in vitality.ts). But these fields are only set at creation (access_count: 0 in add.ts) and on promote. They're never updated when a note is actually retrieved via runQueryRanked.
This means the ACT-R model has no signal for how often a note gets used. Every note decays at the same rate regardless of retrieval frequency, which defeats the purpose of the cognitive decay model.
v0.5.5 added Ebbinghaus tracking in the boosts table, which slows activation boost decay for frequently accessed notes. But that feeds a separate signal (activationBoost at line 136 of vitality.ts), added on top of the base vitality score. The frontmatter access_count that drives the core ACT-R calculation and access saturation remains stale.
The two systems also differ in durability: the boosts table lives in SQLite and is lost if the database is deleted or rebuilt. Frontmatter lives in the markdown files and survives.
A fix would be to update access_count and last_accessed in frontmatter for each note returned by the retrieval pipeline. I have a patch ready if you'd like a PR.
Worth noting: runQueryFading and runQueryImportant also return notes without updating access metadata. Those could be addressed separately.
The ACT-R vitality model reads
access_countandlast_accessedfrom note frontmatter to compute vitality scores (computeVitalityACTRandcomputeAccessSaturationinvitality.ts). But these fields are only set at creation (access_count: 0inadd.ts) and on promote. They're never updated when a note is actually retrieved viarunQueryRanked.This means the ACT-R model has no signal for how often a note gets used. Every note decays at the same rate regardless of retrieval frequency, which defeats the purpose of the cognitive decay model.
v0.5.5 added Ebbinghaus tracking in the boosts table, which slows activation boost decay for frequently accessed notes. But that feeds a separate signal (
activationBoostat line 136 ofvitality.ts), added on top of the base vitality score. The frontmatteraccess_countthat drives the core ACT-R calculation and access saturation remains stale.The two systems also differ in durability: the boosts table lives in SQLite and is lost if the database is deleted or rebuilt. Frontmatter lives in the markdown files and survives.
A fix would be to update
access_countandlast_accessedin frontmatter for each note returned by the retrieval pipeline. I have a patch ready if you'd like a PR.Worth noting:
runQueryFadingandrunQueryImportantalso return notes without updating access metadata. Those could be addressed separately.