MRP-VM expresses all domain behavior through four typed plugin families. The core kernel is neutral — it orchestrates plugin execution but never contains retrieval, normalization, or synthesis logic.
| Type | Role | Built-in Implementations |
|---|---|---|
sd-plugin | Seed detection: normalize user input into Intent CNL + context seeds | sd-symbolic, sd-llm-fast, sd-llm-deep |
kb-plugin | Knowledge retrieval: goal-conditioned evidence gathering | kb-fast, kb-balanced, kb-thinkingdb |
gs-plugin | Goal solving: produce grounded answer from evidence | gs-symbolic, gs-llm-fast, gs-llm-deep |
val-plugin | Validation: verify answer is grounded and correct, reject to force replanning | val-llm |
mrp-plan-plugin | Meta-rational planning: order plugin execution per request | planner-default, planner-depth |
Request → Planner builds plan
→ sd-plugin candidates (first success)
→ parser/decomposer (shared services)
→ kb-plugin candidates (first sufficient)
→ gs-plugin candidates (first success or no-context fallback)
→ val-plugin validates answer (reject → replan)
→ Response
Each stage tries candidates in planner-determined order. If a plugin returns unsupported or error, the next candidate is tried. Three levels of backtracking:
planner-depth)no-context results are produced, accept the best weak answer rather than failingEvery plugin exposes a descriptor (DS003):
{
id: "kb-balanced",
type: "kb-plugin",
costClass: "moderate",
usesLLM: false,
maxLLMCalls: 0,
modelRoles: [],
plannerHints: {
supportedActs: ["compare", "explain"],
topicTags: ["technical"],
preferredDepth: "medium",
evidenceStyle: ["hybrid"]
}
}
The old processing_mode and retrieval_profile concepts map to typed plugins:
| Legacy | Plugin Equivalent |
|---|---|
symbolic-only | sd-symbolic + gs-symbolic |
llm-assisted | sd-llm-fast + gs-llm-fast |
fast profile | kb-fast |
balanced profile | kb-balanced |
thinkingdb profile | kb-thinkingdb |
Legacy fields are derived from plugin IDs for API compatibility but are not stored on sessions.