Plugin Inventory

MRP-VM organizes all behavior through five typed plugin families. The VM core provides only the LLM bridge, execution frames, and plugin orchestration. All domain logic belongs to plugins.

Plugin Categories

Type	Role in VM Loop	Phase
sd-plugin	Extracts intents (fine-grained) and knowledge (semantically coherent KUs) from user input or source text.	Seed Generation
mrp-plan-plugin	Builds execution plans ordering plugins per stage. Uses descriptions and plannerHints for relevance filtering. May request task decomposition.	Plan Generation
kb-plugin	Retrieves relevant Knowledge Units from the hierarchical KB at the appropriate abstraction level. Builds plugin-private indices during ingest.	Task Resolution
gs-plugin	Produces grounded answers from resolved intents and retrieved evidence. May signal `needs-decomposition`.	Task Resolution
val-plugin	Validates goal solver output. Rejection triggers planner backtracking.	Result Composition

Built-In Plugins

sd-plugin — Seed Detectors

ID	Description	Uses LLM	Cost
`sd-symbolic`	Rule-based intent and knowledge extraction. Fast, deterministic, no LLM cost. Best for simple factual queries and structured input.	No	cheap
`sd-llm-fast`	Lightweight LLM-backed normalization. Good balance of quality and speed for most conversational input.	Yes	moderate
`sd-llm-deep`	Thorough LLM normalization with richer intent decomposition. Best for ambiguous, multi-part, or complex requests.	Yes	expensive

kb-plugin — Knowledge Retrievers

ID	Description	Backend	Cost
`kb-fast`	Lexical-first retrieval with small result budget. Cheapest path, suitable for simple focused questions.	BM25 (DS009)	cheap
`kb-balanced`	Lexical + associative retrieval with diversity-aware reranking. Recommended default for moderate-complexity questions.	BM25 + HDC/VSA (DS009, DS024)	moderate
`kb-thinkingdb`	Lexical + bounded symbolic closure. Best for multi-hop, relation-sensitive, or proof-bearing retrieval tasks.	BM25 + ThinkingDB (DS009, DS025)	expensive

gs-plugin — Goal Solvers

ID	Description	Uses LLM	Cost
`gs-symbolic`	Deterministic answer assembly from retrieved evidence. No LLM cost. Produces structured bullet-point answers.	No	cheap
`gs-llm-fast`	Lightweight LLM synthesis from evidence. Good fluency with low latency.	Yes	moderate
`gs-llm-deep`	Thorough LLM synthesis with richer reasoning. Best for complex or nuanced answers.	Yes	expensive

mrp-plan-plugin — Planners

ID	Description	Style
`planner-default`	Adaptive cheap-first planner with EWMA learning. Inspects task signals (depth, speed, symbolic cues) to adjust ordering.	cheap-first
`planner-depth`	Heavy-first fallback planner for multi-hop or recovery paths. Used when cheap planners exhaust their options.	deep-first

val-plugin — Validators

ID	Description	Uses LLM
`val-llm`	LLM-backed response validator. Checks that the answer is grounded in evidence and addresses the question. Rejection triggers replanning.	Yes

How to Build a Plugin

Step 1: Choose the Plugin Type

Decide which phase of the execution loop your plugin serves. Each type has a specific contract defined in DS027.

Step 2: Implement the Interface

Every plugin must implement:

getDescriptor() — returns the plugin descriptor (see below)
The type-specific methods:
- sd-plugin: detectSeeds(input, ctx), normalizePersistentContext(input, ctx)
- kb-plugin: retrieve(input, ctx), onSourceText(input, ctx)
- gs-plugin: solve(input, ctx)
- val-plugin: validate(input, ctx)
- mrp-plan-plugin: buildPlan(input, ctx), recordOutcome(outcome, ctx)

Step 3: Write the Descriptor

{
  id: "my-kb-plugin",
  type: "kb-plugin",
  name: "My Custom KB Retriever",
  version: "1.0.0",
  description: "Semantic search using embeddings.
    Best for long-form technical documents.",
  costClass: "moderate",
  usesLLM: false,
  modelRoles: [],
  maxLLMCalls: 0,
  tags: ["custom", "embeddings"],
  timeoutMs: 15000,
  plannerHints: {
    expectedLatencyMs: 200,
    expectedLLMCalls: 0,
    relativeCost: 0.3,
    supportedActs: ["explain", "compare", "define"],
    topicTags: ["technical"],
    preferredDepth: "medium",
    confidenceWhenMatched: 0.7
  },
  provides: ["retrieve-context"],
  accepts: ["chat-turn", "source-text"]
}

Descriptor Requirements

id and type are mandatory
description must be concise (1–3 sentences) and operationally useful for planner filtering
plannerHints are required for sd-plugin, kb-plugin, gs-plugin
maxLLMCalls must be a conservative upper bound — the core uses it for budget pre-checks

Step 4: Register the Plugin

Built-in plugins (JavaScript)

typedPluginRegistry.register(new MyKBPlugin(...));

External wrapper plugins (any language)

Create a directory under wrappers/:

wrappers/my-plugin/
├── manifest.json    # descriptor + command + args
├── wrapper.js       # (or .py, .rs, etc.)
└── README.md

The manifest.json follows the same descriptor shape plus:

{
  "command": "node",
  "args": ["wrapper.js"],
  "protocolVersion": 1,
  "maxInputSizeBytes": 65536
}

Add the plugin ID to pluginAllowlist in config/engine.json.

Step 5: Configure

config/plugins.json — default plan ordering, fallback chains
config/llm-role-settings.json — model assignments per role
config/engine.json — budget limits, allowlist

Step 6: Test

Deterministic tests: test/deterministic/
Live LLM tests: test/live-llm/
Evaluation suites: test/evaluation/suiteXX/

Plugin Communication

Plugins communicate through natural language using CNL formats:

Intent CNL (DS004) — sd-plugin output, consumed by decomposer and planner
Context CNL (DS005) — KU serialization, produced by sd-plugin and consumed by kb-plugin and gs-plugin
Resolved Markdown (DS016) — evidence bundle sent to external wrapper plugins via stdin

The VM is agnostic to the content inside these formats. It enforces only the structural delimiters (headings, field names) defined by each CNL schema.

← VM Model Plugin Dev Guide →