docs: fix drift in Recall Operations

[jack-arturo]

Automated docs-accuracy audit of reference/api/recall-operations. Every fix below is anchored to a permalink in the code it describes.

Claim	Current state	Fix	Evidence
Recency sub-score is max(0, 1 - (age_days / 180)), "6-month linear decay based on time since last access"	_compute_recency_score() is called with memory.get("timestamp") — creation time, not last_accessed. The window is SEARCH_RECENCY_WINDOW_DAYS (default 180) and the curve is selectable via SEARCH_RECENCY_CURVE (linear default, exp available)	Describe the formula in terms of SEARCH_RECENCY_WINDOW_DAYS, say it measures from timestamp, and mention the exp curve	scoring.py#L166, scoring.py#L74-L81, config.py#L499-L503
Sorting section: score combines "all 9 components"	Ten weighted components are summed (vector, keyword, metadata, exact, importance, confidence, recency, tag, relation, relevance) — and this page already says "10 scoring components" in its intro and lists 10 in the weight table	9 → 10	config.py#L473-L482
match_type is one of semantic, keyword, tag, relation, entity	The service emits vector, keyword, trending, metadata, tag, relation, entity_expansion, priority_id, state_replacement. Neither semantic nor entity is ever produced	Replace the list with the emitted identifiers	runtime_recall_helpers.py#L1023, #L719, #L584, #L823, recall.py#L1465
Sample response shows "match_type": "semantic"	Same as above — a vector hit is labelled vector	semantic → vector	runtime_recall_helpers.py#L1023

Verified against: verygoodplugins/automem@8ff266e
Verified against: verygoodplugins/mcp-automem@2816beb

Claims re-checked this pass and found accurate (no edit made): RECALL_MAX_LIMIT=100; tag_match server default prefix; sidecar slot reservation max(1, min(limit, 10)); the vector over-fetch formula and its RECALL_VECTOR_OVERFETCH=4 / RECALL_VECTOR_FETCH_CAP=200 defaults; RECALL_RELATION_LIMIT=5; RECALL_EXPANSION_LIMIT=25; RECALL_RECENCY_BIAS shipping off; all ten SEARCH_WEIGHT_* defaults; the keyword scoring points (2 content / 1 tag, +2 / +1 phrase) and ORDER BY score DESC, m.importance DESC, m.timestamp DESC; the MCP three-branch routing in src/automem-client.ts including enumeration-mode rejection of ranked-only params; recall_memory annotated readOnlyHint: true / idempotentHint: true; MCP limit 1–200 default 5, expansion_limit 1–500 default 25, relation_limit 1–200 default 5; and the src/recall-memory.ts budgeting constants (400-char preview, max 3 relation stubs, 100-char relation summaries, 18,000-token default budget).

Questions

• The "Source files" callout pins automem links to 0720da2 and mcp-automem links to 538721c. Those are still valid permalinks, so I left them alone rather than bumping them to the SHAs above — but if the convention is that the callout should track the most recently audited SHA, it needs a refresh. Same question for the sentence "At automem@0720da2 this exclusion applies to ranked recall only", which is deliberately SHA-qualified.
• The Graph Expansion Parameters table omits expand_respect_tags, even though the expansion response example below it returns respect_tags. The parameter is real (recall.py#L1634), so this reads as an omission rather than an error — adding a row felt like new documentation rather than a drift fix, so I left it out.

Unverified

• "LRU Caching: Entity extraction results cached (80% speedup)" — the 80% figure has no counterpart I could locate in code; left as written.
• The "Typical performance" numbers (sub-100ms, 100–300ms with expansion, 100k+ memories) are not derivable from source; left as written.

Follow-ups

None — all proven discrepancies on this page are fixed here (4, under the 5-fix cap).

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying automem-website with    Cloudflare Pages

Latest commit:	08f59c7
Status:	✅  Deploy successful!
Preview URL:	https://947f8a89.automem-website.pages.dev
Branch Preview URL:	https://docs-audit-reference-api-rec-9zhv.automem-website.pages.dev

View logs