`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…)