Skip to content

Runtime architecture

The current runtime has two HTTP boundaries that serve different callers:

  1. The Handler accepts application interaction requests.
  2. The Pipeline coordinates dialogue-processing services for the Handler.

Tala supplies DDD loading and shared semantic models. TDM's Dialogue Move Engine (DME) updates the dialogue state and selects moves from those models. NLU/NDU and NLG/NDG services participate in interpretation and realization; the Pipeline chooses and coordinates calls according to the request, session, configured endpoints, and enabled neural settings.

Request path

Application
    │ interaction request
    ▼
Handler (/interact/{offer_id})
    │ prepares offer/session and forwards request
    ▼
Pipeline (/pipeline-fn)
    ├── language understanding and interpretation
    ├── DME dialogue processing
    ├── optional follow-up component calls
    └── response enrichment
    │
    ▼
Handler response to application

The Handler may load an offer when the session does not already contain its ODB. It forwards the request to the Pipeline, handles any service invocation requested by the Pipeline, and resubmits the result until a user-facing response is ready. It also applies Handler-specific behavior such as session encryption, wakeword handling, and response timing.

The Pipeline's request runner prepares session data, coordinates interpretation and DME processing, may restart interpretation after an ASR/NDU correction, then enriches the response and trims dialogue history. This is asynchronous service orchestration, not a single direct DME call.

Repository ownership

Component Responsibility Main boundary/model
Handler Application interaction boundary Session lifecycle and /interact/{offer_id}
Pipeline Runtime orchestration Component calls and /pipeline-fn
Tala DDD loading and semantic models DDD formats and shared model vocabulary
TDM/DME Dialogue move processing Dialogue state and move selection

The production endpoint configuration is supplied to the deployed services. This site documents configuration names and behavior, not environment-specific URLs, credentials, or deployment values.

Compatibility boundary

The Handler contains compatibility behavior in addition to its main /interact/{offer_id} route. Treat those paths as compatibility behavior, not as the recommended application contract. Check the deployed Handler revision before relying on a detail described here.