LLM‑Style Issue Prediction Using JMP Neural Modeling (2026-US-30MP-2970)

Hello, my name is Paulo Herrera, and today we present an applied example of what I'm calling a JMP LLM-style application within the Kinex Process Support Engineering team. Kinex is a tool that is manufactured by Applied Materials, and I'm going to be using it as my example for this application.

The objective of this presentation is to show how historical engineering text data can be transformed into structured modeling features and then used in JMP to support predictive classification of tool issues. Basically, it creates a database that engineers are going to be referring to, to solve problems that become routine as we continue processing with the same tool.

This work is not intended to claim that a JMP Neural Model is a full LLM. Rather, it demonstrates how JMP can reproduce several important behaviors associated with LLM-style workflows. For example, extracting the meaning from the text, representing the text numerically, learning associations from historical examples, and predicting likely outcomes from new incidents, which is like the main idea.

Now here's the example. I introduce here the foundation of the proposed application. The source data is a file called Tool_Log.xlsx, which contains free text, issue, and solution fields across 1,600 historical records. Those records keep adding up every day. We keep manually storing all the issues that occur on our fleet to enrich this database.

These records represent a practical engineering knowledge base because they capture real tool problems and the associated resolutions with them. The key idea is to use JMP Text Explorer to extract keywords and term frequencies from these free text fields. Once extracted, those text-derived features can become X variables in a neural modeling workflow, while a selected response column, such as category, becomes the Y variable.

In this way, the trained neural model can classify new text in a manner that is analogous to an LLM-style system, of course, in a simplified manner. The academic significance here is that we are moving from unstructured engineering logs towards a structured, quantitative representation of operational knowledge. This enables modeling, metric validation, and repeatable inference rather than relying only on manual interpretation or what we usually call in engineering, tribal knowledge.

This is a better way to classify all what is happening and keep a better plan of attack on how to resolve problems in the future. Here is how we prepare the data. The first methodological step is text preparation. In JMP, Text Explorer is used to process the free text issue descriptions and extract main words, phrases, term frequencies, and word cloud representations.

These outputs provide a summary of the recurring vocabulary in the engineering log. We have asked our technicians to try to use the same words. Then we use the features in JMP to make similar phrases look the same so they can be analyzed in the same categories. From a machine learning perspective, this step corresponds to tokenization and feature extraction.

In an LLM pipeline, raw text is first broken into meaningful units before the model can learn patterns. In the JMP workflow, Text Explorer performs an analogous first stage by converting language into analyzable components. For the audience, the important point is that the model does not begin with numerical measurements in the traditional sense. This is like doing, as I was joking with my son at one point when he was struggling with statistics, "See, here I am doing statistics with words rather than with numbers."

What happens is here we begin with human-written engineering descriptions, and then JMP is going to provide a mechanism to translate those descriptions into a form that is suitable for modeling.

Here you see an example of the terms that we see and phrases that are used. Then we convert that text into modeling features. After extracting the text components, the next step is to convert them into modeling features. Text Explorer outputs can become binary indicators, frequency counts, or categorical groupings. This means that each row in the historical log can be represented as a numeric feature vector derived from the original issue text.

This transformation is essential because neural models require structured input. The free text issue description is therefore converted into a representation that the model can interpret mathematically. In the context of this work, each issue description becomes a structured representation of the observed engineering problem.

Conceptually, this is a bridge between qualitative engineering observations and quantitative predictive modeling. It allows us to preserve information from the text while still applying neural predictive modeling methods. The idea is that eventually we're just going to have a simple interface where we are going to be finding the solution for a common problem very easily using this interface.

How do we define the prediction target? Once the input features are created, the next question is what the model should predict. In the Kinex data, the tool that we are using, several LLM-style tasks can be mapped to a JMP response column. For example, issue classification can map to chamber category, auto-routing can map to Jira code, risk prediction can map to status, and recommendation can map to issue solution.

Just a note here, Jira code is… Jira is a system that is commonly used by software teams to classify their issues. That's how I am bringing this up. This mapping is important because it defines the output of the model. In conventional LLM applications, the output may be generated text. But in this JMP workflow, the output is a predicted label or action, such as a category, routing code, status, or solution class.

You really see here that it will depend on the discipline on the users to keep using the same text when they input the issues for the model to be able to classify it properly. We use JMP options to assure that. Here we also know that this is similar to systems like Azure and AWS LLMs in which models predict labels or actions rather than unrestricted text. The emphasis is, therefore, on constrained, operationally useful predictions, which are often more appropriate for engineering decisions than open-ended generation. Instead of having a complete paragraph of options, you are going to get a solution that is specifically based on what we already know.

How do we train the neural predictive model using JMP 19? Before modeling, it is necessary to understand the characteristics of the dataset that is being used. The historical engineering log in the text log file contains a mixture of hardware failures, software bugs, integration, automation, and all kinds of issues, including human or vendor problems. For the application, the response variable that is more important is the issue solution, which is a categorical type. Examples of responses include done, closed, waiting software, need more information. The model goal is to predict issue solution from chamber issues, from Besi software issues, which is a partner in our application, or what we call a CGA context.

CGA is the software that is used by the Applied Materials tools in general, and basically selling here an Applied Materials software context. The methodology uses neural predictive modeling in JMP 19 with K-fold validation. This modeling approach is positioned as a way to support engineering decision-making by enabling faster root cause classification, earlier identification of waiting software release cases, and reinforcement of knowledge for recurring tool issues.

Why are waiting software release cases so important? Because in this fast-evolving semiconductor production environment, as soon as a bug is detected, it is necessary to apply a solution as fast as possible. Those issues that are already detected and that are waiting software are highlighted for two reasons. One, to tell the user that it's being addressed, and it's recognized, and it's already been worked on, and two, do not add it again because it's already been detected.

From an academic viewpoint, this step is where the workflow transitions from descriptive text to predictive modeling. The model is no longer only summarizing historical language. Rather, it is learning relationships between issue context and resolution outcomes.

Here is how the workflow proceeds in JMP 19. It proceeds through Analyze, Predictive Modeling, and then the Neural application. In this setup, the Y variable is issue solution, while the X variables are chamber issues, software from Besi, and the CGA (AMAT) software within the Kinex context. The validation method used is K-fold validation. The rationale for the K-fold validation is that it makes efficient use of limited data, provides a more stable estimate of model performance, and clearly separates training and validation metrics.

Therefore, it is recommended for small or imbalanced datasets, such as the one that we are starting with. I have to point out that Kinex is a rather new application in the semiconductor production facility, and that's why our dataset is limited. There are other tool sets that have been around for 30 years, and therefore, they have a very large dataset of issues and examples and applications where they can use a different approach.

At this stage, we have a neural network learning text patterns and that is going to predict outcomes. This is why the model can be described as an LLM-style because it uses text-derived features and contextual variables to infer likely behavior, but it remains implemented with JMP tools rather than with a generative language model architecture or a pure LLM.

Then we have to train the neural with more information. The model here indicates that the misclassification rate is 0.18 for the training set and zero for the validation set, which is considered pretty good for the application. The Generalized R-Square value here is used to indicate a separation strength between the issue solution values. The slide here notes that the small gap between training and validation statistics suggests that there is a stable generalization.

Operationally, the model can be used by entering a new incident that includes the chamber issue description or the software application that needs to be addressed or the bug or the vendor error, and the model outputs a predicted issue solution class. Potentially, early classification outcomes include immediate closure, software release detection, or monitoring.

In other words, it already detects a solution that can be implemented based on previous cases, or tells the user, "It's already been detected. There is a software release coming," or it's a brand new one, and it recommends, "Okay, keep monitoring. This is a new issue. You need to start working on this." The broader value is that this model can help convert historical support experience into a repeatable decision support process, thus speeding up the engineering response on different cases.

Instead of evaluating every incident from scratch, the model provides an evidence-based starting point based on patterns learned from previous cases. The idea is that the more cases that we get, the larger the database, and then the more accurate results we're going to be getting.

How do we use the model for issue prediction? Here we clarify an important conceptual distinction. We are not using JMP as a JMP Neural Model, sorry, we are not using JMP Neural Model as a true LLM. Instead, we are using it as an LLM-style inference engine for behavioral prediction. The true LLM is trained on massive raw text and learns word-by-word token transitions to generate new text.

By contrast, the JMP Neural Model trains on structured representations of text and learns patterns between issue context and outcomes. It predicts behavioral classes rather than generating sentences. It's going to determine whether this is a particle issue caused by a certain part failure, and that's all it's going to tell me. It's going to say, "Yes, this is a defect issue caused by a pump going bad," or, "This is a software issue caused by a bug detected or software release number 45," for example. But it doesn't give me more than that.

But in the engineering world, that is more than enough for us to focus our troubleshooting effort. Nevertheless, the model exhibits LLM-style behavior because it maps language-derived inputs to meaningful outputs. In this case, the output vocabulary is not natural language text, but it consists of existing issue solutions, which for us in the engineering world is more than enough. The model has learned a behavioral mapping from chamber issues, software issues, and that map to issue solutions.

According to this, it learns patterns such as certain chamber issues behaving similarly, software versions maturing with changing resolution outcomes, and different software types amplifying or delaying resolution. Some issues look similar, but are resolved differently depending on the context.

Here, finally, we explain how a new issue should be represented before model inference. The key instruction is to represent the issue in the same language used in the original Tool Log file. When a new chamber issue appears, the user should not provide raw free text reasoning. Instead, the user provides a structured context similar to prompt engineering for an LLM. What we ask the user is that instead of just going and freely add text to our database interface, there is already some categories that they have to choose from. That is going to make it easier for the neural predictor to find the categories of the potential solution.

Here we have an example. AM3L1 bonder aborted during component check; wafer remained on chuck. The corresponding structured prompt includes a chamber, a software version, and an AMAT software version. The neural model is going to evaluate similar chamber issues in history, similar software maturity states, and similar AMAT software issues.

Then it's going to combine these interaction patterns, which, based on the inputs, is going to give us a predicted issue solution. Based on the accuracy of predicted issue solutions, the model can be updated using different options available for the user. Say that there is what we call an NPI, new product introduction, or an improvement on, or a retrofit kit, that is not going to be included in the database. We are going to have to add, as engineers, we're going to have to add several lines in the Tool Log file with different options and different situations that can occur with this new implementation.

Next time the technicians use the database, they are going to have those options available for them. This is a continuous improvement. The database is a live document that keeps getting updated based on daily occurrences on the floor. It's a potential iterative improvement process in which model predictions and observed outcomes can inform platform future refinement.

In conclusion, this presentation demonstrates how JMP can be used to construct an LLM-style predictive workflow for engineering issue classification. The process begins with free text engineering data, transforms that text into modeling features, defines a prediction target, trains a neural predictive model, and applies the model to support operational decision-making.

The practical value of this approach is that it helps convert historical tool log knowledge into a structured inference system. For Kinex support engineering, this can support faster interpretation of recurring issues, early recognition of software-related dependencies, and more consistent knowledge reinforcement across incidents.

The main takeaway here is that while JMP Neural Modeling is not a true generative large language model, it can still provide LLM-style behavior when applied to a structured representation of engineering text. In this context, the model becomes a practical decision support tool for predicting issue outcomes from historical operational patterns. That should be my target. If there is any question, please let me know.