The Lifecycle of a Turn

From user text to grounded answer and execution graph

The MRP-VM runtime is not a single linear rewrite pipeline. It is a bounded recursive execution loop: seed detection emits control documents, the core interpreter admits them, planners pick plugin routes, KB plugins assemble evidence, goal solvers answer or request decomposition, and the engine records the whole run as a DAG. See DS001, DS002, DS031, and DS032.

Phase 1: Seed detection and SOP admission

A seed detector plugin transforms the raw user turn into two control surfaces:

# Intent CNL
@i1 intent compare "BM25 and dense retrieval for CPU-only deployment"
@i2 set $i1 output comparative_recommendation
@s1 seed $i1 explore locate "retrieval tradeoffs"
@s2 set $s1 domain retrieval
@s3 set $s1 evidenceNeed structural
@s4 set $s1 state active

# Session Context CNL
@k1 ku atomic "session::turn::unit-000"
@k2 set $k1 sourceId session
@k3 set $k1 chunkId session::turn
@k4 set $k1 role Constraint
@k5 set $k1 topic "deployment environment"
@k6 set $k1 claim "The system must run on CPU only."

The deterministic SOP interpreter validates and admits these control objects before the engine proceeds.

Phase 2: decomposition, context profiles, and planning

Admitted intents are symbolically decomposed into retrieval-oriented context profiles. A planner plugin then picks an execution route: KB plugin order, goal solver order, and whether to open child frames for decomposition. This planning step may be refined again after retrieval guidance arrives.

Phase 3: KB retrieval and evidence assembly

KB plugins retrieve evidence from the mounted repository, staged workspace, and session memory. Built-in strategies include lexical retrieval, balanced lexical+associative retrieval, and bounded symbolic closure. Retrieval returns resolved intents plus phase-scoped guidance buckets that can influence planners, goal solvers, validators, and child-frame creation.

Phase 4: goal solving, backtracking, and child frames

Goal solver plugins attempt answers against the retrieved evidence. If a solver returns needs-decomposition, or if the planner asks for recursive work, the engine opens an explicit child frame with its own seeds, planning pass, retrieval attempts, and branch history. If one plugin or evidence view fails, the engine backtracks across remaining candidates instead of collapsing the request into a single retry line.

Phase 5: validation and response commit

Successful answers may be checked by validation plugins. Accepted answers are committed to the session log together with selected plugin IDs, the response document, and the canonical execution trace. Failed turns are also recorded in explainability, but they do not commit assistant text into the conversation history.

Explainability output

Every completed request produces an execution trace whose canonical form is executionTrace.graph. The graph contains frames, seeds, plugin attempts, branches, results, failures, and typed edges such as contains, spawned_from, uses, produced, and failed_as. The UI explainability panel renders this graph per turn rather than reconstructing a flat stage strip.

Retrieval →