The JMP MCP Expert System started with a simple goal: answer questions about JMP. But somewhere between "which platform do I use for X" and "how do I build a time-series dashboard with control limits," it became clear that answers alone were not the final form.

This is the story of what we learned when users asked for workflows, and why the next layer is not just better answers—it is shaping answers into reviewable, source-backed JSL scaffolds that can become executable.

The real request was never just an answer

Early support questions came in two flavors:

1. Conceptual — "What's the difference between ANOVA and regression for my data?" These answered well. The retrieval layer pulled methodology context, the synthesis layer built a coherent explanation, and the provenance layer made it inspectable.

2. Action-shaped — "I need to build a time-series dashboard with control limits for my manufacturing line." These answered less well. The system could retrieve relevant help, explain the platforms, point at examples—but the user still had to translate that knowledge into a working script.

The gap was not in retrieval quality. The gap was in action distance. A support answer is valuable, but a workflow scaffold is closer to what the user actually wants.

The time-series dashboard case study

A user requested a time-series dashboard with control limits. The system correctly retrieved:

• control chart platform documentation
• column selection examples
• script syntax for Control Chart Builder

But the answer stopped at explanation. The user would still need to:

• assemble the correct JSL pattern
• adapt column names to their data
• handle edge cases like phase boundaries or specification limits
• know which variations (individual vs subgroup, moving range vs standard deviation) matched their situation

That is real work. It is also work that the system already had context for—the retrieval knew which columns mattered, what platform to invoke, and what assumptions to flag.

Session-to-JSL: from explanation to scaffold

The natural next step was to turn that context into something closer to executable. Not a magic "generate the perfect script" button, but a workflow scaffold:

• a structured JSL draft
• explicit TODOs and review flags
• source provenance for every section
• an automation level that defaults to "draft, not run"

The system now supports this. When the user clicks Show Me on an answer, the system generates a JSL scaffold based on the previous response. The result is a code block the user can copy, download, or—crucially—execute directly in JMP.

Show in JMP: closing the execution loop

The system now includes an MCP 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.

Architecture: how it actually works

The system is a Django app with clear separation:

• Retrieval: Vector similarity search over indexed JMP documentation (20 PDFs, chunked and embedded)
• Generation: GPT-4o synthesis with source-grounded system prompt
• JSL extraction: Pattern matching to pull code blocks from responses
• MCP execution: jmp_detect_install checks for JMP, jmp_execute_script runs the script
• Frontend: Django template with Show JSL / Show in JMP buttons

There's no orchestrator deciding between multiple answer modes. There's no vault loader or support server. It's a straightforward RAG pipeline with an execution layer bolted on.

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.

The roadmap: where it goes next

The current system implements:

1. Draft scaffold — JSL with review flags, copy/download
2. MCP execution path — Show in JMP button, JMP detection, script launch

What's still ahead:

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.

What this means for JMP users

If you are a JMP power user, the implication is straightforward:

• Ask for a workflow, not just an explanation
• Receive a scaffolded JSL draft with explicit assumptions
• Review, adapt, and run—or click Show in JMP
• Trust that the provenance is there—you can see where every section came from

The system is not replacing JMP expertise. It is accelerating the translation from intent to script. The user still needs to understand the statistical methodology, validate the choices, and decide when assumptions are safe. The system just removes the blank-page friction.

The durable pattern

The pattern we are building toward is:

question → retrieved explanation → workflow scaffold → reviewable JSL path → JMP execution

That is more useful than a flashy answer box. It pushes the system toward practical action while preserving inspectability. And it honors a simple truth:

A support answer is not the end state. It is the starting point for something the user actually needs to do.

Verification Ledger

• VERIFIED: Django app at codingenvironment-sites/jmp_expert/
• VERIFIED: Show Me button generates JSL scaffold from previous answer
• VERIFIED: Show in JMP button executes via MCP
• VERIFIED: Single GPT-4o response mode with RAG retrieval
• VERIFIED: JSL extraction and workflow scaffold pattern
• NOTE: This post was corrected on 2026-04-22 to accurately reflect the live implementation

Explore the live system: JMP Expert System