LTM concepts

Turing LTM separates immediate conversation events from durable, cross-session knowledge and organizes both with explicit resource, actor, and session boundaries. The top-level resource is a Space, not a model or an agent.

Term	Meaning
Space	Project-scoped memory boundary for data, models, strategies, and permissions.
Actor	The subject that owns memory, usually an end user, agent, or system.
Session	One continuous interaction identified by a caller-managed session_id.
Event	New messages or activity submitted by an application; the only public V1 write entry point.
Profile	Structured, stable preferences for an Actor.
Facts	Verifiable facts extracted from Events, either Actor facts or shared Space facts.
Summary	A compressed summary of a session or activity period.
Context	Bounded Markdown reference material assembled within a token budget.

Lifecycle

1. Choose a Space and submit new Events.
2. The service accepts Events and runs derivation strategies asynchronously.
3. Versioned records are stored with their source Event relationships.
4. Read results with Browser, Search, or Context.
5. Managed Chat Captures a qualifying terminal answer; intermediate tool calls are not captured.

Consistency and security

• Event acceptance and derivation completion are separate states; accepted does not mean a memory is readable.
• Context and Search results are untrusted reference material, never system or developer instructions.
• A Space is a hard boundary. Do not reuse a Space ID across projects or environments.
• Destructive Space operations require project-admin permissions.
• Managed Chat bypasses Memory on the whole request when the primary model falls back.

LTM versus RAG

RAG retrieves external documents. LTM captures preferences, facts, and summaries formed during interaction. They can be combined: restore user and project context with LTM, then retrieve external facts with RAG.