256 The methodology unfolds in three stages: Semantic Parsing, Symbolic Planning, and Haptic Execution. 3.1. Stage 1: Semantic Parsing (LLM) The user provides a natural language instruction. An LLM (e.g., GPT-4 or a fine-tuned Llama 3) parses this intent and maps it to a specific Goal State defined in the Knowledge Base. For example, the command "Calculate the volume for Stope A" is translated to the goal state Volume_Report_Generated. The LLM acts strictly as a Semantic Parser. It is prompted with a Few-Shot learning technique containing the available "Goal States" from the Knowledge Base. When a user inputs: "Please update the block model and run the volume for Stope A", the LLM outputs a structured JSON payload: {"intent": "Calculate_Volume", "parameters": {"target": "Stope A"}}. Once this Goal State is identified, the LLM's job is done. The deterministic STRIPS planner takes over. By using a backward-chaining algorithm, STRIPS looks at the Goal (Volume_Calculated), checks its preconditions (Stope_Selected), and recursively searches for actions to satisfy them until it reaches the current Initial State of the software. This absolute separation guarantees zero hallucination during the execution phase. 3.2. Stage 2: Symbolic Planning (STRIPS) To prevent the "Hallucination Problem" common in GenAI, the execution logic is not generated by the LLM. Instead, the Orchestrator's planner performs a backward-chaining search: 1. It identifies an Action whose Effect matches the Goal. 2. It checks the Preconditions of that Action. 3. If preconditions are not met (e.g., "Topography not loaded"), those become new sub-goals. 4. This recursive process generates a guaranteed valid plan: Load_Topo -> Select_Stope -> Run_Calculation. 3.3. Stage 3: Visual Feedback Loop During execution, the Local Agent performs a "Closed-Loop" verification. Before clicking a button, it verifies the visual presence of the element with a confidence threshold (typically > 0.8). If the element is not found (e.g., the software is lagging), the agent waits or reports an error, preventing the "ghost clicking" issues typical of traditional macros. 4. CASE STUDY: LOGIC INJECTION AND EXECUTION VALIDATION While the ultimate target of the MSA architecture is complex mining packages (e.g., Vulcan, Leapfrog, Datamine), proprietary software licenses and End-User License Agreements (EULAs) often strictly prohibit unauthorized API hooking, reverse engineering, or automated scraping. Therefore, to validate the Neuro-Symbolic pipeline in a legally compliant manner, a standard Windows application (Calculator) was utilized as the Minimum Viable Product (MVP). It is crucial to note that the underlying logic, visual perception, and planning algorithms remain exactly the same regardless of the target application. The system interacts purely with pixels and standard OS-level inputs. Knowledge base mapping (Calculator example): To teach the agent how to use the calculator, atomic actions were defined in the database. Each action maps a physical button to a logical state. For example, the "Plus" button is defined as follows: { "action_id": "act_calc_plus", "name": "Click_Plus_Button", "visual_anchor": "/templates/calc/btn_plus.png", "preconditions": ["Number_Inputted"], "effects": ["Operator_Ready"], "execution_type": "single_click",
RkJQdWJsaXNoZXIy MTM0Mzk2