- Provenance Records
- Which data, versions, and execution steps produced a fact or result
- Decision Evidence
- Supporting evidence, underlying rationales, and explicit bounds
- Reproducibility
- Re-executing calculations under identical data, versions, and parameters
- Verification Objective
- Concrete questions to be resolved following the next verification action
This article describes public architecture principles and product design goals. The currently verified demonstration and subsequent validation scope are explained in Current Capabilities & Scope.
White-Box: Engineers Can Audit the Evidence Behind Every Recommendation
When the platform recommends prioritizing inspection of Chamber B, engineers must be able to ask: What visual deviations were observed? Which reference lots were compared? What statistical test was executed? What process variables remain unexamined? Answering these questions through verifiable records establishes auditability.
WaferPilot's white-box architecture focuses on externally auditable engineering decisions: inputs, methods, parameters, run logs, results, selection rationales, limitations, and human sign-offs. Hidden internal model activations are not part of this verifiable evidence trail.
Traceability enables error detection and continuous refinement. Even if a calculation is reproducible, it may have used non-comparable data; even if a judgment is documented, it still requires on-site physical verification.
Every Tier from Input to Recommendation Is Fully Backed by Data
Inputs encompass wafer images, recipe files, equipment telemetry, processing histories, and existing defect analyses. Verified observations enter scientific calculations; computational results and method specs support engineering judgments; judgments formulate targeted recommendations.
| Investigation Tier | What Must Be Preserved | How Engineers Audit It |
|---|---|---|
| Inputs & Observations | Wafer coordinates, data identities, versions, reference objects, and missing channels. | Inspect original wafer maps to confirm identical objects and inspection conditions. |
| Method Selection | Applicability prerequisites, selection justification, alternative algorithms, and constraints. | Confirm the selected comparison or model directly answers the target engineering question. |
| Actual Computation | Input ranges, parameters, tool or library versions, execution scripts, and numerical outputs. | Inspect calculation formulas and re-execute scripts independently in Jupyter. |
| Judgment & Actions | Supporting and contradicting evidence, alternative hypotheses, evidence gaps, and validation goals. | Evaluate whether evidence justifies physical action, modify parameters, or schedule split runs. |
Numbers Stem from Verifiable Calculations, Not Generative Text
A numerical change in edge defect density should at least identify the defect definition, edge region, effective inspection area, sample scope, reference material, and analysis version. A number alone does not let engineers assess whether the comparison is meaningful.
When statistical models are utilized, their assumptions, parameters, and limitations must be documented. Machine learning results must link to dataset splits, ground-truth labels, and model hashes.
State the conditions for recalculation. Deterministic calculations can usually be checked with the same inputs and versions. Analyses involving random training, numerical-library differences, or environment changes should also record randomness and environment details and be checked using appropriate error tolerances or evaluation criteria.
Before Computing, Confirm What the Comparison Evaluates
If excursion and reference groups differ in product code, processing shift, or maintenance cycle, observed deviations may stem entirely from confounding variables. Method specs must verify comparability before computing statistics.
In controlled split tests, grouping or blocking isolates nuisance factors; observational history investigations must clarify grouping logic, potential confounders, and evidentiary bounds. Applicable methods depend on the task and data. NIST guidance on Block Designs explains why comparative studies must control for baseline conditions.
Statistical comparisons can evaluate differences; professional interpretation is still needed to determine what those differences mean.NIST Introduction to ANOVAillustrates multi-factor evaluation; method selection must satisfy underlying statistical prerequisites.
How a Recommendation Deconstructs Layer by Layer
Illustrative recommendation: Prioritize checking the relevant state of chamber B after this maintenance cycle and arrange reference wafers under the same conditions. This is a check recommendation: no component fault is established, and no unvalidated tuning value is directly proposed.
- Observation:The abnormal group shows increased edge detections; original images, regions, and inspection conditions are available for review.
- Comparison:Under checked comparable conditions, regional statistics differ for a group of materials; inputs, definitions, and run results are inspectable.
- Candidate Correlation:Affected wafers share processing in Chamber B within a bounded timeframe; supporting and opposing lots are logged.
- Unresolved Gaps:Alternative explanations, including maintenance, material, and inspection changes, have not all been ruled out.
- Next Steps:Perform checks or controlled verification within site permissions, using new data to distinguish candidate explanations.
The platform enables engineers to trace from recommendations back through supporting nodes and inspect intermediate gaps. Graph integrity derives from recorded empirical links, not merely coloring every node verified.
Evidence Graphs Organize Records; Method Specs Guide Reasoning
An evidence graph connects raw images, analytical inputs, execution logs, outputs, hypotheses, and recommendations. Edges represent explicit provenance and support relations, clearly distinguishing 'computed from this data' from 'proves this root cause.'
Method specs define how investigations proceed, what evidence is required, and what conclusions are supported. The graph organizes the actual process but does not replace physical validation.
Raw datasets need not be duplicated entirely into graph displays. Large image maps link via indices and coordinate bounding boxes; versions and access controls persist. Preserving 'currently unverified' states is central to white-box transparency.
Empowering Engineers to Correct, Override, and Take Over
Engineers may find that a reference is wrong, inspection coverage differs, or an assumption does not match site conditions. These corrections should affect subsequent plans and reports, with executed results, results awaiting recalculation, and withdrawn judgments clearly distinguished.
When fresh split data returns, compare baseline conditions and evaluate whether anomaly levels improved. Fresh evidence can strengthen, weaken, or rewrite recommendations; critical decisions follow fab sign-off protocols.
White-box architecture ensures human engineering judgment remains in command, while autonomous systems handle repetitive data retrieval, calculation, and documentation. Transparent processes make automation auditable, correctable, and safe.
Checklist for Validating White-Box Delivery
- Can you trace every recommendation back to specific wafer maps, recipe versions, and execution logs?
- Can you trace every number back to explicit formulas, measurement units, and denominators?
- Are applicability prerequisites and alternative hypotheses clearly stated for each selected method?
- Does the report clearly display contradictory evidence and unexamined gaps alongside supporting data?
- When an input assumption is corrected, does the system transparently update affected findings and recommendations?
These are rigorous delivery benchmarks, not marketing claims. Full evidence trails and live fab diagnostics require evaluation in agreed testbeds; current interactive capabilities are detailed in Scope Documentation.