Memory correction

Correct the record, do not append a contradiction

A correction changes the existing memory through PATCH /v1/memories/{memory_id}. MemoryUpdateRequest makes every field optional and includes content, path, metadata, source, provenance, memory_type, status, expires_at, scope, and team_id. This keeps the correction attached to the same memory reference and lets the server apply its versioning path.

PATCH /v1/memories/<memory-id>
X-API-Key: <your-assigned-api-key>
Content-Type: application/json

{
  "content": "The corrected deployment decision was verified on 2026-09-02.",
  "provenance": {
    "correction": "owner-confirmed"
  },
  "merge_provenance": true,
  "detect_conflicts": true
}

Version and conflict controls are part of the request

The update contract includes merge_metadata, merge_provenance, and detect_conflicts, all defaulting to true, plus supersession_reason. The persistence path increments the memory version and keeps status/superseded_by/conflict evidence in the public memory contract; read the returned implementation data as the current result, while the OpenAPI response remains untyped.

• Merge metadata and provenance when the correction should retain existing evidence.
• Keep detect_conflicts enabled when concurrent edits or competing versions matter.
• Use supersession_reason when the correction intentionally supersedes an earlier version.

Verify the corrected scope

After a correction, perform a scoped read and inspect the returned version, status, provenance, and conflict fields. Retrieval still follows the authenticated scope and memory status filters; a successful PATCH alone is not a proof that the intended scoped result is now visible.

GET /v1/memories/search?query=corrected%20deployment%20decision&scope=memory-os&status=active&limit=5
X-API-Key: <your-assigned-api-key>