DME information state¶

The Dialogue Move Engine maintains a TDM Information State (TIS) while processing a session. It contains shared dialogue state and private engine state; it is runtime state, not a DDD or an application-owned object.

Main structure¶

The current TDM model has shared and private parts. Shared state includes previous moves, the latest utterance and turn content, questions under discussion (QUD), active goals, commitments, and a previous goal. Private state includes the agenda, beliefs, issues being accommodated, iterators, question hints, the next-move queue, the active plan, and temporary data.

The exact structure is defined by the DME Information State contract. Changes to state fields can affect persistence and session compatibility.

Serialization and storage¶

TDM exposes JSON:API serialization for its state resources and also serializes the TIS as JSON for persistence. The CouchDB session retriever stores this serialized TIS with the TDM session record and returns a compressed serialized form to the caller. The Pipeline and Handler also carry session fields across interaction requests; that outer session envelope is distinct from the TIS serialization itself.

Use the versioned state contract when changing this format. Do not hand-edit persisted production session state based only on an example from the documentation.

Important distinction¶

The Handler response session is the application round-trip object. It can contain offer data, request metadata, dialogue history, and other fields in addition to DME state. The Handler can encrypt non-whitelisted session values under session.encrypted_data. Neither that wrapper nor the encrypted values should be confused with the TIS's own JSON/JSON:API representation.