Scoping & recall

Recall is search-driven, not a dump of everything you’ve ever stored. Scoping fields tell Nexus-Catalyst what thread and project you’re in; the query and user_query_full fields tell it what to look for.

The scoping fields

Field	Tool	Purpose
conversation_id	recall_context, store_context	Thread ID, format nc-[topic]-[YYYYMMDD]. Reuse across turns in the same session
client_project	store_context	Workspace slug (repo name) — scopes project-recent recall
query	recall_context, search_memories	Short topic label — name the subject, not the action
user_query_full	recall_context	User’s verbatim message — improves retrieval on long prompts

Good vs bad queries

✅ "OAuth Lambda middleware TypeScript"
✅ "Stripe subscription free tier"
❌ "fix implement analyze extract"

Action verbs match poorly against stored content. Name what the subject is.

Project silos vs cross-project recall

Native client memory is often scoped to a workspace or CWD. That helps focus. Nexus-Catalyst adds intentional cross-scope recall:

• Same client_project on store → surfaces in project-scoped recent recall
• Semantic search via query / user_query_full → can pull relevant work from other projects when the current scope isn’t enough
• You are not forced into one undifferentiated blob — retrieval is query-driven

See Comparison for the native-memory tradeoff.

Session workflow

1. recall_context at session start — same conversation_id all thread
2. search_memories mid-session when recall didn’t surface something you now need
3. store_context when the turn produced something worth remembering — tag client_project when the work is repo-specific

Team and department scope

Team plan memories are per user with department-level sharing options. client_project still helps organize recall within a department; cross-department rules are admin-configured. See Memory System.

Related

• Memory System — storage tiers and metadata
• MCP tools — parameter reference
• User facts — injected profile data (separate from search)