[Docs]: Cloud docs describe foresight/eventlog search and top_k=-1, but the v1 search API rejects both

[Mist-wu]

Page or file

https://docs.evermind.ai/llms-full.txt (and llms.txt) — "Foresight Memory" and "Search Memories" sections

What should be improved?

Two documented Cloud search features don't match the live v1 API behavior (verified 2026-06-10 against https://api.evermind.ai):

1. memory_types=["foresight"] (and eventlog) are rejected with 422

The "Foresight Memory" section shows searching with memory_types=["foresight"] + current_time, and the memory-types table lists foresight / eventlog as API values. The live API rejects both:

{"code":"HTTP_ERROR","message":"Value error, memory_types must be from: agent_memory, episodic_memory, profile, raw_message. Invalid: ['foresight']: memory_types","request_id":"0a4673bd-833a-49fe-b748-3be219abb007","timestamp":"2026-06-10T00:39:10.952452+00:00","path":"/api/v1/memories/search"}
{"code":"HTTP_ERROR","message":"Value error, memory_types must be from: agent_memory, episodic_memory, profile, raw_message. Invalid: ['eventlog']: memory_types","request_id":"aa9953f9-cd7a-48c7-a488-0cd4d8f1e4df","timestamp":"2026-06-10T00:39:11.985480+00:00","path":"/api/v1/memories/search"}

(The "Search Memories" parameter table itself only lists the 4 accepted values, so the docs are also internally inconsistent with the Foresight section.)

2. top_k=-1 is documented as the default ("-1 for all up to 100 (default -1)") but errors

curl -X POST https://api.evermind.ai/api/v1/memories/search \
  -H "Authorization: Bearer $EVEROS_API_KEY" -H "Content-Type: application/json" \
  -d '{"query":"preferences","filters":{"user_id":"<uid>"},"method":"hybrid","top_k":-1}'

{"code":"HTTP_ERROR","message":"Failed to search memories, please try again later","request_id":"304c4f86-95ef-4087-8df2-ab33d1899080","timestamp":"2026-06-10T00:39:21.292009+00:00","path":"/api/v1/memories/search"}

The same request with top_k=5 succeeds.

Suggested wording or structure

Either implement foresight/eventlog as searchable memory_types and fix top_k=-1 server-side, or update the docs to:

• remove foresight/eventlog from the searchable memory-types until supported (or mark them "extraction-only, not yet searchable"), and rewrite the "Searching foresight memories" example accordingly;
• document top_k as a required positive integer (recommend 5–10) and drop the -1 auto-cutoff claim.

Happy to provide more request_ids if useful — I maintain a TypeScript client (pi-everos-memory) against the v1 API and re-verify these regularly.