§4 — Geometry and inference How much geometry you supply, and what the library infers when you don't
buildWaferMap infers whatever geometry you leave out, working backwards from the extent of your data. This page is that one question from three angles: how much you supply (how the map changes as dieConfig and waferConfig are filled in), when inference alone is not enough (data that does not span the whole wafer, where the extent is a misleading guide), and how you get told when the library knows the geometry is a guess. Cards A–G are all built from one identical results array.

Inference levels — same data, different geometry context A — no geometry, normalized units. B — die size only, diameter inferred. C — diameter only, pitch estimated, notch visible. D — fully specified with a 5 mm edge exclusion band (dimmed dies are excluded from yield).

A — grid positions only
Neither provided. Pitch inferred by nearest-neighbour step analysis. units: 'normalized' — proportionally correct but not in mm.
B — die size provided
dieConfig: { width: 8, height: 12 } — diameter inferred from grid extent × pitch. units: 'mm'
C — diameter provided
waferConfig: { diameter: 300 } — die pitch estimated from diameter ÷ grid extent. Notch visible. units: 'mm'
D — fully specified + edge exclusion
diameter: 300, notch: bottom, edgeExclusion: 5 mm, die: 8×12 mm. Dimmed dies fall within the 5 mm exclusion band and are excluded from yield.

Centre anchoring — when inference needs help, and when it doesn't Inference cannot tell a small full wafer apart from a slice of a big one. E — a tested half-wafer with no geometry is mistaken for a small full wafer and mis-centred. F — supplying waferConfig.center (the prober coordinate of the wafer centre) anchors it correctly. G — sparse data is different: positions are missing but the extent still reaches the wafer edge, so centre and diameter resolve without a hint.
The notes under each card read result.inference.warnings directly. Hover card E and you will also see the library's own ⚠ indicator in its toolbar — it raises partial-coverage and now says so on screen, without the page doing anything (see the next section).

E — partial, inferred (wrong)
Half wafer, no geometry. The right-half data is treated as a small full wafer and re-centred on its own midpoint.
F — partial, anchored (correct)
Same half + waferConfig.center: { x: 0, y: 0 }, diameter 300, die 8×12 mm. center anchors prober (0,0) to the true wafer centre, so the tested half sits on the right side of a full 300 mm wafer.
G — sparse, inferred (correct)
Every other row & column; die 8×12 mm, no center. Positions are missing across the whole wafer, but the extent still reaches the edge — so the centre and diameter resolve correctly without a center hint.

Warnings the library surfaces itself Bad geometry is only worth detecting if somebody is told. The library raises structured advisories — result.warnings from inference, summary.stats.warnings from analysis — and now shows them itself: a ⚠ indicator appears in the toolbar only when there is something to say. It is not a toast; these are persistent conditions about whether the map can be trusted, so the explanation stays retrievable. H — an analysis advisory (amber ⚠). I — the opt-out for apps with their own notification UI.

H — analysis advisory (warning)
300 tests per die, above the analysis cap. analyzeWaferMap computed no test findings at all — a silent absence, since nothing throws and the map renders fine. Severity warning (⚠ amber): what is drawn is correct, a feature just produced nothing. Geometry advisories are error (⛔ red) instead, because the dies themselves may be misplaced.
I — host owns presentation
warnings: { display: false, onWarning } — no toolbar indicator, but the library still collects, de-duplicates and severity-orders, then hands the list over. The box below was rendered by this page, not by wmap. Use this when your app already has a notification system; use collectWarnings if you want the same set without mounting a map at all.
(waiting for onWarning…)