FabYield-PM

Evidence-bounded GPT-5.6 investigation for semiconductor yield teams

Comment

Inspiration

FabYield-PM was built by an engineer with prior experience in semiconductor manufacturing, including hands-on work in etch process development and advanced semiconductor process integration.

That experience shaped the central principle behind this project:

In yield engineering, honesty is more important than confidence.

A process alarm can tell an engineer that something changed. It does not automatically prove why it changed, how much yield was affected, or whether maintenance should be performed.

In semiconductor manufacturing, a plausible but unsupported explanation can be costly. It can lead to unnecessary chamber intervention, wasted engineering effort, production downtime, or the wrong corrective action.

I wanted to build an AI system that does not simply generate the most convincing root-cause narrative. It should clearly separate:

  • what was directly observed;
  • what was calculated by deterministic code;
  • what was interpreted by a model;
  • what remains unknown;
  • what evidence should be collected next;
  • what still requires a human decision.

That became FabYield-PM:

An evidence-bounded investigation workbench for semiconductor yield teams.

The goal is not to make AI sound certain.

The goal is to help an engineer move from an alarm to the next defensible investigation step.

What FabYield-PM Does

FabYield-PM combines deterministic semiconductor analysis, bounded GPT-5.6 reasoning, browser-local data validation, and human-controlled decision support.

The project has three complementary product surfaces:

  1. a public BOSCH plasma-etch data investigation workspace;
  2. a browser-local canonical export workflow;
  3. a simulation workbench with an interactive Digital Twin.

Each surface serves a different evidence boundary.

The real-data workspace demonstrates what can be concluded from a public experimental dataset.

The connected workspace demonstrates how sensitive manufacturing exports can be validated without uploading them.

The simulation workspace demonstrates the complete cross-process investigation flow when linked evidence is available.

1. Public BOSCH Plasma-Etch Data Investigation

The /real workspace analyzes a public BOSCH plasma-etching dataset containing:

  • 42,535 canonical wafer-measurement records;
  • 10 lots;
  • 90 wafers;
  • 5 measurement metrics;
  • experimental observations released under CC BY 4.0.

Before GPT-5.6 is involved, FabYield-PM performs deterministic analysis.

The system:

  • identifies engineering outlier candidates using median/MAD-based robust screening;
  • recomputes Welch statistics using independent wafer means;
  • avoids treating repeated measurements from the same wafer as independent samples;
  • displays lot-level statistics;
  • presents real per-wafer minimum, mean, and maximum profiles;
  • preserves dataset provenance and licensing;
  • distinguishes an outlier candidate from a confirmed physical cause.

This distinction is important.

An unusual measurement pattern is evidence that something deserves investigation. It is not automatically evidence of a specific chamber fault, process source, yield loss, or maintenance requirement.

GPT-5.6 investigation

For an allowlisted BOSCH candidate, GPT-5.6 performs a bounded investigation using exactly three same-source, read-only tools:

  1. get_candidate_statistics
  2. get_wafer_profile
  3. get_source_boundary

Deterministic code remains authoritative for:

  • candidate identity;
  • numerical statistics;
  • observation direction;
  • wafer-profile facts;
  • source identifiers;
  • evidence hashes;
  • provenance;
  • claim availability;
  • safety boundaries.

GPT-5.6 is used where model reasoning adds value:

  • interpreting the observed pattern;
  • ranking plausible explanations;
  • separating supporting and contradicting evidence;
  • identifying missing evidence;
  • defining a falsification check;
  • proposing one bounded next investigation step.

The model does not generate the underlying statistics and does not decide which claims are available.

After the tool loop, a deterministic verifier checks:

  • strict output-schema compliance;
  • completion of all required tools;
  • candidate consistency;
  • provenance consistency;
  • current-run evidence references;
  • evidence hashes;
  • code-owned observation facts;
  • claim-tier boundaries.

Provider failures, invalid tool calls, schema failures, citation failures, and unsupported claims return visible typed errors.

A mock answer is never substituted for a failed user-triggered GPT investigation.

The honest gates are part of the demo

The BOSCH dataset contains real plasma-etch measurements, but the tracked export does not contain linked:

  • upstream process genealogy;
  • equipment and chamber history;
  • final yield outcomes;
  • maintenance records.

FabYield-PM therefore keeps the following conclusions explicitly unavailable:

  • confirmed physical-source attribution;
  • quantified yield impact;
  • maintenance recommendation.

The system still provides useful engineering value.

It can identify an unusual candidate, organize the available evidence, compare possible explanations, show what contradicts them, and recommend the next falsifiable check.

It simply refuses to cross the boundary that the data cannot support.

The frozen release also includes one sanitized, accepted GPT-5.6 provider receipt for BOSCH-LOT-01:oxide_etch.

That receipt demonstrates one real provider trace with all three read-only tools completed. It is not presented as full-suite semantic validation, independent fab validation, or proof of real-fab root-cause accuracy.

2. Browser-Local Canonical Export Analysis

Real semiconductor manufacturing data often contains proprietary information about products, recipes, equipment, yields, and process history.

Uploading those records to an external service may be unacceptable.

The /connected workspace was designed around that constraint.

An engineer can select a canonical package containing:

  • manifest.json
  • operations.jsonl
  • measurements.jsonl
  • baselines.jsonl

The selected files are processed entirely in browser memory.

There is:

  • no file upload;
  • no server persistence;
  • no GPT egress;
  • no application API request;
  • no equipment write path.

Before any screening result is produced, FabYield-PM validates the complete package.

It checks:

  • duplicate operation IDs;
  • duplicate measurement IDs;
  • source-record uniqueness;
  • event-time ordering;
  • process-sequence ordering;
  • lot and wafer continuity;
  • operation-to-measurement linkage;
  • unit validity;
  • baseline-unit consistency;
  • provenance consistency;
  • record coverage;
  • computability.

A valid package produces a deterministic screening receipt containing:

  • process step;
  • metric;
  • lot and wafer;
  • event time;
  • baseline value;
  • tolerance;
  • result status;
  • supporting source-record identifiers.

A damaged or inconsistent package is quarantined before analysis.

The result becomes:

  • QUARANTINE
  • NOT EXECUTED

This is not just an error message.

It demonstrates a core product principle: invalid data should not silently flow into an AI investigation.

The browser safety workflow also verifies that local validation produces no application request and no external data egress.

This provides a practical pattern for sensitive manufacturing environments:

Validate and screen locally before deciding whether any bounded evidence should leave the engineer’s device.

3. Simulation Workbench and Digital Twin

The main simulation workspace demonstrates the complete investigation workflow when linked cross-process evidence exists.

It includes:

  • matched manufacturing context;
  • process and metrology signals;
  • SPC detectors;
  • source and contributing-step hypotheses;
  • evidence-linked explanations;
  • competing hypotheses;
  • explicit abstention cases;
  • intervention comparisons;
  • a human decision panel;
  • an interactive Digital Twin.

The deterministic statistics engine includes:

  • Welch’s t-test;
  • Hedges’ g;
  • Welch confidence intervals;
  • CUSUM;
  • EWMA;
  • chamber ANOVA;
  • robust modified z-score screening.

Attribution remains separate from statistical inference.

Structured evidence keys connect observations to hypotheses, and named score and margin gates determine whether a source conclusion can be displayed or must be withheld.

Interactive Digital Twin

The Digital Twin visualizes a fictional five-position process route:

  • Photo Track;
  • Scanner;
  • ADI;
  • Etch;
  • AEI.

It displays:

  • equipment status;
  • alarm severity;
  • the detection position;
  • the candidate-source position;
  • an RCA trace across the process route;
  • evidence associated with each node.

The Digital Twin is deliberately labeled as simulation.

Its purpose is to help a human understand the investigation state. It is not an equipment-control interface.

The Review PM Decision control only navigates to the existing human-review panel.

It does not:

  • approve maintenance;
  • create a work order;
  • change a recipe;
  • control equipment;
  • write to MES or CMMS;
  • execute a production action.

Human approval is always required, and execution status remains not_executed.

The simulation workspace demonstrates the complete decision-support experience without pretending that a public web application is connected to a real fab.

How I Built It

FabYield-PM is built with:

  • Next.js;
  • React;
  • TypeScript;
  • OpenAI Responses API;
  • GPT-5.6;
  • strict function tools;
  • strict structured outputs;
  • deterministic statistical analysis;
  • deterministic provenance verification;
  • Playwright browser testing;
  • Three.js;
  • Vercel.

The architecture deliberately separates fact generation from model interpretation:

Canonical or public evidence
        ↓
Deterministic statistics and observations
        ↓
Three strict read-only tools
        ↓
GPT-5.6 bounded investigation
        ↓
Deterministic provenance and claim verifier
        ↓
Human-reviewed result

GPT-5.6 is not treated as the source of truth for:

  • numerical statistics;
  • source identifiers;
  • evidence provenance;
  • safety gates;
  • claim availability;
  • equipment actions.

The model can interpret evidence, compare hypotheses, and propose a next check.

It cannot rewrite the deterministic facts, manufacture missing evidence, unlock an unavailable claim, or execute an action.

How Codex Helped

Codex was my primary engineering partner during Build Week.

Before the event, FabYield-PM already had a deterministic semiconductor Patterning workbench.

During Build Week, Codex helped transform it into a verified AI product by accelerating:

  • repository-wide architecture analysis;
  • OpenAI Responses API integration;
  • strict function-tool design;
  • structured-output contract design;
  • BOSCH public-data adapters;
  • current-run evidence verification;
  • source and license tracking;
  • data-quality enforcement;
  • wafer-genealogy partitioning;
  • browser-local canonical export processing;
  • fail-closed API behavior;
  • public read-only safeguards;
  • responsive visual QA;
  • Playwright browser verification;
  • release evidence and regression testing.

The most valuable contribution was not simply generating code.

Codex repeatedly identified mismatches between what the product claimed and what the implementation actually guaranteed.

For example, the system was hardened to:

  • evaluate every measurement linked to an operation rather than only the first;
  • prevent evidence propagation across unrelated wafer genealogies;
  • require provenance agreement between manifests and measurements;
  • check event and process-sequence continuity;
  • quarantine invalid packages before analysis;
  • prove that browser-local validation creates zero API or external-egress requests;
  • require GPT observations to match code-owned deterministic preflight facts;
  • return typed failures instead of silently falling back.

These decisions became automated regression gates rather than informal documentation.

Challenges I Faced

Deciding what GPT-5.6 should not do

The hardest challenge was defining the boundary where the model must stop.

It was easy to produce an impressive root-cause narrative.

It was much harder to build a system that visibly refuses unsupported source, yield, or maintenance conclusions while still giving the engineer a useful next step.

Separating evidence classes

FabYield-PM contains several different types of evidence:

  • public experimental observations;
  • transparent simulation;
  • deterministic evaluation fixtures;
  • browser-local sample packages;
  • sanitized live-provider receipts.

These evidence classes cannot be presented as though they prove the same thing.

Much of the engineering work focused on keeping those boundaries explicit in the code, interface, documentation, and release artifacts.

Working with sensitive-data constraints

Semiconductor manufacturing data is rarely suitable for unrestricted cloud upload.

That constraint motivated the browser-local Connected workflow and made no-egress behavior a tested requirement rather than a marketing statement.

Verifying the complete product experience

Passing unit tests was not enough.

The release also verifies:

  • responsive layouts;
  • keyboard-accessible alternatives;
  • reduced-motion behavior;
  • WebGL fallback;
  • Digital Twin lifecycle;
  • public read-only behavior;
  • quarantine states;
  • absence of production writes;
  • visible fail-closed errors.

The frozen release contains:

  • 247 automated tests;
  • a 1,000-scenario deterministic self-check;
  • offline agent-contract evaluations;
  • browser interaction and safety verification;
  • one accepted single-case GPT-5.6 provider receipt.

Accomplishments

I am proud that FabYield-PM goes beyond a prompt demonstration.

The final project includes:

  • a working public BOSCH data workspace;
  • robust screening over real experimental measurements;
  • independent-wafer statistical analysis;
  • a verified GPT-5.6 read-only investigation loop;
  • deterministic provenance and claim verification;
  • explicit unavailable and abstention states;
  • browser-local manufacturing-export validation;
  • a quarantine path that prevents invalid analysis;
  • an interactive simulation-only Digital Twin;
  • human-only decision controls;
  • fail-closed API behavior;
  • 247 automated tests;
  • a 1,000-scenario deterministic reliability check;
  • a frozen release with traceable evidence boundaries.

What I Learned

This project reinforced that trustworthy industrial AI is not mainly about making a model more capable or more confident.

It is about controlling the transitions between:

  • observation;
  • statistical result;
  • interpretation;
  • hypothesis;
  • evidence;
  • decision;
  • execution.

GPT-5.6 was most useful when given a narrow and structured role:

  • read bounded evidence;
  • compare explanations;
  • identify contradictions;
  • state missing evidence;
  • propose a falsifiable next step.

Codex was most useful when those principles had to become enforceable software contracts, tests, and release evidence.

I also learned that abstention can be a product feature.

When the evidence is weak, the correct output is not a more polished explanation.

It is a clear statement of what cannot yet be concluded and what evidence should be collected next.

Current Limitations

FabYield-PM is not presented as a validated production-fab root-cause system.

The public datasets used by the project do not share governed identifiers for products, lots, wafers, operations, equipment, recipes, yield results, and maintenance events.

For that reason, the project deliberately avoids constructing a premature unified ontology across unrelated datasets.

Creating a knowledge graph without real shared lineage would encode assumed relationships rather than observed ones.

Instead, FabYield-PM currently uses:

  • a canonical manufacturing schema;
  • a controlled process taxonomy;
  • explicit source manifests;
  • provenance types;
  • event-time boundaries;
  • dataset-specific claim limits.

Each public dataset remains an independent evidence track.

A richer ontology would become valuable when the system is connected to organization-specific MES, FDC, metrology, yield, and maintenance systems with shared identifiers and governed lineage.

Until then, the system does not invent connections that the data cannot prove.

What’s Next

A production deployment would require:

  • organization-specific canonical data contracts;
  • approved read-only manufacturing connectors;
  • identity and access controls;
  • deidentification policies;
  • governed baseline cohorts;
  • MES and FDC lineage;
  • linked metrology and yield outcomes;
  • maintenance-history integration;
  • engineer review and audit workflows;
  • independent semiconductor-domain validation;
  • prospective measurement of operational impact.

The next step is not autonomous equipment control.

It is stronger evidence, better data linkage, and carefully governed human review.

Final Summary

FabYield-PM is not a root-cause oracle.

It is a working demonstration of how AI can participate in a high-stakes manufacturing investigation without taking ownership of facts or actions that it cannot justify.

It combines:

  • real public semiconductor measurements;
  • deterministic statistical analysis;
  • bounded GPT-5.6 reasoning;
  • strict evidence verification;
  • browser-local sensitive-data analysis;
  • explicit abstention;
  • a simulation-only Digital Twin;
  • human-controlled decisions.

The central design principle is simple:

Deterministic facts, bounded model reasoning, explicit abstention, and human-controlled action.

FabYield-PM helps an engineer move from an alarm to the next defensible investigation step.

It does not pretend that every alarm already has an answer.

Built With

Share this project:

Updates