slowave_recall: Semantic Mid-Task Memory Retrieval

Use slowave_recall for deliberate mid-task lookups when the task evolves and activation alone did not surface the historical context you need.

slowave_recall is the mid-task counterpart to slowave_activate. Where activation primes working memory at the start of a task, recall gives you an on-demand semantic lookup when the question shifts, a new sub-problem arises, or you need specific historical context that was not included in the activation response. Every recall call is tied to your active session and scope, and returns its own retrieval_id that must be covered by feedback before the session can be committed.

When to use recall vs activate

Use slowave_recall when:

• The task has evolved and you now need context that wasn’t covered by the original activation query.
• A sub-problem requires a focused search on a specific topic.
• Activate returned more_available: true and you need the remaining context.

Do not call slowave_recall as a substitute for slowave_activate. Activate opens the session, enforces the continuity contract, and sets up the feedback ledger. Recall assumes that activation has already happened.

Parameters

query · string · required

A natural-language question or description of the context you are looking for. Must be nonblank. Make it specific to the current sub-problem — the more focused the query, the more useful the retrieval results.

session_id · string · required

The active session identifier returned by slowave_activate. The session must be open and must not have been ended. Its scope must match the scope parameter.

scope · string · required

The retrieval boundary in kind:id form. Must match the scope of the active session. All memory retrieval is scoped to this value.

task_context · object

Optional structured facts describing the current sub-question or evolving task state. When provided, these facts are merged into the session’s task context and used as additional retrieval cues for this call and subsequent ones.

evidence · string

Controls how much raw source material is included in the response. Accepted values:

• references (default) — returns metadata for each evidence record (source kind, timestamps, source ref) without the full text content. Lower token cost; use when you only need to know what evidence exists.
• full — additionally includes the bounded source text for each evidence record, capped at 1000 characters per record. Use when you need to inspect the actual raw material that underpins a memory.

The number of evidence records returned is always bounded by a server-owned limit regardless of mode.

Response

retrieval_id · string

An opaque identifier for this recall event. Pass this to slowave_feedback after you have used (or decided not to use) the returned memories and procedures. Every recall’s retrieval_id must be covered by feedback before slowave_commit will succeed.

memories · array

Relevant memories for the query.

Show memory object fields

memory_id · string

Stable sch_N identifier. Use this in slowave_feedback to record an assessment.

content · string

The memory text, capped at 500 characters.

pathway · string

Either direct (query-matched) or associated (surfaced via graph relations from a direct match). Associated memories are not counted toward the primary result budget.

provenance · object

Optional. When present, contains source_kind, integration, integration_version, and origin_scope (when the memory originated in a different scope).

procedures · array

Execution-backed procedures matching the recall query. Each entry includes procedure_id, goal, summary, context, steps, caveats, outcome, outcome_summary, evidence (use/effect tallies), and contributions (the three most recent observed outcomes).

Show procedure object fields

procedure_id · string

Stable identifier for the procedure. Use in slowave_feedback to record whether the procedure was used and whether it helped.

goal · string

The objective this procedure was designed to accomplish.

summary · string

A concise description of the method.

context · object

Structured context (environment, tooling, language, etc.) that determines when the procedure applies.

steps · array

Ordered list of steps. A procedure is evidence from past work, not a mandatory instruction.

caveats · array

Safety notes and known failure modes. Caveats are never silently omitted.

outcome · string

The most recent outcome when this procedure was last used: success, partial, failure, or unknown.

outcome_summary · string

A human-readable description of what happened the last time this procedure was applied.

evidence · object

Tallies of observed use and effect signals accumulated from past feedback: used, not_used, helped, no_effect, harmed, unknown.

contributions · array

The three most recent observed contribution records, each with effect, contribution, outcome, outcome_summary, and occurred_at.

evidence · array

Bounded raw source records underlying the memories. Always present; content fields only populated in full mode.

Show evidence record fields

evidence_id · string

Prefixed identifier: ep_N for episode records, evt_N for raw event records.

source_kind · string

Either episode or event.

recorded_at · integer

Unix timestamp of when the record was written to storage.

occurred_at · integer

Unix timestamp of the source event time. May differ from recorded_at when occurred_at was supplied at remember time.

source_ref · object

A stable reference to the underlying record: {"kind": "episode"|"event", "id": N}.

content · string

Only present in full mode. The source text, capped at 1000 characters.

truncated · boolean

Only present in full mode. true when the source text exceeded 1000 characters and was cut.

evidence_mode · string

Echoes back the evidence parameter value used for this call: references or full.

evidence_truncated · boolean

true when there are more raw source records than the server-owned evidence limit allows. Only the first bounded set of records is returned.

Examples

References mode (default)

{
  "query": "What database migration strategy does this project use?",
  "session_id": "sess_abc123",
  "scope": "project:my-repo"
}

Every retrieval_id returned by slowave_recall must be covered by a slowave_feedback call before slowave_commit will succeed. If you issue multiple recall calls during a task, keep track of each retrieval_id and submit feedback for all of them.