Yoon Hwang

A metrology or sensor alarm in a chip fab stops a lot and its equipment until an engineer finds the cause. The chamber, a metrology tool, an upstream clean step, a faulty sensor and a single odd wafer all look alike on a control chart. Fab teams use fixed playbooks that run one sequence of checks. If an engineer holds a healthy chamber, the fab loses hours. If the engineer misses a real fault, the chamber keeps producing bad lots. FabTriage runs an agent on Meta’s Muse Spark that investigates these alarms step by step. The agent picks its evidence: the lot’s route, the four chambers side by side, a commonality test, trends, the maintenance log, sensor data and wafer maps segmented with SAM 3.1. It re-measures the lot on a second tool if the diagnosis hinges on the reading. Each claim in its disposition cites an evidence ID. A verifier returns any answer that quotes a number missing from the evidence or skips a playbook check. The engineer then approves the disposition, or rejects it with a note, and the agent investigates again. For a chamber held after maintenance, the agent also handles recovery: it reads the maintenance record and history, runs monitor wafers, sets a new recipe and releases the chamber. I tested it on a simulated CVD deposition area and wrote the success criteria before any run. On 70 held-out alarms the agent made the right call in all three runs (95% interval 94.8 to 100%); a fixed playbook got 78.6%. On 50 held-out recoveries it left 0.23 off-target lots per recovery, against 1.86 for the standard two-monitor-wafer rule. As I raised the noise, it kept its lead through level two, and at the hardest level it held equipment rather than miss faults. Each alarm costs about $0.07. The same agent runs on open weights through Muse Spark Open on Baseten. Live site: https://yhwang55.github.io/fabtriage/ Live console: https://fabtriage.onrender.com