Many AI support demos fail in the same way: they produce fluent answers, but the user has no clean way to inspect where those answers came from. For technical support, analytical software, and documentation-heavy workflows, that is a fragile foundation.

The JMP MCP Expert System started from a different premise. The goal was not to build an LLM that somehow "knows JMP." The goal was to build a source-backed assistant surface with visible tool boundaries, explicit retrieval, and a path from answers to executable workflows.

The real problem was fragmentation

JMP support knowledge lived across several surfaces:

• official online help
• PDF manuals
• support-style notes and cases
• practical workflow knowledge that did not naturally live in one interface

That fragmentation creates two problems at once:

1. users do not know where to look, and
2. an assistant can appear smarter than it really is unless its source path stays visible.

So the core challenge was not "make a chatbot for JMP." It was: turn a fragmented support landscape into an answer surface that stays inspectable.

Why MCP mattered here

The value of MCP in this project was not magical intelligence. It was contract discipline.

An MCP-style boundary let the project expose JMP capabilities through explicit actions such as querying the knowledge base, executing JSL scripts, and detecting JMP installations. That makes the system easier to reason about because:

• the tool surface is inspectable
• the retrieval path is explicit
• the UI can evolve without rewriting the knowledge contract
• future MCP-aware clients can reuse the same interface

That is strategically stronger than a one-off assistant wrapped around hidden prompt logic.

Architecture: from sources to execution

The current system is a Django app with a clear separation of concerns:

1. Sources
   • indexed JMP 19 PDF manuals (20 documents)
   • online help pages
   • chunked and embedded for vector retrieval
2. Retrieval layer
   • vector similarity search over document chunks
   • context building with source citations
3. Generation layer
   • GPT-4o synthesis with source-grounded system prompt
   • JSL extraction from responses
   • Show Me follow-up for workflow scaffolds
4. Execution layer
   • MCP server for JMP detection and script execution
   • Show in JMP button routes JSL through MCP path
   • Fallback to saved scripts when JMP unavailable
5. User surface
   • web app delivers the answer, source cards, and workflow scaffolds
   • Show JSL and Show in JMP buttons for action paths

The important design choice is separation. When retrieval, generation, and execution remain distinct, the system has room to evolve without collapsing into one brittle blob.

From answers to workflows: session-to-JSL generation

The original roadmap pointed toward "workflow generation" as a future direction. That future is now partially here.

As of March 2026, the system supports session-to-JSL workflow generation for explicit workflow requests. When a user asks to generate a JSL workflow (for example, "build a time-series dashboard with control limits"), the system can generate a structured JSL scaffold:

kind: jsl_workflow
workflow_summary: "Time-series dashboard with control limits"
jsl_script: |
  // Setup: column assumptions
  // Validation: required columns
  // EDA / preprocessing
  // Analysis: Control Chart Builder launch
  // Outputs: graph and summary
  // Interpretation scaffold
  // Next-step prompts
review_flags: ["validate column names", "check datetime format", "confirm subgrouping"]
source_map: { ... }
automation_level: "draft-review-required"

This is draft-mode generation:

• The JSL is comment-heavy, assumption-explicit, and deliberately not executable without human review.
• Review flags surface assumptions the user should validate.
• The source map traces every section back to retrieved material.
• The automation level defaults to "draft, not run" — the system does not execute side effects.

The user receives a starting point, not a finished product. They still need to understand the statistical methodology, validate choices, and decide when assumptions are safe. The system just removes the blank-page friction.

Show in JMP: from draft to execution

The system now includes an execution path. When the user clicks Show in JMP:

1. The JSL code is extracted from the response
2. The MCP server checks if JMP is installed locally
3. If JMP is available, the script launches in JMP
4. If JMP is unavailable, the script saves to a temp file with a helpful message

This closes the loop from question → answer → JSL scaffold → executable workflow.

Why context understanding beats brittle suppression rules

One might ask: why not just block unsafe patterns? The answer is that suppression is a poor substitute for understanding.

A brittle suppression rule might say "never generate database writes." But a context-aware system can recognize when a user actually needs a database write, flag it, and ask for confirmation. The difference is:

• Suppression — hides capability, removes autonomy
• Context + flags — surfaces capability with guardrails, preserves autonomy

The workflow generator does not refuse to emit JSL. It emits JSL with explicit review gates. The script includes:

// REVIEW: Assumes datetime column named "timestamp" - update if different
// TODO: Validate subgrouping before running

That is not the system being cautious for caution's sake. It is the system being honest about what it knows and what it doesn't.

What makes it source-backed instead of merely fluent

The trust feature is provenance.

Each answer is stronger when it points back to something concrete:

• a manual page
• an online help URL
• a recognizable source label
• a PDF location when relevant
• related support material when it adds context

That is what makes this a support surface rather than a fluent model demo. The user has a path to inspect where the answer came from instead of judging the system by tone alone.

At the time of publishing, the knowledge base includes approximately:

• 20 JMP 19 PDF manuals (indexed and embedded)
• source citations attached to every response
• JSL extraction for workflow scaffolds

Those numbers are most useful as scope markers. They say something about current retrieval coverage, not about the system being "finished."

The roadmap: from draft scaffold to planner-guided generation

Milestones 1 and 2 implement draft-mode JSL generation with execution path:

1. Draft scaffold (Milestone 1) — JSL with review flags, copy/download
2. MCP execution path (Milestone 2) — Show in JMP button, JMP detection, script launch
3. Planner-guided generation — a planning layer that reasons about the entire workflow before emitting
4. Schema-aware execution — the system understands column types, data shape, and can validate assumptions

The key insight is that workflow generation is a different problem than answer generation. An answer needs to be accurate, cited, and clear. A workflow needs to be accurate, cited, clear, and executable, inspectable, and safe. That requires a different architecture.

Honest limits

The current system is not a general intelligence that understands all of JMP from first principles.

What it already does:

• retrieve source-backed material via vector similarity
• synthesize documentation-backed answers with GPT-4o
• surface provenance clearly in every response
• generate draft JSL scaffolds for workflow requests
• execute JSL through MCP when JMP is available

What is still emerging:

• richer planner-guided task shaping
• deeper schema-aware execution
• broader coverage and more refined corpora

That distinction matters. The project is strongest when described as a reusable, inspectable support architecture with an expanding action layer — not as a magical fully solved assistant.

Why this project matters

The interesting part of this build is not only that it answers JMP questions. It is that it treats support knowledge as architecture:

• sources are explicit
• tool boundaries are inspectable
• retrieval is visible
• trust comes from provenance
• workflow scaffolds are now live
• execution path closes the loop

That is a healthier pattern for serious AI support work than hiding everything inside a clever prompt.

Explore the live system

Explore the live JMP expert system

Verification Ledger

• VERIFIED: Django app at codingenvironment-sites/jmp_expert/
• VERIFIED: MCP server exposes jmp_expert_query, jmp_execute_script, jmp_detect_install
• VERIFIED: Show in JMP button routes JSL through MCP execution path
• VERIFIED: Single GPT-4o response mode with RAG retrieval
• VERIFIED: JSL extraction and workflow scaffold generation
• NOTE: This post was corrected on 2026-04-22 to accurately reflect the live implementation