slowave_commit: Close the Task and Persist Outcomes

Call slowave_commit at task end to record the outcome and verification, optionally capture a reusable procedure, and trigger offline memory consolidation.

slowave_commit closes the current task session, records the verified outcome, and triggers offline memory consolidation. It is the final step of the Slowave cognitive cycle. Every task that begins with slowave_activate should end with slowave_commit. If the commit is skipped, the idle-session reaper will eventually close the session, but without the outcome metadata, feedback enforcement, or procedure capture that commit provides.

Parameters

session_id · string · required

The active session identifier returned by slowave_activate. The session must exist and must not already be ended.

final_goal · string · required

The confirmed goal for the task, as understood after completing the work. This may refine the initial_goal provided at activation if the task evolved. Must be nonblank.

outcome · string · required

The result of the task. Must be one of:

• success — the task was completed as intended.
• partial — the task was partially completed or the result is incomplete.
• failure — the task was not completed or ended in an error.

outcome_summary · string · required

A standalone, human-readable description of what actually happened. Write this as a self-contained sentence that is meaningful without other context — it will be surfaced in future memory retrievals. Must be nonblank.

verification · object · required

A structured record of how the outcome was verified.

Show verification object fields

status · string · required

The verification result. Must be one of:

• verified — the outcome was confirmed through direct observation or testing.
• partially_verified — the outcome was partially confirmed.
• unverified — no verification was performed or possible.

summary · string · required

A concise description of what verification was done and what it showed. Must be nonblank.

evidence_refs · array

Optional list of evidence references supporting the verification claim — for example test run IDs, CI build URLs, or log file references.

procedure · object

An optional record of the reusable method that was applied during the task. Include a procedure when the task followed a clear, repeatable sequence of steps that would be useful to a future agent working on a similar problem in the same scope.

Show procedure object fields

goal · string

The objective this procedure accomplishes.

summary · string

A concise description of the approach.

context · object

Structured context that defines when this procedure applies — for example, environment, language, framework, or tool versions.

steps · array

An ordered list of the steps that were executed.

caveats · array

Safety notes, known failure modes, or conditions under which the procedure should not be used.

trajectory · array

An optional executed-attempt trace of the task. Limited to at most 32 entries. Each entry describes one step of what the agent did, not the Slowave lifecycle itself.

Show trajectory entry fields

kind · string · required

Either action (something the agent did) or observation (something the agent observed as a result).

summary · string · required

A nonblank description of the action or observation, at most 1000 characters.

status · string

The outcome of this step: started, succeeded, failed, or unknown. Defaults to unknown.

Do not include Slowave lifecycle calls in the trajectory — entries like “Activated the Slowave session”, “Called slowave_recall”, or “Committed the session” will be silently filtered out by the server. The trajectory is a narration of your task actions and observations only. If the server filtered entries, the response will include a trajectory_lifecycle_filtered count.

Response

session_id · string

The session identifier that was closed, echoed back for confirmation.

episodes_formed · integer

The number of episodic memories created from this session’s activity during consolidation.

feedback_status · string

complete for a normal closure where all required feedback was present.

committed · boolean

true when the session was successfully closed.

outcome · string

The recorded outcome, echoed back.

verification_status · string

The recorded verification status, echoed back.

operation · string

closed when the session was freshly committed; updated when commit was called on an already-ended session.

trajectory_lifecycle_filtered · integer

Present only when trajectory entries were removed because they described Slowave lifecycle operations. Indicates how many entries were filtered. If this field appears, review your trajectory construction to exclude Slowave tool calls.

session_note · string

Informational only. Present when the session had several tool-use events but zero slowave_recall calls, as a reminder that deliberate mid-task recall is available.

Incomplete feedback error

If any retrieval_id from an activation or recall during this session has not been fully covered by feedback, slowave_commit returns a retryable error:

{
  "ok": false,
  "error": {
    "code": "incomplete_feedback",
    "message": "feedback is incomplete",
    "retryable": true,
    "outstanding": [
      {
        "retrieval_id": "ctx_a1b2c3d4e5f6",
        "memory_ids": ["sch_42", "sch_17"],
        "procedure_ids": []
      }
    ]
  }
}

The outstanding array lists every retrieval event and the specific memory and procedure IDs that still need assessment. Submit slowave_feedback for each entry in outstanding, then retry the commit.

When to include a procedure

Include the procedure field when:

• The task followed a clear sequence of steps that solved a well-defined problem.
• The method is likely to apply in a future session on the same or a related task.
• The steps are repeatable and can be described without relying on task-specific ephemera.

Omit the procedure field when:

• The task was a one-off that required unique judgment calls.
• The steps are too specific to this exact situation to generalize.
• The task failed and no reusable method emerged.

A procedure captured in slowave_commit is stored as an execution-backed record tied to the session’s outcome and verification. Failed attempts are stored too when a procedure is supplied — they appear as warnings when the procedure is retrieved in a future task. Only include a procedure when you genuinely followed the steps; do not reconstruct them post-hoc.

Idle-session fallback

If slowave_commit is never called, the idle-session reaper closes the session after SLOWAVE_SESSION_IDLE_TIMEOUT seconds (default 3600). Sessions closed by the reaper:

• Do not enforce feedback completeness.
• Do not capture a final goal, outcome summary, verification, or procedure.
• Do not trigger the same consolidation quality as an explicit commit.

Always prefer an explicit slowave_commit call over relying on the reaper.

Examples

Successful task with verification

{
  "session_id": "sess_abc123",
  "final_goal": "Fix the double-close race in the session reaper",
  "outcome": "success",
  "outcome_summary": "Added a threading lock around the reaper's close logic; the race no longer reproduces under 100-thread stress testing.",
  "verification": {
    "status": "verified",
    "summary": "Full integration test suite passed. Ran the stress test 3 times with 100 concurrent threads — zero double-close errors."
  }
}