- ImageLens
- Dedicated Workspace for Wafer Maps, Spatial ROIs, Baselines, and Prior Runs
- Notebook
- Interactive Workspace for Plan Auditing, Analytical Execution, and Peer Review
- Finding
- Findings and Leads Linked to Physical Objects and Raw Evidence
- Reporting
- Structuring Findings, Recommendations, and Evidentiary Chains for Engineering Decisions
This article describes public architecture principles and product design goals. The currently verified demonstration and subsequent validation scope are explained in Current Capabilities & Scope.
An Investigation Demands Multiple Observation Scales
Engineers first identify spatial patterns in wafer images, then evaluate differences in analytical results, and finally use the report to decide the next step. Each stage needs a different interface: observation needs regions and context, computation needs parameters and runs, and recommendation review needs supporting evidence and limitations.
WaferPilot's target experience organizes these interfaces around one investigation object. The Agent can continue interpreting the problem as work proceeds, while image selections, actual execution records, and engineer approvals retain explicit provenance and responsibility.
ImageLens: Surfacing Problems Directly from Wafer Images
When an image is opened, engineers should see the current data, image coverage, reference relationships, and already generated analyses. Multiscale display of large images helps move from wafer distributions to local regions; original images, heatmaps, and regional statistics provide different views.
Agent inspection starts with the visible scenario and its linked analyses, confirming the wafer, region, and reference. Findings connect positions to results and explain what deserves further checking.
Findings represent observations surfacing during an excursion. Multiple findings may capture different facets of a single anomaly, requiring deduplication rather than being treated as distinct confirmed root causes.
Transitioning from Observation to Investigation While Carrying Context
The target experience carries the current question, selected images and regions, reference objects, data versions, existing analyses, and known limitations into the investigation. Engineers should not have to find the same data again or repeat what they just observed.
Guided by method specs, the Agent audits data validity, determines baseline coverage, compares available checks, and prepares an investigation plan, reusing proven routines before proposing novel runs.
Plans detail target datasets, methods, parameters, rationales, deliverables, and open items. Runtime boundaries preserve human audit gates, advancing routine computing while escalating high-impact choices to engineers.
Notebook: Exposing Computational Workflows Directly to Engineers
Notebooks anchor the execution and review of approved plans. Engineers track queued, running, completed, and failed tasks while inspecting the target datasets, algorithms, parameters, and raw outputs for each step.
Workflow transparency connects UI actions directly to underlying computation: loaded images carry metadata, executed checks have logged permissions, and outputs cite run provenance and selection rationales.
As new outputs return, they are evaluated against cumulative evidence. Data supporting one hypothesis may contradict another. Next steps can include supplementary tests, awaiting lots, revising hypotheses, or concluding.
Diagnostic Reports: Structured for Real-World Engineering Decisions
Reports lead with actionable engineering clarity: confirmed phenomena, isolation depth, prioritized checks, conditional assumptions, and verification targets, followed by full supporting calculations.
| Report Content | What This Helps Engineers Accomplish |
|---|---|
| Executive Summary & Isolation Hierarchy | Quickly ascertain whether evidence isolates down to step, tool, chamber, or component tier |
| Candidate Causes & Evidence | Evaluating Supporting, Contradictory, and Unresolved Hypotheses |
| Inspection or Recipe Adjustment Recommendations | Deciding Where to Inspect First and What Prerequisites Must Be Met |
| Complete Analytical Trajectory | Auditing Inputs, Reference Baselines, Methods, Parameters, and Raw Outputs |
| Verification Goals & Evidence Gaps | Scheduling Verification Tests with Explicit Acceptance Criteria |
Specific adjustment recommendations require an applicable model, operating window, and supporting verification. Otherwise, the report should identify the next check and the evidence needed.
Returning to Images to Continue the Same Investigation
Engineers reviewing recommendations can return directly to cited micrograph ROIs, baselines, and code runs. Physical adjustments produce follow-up data that re-enters the session with documented recipe modifications.
After new data returns, evaluate verification effectiveness: whether old and new materials are comparable, whether the anomaly improved, how results change candidate explanations, and what still needs investigation. Earlier conclusions and new judgments should have a version relationship rather than being silently replaced in the interface.
Across multi-shift cycles, the system tracks which hypotheses were accepted, which remain open, and their validity limits. Reconstituting historical context during post-mortems is critical for long-term fab operations.
Show Interface Continuity in a Specific Example
In ImageLens, an engineer observes an edge defect spike and selects a baseline. The Agent synthesizes prior runs into an audit plan; upon approval, Notebooks execute comparative analytics to guide targeted physical verification.
The value of this example is reducing repeated data organization and tool-learning effort while keeping professional judgment with engineers. It assumes no equipment root cause and does not require model training for every case: methods depend on the current question, evidence, and available capabilities.
Model degradation diagnostics follow an identical workflow paradigm with tailored UI inputs: benchmark splits, labels, versions, and training metrics require explicit bindings, evaluation gates, and permissions.
How the Engineering Experience Should Be Validated
- Is Investigation Context Continuous:Whether micrographs, spatial ROIs, baselines, and data versions transfer without loss.
- Are Analyses Verifiable and Reproducible:Whether engineers inspect actual inputs, run parameters, and execution logs, not mock animations.
- Are Recommendations Operationally Actionable:Whether the report clarifies isolation level, target objects, evidence, and verification goals.
- Do Human Engineers Retain Full Control:Whether humans can amend hypotheses, redirect focus, handle edge cases, and take over.
- Are Results Retrievable with Provenance:Whether reports allow seamless recovery of cited micrographs, code runs, and audit logs.
This article outlines end-to-end architectural goals. The current demonstrator highlights micrograph browsing and cited findings; live execution loops and automated cross-tool handshakes are validated separately; see Current Demonstrator and Scope of Capabilities.