Measure

STDF Analytics

Production data is the ground truth of a test program, and it arrives as STDF V4 binaries nobody wants to open by hand. ATE·IQ parses them natively on the engineer's machine — yield, bins, Cpk, drift, wafer maps, outlier screens — and feeds the statistics back toward the program as proposals, never silent edits.

Overview

The parser is implemented from the STDF V4 record specification — record framing, byte offsets, optional-field rules, PRR/PTR pass-flag semantics — with no external Python or wasm dependency at runtime. Files arrive as .std or .std.gz, by direct upload or from a synced repository, and parse locally.

STDF library page with lot-to-lot trend and hard-bin drift — Fig. 1 — The STDF library for the TMP126 demo: 8 lots, 1,860 parts, 94.09% overall. The trend strip shows yield falling −22.4% first-to-last lot, and the hard-bin drift panel names the two bins responsible.

The library page is not just a file list. It carries a lot-to-lot yield trend and a hard-bin drift strip summed across lots, so a program that is slowly losing yield is visible before anyone opens a single lot.

The analysis tools

Every computation is a deterministic function over the parsed records. The same tools serve the STDF pages, the traceability dashboard's production hop, and the chat assistant — one implementation, no way for the surfaces to disagree.

Tool	What it computes
Lot summary	Lot, device, tester and program identity plus part count and yield, from the MIR and PCR records.
Yield summary	Hard- and soft-bin pareto and overall yield per lot.
Parametric statistics	Per-test mean, standard deviation, Cp and Cpk — from PTR and MPR records. Multi-pin parametric results are folded in, not silently excluded, so MPR-heavy programs do not show an empty grid.
Correlation	Cross-file trend for a single test across lots, plus first-fail and test-time paretos and a wafer map.
Outlier screen	Dynamic-PAT robust limits: median ± 6·(IQR/1.349). Flags parts that pass program limits but sit outside the population. Below 30 samples it reports insufficient data — never a fake "0 outliers".
Functional fails	Fail table from FTR records for pattern-based tests.
Limit drift	Joins PTR test numbers to the spec and program limits — the limits a lot actually ran versus the limits the program has now.

Fig. 2 — The dynamic-PAT outlier screen. The robust window uses median and IQR, so the population estimate is not dragged by the outliers it is trying to find.

Lot detail

Opening a lot gives the working view a product engineer reaches for first: per-site yield, the hard-bin pareto, the top failing tests with their Cpk, and a limit-drift table that reconciles what the lot ran against the spec and the program.

The site↔socket overlay maps each test site to a load-board socket, so a per-site yield skew can be read against the physical board rather than an abstract site number.

Wafer maps

Wafer-sort lots render as a die map with spatial-cluster detection. A quadrant failing at several times the wafer rate is flagged with its dominant bin — the difference between a random defect level and a process or probe-card signature.

Wafer map for lot TMP126-W04 with a detected fail cluster — Fig. 4 — Wafer W04: 225 dies, 95.11% yield. The detector flags one cluster — 11 continuity fails across 20 dies in the lower-right quadrant, 55% local fail rate against 4.89% for the wafer.

Feeding statistics back to the program

The loop does not stop at detection. propose_limit_update turns lot statistics into a proposed program limit pair — deterministically, with zero LLM calls.

Compute the lot statistics.
Mean and sigma for the chosen test across the selected lots, from the same parametric engine the lot pages use.
Propose a window.
Mean ± 4σ per side, clipped so a proposal can never exceed the spec limit. A side with no spec bound is only allowed to tighten.
Classify the move.
Each proposal is labelled tighten-guard-band, widen-within-spec, no-change, process-cannot-support (the population itself sits outside spec — an engineering flag, not a limits problem), or insufficient-data.
Present, never write.
The output is a proposal the engineer applies through the Limits sheet. The tool has no write path to the program, by design.

The proposal also reports which copy of the program its current limits came from — the live open workbook or an ingested snapshot — the same source attribution the traceability dashboard uses.

On the TMP126 demo

The demo project carries eight lots: four wafer-sort (W01–W04) and four final-test (L01–L04). These are genuine STDF V4 binaries read by the same parser a production file goes through — but the lots are synthesised for the demo, not silicon data, and the platform does not present them as a production result. They tell one story in two halves.

Wafer sort stays healthy. W04 yields 95.11% — and the wafer map still discloses what it found: one continuity cluster in the lower-right quadrant, flagged with its dominant bin rather than averaged away.

Final test drifts. Test 1100 — active supply current — degrades from Cpk 1.05 to 0.27 across L01→L04, taking L04 to 76.67% yield with 56 parts in a single fail bin. Because the lot is joined to the load board, the analysis hub names the board-side debug suspects for that test — U1, R2 and R9 — the first question a product engineer asks, answered from data that was already on disk.

Honest boundary .std.Z (LZW compression) is intentionally rejected with a clear error — Node's zlib has no LZW codec, so decompress externally to .std first. And parametric rows cached before the MPR fold-in keep their PTR-only statistics until the file is re-ingested; the tool does not silently recompute history.