VM Execution Model

MRP-VM is a lightweight plugin-kernel system. The VM core provides only three things:

1. LLM Bridge — a single shared interface to language models (DS015)
2. Execution Frame Stack — recursive task execution with budget enforcement (DS002)
3. Plugin Orchestration — typed plugin registry, planner-driven ordering, and CNL validation (DS003)

All domain logic — knowledge extraction, indexing, retrieval, scoring, synthesis — belongs to plugins. The VM is syntax-agnostic with respect to the content transmitted between plugins; it only enforces the structural delimiters defined by each plugin type's CNL schema.

The Standard Execution Loop

Every execution frame runs a loop with four phases:

Phase	Plugin Type	What Happens
1. Seed Generation	sd-plugin	Extracts intents (fine-grained task seeds as Intent CNL) and knowledge (semantically coherent KUs as Context CNL) from the input.
2. Plan Generation	mrp-plan-plugin	Builds an execution plan ordering KB and goal solver plugins. Uses plugin descriptions and plannerHints for relevance filtering.
3. Task Resolution	kb-plugin → gs-plugin	KB plugin retrieves relevant Knowledge Units at the appropriate abstraction level. Goal solver produces a grounded answer using the assembled context.
4. Result Composition	(core)	Results are assembled into the response document and Markdown output. Validation plugin runs if registered.

Execution Frames and Recursive Resolution

Task resolution is recursive. When a task is too broad or complex for direct resolution, the VM creates a child execution frame — analogous to a function call pushed onto a call stack.

Root Frame (original user request)
  ├── Seed: 3 intent groups detected
  ├── Plan: kb-balanced → gs-llm-fast
  ├── Intent 1: resolved directly
  ├── Intent 2: resolved directly
  └── Intent 3: gs-plugin returns "needs-decomposition"
        └── Child Frame (sub-task)
              ├── Seed: decomposed into 2 sub-intents
              ├── Plan: kb-thinkingdb → gs-llm-deep
              ├── Sub-intent 3a: resolved
              └── Sub-intent 3b: resolved
              → result returned to parent frame

When is a child frame created?

• The planner explicitly requests decomposition (decompose: true in the plan)
• A goal solver returns needs-decomposition
• All goal solvers produce only weak no-context results and the planner determines decomposition may help

Frame structure

• frameId — unique identifier
• parentFrameId — null for root frame
• depth — nesting level (0 for root)
• maxDepth — budget limit (default: 3)
• localState — seeds, plan, evidence, partial results (frame-scoped)
• globalStateRef — shared session/request state (budgets, trace)

Knowledge Units (KU)

Knowledge is represented as hierarchical Knowledge Units (DS030) at all levels:

• Session memory — KUs extracted from chat turns
• Persistent KB — hierarchical KU trees per ingested source
• Retrieval context — KUs selected at the appropriate abstraction level

KU Hierarchy per Source

Source Aggregate (root summary, kuType: "aggregate")
  ├── Section Aggregate (chapter/section, kuType: "composite")
  │     ├── Atomic KU (leaf claim/fact)
  │     ├── Atomic KU (leaf claim/fact)
  │     └── Atomic KU (leaf procedure step)
  └── Section Aggregate
        └── ...

KB plugins traverse this hierarchy to select the right abstraction level: summaries for broad context, intermediate KUs for moderate detail, leaf KUs for specific evidence.

Inter-Plugin Communication

Plugins communicate through natural language using two CNL formats:

• Intent CNL (DS004) — structured intent/task descriptions
• Context CNL (DS005) — structured Knowledge Units with provenance

The VM is agnostic to the content inside these formats. It enforces only the structural delimiters (headings, field names) defined by each CNL schema. A future extension may allow plugins to exchange a more formal intermediate representation (IR) for specific domains.

Validation and Backtracking

After a goal solver produces a successful answer, a val-plugin may validate it. If rejected, the core throws VALIDATION_REJECTED and the planner backtracking loop attempts an alternative plan. Backtracking can happen:

1. Within a stage — try the next plugin candidate
2. Across planners — fall back to a heavier planner
3. Via decomposition — open a child frame for the failing sub-task

Budget Enforcement

• Max LLM calls per request (shared across all frames)
• Request timeout (shared)
• Max plugins per stage
• Max frame depth (default: 3)
• Pre-invocation budget check: skip plugins whose maxLLMCalls exceeds remaining budget