Fab Utilization Ledger: Wafer-Start Loss Attribution for Device Fabs

October 30, 2026

Get this White Paper in PDF

VERTICAL-DRIVEN ARCHITECTURES · SEMICONDUCTORS

Fab Utilization Ledger

A system design for device fab engineering leads, operations, yield and quality managers, and the engineers who would build it. It shows how a silicon carbide device fab can see where wafer starts are lost and why, respond to excursions with evidence already assembled, and keep every recipe decision on the qualification path.

THE CASE IN BRIEF

  • An underused fab carries a cost that is recorded throughout the factory but assembled nowhere.
  • Lot history, tool state, recipes, wafer maps, defect scans, test results, substrate genealogy and order mix each sit in a separate system.
  • No existing view can trace a lost wafer start back through the tools it waited for to the substrate lot it came from, and rank the cause.
  • During excursions, engineers spend their time reconciling data instead of deciding, and between excursions the loss accrues unseen.
  • Fab Utilization Ledger projects every source onto one model inside the fab's perimeter, producing a weekly loss ledger by cause and excursion briefs assembled in minutes.
  • Recommendations never bypass change control: the model proposes, deterministic code commits and every recipe-adjacent finding goes through the quality team.

WHY THIS MATTERS

Lost starts are the largest cost nobody can see. When a fab runs well below its wafer-start capacity, underutilization becomes a recurring charge, and its causes sit in data that is never joined.

Excursions are spent assembling evidence. Engineers write scripts to pull lot history, tool state and recipe changes together before any analysis can begin.

Yield attribution needs the substrate's history. Without linking wafer maps and probe results back to the substrate lot and growth run, incoming material and chamber pairing cannot be ranked as causes.

And process data is sensitive IP. Wafer maps, recipes and tool logs fall under trade controls and customer expectations, so the analysis must run inside the operator's own perimeter on weights it holds.

This creates a structural exposure.

  • The manufacturing execution system records holds and scrap but not their causes.
  • Dispatch data shows where lots wait but not why.
  • Wafer maps and probe results are not linked to the substrate lots they came from.
  • Engineers rebuild the same joins by hand every time an excursion starts.
  • A parallel data lake would fork the truth the fab has already governed.
  • Any recommendation that touches a qualified recipe risks becoming a compliance incident.

Ledger lost wafer starts weekly, not reconcile them during excursions.

Every loss is attributed to a cause, every brief arrives assembled, and every decision stays with a named engineer.

WHAT YOU'LL LEARN

Inside the architecture, you'll find:

  • Why an underused fab carries a cost that is recorded everywhere and assembled nowhere
  • How eight fab systems each see one slice of the loss, and the join none of them can make
  • The constraints that bind the design: sovereignty, building on the governed platform, an untouched cleanroom, the qualification path and capital discipline
  • Three scoping decisions and what each buys, from a projection ontology to normal-only anomaly training
  • What the design chose against, including a parallel data lake and a hosted frontier API
  • The layered stack from eight sources through two adapter families to six surfaces
  • The sixteen-object model, with the substrate lot shown in its recorded form
  • How streaming subscriptions to tool and dispatch events let excursion briefs assemble in minutes
  • Why all inference runs on one operator-owned node in the fab's IT hall, with the frontier model memory arithmetic
  • The four open-weight models and why each license lets the fab hold its own weights
  • How anomaly detection finds yield issues on the fab's own normal wafer maps before any defect-labeling program exists
  • How the rollout proves the joins on one real production week before any model runs
  • The adoption measures, six named failure modes, lessons the design encodes and the questions still open
  • How Praxis contextualized the requirement, read it through eight lenses and reasoned every choice in the design

DOWNLOAD THE ARCHITECTURE

Read the complete architecture, from the join no fab system can make, through the object model, ingestion, inference placement and model register, to a gated two-phase rollout and the reasoning Praxis recorded for every choice.

A fab that can see where every wafer start is lost, and why, can direct its engineers to the causes that matter most. That intelligence compounds best inside the perimeter where the wafers are made.

Contributors

CodeNinja Engineering Team

Designed with Praxis