- Grounding
- Planning Workflows by Fusing Objectives, Method Specs, Instance Telemetry, and Tool APIs
- Expertise Package
- Version-Controlled, Peer-Reviewed Engineering Knowledge Assets
- Rail
- A cohesive decision scope grouping related domain questions
- Plan
- The reviewable investigation plan for this incident
This article describes public architecture principles and product design goals. The currently verified demonstration and subsequent validation scope are explained in Current Capabilities & Scope.
What Kind of Agent Does Engineering Investigation Demand?
Engineering investigations have stable requirements and changing circumstances. Stable requirements include checking data identity, comparability, evidence retention, and action permissions. Circumstances vary with anomalies, missing data, alternative explanations, and how results affect the next step.
WaferPilot is designed to connect these responsibilities: professional methods organize what the investigation should consider; the model interprets the current case and proposes reasonable choices; the runtime binds facts, capabilities, and state; tools perform specific observations and calculations.
This Agent is intended for tasks requiring expert experience, scientific analysis, and engineering review. Its specialization comes from methods, data, execution, and deliverables working together; it cannot be measured solely by prompt length or the fluency of a single answer.
How Heuristics, Judgment, Planning, and Execution Coordinate
Reusable methods and current case facts first enter professional judgment, which produces a reviewable plan. Authorized work executes in the appropriate tools, and actual results and evidence return to the investigation. Separating preparation from execution makes clear who proposes work, who performs computation, and who authorizes it.
| Role / Component | Primary Responsibility | What Must Not Be Conflated |
|---|---|---|
| Methods & Engineering | Applicability rules, diagnostic framework, evidence criteria, and bounds | Instance telemetry vs ground truth of a specific past incident |
| Model Reasoning | Interpreting goals, evaluating hypotheses, and managing technical trade-offs | Ungrounded generated text vs empirically verified facts |
| Execution Framework | Managing session state, binding methods, tool capabilities, and permissions | Structural permission validation vs scientific ground truth verification |
| Analytical Execution | Executing authorized tasks and logging actual outputs | Planned workflows vs actual executed actions |
| Human Engineer | Framing objectives, business trade-offs, approvals, and peer review | Routine computational choices vs physical on-site intervention decisions |
Method Specs Preserve How to Reason, Not Rigid Answers
A domain method spec defines: when to investigate an issue, required inputs, candidate checks, contradictory evidence policies, when to request data or abort, and which critical decisions require human sign-off.
Specs can reference process kinetics, tool manuals, and API contracts. Domain know-how need not be shoehorned into a single file; the key is explicitly declaring how knowledge governs inspection choices and decision limits.
Edge anomaly methods mandate verifying inspection recipe versions and baseline comparability. If invalid, the Agent flags evidence gaps; if supported, it proceeds to spatial or history analysis without pre-judging root cause.
Regarding knowledge sources, extraction, and validation, this series includes Knowledge Assets and Case to Method two companion articles.
Preserving Meaningful Domain Reasoning Scope for the Model
At a public conceptual level, a Rail is a coherent scope of professional judgment. For example, deciding whether current data is suitable for a comparison requires considering inspection definitions, sample identities, reference conditions, and missing information together. Selecting an execution method likewise requires considering the investigation goal, available capabilities, coverage, and limitations together.
This organization brings related questions together into model reasoning. One judgment can influence several plan sections; several judgments can also support one engineering recommendation. The final plan is organized in an understandable, reviewable order, without needing a one-to-one mapping to the internal judgment structure.
Fine-grained telemetry and parameters are fully preserved without turning every database field or UI click into an isolated node; the architecture focuses on reasoning over coherent domain problems to yield auditable results.
The Appropriate Boundary for Model Reasoning
Within its delegated scope, the Agent interprets observations, compares candidate causes, selects methods, balances parameters, and proposes next steps without forcing engineers to micromanage routine choices.
Models can suggest novel hypotheses to uncover method or telemetry gaps. However, facts influencing engineering judgment must cite raw sources, numbers must stem from calculations, and new specs require peer review.
- Autonomous Progression Permitted:Approved inspection steps, comparative evaluations, interpretation, and next actions within scope.
- Evidence Required:Critical data missing, comparative baseline invalid, or tool capabilities insufficient.
- Human Engineer Intervention Required:Ambiguous goals, critical business trade-offs, proprietary context, or elevated permissions.
- Eligible to Conclude:Objectives have been achieved, or current evidence strictly supports a bounded conclusion.
Ongoing investigations update judgment based on cumulative evidence and domain specs. New observations need not always trigger further computations; they can pause work, await data, or revise hypotheses.
Scientific Execution and Model Judgment Maintain Distinct Roles
Selecting an analytical method and executing it represent distinct tasks. The model explains method suitability; deterministic tools process inputs to yield outputs, which engineers and the Agent evaluate together.
The runtime can check input bindings, capability declarations, workflow state, and permissions. These mechanisms help prevent unauthorized actions or version misuse, but do not automatically establish that a statistical interpretation or domain judgment is true. Data applicability and method validity still require professional review and practical testing.
In the current system contract, grounding prepares a reviewable Plan; authorized execution and post-run reporting follow. Continuous investigation requires live execution feedback before claiming closed-loop disposition.
Scaling Domain Capabilities While Reusing Shared Runtimes
The architecture decouples domain method specs from shared execution runtimes. New tasks define operational prerequisites, inputs, checks, and evidentiary standards while reusing planning, execution, and audit infrastructure.
Extending from equipment-deviation investigation to model-degradation diagnosis changes the professional questions: the model scenario must check evaluation data, labels, input distributions, versions, and training conditions. Investigation and review mechanisms are shared; professional methods, tool capabilities, and acceptance goals differ.
Expansion requires domain specialists, tool bindings, and task benchmarking. Extensibility manifests in clean integration, modular auditing, and runtime reuse, rather than an empty promise of zero-effort universal applicability.
How to Evaluate This Architecture
When evaluating the platform, benchmark against a specific task: audit spec origins, inspection selection, computational validity, and evidentiary traceability across diverse tool integrations.
Evaluation criteria span method applicability, plan fidelity, runtime outputs, engineering review hours, and exception handling. Architectural principles must be empirically proven; see capabilities scope in Current Capabilities & Scope.