LTM observability and troubleshooting

An LTM request has at least four useful dimensions: entry point, Space boundary, derivation or recall stage, and final outcome. First confirm the environment, then distinguish asynchronous delay, boundary filtering, and model bypass.

Signals to record

Signal	Use
X-Turing-Trace-Id	Correlate API, Managed Chat, and platform audit records
space_id, actor_id, session_id	Confirm ownership and session boundaries
Event status	Distinguish acceptance from completed derivation
Memory outcome headers	Determine whether Recall, Evidence injection, and Capture ran
source_event_id, revision_id	Explain a record's source and current version

Standard troubleshooting path

1. Confirm Base URL, API Key, Client, and Space belong to the same environment.
2. Confirm owner_type, actor_id, and session_id; 202 Accepted means queued, not derived.
3. Use List memories to inspect derived records before judging a Search miss.
4. Check include_shared, memory_type, topic, token_budget, and abstain_threshold.
5. For Managed Chat, inspect outcome headers and Trace. A fallback request does not read or save Memory.

Common symptoms

Symptom	Check first
202 but no record yet	Derivation delay and Space/Actor consistency
Search returns no hit	Scope, type, threshold, and shared-only filters
Context is unexpectedly short	Budget, sections, summary limit, and available records
Managed Chat did not save	Terminal status, fallback, outcome header, and Trace
Duplicate derived records	Whether retries reused the same Idempotency-Key

Use Memory Explorer for records and visual audit, and server logs for Trace, Space, and time-window aggregation. Correlate with X-Turing-Trace-Id, not model output text.